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.