* Eduardo Habkost (ehabkost@xxxxxxxxxx) wrote: > 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? Hmm I don't like that idea; as an option that's fine, as the only way it's not. > I would agree with this only if we make QEMU able to prevent live > migration to a host with mismatching cbitpos. Yeh; especially since I suspect debugging stuff with a failed SEV migration like that is going to be really hard. Dave > -- > Eduardo -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
