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?