From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dr. David Alan Gilbert" Subject: Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object Date: Tue, 13 Mar 2018 19:49:45 +0000 Message-ID: <20180313194944.GN3545@work-vm> References: <20180308124901.83533-1-brijesh.singh@amd.com> <20180308124901.83533-9-brijesh.singh@amd.com> <20180308164910.GF4718@redhat.com> <20180308224412.GF3417@localhost.localdomain> <8cf2f9bc-0339-1c80-b53b-ef5915248d1f@redhat.com> <20180313184950.GB3417@localhost.localdomain> <253374a3-0d09-a29a-94fc-ea4f5718f477@redhat.com> <20180313192056.GD3417@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Edgar E. Iglesias" , Peter Maydell , Borislav Petkov , Brijesh Singh , kvm@vger.kernel.org, "Michael S. Tsirkin" , Stefan Hajnoczi , Alistair Francis , Peter Crosthwaite , Richard Henderson , qemu-devel@nongnu.org, Alexander Graf , Christian Borntraeger , Marcel Apfelbaum , Paolo Bonzini , Thomas Lendacky , Bruce Rogers , Cornelia Huck , Markus Armbruster , Richard Henderson To: Eduardo Habkost Return-path: Content-Disposition: inline In-Reply-To: <20180313192056.GD3417@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel2=m.gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org * Eduardo Habkost (ehabkost@redhat.com) wrote: > On Tue, Mar 13, 2018 at 08:04:51PM +0100, Paolo Bonzini wrote: > > On 13/03/2018 19:49, Eduardo Habkost wrote: > > >>> > > >>> Exactly, in other words these two options are part of the guest > > >>> ABI, and QEMU promises to never make the guest ABI depend on the > > >>> host hardware unless you're using "-cpu host". > > >> > > >> This is not entirely true; while MAXPHYADDR is constant downstream > > >> unless using "-cpu host", in practice that behavior is wrong and a guest > > >> could misbehave if passed a MAXPHYADDR that is different from the host's. > > >> > > >> I think this is the same, and management software will have to live with it. > > > > > > I think they are very far from being equivalent. > > > > Right, I only meant to say that guest ABI actually does depend on the > > host hardware, even outside of "-cpu host". > > > > > But if you tell the guest the wrong C-bit location, guests are > > > likely to rely on it and break. Migration between hosts with > > > different C-bit locations won't work, will it? > > > > It won't---but as long as the destination hosts fails fast when the > > C-bit location is wrong, it's okay. What matters is that we don't run > > guest code with the wrong C bit, as you noted. > > Are you proposing we change the default to simply use cbitpos > from the host? Hmm I don't like that idea; as an option that's fine, as the only way it's not. > I would agree with this only if we make QEMU able to prevent live > migration to a host with mismatching cbitpos. Yeh; especially since I suspect debugging stuff with a failed SEV migration like that is going to be really hard. Dave > -- > Eduardo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK