Re: [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Mar 13, 2018 at 09:42:51AM +0100, Paolo Bonzini wrote:
> On 08/03/2018 23:44, Eduardo Habkost wrote:
> >> I think doing so will be an issue for the migration. Consider your above
> >> use case, a SEV guest is running on EPYC with cbitpos=47 and if we
> >> migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
> >> will fail to resume the guest on destination after migrating.
> > 
> > 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.

In practice guests don't seem to mind if we don't perfectly
emulate behavior that depend on MAXPHYADDR, and live-migration
between hosts with different MAXPHYADDR works.

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?

-- 
Eduardo