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
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
