qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Vir


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object
Date: Tue, 13 Mar 2018 16:20:56 -0300
User-agent: Mutt/1.9.2 (2017-12-15)

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?

I would agree with this only if we make QEMU able to prevent live
migration to a host with mismatching cbitpos.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]