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: 2336 bytes --]

On Mon, Jan 31, 2022 at 04:10:34PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 1/29/22 03:50, 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.
> 
> Is this the scenario where migration failures can occur? I don't understand
> what are the migration problems you cited that were possible to
> happen.

The problem case (well, the main one) is migrating from qemu on a
recent KVM running with AIL==3 to qemu on an older KVM (or PR) where
AIL==3 doesn't work properly.

Theoretically, a qemu running with AIL==2 on TCG to a qemu running on
KVM is also a problem, though it's not going to arise in practice,
since AFAIK no guests we care about use AIL==2.

> > 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.
> 
> Why add a new machine cap in this case? Isn't something that the KVM capability
> should be able to handle by itself, where we always assume that we should have
> the best AIL value possible?

Because the "best AIL possible" might change across a migration.

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