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. Paolo > In theory we could make QEMU choose the right values > automatically if we document very clearly that the default > behavior is unsafe. But I would rather not take that risk and > force management software to be aware of the gotchas involved in > using SEV + live-migration.