From: Filip Schauer <f.schauer@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server] Properly identify the CPU architecture of 32-bit VMs
Date: Wed, 13 Dec 2023 18:31:13 +0100 [thread overview]
Message-ID: <7d2ebfc9-7172-410a-be4c-1fc681d07e43@proxmox.com> (raw)
In-Reply-To: <93b6aa58-fea8-48ba-b007-a08fd02c734a@proxmox.com>
On 12/12/2023 12:48, Fiona Ebner wrote:
> Am 12.12.23 um 11:39 schrieb Filip Schauer:
>> It's actually not a different binary. qemu-system-i386 is a symlink that
>> points to qemu-system-x86_64. But still this does indeed break migration
>> between a node that has this patch applied and another node without the
>> patch.
>>
> Oh, okay. But then that's a bit surprising. From a quick glance, we do
> have some logic matching arch 'x86_64' specifically in CPUConfig.pm, so
> that might be it. E.g.:
>
>> my $pve_forced_flags = {};
>> $pve_forced_flags->{'enforce'} = {
>> reason => "error if requested CPU settings not available",
>> } if $cputype ne 'host' && $kvm && $arch eq 'x86_64';
This check does not make any difference in my case since $kvm is not set
when using a qemu32 CPU.
Not sure what causes this to break migration, not that it matters but
here are my results anyway.
Journal of an unpatched node when migrating a running VM with CPU type
qemu32 from a node with this patch v1 applied:
Dec 13 18:09:28 pve2 QEMU[124616]: KVM: entry failed, hardware error
0x80000021
Dec 13 18:09:28 pve2 QEMU[124616]: If you're running a guest on an Intel
machine without unrestricted mode
Dec 13 18:09:28 pve2 QEMU[124616]: support, the failure can be most
likely due to the guest entering an invalid
Dec 13 18:09:28 pve2 QEMU[124616]: state for Intel VT. For example, the
guest maybe running in big real mode
Dec 13 18:09:28 pve2 QEMU[124616]: which is not supported on less recent
Intel processors.
Dec 13 18:09:28 pve2 QEMU[124616]: EAX=00003433 EBX=0006880c
ECX=00002fa5 EDX=89817860
Dec 13 18:09:28 pve2 QEMU[124616]: ESI=898098c0 EDI=8980f758
EBP=00183aec ESP=00183ad0
Dec 13 18:09:28 pve2 QEMU[124616]: EIP=00292afa EFL=00200006 [-----P-]
CPL=0 II=0 A20=1 SMM=0 HLT=0
Dec 13 18:09:28 pve2 QEMU[124616]: ES =0030 00000000 ffffffff 00c09300
DPL=0 DS [-WA]
Dec 13 18:09:28 pve2 QEMU[124616]: CS =0020 00000000 ffffffff 00c09b00
DPL=0 CS32 [-RA]
Dec 13 18:09:28 pve2 QEMU[124616]: SS =0030 00000000 ffffffff 00c09300
DPL=0 DS [-WA]
Dec 13 18:09:28 pve2 QEMU[124616]: DS =0030 00000000 ffffffff 00c09300
DPL=0 DS [-WA]
Dec 13 18:09:28 pve2 QEMU[124616]: FS =0060 00023de0 0000ffff 00009300
DPL=0 DS16 [-WA]
Dec 13 18:09:28 pve2 QEMU[124616]: GS =0060 00023de0 0000ffff 00009300
DPL=0 DS16 [-WA]
Dec 13 18:09:28 pve2 QEMU[124616]: LDT=0000 00000000 00000000 00008200
DPL=0 LDT
Dec 13 18:09:28 pve2 QEMU[124616]: TR =0040 00025260 00000077 00008900
DPL=0 TSS32-avl
Dec 13 18:09:28 pve2 QEMU[124616]: GDT= 00184000 0000007f
Dec 13 18:09:28 pve2 QEMU[124616]: IDT= 00184080 000007ff
Dec 13 18:09:28 pve2 QEMU[124616]: CR0=80000011 CR2=00000000
CR3=00185000 CR4=00000000
Dec 13 18:09:28 pve2 kernel: set kvm_intel.dump_invalid_vmcs=1 to dump
internal KVM state.
Dec 13 18:09:28 pve2 QEMU[124616]: DR0=0000000000000000
DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
Dec 13 18:09:28 pve2 QEMU[124616]: DR6=00000000ffff0ff0 DR7=0000000000000400
Dec 13 18:09:28 pve2 QEMU[124616]: EFER=0000000000000000
Dec 13 18:09:28 pve2 QEMU[124616]: Code=0c 89 08 89 7a 0c 8b 45 0c 83 45
10 02 8b c8 2b cf 23 4a 08 <8b> 3a 8a 1c 0f 88 1c 07 40 41 ff 4d 10 83
7d 10 00 7f ed 3b 45 f4 8b 7d fc 89 45 0c 0f 8c
Journal of the patched node when migrating the same VM from an unpatched
node:
Dec 13 18:12:17 pve1 QEMU[125150]: qemu-system-i386: Unknown savevm
section or instance 'kvmclock' 0. Make sure that your current VM setup
matches your saved VM setup, including any hotplugged devices
Dec 13 18:12:17 pve1 QEMU[125150]: qemu-system-i386: load of migration
failed: Invalid argument
next prev parent reply other threads:[~2023-12-13 17:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-11 14:12 Filip Schauer
2023-12-11 14:37 ` Fiona Ebner
2023-12-12 10:39 ` Filip Schauer
2023-12-12 11:48 ` Fiona Ebner
2023-12-13 17:31 ` Filip Schauer [this message]
2023-12-14 9:13 ` Fiona Ebner
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=7d2ebfc9-7172-410a-be4c-1fc681d07e43@proxmox.com \
--to=f.schauer@proxmox.com \
--cc=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/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.