From: raistlin <1769053@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1769053]
Date: Thu, 29 Oct 2020 15:30:25 -0000 [thread overview]
Message-ID: <163480218309.25993.17258849993308709105.launchpad@loganberry.canonical.com> (raw)
In-Reply-To: 152541524728.557.4600864098110042577.malonedeb@gac.canonical.com
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 qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1769053
Title:
Ability to control phys-bits through libvirt
Status in libvirt:
Confirmed
Status in QEMU:
Invalid
Status in libvirt package in Ubuntu:
Triaged
Status in qemu package in Ubuntu:
Invalid
Bug description:
Attempting to start a KVM guest with more than 1TB of RAM fails.
It looks like we might need some extra patches:
https://lists.gnu.org/archive/html/qemu-discuss/2017-12/msg00005.html
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: qemu-system-x86 1:2.11+dfsg-1ubuntu7
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: Unity:Unity7:ubuntu
Date: Fri May 4 16:21:14 2018
InstallationDate: Installed on 2017-04-05 (393 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
MachineType: Dell Inc. XPS 13 9360
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-20-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash transparent_hugepage=madvise vt.handoff=1
SourcePackage: qemu
UpgradeStatus: Upgraded to bionic on 2018-04-30 (3 days ago)
dmi.bios.date: 02/26/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 2.6.2
dmi.board.name: 0PF86Y
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr2.6.2:bd02/26/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0PF86Y:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 13 9360
dmi.sys.vendor: Dell Inc.
To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1769053/+subscriptions
next prev parent reply other threads:[~2021-10-21 7:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <152541524728.557.4600864098110042577.malonedeb@gac.canonical.com>
2018-05-04 6:46 ` [Qemu-devel] [Bug 1769053] Re: Cannot start a guest with more than 1TB of RAM Daniel Axtens
2018-05-04 7:44 ` ChristianEhrhardt
2018-05-04 8:04 ` Daniel Axtens
2018-05-04 8:12 ` ChristianEhrhardt
2018-05-04 16:10 ` Dr. David Alan Gilbert
2018-05-04 16:14 ` Dan Streetman
2018-05-04 16:15 ` Dan Streetman
2018-05-04 16:19 ` Dan Streetman
2018-05-04 16:33 ` Dr. David Alan Gilbert
2018-05-07 10:33 ` ChristianEhrhardt
2018-05-08 8:37 ` Dr. David Alan Gilbert
2018-05-08 9:57 ` ChristianEhrhardt
2018-05-08 10:26 ` Dr. David Alan Gilbert
2018-05-08 10:48 ` Daniel Berrange
2018-05-08 11:23 ` Dr. David Alan Gilbert
2018-05-08 13:22 ` Gerd Hoffmann
2018-05-08 14:00 ` Dr. David Alan Gilbert
2018-05-15 1:16 ` David Coronel
2018-05-15 7:17 ` Christian Ehrhardt
2018-05-15 7:19 ` Christian Ehrhardt
2018-05-15 7:45 ` Christian Ehrhardt
2018-06-11 9:30 ` Christian Ehrhardt
2018-06-12 7:02 ` [Qemu-devel] [Bug 1769053] Re: Ability to control phys-bits through libvirt Launchpad Bug Tracker
2018-06-12 7:04 ` Christian Ehrhardt
2018-06-12 7:18 ` Launchpad Bug Tracker
2018-06-12 7:18 ` Christian Ehrhardt
2018-06-12 7:46 ` Launchpad Bug Tracker
2018-06-12 8:27 ` Christian Ehrhardt
2018-06-12 11:14 ` Launchpad Bug Tracker
2019-08-28 2:55 ` [Bug 1769053] sirswa
2019-08-28 14:16 ` ehabkost
2020-10-29 15:30 ` raistlin [this message]
2023-04-19 5:43 ` [Bug 1769053] Re: Ability to control phys-bits through libvirt Christian Ehrhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=163480218309.25993.17258849993308709105.launchpad@loganberry.canonical.com \
--to=1769053@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.