From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Babu Moger <babu.moger@amd.com>,
pbonzini@redhat.com, richard.henderson@linaro.org,
weijiang.yang@intel.com, philmd@linaro.org, dwmw@amazon.co.uk,
paul@xen.org, joao.m.martins@oracle.com, qemu-devel@nongnu.org,
mtosatti@redhat.com, kvm@vger.kernel.org, mst@redhat.com,
marcel.apfelbaum@gmail.com, yang.zhong@intel.com,
jing2.liu@intel.com, vkuznets@redhat.com, michael.roth@amd.com,
wei.huang2@amd.com, bdas@redhat.com, eduardo@habkost.net,
qemu-stable <qemu-stable@nongnu.org>
Subject: Re: [PATCH v3] target/i386: Fix CPUID encoding of Fn8000001E_ECX
Date: Thu, 9 May 2024 15:11:14 +0100 [thread overview]
Message-ID: <ZjzZgmt-UMFsGjvZ@redhat.com> (raw)
In-Reply-To: <89911cf2-7048-4571-a39a-8fa44d7efcda@tls.msk.ru>
On Thu, May 09, 2024 at 04:54:16PM +0300, Michael Tokarev wrote:
> 03.05.2024 20:46, Babu Moger wrote:
> > Observed the following failure while booting the SEV-SNP guest and the
> > guest fails to boot with the smp parameters:
> > "-smp 192,sockets=1,dies=12,cores=8,threads=2".
> >
> > qemu-system-x86_64: sev_snp_launch_update: SNP_LAUNCH_UPDATE ret=-5 fw_error=22 'Invalid parameter'
> > qemu-system-x86_64: SEV-SNP: CPUID validation failed for function 0x8000001e, index: 0x0.
> > provided: eax:0x00000000, ebx: 0x00000100, ecx: 0x00000b00, edx: 0x00000000
> > expected: eax:0x00000000, ebx: 0x00000100, ecx: 0x00000300, edx: 0x00000000
> > qemu-system-x86_64: SEV-SNP: failed update CPUID page
> ...
> > Cc: qemu-stable@nongnu.org
> > Fixes: 31ada106d891 ("Simplify CPUID_8000_001E for AMD")
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
> > Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > ---
> > v3:
> > Rebased to the latest tree.
> > Updated the pc_compat_9_0 for the new flag.
>
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 08c7de416f..46235466d7 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -81,6 +81,7 @@
> > GlobalProperty pc_compat_9_0[] = {
> > { TYPE_X86_CPU, "guest-phys-bits", "0" },
> > { "sev-guest", "legacy-vm-type", "true" },
> > + { TYPE_X86_CPU, "legacy-multi-node", "on" },
> > };
>
> Should this legacy-multi-node property be added to previous
> machine types when applying to stable? How about stable-8.2
> and stable-7.2?
machine types are considered to express a fixed guest ABI
once part of a QEMU release. Given that we should not be
changing existing machine types in stable branches.
In theory we could create new "bug fix" machine types in stable
branches. To support live migration, we would then need to also
add those same stable branch "bug fix" machine type versions in
all future QEMU versions. This is generally not worth the hassle
of exploding the number of machine types.
If you backport the patch, minus the machine type, then users
can still get the fix but they'll need to manually set the
property to enable it.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-05-09 14:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-02 23:17 [PATCH v2] target/i386: Fix CPUID encoding of Fn8000001E_ECX Babu Moger
2024-03-22 19:18 ` Moger, Babu
2024-05-03 17:46 ` [PATCH v3] " Babu Moger
2024-05-04 11:58 ` Paolo Bonzini
2024-05-09 13:54 ` Michael Tokarev
2024-05-09 14:11 ` Daniel P. Berrangé [this message]
2024-05-10 8:05 ` Michael Tokarev
2024-05-10 8:10 ` Daniel P. Berrangé
2024-05-10 20:03 ` Moger, Babu
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=ZjzZgmt-UMFsGjvZ@redhat.com \
--to=berrange@redhat.com \
--cc=babu.moger@amd.com \
--cc=bdas@redhat.com \
--cc=dwmw@amazon.co.uk \
--cc=eduardo@habkost.net \
--cc=jing2.liu@intel.com \
--cc=joao.m.martins@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=michael.roth@amd.com \
--cc=mjt@tls.msk.ru \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=vkuznets@redhat.com \
--cc=wei.huang2@amd.com \
--cc=weijiang.yang@intel.com \
--cc=yang.zhong@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).