Re: [RFC PATCH] spapr: Add SPAPR_CAP_AIL_MODES for supported AIL modes for H_SET_MODE hcall

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3059 bytes --]

On Mon, Jan 31, 2022 at 12:51:00PM -0300, Fabiano Rosas wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
> 
> > 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.
> 
> Could you expand a bit on what is the use case for setting this in the
> QEMU cmdline? I looks to me we already have all the information we need
> with just the KVM cap.

The problem is that changing guest visible behaviour based on a KVM
cap is a no-no.  It causes grief with migration, because the basic
assumption of qemu's migration model is that identically configured
machines are migration compatible, but that's no longer the case if
the machine's behaviour can be altered by host properties like a KVM
cap.

In this specific case, I can see one approach that *might* avoid the
need for an spapr cap.  That would be to declare that we were always
(at least since the AIL setting hypercall was introduced) "supposed"
to support AIL modes 0 and 3 and the fact that we didn't on certain
hosts was simply a bug.  Then we could start enforcing this and simply
error outrun at all on host where KVM doesn't support those modes.
The trade-off, obviously, is that we'd now fail on certain setups
which previously worked (albeit in a fragile way).

You'd also need to enforce that the guest not select AIL mode 2, of
course.  That's technically an incompatible breaking change, but I
think it's one we could get away with, since the vast majority of
setups in practice never worked with it anyway.  If you did want to
add support for AIL mode 2, then you'd need an spapr cap.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]