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).

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.

I've also mentioned this during my KVM Forum talk (slides 81, 82, from
here:

http://xenbits.xen.org/people/dariof/talks/Virtual%20Topology%20Friend%20or%20Foe.pdf)

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

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.

Basically, this works and can be used very much like the <cache/> element.

Ah, so, the series is RFC basically because the QEMU capability test is
failing. I think I may be failing at understanding how things should
work. Or maybe I "just" need to regenerate the files against which
capabilities themselves are checked (and if this is the case, I need to
understand how). Well, I'll keep looking into this, and try to figure it
out (but, if anyone has any hint, that's much appreciated :-P).

Feedback welcome.

Thanks and Regards
---
Dario Faggioli (2):
      Add support for specifying max physical address size.
      qemu: Add support for max physical address size

 src/qemu/qemu_capabilities.c                  |  2 +
 src/qemu/qemu_capabilities.h                  |  1 +
 src/qemu/qemu_command.c                       | 28 +++++++++++
 src/qemu/qemu_domain.c                        | 46 +++++++++++++++++++
 .../cpu-phys-bits-emulate.args                | 29 ++++++++++++
 .../cpu-phys-bits-emulate.xml                 | 20 ++++++++
 .../cpu-phys-bits-emulate2.args               | 30 ++++++++++++
 .../cpu-phys-bits-emulate2.xml                | 20 ++++++++
 .../cpu-phys-bits-emulate3.err                |  1 +
 .../cpu-phys-bits-emulate3.xml                | 20 ++++++++
 .../cpu-phys-bits-passthrough.args            | 29 ++++++++++++
 .../cpu-phys-bits-passthrough.xml             | 20 ++++++++
 .../cpu-phys-bits-passthrough2.err            |  1 +
 .../cpu-phys-bits-passthrough2.xml            | 20 ++++++++
 .../cpu-phys-bits-passthrough3.err            |  1 +
 .../cpu-phys-bits-passthrough3.xml            | 20 ++++++++
 tests/qemuxml2argvtest.c                      |  7 +++
 17 files changed, 295 insertions(+)
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate.args
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate.xml
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate2.args
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate2.xml
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate3.err
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-emulate3.xml
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough.args
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough.xml
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.err
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough2.xml
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.err
 create mode 100644 tests/qemuxml2argvdata/cpu-phys-bits-passthrough3.xml
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

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

On Wed, 2020-11-04 at 13:03 +0000, Daniel P. Berrangé wrote:
> On Thu, Oct 29, 2020 at 03:55:30PM +0000, Dario Faggioli wrote:
> > 
> > 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.
> 
Yeah, and as I said, we bump that 40 to 42 in our QEMU package. I guess
this is why not many people have bumped into this on our side either.

Until now that I bumped into it... So, sad to admit, but apparently 42
was not the answer in this case. :-P

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)