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. :-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1769053
Title:
Ability to control phys-bits through libvirt
To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1769053/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
