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 :|