mbox series

[v4,0/3] KVM: PPC: Book3S PR: Fixes for AIL and SCV

Message ID 20220222064727.2314380-1-npiggin@gmail.com (mailing list archive)
Headers show
Series KVM: PPC: Book3S PR: Fixes for AIL and SCV | expand

Message

Nicholas Piggin Feb. 22, 2022, 6:47 a.m. UTC
Paolo,

Patch 3 requires a KVM_CAP_PPC number allocated. QEMU maintainers are
happy with it (link in changelog) just waiting on KVM upstreaming. Do
you have objections to the series going to ppc/kvm tree first, or
another option is you could take patch 3 alone first (it's relatively
independent of the other 2) and ppc/kvm gets it from you?

The first patch in this series fixes a KVM PR host crash due to a
guest executing the scv instruction or with a pseries SMP host, the
host CPUs executing the scv instruction while a PR guest is running.

The second patch fixes unimplemented H_SET_MODE AIL modes by returning
failure from the hcall rather than succeeding but not implementing
the required behaviour. This works around missing host scv support for
scv-capable Linux guests by causing them to disable the facility.

The third patch adds a new KVM CAP to go with some QEMU work to get
the AIL differences properly represented in QEMU. The third patch will
need to allocate a KVM CAP number and merged with upstream KVM tree
before the QEMU side goes ahead.

Changes since v2:
- Fix fscr compile error in patch 1.
- Add patch 3.

Changes since v3:
- Rebased, cc kvm@

Thanks,
Nick

Nicholas Piggin (3):
  KVM: PPC: Book3S PR: Disable SCV when AIL could be disabled
  KVM: PPC: Book3S PR: Disallow AIL != 0
  KVM: PPC: Add KVM_CAP_PPC_AIL_MODE_3

 Documentation/virt/kvm/api.rst         | 14 +++++++++++++
 arch/powerpc/include/asm/setup.h       |  2 ++
 arch/powerpc/kernel/exceptions-64s.S   |  4 ++++
 arch/powerpc/kernel/setup_64.c         | 28 ++++++++++++++++++++++++++
 arch/powerpc/kvm/Kconfig               |  9 +++++++++
 arch/powerpc/kvm/book3s_pr.c           | 26 +++++++++++++++---------
 arch/powerpc/kvm/book3s_pr_papr.c      | 20 ++++++++++++++++++
 arch/powerpc/kvm/powerpc.c             | 17 ++++++++++++++++
 arch/powerpc/platforms/pseries/setup.c | 12 ++++++++++-
 include/uapi/linux/kvm.h               |  1 +
 tools/include/uapi/linux/kvm.h         |  1 +
 11 files changed, 124 insertions(+), 10 deletions(-)

Comments

Paolo Bonzini Feb. 22, 2022, 2:11 p.m. UTC | #1
On 2/22/22 07:47, Nicholas Piggin wrote:
> Patch 3 requires a KVM_CAP_PPC number allocated. QEMU maintainers are
> happy with it (link in changelog) just waiting on KVM upstreaming. Do
> you have objections to the series going to ppc/kvm tree first, or
> another option is you could take patch 3 alone first (it's relatively
> independent of the other 2) and ppc/kvm gets it from you?

Hi Nick,

I have pushed a topic branch kvm-cap-ppc-210 to kvm.git with just the 
definition and documentation of the capability.  ppc/kvm can apply your 
patch based on it (and drop the relevant parts of patch 3).  I'll send 
it to Linus this week.

Paolo
Nicholas Piggin Feb. 23, 2022, 6:44 a.m. UTC | #2
Excerpts from Paolo Bonzini's message of February 23, 2022 12:11 am:
> On 2/22/22 07:47, Nicholas Piggin wrote:
>> Patch 3 requires a KVM_CAP_PPC number allocated. QEMU maintainers are
>> happy with it (link in changelog) just waiting on KVM upstreaming. Do
>> you have objections to the series going to ppc/kvm tree first, or
>> another option is you could take patch 3 alone first (it's relatively
>> independent of the other 2) and ppc/kvm gets it from you?
> 
> Hi Nick,
> 
> I have pushed a topic branch kvm-cap-ppc-210 to kvm.git with just the 
> definition and documentation of the capability.  ppc/kvm can apply your 
> patch based on it (and drop the relevant parts of patch 3).  I'll send 
> it to Linus this week.

Hey Paolo,

