Bug 1578278

Summary: Ability to control phys-bits through libvirt
Product: [Community] Virtualization Tools Reporter: Christian Ehrhardt <paelzer>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: ailan, dannf, jsuchane, kchamart, libvirt-maint, raistlin, sirswa, smooney
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-04-19 05:58:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Christian Ehrhardt 2018-05-15 07:41:18 UTC
Description of problem:
Based on a discussion about Qemus ability to work with Guests >1TB [1] it was identified that it might be wise to have libvirt be able to:
  a) add a setting to the XML to specify the phys-bits
  b) It should be possible for libvirt to check the host it's on can
     satisfy that requirement (enough HW phys bits)
  c) libvirt can check that if RAM > 2^phys-bits it can complain

It is known that (c) can't catch all, as it might still fail if RAM+rounding+pci+hotplug space goes over the limit. Figuring that limit out is tricky and should not be part of the scope here.

[1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1769053

Version-Release number of selected component (if applicable):
Up to latest 4.3

How reproducible:
100% - well it essentially is a feature request not an error

Steps to Reproduce:
1. try to control phys-bits through libvirt xml/api

Actual results:
No option exposed to do so.

Expected results:
Be able to control phys-bits

Additional info:
See the discussion on Launchpad [1] for more details of the qemu side of this.

Comment 1 sirswa@gmail.com 2019-08-28 02:55:41 UTC

We are hitting this bug. We have specialist hardwares including hi-memory hypervisors to run HPC workload on virtualised environment. This bug is affecting us at the machines which has more than 1TB of memory.

Comment 2 Eduardo Habkost 2019-08-28 14:16:31 UTC
(In reply to sirswa from comment #1)
> Hi
> We are hitting this bug. We have specialist hardwares including hi-memory
> hypervisors to run HPC workload on virtualised environment. This bug is
> affecting us at the machines which has more than 1TB of memory.

This bz# is not a bug, but a feature planned to make live migration ability more flexible.  The option might be useful to work around bugs or other limitations, though.

If you are seeing a bug related to large guests or large hosts, please send more details so we can investigate it.

Comment 5 Dario Faggioli 2020-10-29 15:30:25 UTC

Recently I had to deal with a VM with ~2.7 TB of RAM. The [open]SUSE QEMU package carries a patch for bumping the default maximum virtual address bits to 42 (from 40). Now, the last entry of the VM's e820 was this one:

    BIOS-e820: [mem 0x0000000100000000-0x000002b57fffffff] usable

Which, if I have computed correctly, is representable on 42 bits, so things should be fine. However, during boot, the VM shows this:

    L1TF: System has more than MAX_PA/2 memory. L1TF mitigation not effective

And if I look in /sys/devices/system/cpu/vulnerabilities/l1tf, I see this:

    l1tf: Vulnerable

This is because, while the RAM fits in MAX_PA=42, as soon as we take 1 bit off for PTE inversion, it does not fit any longer (in MAX_PA/2).

I understand that this is not critical per-se, but I think it's rather annoying for a user to see messages like the ones above, especially considering they're about vulnerabilities and security. And it's not necessarily easy for everyone to realize that L1TF is reported as vulnerable because QEMU is making the VM think that physical addresses are on 42 (or 40) bits.

So, I also think we need to be able to tweak this part of the VM configuration more easily, from libvirt. It's doable either by using specially modified CPU-models, or doing things like this, which are rather inconvenient:

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

I also believe that host-phys-bits=on should be QEMU's default when the user chooses host as CPU model, but that's for another bugzilla. :-)

Comment 13 Christian Ehrhardt 2023-04-19 05:58:53 UTC
I know we no more track libvirt issues in bugzilla but gitlab nowadays, but I couldn't find it over there.

To make this bug reflect latest changes I think it is worth to mention that (IMHO) this landed via
in v8.7.0

Since I see some OpenStack names on the bug here, using this feature is already considered there via

Thanks Dario!

Comment 14 Red Hat Bugzilla 2023-09-18 00:13:37 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days