Hi Eric, On Wed, 14 Feb 2024 18:07:58 +0000, Eric Auger <eauger@xxxxxxxxxx> wrote: > > > I'm not sure SEIS is such an easy one: if you promised the guest that > > it would never get an SError doing the most stupid things (SEIS=0), it > > really shouldn't get one after migration. If you advertised it on the > > source HW (Altra), a migration to TX2 would be fine. > I see. Indeed for sure we must make sure KVM cannot inject SEIs in the > guest if SEIS is not advertised on guest side. The problem isn't KVM injecting an SError, but the HW doing it (that's what SEIS indicates). On some HW, it only takes an old enough EFI build to trigger those. > In this case SEIS is 0 on src Altra. On dst TX2 ich_vtr_el2 advertises > it and host seis =1 causing set_gic_ctlr to fail (vgic-sys-reg-v3.c). > > > > > The other bits are possible to change depending on the requirements of > > the VM (aff3, IDBits), and ExtRange should always be set to 0 (because > > our GIC implementation doesn't support EPPI/ESPI). > > > > The really ugly part here is that if you want to affect these bits, > > you will need to trap and emulate the access. Not a big deal, but in > > the absence of FGT, you will need to handle the full Common trap > > group, which is going to slow things down (you will have to trap > > ICV_PMR_EL1, for example). > Would it be sensible to simplify things and only support the new range > if FGT is supported? I'm not sure that helps. The only FGT that covers the GIC is for ICC_IGRPENn_EL1, and we don't care much about that guy. So ICH_VMCR_EL2.TC it is, and that sucks a bit. But if that's what you want to show, you don't have a choice. Thanks, M. -- Without deviation from the norm, progress is not possible.
