From mboxrd@z Thu Jan  1 00:00:00 1970
From: Borislav Petkov <bp@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
Message-ID: <20180212211948.GK14422@pd.tnic>
References: <20180212153715.87555-1-brijesh.singh@amd.com>
 <20180212153715.87555-6-brijesh.singh@amd.com>
 <20180212183803.GR13981@localhost.localdomain>
 <4a1f22d9-da2e-618b-1423-629817389948@amd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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
To: Brijesh Singh <brijesh.singh@amd.com>,
        Eduardo Habkost <ehabkost@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx2.suse.de ([195.135.220.15]:51703 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1754006AbeBLVUU (ORCPT <rfc822;kvm@vger.kernel.org>);
        Mon, 12 Feb 2018 16:20:20 -0500
Content-Disposition: inline
In-Reply-To: <4a1f22d9-da2e-618b-1423-629817389948@amd.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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)
--