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

[Michael Brown]

On 11/03/16 14:57, Michael S. Tsirkin wrote:
>>> 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?

Roughly, yes.  It's also some complexity that I'd prefer not to 
introduce, given that this is an extremely niche use case and can be 
solved more simply (see below).

>> For virtual machines, is it an issue?  Are there CPUs that support VMX but
>> don't support long mode?
>
> 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.

OK, so this seems to be an issue that affects only 32-bit virtual 
machines, where the choice on 32-bit versus 64-bit is being made by qemu 
itself.

That would suggest that the simplest solution is to have qemu expose the 
correct ROM for the CPU architecture.  No guessing required, since qemu 
already knows which CPU architecture it is exposing to the guest.

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

I'd still prefer the driver to be written to abstract away the 
difference between ioremap() and cfg accesses, and to attempt the 
ioremap() first.  This seems like a relatively trivial change, and 
avoids crippling the driver performance unnecessarily.

Michael