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
