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

[Daniel Henrique Barboza <danielhb413@gmail.com>]

On 2/6/22 22:54, David Gibson wrote:
> 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.

Well, since there's a possible migration breakage scenario I believe we'll need to
consider adding this new cap then.

Given that Nick is using a sensible default and most users won't be affected by this
cap I think it's ok.


Thanks,


Daniel

>