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
