From: Nicholas Piggin <npiggin@gmail.com>
To: Fabiano Rosas <farosas@linux.ibm.com>, qemu-ppc@nongnu.org
Cc: qemu-devel@nongnu.org,
"Daniel Henrique Barboza" <danielhb413@gmail.com>,
"Cédric Le Goater" <clg@kaod.org>,
"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [PATCH 2/2] target/ppc/kvm: Use KVM_CAP_PPC_AIL_MODE_3 to determine cap-ail-mode-3 support
Date: Wed, 16 Feb 2022 11:46:58 +1000 [thread overview]
Message-ID: <1644975678.e05ill5mjj.astroid@bobo.none> (raw)
In-Reply-To: <87tud0xqvb.fsf@linux.ibm.com>
Excerpts from Fabiano Rosas's message of February 15, 2022 10:21 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
>> Excerpts from Fabiano Rosas's message of February 14, 2022 11:13 pm:
>>> Nicholas Piggin <npiggin@gmail.com> writes:
>>>
>>>> Use KVM_CAP_PPC_AIL_MODE_3 to determine cap-ail-mode-3 support for KVM
>>>> guests. Keep the fallback heuristic for KVM hosts that pre-date this
>>>> CAP.
>>>>
>>>> This is only proposed the KVM CAP has not yet been allocated. I will
>>>> ask to merge the new KVM cap when there are no objections on the QEMU
>>>> side.
>>>>
>>>> not-yet-Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>>> ---
>>>> hw/ppc/spapr_caps.c | 2 +-
>>>> linux-headers/linux/kvm.h | 1 +
>>>> target/ppc/kvm.c | 18 +++++++++++++++++-
>>>> target/ppc/kvm_ppc.h | 4 ++--
>>>> 4 files changed, 21 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
>>>> index 5fd4a53c33..5cc80776d0 100644
>>>> --- a/hw/ppc/spapr_caps.c
>>>> +++ b/hw/ppc/spapr_caps.c
>>>> @@ -619,7 +619,7 @@ static void cap_ail_mode_3_apply(SpaprMachineState *spapr,
>>>> ERRP_GUARD();
>>>>
>>>> if (kvm_enabled()) {
>>>> - if (!kvmppc_supports_ail_3()) {
>>>> + if (!kvmppc_has_cap_ail_3()) {
>>>> error_setg(errp, "KVM implementation does not support cap-ail-mode-3");
>>>> error_append_hint(errp, "Try appending -machine cap-ail-mode-3=off\n");
>>>> return;
>>>> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
>>>> index 02c5e7b7bb..d91f578200 100644
>>>> --- a/linux-headers/linux/kvm.h
>>>> +++ b/linux-headers/linux/kvm.h
>>>> @@ -1130,6 +1130,7 @@ struct kvm_ppc_resize_hpt {
>>>> #define KVM_CAP_BINARY_STATS_FD 203
>>>> #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
>>>> #define KVM_CAP_ARM_MTE 205
>>>> +#define KVM_CAP_PPC_AIL_MODE_3 210
>>>>
>>>> #ifdef KVM_CAP_IRQ_ROUTING
>>>>
>>>> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
>>>> index 128bc530d4..d0d0bdaac4 100644
>>>> --- a/target/ppc/kvm.c
>>>> +++ b/target/ppc/kvm.c
>>>> @@ -90,6 +90,7 @@ static int cap_ppc_nested_kvm_hv;
>>>> static int cap_large_decr;
>>>> static int cap_fwnmi;
>>>> static int cap_rpt_invalidate;
>>>> +static int cap_ail_mode_3;
>>>>
>>>> static uint32_t debug_inst_opcode;
>>>>
>>>> @@ -154,6 +155,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>>>> }
>>>>
>>>> cap_rpt_invalidate = kvm_vm_check_extension(s, KVM_CAP_PPC_RPT_INVALIDATE);
>>>> + cap_ail_mode_3 = kvm_vm_check_extension(s, KVM_CAP_PPC_AIL_MODE_3);
>>>> kvm_ppc_register_host_cpu_type();
>>>>
>>>> return 0;
>>>> @@ -2563,10 +2565,24 @@ int kvmppc_has_cap_rpt_invalidate(void)
>>>> return cap_rpt_invalidate;
>>>> }
>>>>
>>>> -int kvmppc_supports_ail_3(void)
>>>> +int kvmppc_has_cap_ail_3(void)
>>>> {
>>>> PowerPCCPUClass *pcc = kvm_ppc_get_host_cpu_class();
>>>>
>>>> + if (cap_ail_mode_3) {
>>>> + return 1;
>>>> + }
>>>> +
>>>> + if (kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION, KVM_CAP_PPC_AIL_MODE_3) == 0) {
>>>> + return 0;
>>>> + }
>>>
>>> This is not needed here it seems.
>>
>> This is to test whether the capability is recognised by the HV.
>> kvm_vm_check_extension() treats ioctl error as 0 capability but we want
>> to do this extra heuristic.
>
> Do you intend to make the KVM capability return < 0 in case AIL_3 is not
> supported?
No it should return 0 in that case.
> AFAICS the unknown capability won't result in an ioctl error
> as kvm_vm_ioctl_check_extension always returns >= 0.
Oh. There is no way to tell that a host does not recognise a cap? :(
Great for the purity test, unknown cap == unsupported. For a practical
point of view to catch such bugs and oversights there should have been
some way to handle it.
I'm not sure what to do then. Try some even worse hack and leave that
in for a couple of years to give upstream KVM a chance to trickle down.
Thanks,
Nick
next prev parent reply other threads:[~2022-02-16 1:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 11:17 [PATCH 1/2] spapr: Add SPAPR_CAP_AIL_MODE_3 for AIL mode 3 support for H_SET_MODE hcall Nicholas Piggin
2022-02-14 11:17 ` [PATCH 2/2] target/ppc/kvm: Use KVM_CAP_PPC_AIL_MODE_3 to determine cap-ail-mode-3 support Nicholas Piggin
2022-02-14 13:13 ` Fabiano Rosas
2022-02-14 22:54 ` Nicholas Piggin
2022-02-15 12:21 ` Fabiano Rosas
2022-02-16 1:46 ` Nicholas Piggin [this message]
2022-02-16 4:58 ` David Gibson
2022-02-15 1:10 ` [PATCH 1/2] spapr: Add SPAPR_CAP_AIL_MODE_3 for AIL mode 3 support for H_SET_MODE hcall David Gibson
2022-02-16 1:50 ` Nicholas Piggin
2022-02-16 5:00 ` David Gibson
2022-02-16 8:25 ` Cédric Le Goater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1644975678.e05ill5mjj.astroid@bobo.none \
--to=npiggin@gmail.com \
--cc=clg@kaod.org \
--cc=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=farosas@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).