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.
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.
(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.
Hello. 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:commandline> <qemu:arg value='-cpu'/> <qemu:arg value='host,host-phys-bits=on'/> </qemu:commandline> 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 https://gitlab.com/libvirt/libvirt/-/commit/e6c29f09e5b75d7a8d79ae670407060446282c78 in v8.7.0 Since I see some OpenStack names on the bug here, using this feature is already considered there via https://specs.openstack.org/openstack/nova-specs/specs/2023.1/approved/libvirt-maxphysaddr-support.html Thanks Dario!
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days