[ipxe-devel] [PATCH 4/4] [virtio] Add virtio-net 1.0 support

[Michael Brown]

On 11/03/16 13:35, Michael S. Tsirkin wrote:
>>> Thinking more about it, I think it's a good idea to
>>> leave the mapping infrastructure in place, but
>>> maybe only do the CFG approach as the first step.
>>>
>>> Once code is upstream and works, we can add
>>> faster BAR/IO support later.
>>
>> Apologies for a naive question: since we need a 64-bit iPXE build for
>> proper 64-bit BAR support, does it mean that we would have to ship two
>> .rom files with QEMU, one for 32-bit guests and one for 64-bit guests?

In terms of the virtio-net driver: my preference would be for it to 
first attempt an ioremap() of the PCI BAR.  This will fail if the BAR is 
unmappable for any reason (including being unmappable because the BAR is 
assigned above 4GB on a 32-bit system).  If the ioremap() fails, then 
the virtio-net driver should fall back to using cfg space accesses.

The difference between ioremap()ed and cfg space operations should be 
abstracted behind some common wrapper function with a name such as 
virtio_writel(), so that the main body of the code does not need to care 
which mechanism is being used.

This approach would allow for fast operation on 64-bit guests and on 
32-bit guests with less than 4GB of RAM (in which the BAR will probably 
be mapped below 4GB even if it's a 64-bit BAR).

> Maybe include both binaries in the rom, and add a wrapper selecting
> the correct part of the ROM depending on the CPU?
> 1. start wrapper
> 2. check cpuid for 64 bit extensions
> 3. run 32 or 64 bit binary
>
> A bit wasteful but rather easy to implement.

That would result in a rather large ROM.

For physical hardware, this isn't an issue.  The amount of hardware that 
has both a 32-bit CPU and PCI cards that have BARs large enough to be 
mapped above 4GB is vanishingly small.  I would not be surprised if no 
such hardware exists.

For virtual machines, is it an issue?  Are there CPUs that support VMX 
but don't support long mode?

Michael