On Thu, Oct 29, 2020 at 03:55:30PM +0000, Dario Faggioli wrote:
Hello everyone,
These patches let one specify how wide the physical addresses are, in bits.
Using current QEMU's default of 40 may limit the amount of RAM the guest can see (which is the reason why, in our packages, we bump that to 42; and as far as I've understood from reading some old mailing list threads on the subject, other downstreams do something similar).
In RHEL we provide custom machine types which set host-phys-bits=on by default, which is why making it configurable in libvirt hasn't been a high priority previously.
It also can cause other problems, such as the one described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1578278#c5
Basically, the VM thinking and reporting to the user that L1TF is unmitigated, because while its RAM may fits in MAX_PHYS_ADDR (e.g., equal to 42 or 40) it does not fit in MAX_PHYS_ADDR/2, which is necessary for PTE inversion to be effective.
Yep, that's not nice.
The series alleviates the problem by providing an user with an easy way to either specify an arbitrary number of physical address bits bits for the VM (with, e.g., <maxphysaddr mode='emulate' bits='42'/>) or just using the same number of bits of the host (with <maxphysaddr mode='passthrough'/>).
This in theory is already possible, but only in an hack-ish way, such as adding:
<qemu:commandline> <qemu:arg value='-cpu'/> <qemu:arg value='host,host-phys-bits=on'/> </qemu:commandline>
But this is super inconvenient. :-)
And explicitly unsupported in a production deployment, so not a viable solution except for experimentation.
I have not done it such as host-phys-bits=on is automatically added when using cpu-passthrough as CPU model, as I think that that actually belongs in QEMU.
Agreed, I think I raised that as a suggestion before too. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|