On Thu, Oct 29, 2020 at 03:55:30PM +, 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., ) or just
> using the same number of bits of the host (with mode='passthrough'/>).
>
> This in theory is already possible, but only in an hack-ish way, such as
> adding:
>
>
>
>
>
>
> 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 :|
