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
