all lists on lists.proxmox.com
 help / color / mirror / Atom feed
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





  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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal