On Sat, Jan 29, 2022 at 04:50:07PM +1000, Nicholas Piggin wrote: > The behaviour of the Address Translation Mode on Interrupt resource is > not consistently supported by all CPU versions or all KVM versions. In > particular KVM HV only supports mode 0 on POWER7 processors, and does > not support mode 2 on any processors. KVM PR only supports mode 0. TCG > can support all modes (0,2,3). > > This leads to inconsistencies in guest behaviour and could cause > problems migrating guests. > > This was not too noticable for Linux guests for a long time because the > kernel only used mode 0 or 3, and it used to consider AIL to be somewhat > advisory (KVM would not always honor it either) and it kept both sets of > interrupt vectors around. > > Recent Linux guests depend on the AIL mode working as defined by the ISA > to support the SCV facility interrupt. If AIL mode 3 can not be provided, > then Linux must be given an error so it can disable the SCV facility. > > Add the ail-modes capability which is a bitmap of the supported values > for the H_SET_MODE Address Translation Mode on Interrupt resource. Add > a new KVM CAP that exports the same thing, and provide defaults for PR > and HV KVM that predate the cap. > --- > > I just wanted to get some feedback on the approach before submitting a > patch for the KVM cap. > > The reason I don't make that a boolean cap for AIL=3 is that future > processors might implement new modes a guest would like to use even > though it's not the nicest interface.
[snip] > SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { > [SPAPR_CAP_HTM] = { > .name = "htm", > @@ -730,6 +802,15 @@ SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = { > .type = "bool", > .apply = cap_rpt_invalidate_apply, > }, > + [SPAPR_CAP_AIL_MODES] = { > + .name = "ail-modes", > + .description = "Bitmap of AIL (alternate interrupt location) mode > support", A bitmap doesn't quite work as an spapr cap. The general caps code assumes that bigger is always better, or more precisely that migrating from an instance that has a lower value to one which has a higher value is "good enough" to be compatible. That's obviously not the case for a bitmap. I think to handle this properly within the limitations of papr caps, you instead want a separate boolean cap for each supported AIL mode (or at least for each AIL mode you want to have control over). -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature