[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 05/28] target/i386: add memory encryption fea
From: |
Brijesh Singh |
Subject: |
Re: [Qemu-devel] [PATCH v8 05/28] target/i386: add memory encryption feature cpuid support |
Date: |
Tue, 13 Feb 2018 09:39:01 -0600 |
On Mon, Feb 12, 2018 at 3:19 PM, Borislav Petkov <address@hidden> wrote:
> 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.
>
>
Sure I will do that. We can simplify this patch if we don't fill the CPUID
for non SEV guest. I am thinking of doing something like this:
"If SEV configration is provided in QEMU command line then
automatically increase xlevel to 0x8000_001F and populate the EAX and EBX
registers"
> > > 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.
>
>
Yes, I think we should be able to avoid creating new CPU model to handle
this case.
I am leaning towards dropping this patch and implement logic to populate the
CPUID 0x8000_001F only when SEV is enabled. This should not require any
changes
in existing CPU model feature flag and live migration of existing guest
should work fine.
> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB
> 21284 (AG Nürnberg)
> --
>
>
- [Qemu-devel] [PATCH v8 00/28] x86: Secure Encrypted Virtualization (AMD), Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 03/28] exec: add debug version of physical memory read and write API, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 01/28] memattrs: add debug attribute, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 02/28] exec: add ram_debug_ops support, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 04/28] monitor/i386: use debug APIs when accessing guest memory, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 05/28] target/i386: add memory encryption feature cpuid support, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 07/28] kvm: update kvm.h to include memory encryption ioctls, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 06/28] machine: add -memory-encryption property, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 09/28] target/i386: add Secure Encrypted Virtulization (SEV) object, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 08/28] docs: add AMD Secure Encrypted Virtualization (SEV), Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 10/28] sev/i386: add command to initialize the memory encryption context, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 11/28] sev/i386: register the guest memory range which may contain encrypted data, Brijesh Singh, 2018/02/12
- [Qemu-devel] [PATCH v8 12/28] kvm: introduce memory encryption APIs, Brijesh Singh, 2018/02/12