Description of problem:
Based on a discussion about Qemus ability to work with Guests >1TB  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.
Version-Release number of selected component (if applicable):
Up to latest 4.3
100% - well it essentially is a feature request not an error
Steps to Reproduce:
1. try to control phys-bits through libvirt xml/api
No option exposed to do so.
Be able to control phys-bits
See the discussion on Launchpad  for more details of the qemu side of this.
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.
(In reply to sirswa from comment #1)
> 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.
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:
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:
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. :-)
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
Since I see some OpenStack names on the bug here, using this feature is already considered there via