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

[Michael S. Tsirkin]

On Fri, Mar 11, 2016 at 02:20:20PM +0000, Michael Brown wrote:
> 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.

About 2x the current one, won't it be?

> 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

For the host - likely no. But for the guest we can emulate 32 bit
CPUs, it's a question of setting an appropriate flag.

One can say "so don't do this" but this means qemu has to ship
both 64 and 32 bit ROMs, and somehow guess which one to
expose to guest.

Short term, I agree using cfg access + 32 bit ROM is likely best.


-- 
MST