Thanks for this, I could have done it for you! This seems like a good 
way to reserve/merge caps: when there is a series ready for N+1, then
merge window then the cap number and description could have a topic
branch based on an earlier release. I'm not sure if you'd been doing 
that before (looks like not for the most recent few caps, at least).

One thing that might improve it is if you used 5.16 as the base for
the kvm-cap branch. I realise it wasn't so simple this time because 
5.17-rc2 had a new cap merged. But it should be possible if all new caps 
took this approach. It would give the arch tree more flexibility where 
to base their tree on without (mpe usually does -rc2). NBD just an idea 
for next time.

Thanks,
Nick
Christian Borntraeger Feb. 23, 2022, 9:14 a.m. UTC | #3
Am 22.02.22 um 15:11 schrieb Paolo Bonzini:
> On 2/22/22 07:47, Nicholas Piggin wrote:
>> Patch 3 requires a KVM_CAP_PPC number allocated. QEMU maintainers are
>> happy with it (link in changelog) just waiting on KVM upstreaming. Do
>> you have objections to the series going to ppc/kvm tree first, or
>> another option is you could take patch 3 alone first (it's relatively
>> independent of the other 2) and ppc/kvm gets it from you?
> 
> Hi Nick,
> 
> I have pushed a topic branch kvm-cap-ppc-210 to kvm.git with just the definition and documentation of the capability.  ppc/kvm can apply your patch based on it (and drop the relevant parts of patch 3).  I'll send it to Linus this week.

We to have be careful with the 210 cap that was merged from the s390 tree.
Nicholas Piggin Feb. 23, 2022, 11:47 a.m. UTC | #4
Excerpts from Christian Borntraeger's message of February 23, 2022 7:14 pm:
> 
> 
> Am 22.02.22 um 15:11 schrieb Paolo Bonzini:
>> On 2/22/22 07:47, Nicholas Piggin wrote:
>>> Patch 3 requires a KVM_CAP_PPC number allocated. QEMU maintainers are
>>> happy with it (link in changelog) just waiting on KVM upstreaming. Do
>>> you have objections to the series going to ppc/kvm tree first, or
>>> another option is you could take patch 3 alone first (it's relatively
>>> independent of the other 2) and ppc/kvm gets it from you?
>> 
>> Hi Nick,
>> 
>> I have pushed a topic branch kvm-cap-ppc-210 to kvm.git with just the definition and documentation of the capability.  ppc/kvm can apply your patch based on it (and drop the relevant parts of patch 3).  I'll send it to Linus this week.
> 
> We to have be careful with the 210 cap that was merged from the s390 tree.

Ah thanks, I didn't notice it.

Using 211 is no problem for me, merge will have a conflict now though.
We could avoid it by just sending my patch in a second batch instead of
doing the topic branch this time (I still like the idea of a topic
branch for caps for future).

Thanks,
Nick
Christian Borntraeger Feb. 24, 2022, 9:32 a.m. UTC | #5
Am 23.02.22 um 12:47 schrieb Nicholas Piggin:
> Excerpts from Christian Borntraeger's message of February 23, 2022 7:14 pm:
>>
>>
>> Am 22.02.22 um 15:11 schrieb Paolo Bonzini:
>>> On 2/22/22 07:47, Nicholas Piggin wrote:
>>>> Patch 3 requires a KVM_CAP_PPC number allocated. QEMU maintainers are
>>>> happy with it (link in changelog) just waiting on KVM upstreaming. Do
>>>> you have objections to the series going to ppc/kvm tree first, or
>>>> another option is you could take patch 3 alone first (it's relatively
>>>> independent of the other 2) and ppc/kvm gets it from you?
>>>
>>> Hi Nick,
>>>
>>> I have pushed a topic branch kvm-cap-ppc-210 to kvm.git with just the definition and documentation of the capability.  ppc/kvm can apply your patch based on it (and drop the relevant parts of patch 3).  I'll send it to Linus this week.
>>
>> We to have be careful with the 210 cap that was merged from the s390 tree.
> 
> Ah thanks, I didn't notice it.
> 
> Using 211 is no problem for me, merge will have a conflict now though.
> We could avoid it by just sending my patch in a second batch instead of
> doing the topic branch this time (I still like the idea of a topic
> branch for caps for future).

Paolo,

the power people have not used your branch yet. So you could - as an alternative also
create an kvm-cap-ppc-211 branch for 5.17 and leave the s390 cap at 210. But it would
be good to do something now so that we have final numbers for the caps. Either create
a kvm-cap-ppc-211 branch, or merge the kvm-cap-ppc-210 branch into next and fixup the
s390 cap to become 211.