From: Borislav Petkov <bp@suse.de>
To: Brijesh Singh <brijesh.singh@amd.com>,
Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org,
Alistair Francis <alistair.francis@xilinx.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
"Daniel P . Berrange" <berrange@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Edgar E. Iglesias" <edgar.iglesias@xilinx.com>,
Eric Blake <eblake@redhat.com>,
kvm@vger.kernel.org, Marcel Apfelbaum <marcel@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Crosthwaite <crosthwaite.peter@gmail.com>,
Peter Maydell <peter.maydell@linaro.org>,
Richard Henderson <richard.henderson@linaro.org>,
Stefan Hajnoczi <stefanha@gmail.com>,
Thomas Lendacky <Thomas.Lendacky@amd.com>,
Alexander Graf <agraf@suse.de
Subject: Re: [PATCH v8 05/28] target/i386: add memory encryption feature cpuid support
Date: Mon, 12 Feb 2018 22:19:48 +0100 [thread overview]
Message-ID: <20180212211948.GK14422@pd.tnic> (raw)
In-Reply-To: <4a1f22d9-da2e-618b-1423-629817389948@amd.com>
On Mon, Feb 12, 2018 at 03:07:26PM -0600, Brijesh Singh wrote:
> In current implementation, when -cpu ...,+sev is passed without
> appropriate SEV configuration then we populate the Fn8000_001F CPUID but
> VMCB will not have SEV bit set hence a guest will be launched as
> non-SEV.
I think we should fail the guest init if sev is not really supported by
the host. Otherwise people might get mislead.
> > Changing existing CPU models is possible only on very specific
> > circumstances (where VMs that are currently runnable would always
> > stay runnable), and would require compat_props entries to keep
> > compatibility on existing machine-types.
>
> Ah I didn't consider that case. What is recommendation, should we create
> a new CPU Model (EPYC-SEV) ?
Can we please stop creating a new CPU model with every new CPUID feature
support added? This is just ridiculous.
If this is about live migration, then by all means, fail the migration
if the feature bits are not compatible. But replicating CPU models and
then adding one new differing feature doesn't make any sense.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
next prev parent reply other threads:[~2018-02-12 21:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 15:36 [PATCH v8 00/28] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 01/28] memattrs: add debug attribute Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 02/28] exec: add ram_debug_ops support Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 03/28] exec: add debug version of physical memory read and write API Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 04/28] monitor/i386: use debug APIs when accessing guest memory Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 05/28] target/i386: add memory encryption feature cpuid support Brijesh Singh
2018-02-12 18:38 ` Eduardo Habkost
2018-02-12 21:07 ` Brijesh Singh
2018-02-12 21:19 ` Borislav Petkov [this message]
2018-02-13 15:39 ` Brijesh Singh
2018-02-13 15:41 ` [Qemu-devel] " Borislav Petkov
2018-02-13 15:45 ` Dr. David Alan Gilbert
2018-02-12 15:36 ` [PATCH v8 06/28] machine: add -memory-encryption property Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 07/28] kvm: update kvm.h to include memory encryption ioctls Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 08/28] docs: add AMD Secure Encrypted Virtualization (SEV) Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 09/28] target/i386: add Secure Encrypted Virtulization (SEV) object Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 10/28] sev/i386: add command to initialize the memory encryption context Brijesh Singh
2018-02-12 18:57 ` Eduardo Habkost
2018-02-12 15:36 ` [PATCH v8 11/28] sev/i386: register the guest memory range which may contain encrypted data Brijesh Singh
2018-02-12 15:36 ` [PATCH v8 12/28] kvm: introduce memory encryption APIs Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 13/28] qmp: add query-sev command Brijesh Singh
2018-02-12 17:27 ` Eric Blake
2018-02-12 18:47 ` Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 14/28] hmp: add 'info sev' command Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 15/28] sev/i386: add command to create launch memory encryption context Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 16/28] sev/i386: add command to encrypt guest memory region Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 17/28] target/i386: encrypt bios rom Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 18/28] sev/i386: add support to LAUNCH_MEASURE command Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 19/28] sev/i386: finalize the SEV guest launch flow Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 20/28] hw/i386: set ram_debug_ops when memory encryption is enabled Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 21/28] sev/i386: add debug encrypt and decrypt commands Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 22/28] target/i386: clear C-bit when walking SEV guest page table Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 23/28] include: add psp-sev.h header file Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 24/28] sev/i386: add support to query PLATFORM_STATUS command Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 25/28] sev/i386: add support to KVM_SEV_GUEST_STATUS Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 26/28] qmp: add query-sev-launch-measure command Brijesh Singh
2018-02-12 15:37 ` [PATCH v8 27/28] tests/qmp-test: blacklist " Brijesh Singh
2018-02-13 16:44 ` Dr. David Alan Gilbert
2018-02-12 15:37 ` [PATCH v8 28/28] sev/i386: add migration blocker Brijesh Singh
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=20180212211948.GK14422@pd.tnic \
--to=bp@suse.de \
--cc=Thomas.Lendacky@amd.com \
--cc=agraf@suse.de \
--cc=alistair.francis@xilinx.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=brijesh.singh@amd.com \
--cc=cornelia.huck@de.ibm.com \
--cc=crosthwaite.peter@gmail.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=edgar.iglesias@xilinx.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=stefanha@gmail.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