[RFC PATCH 0/2] Handle physical address bits

Dario Faggioli dfaggioli at suse.com
Thu Oct 29 15:55:30 UTC 2020

Hello everyone,

These patches let one specify how wide the physical addresses are, in

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:


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


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

This in theory is already possible, but only in an hack-ish way, such as

 <qemu:arg value='-cpu'/>
 <qemu:arg value='host,host-phys-bits=on'/>

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
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

More information about the libvir-list mailing list