[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHibDyztkj3vFmZ7Gg=0QFoauO7pdm4+c16y8hQiaTkCQPc=LQ@mail.gmail.com>
Date: Mon, 9 Dec 2024 16:09:51 +0800
From: Max Hsu <max.hsu@...ive.com>
To: Andrew Jones <ajones@...tanamicro.com>
Cc: Conor Dooley <conor@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Anup Patel <anup@...infault.org>, Atish Patra <atishp@...shpatra.org>,
Palmer Dabbelt <palmer@...ive.com>, linux-riscv@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
kvm-riscv@...ts.infradead.org, Samuel Holland <samuel.holland@...ive.com>
Subject: Re: [PATCH RFC v3 3/3] riscv: KVM: Add Svukte extension support for Guest/VM
Okay, I understand it now, since the Guest OS may utilize the Svukte
extension simply by setting the senvcfg.UKTE without any trap.
In the view of VMM, the Svukte extension should be always presented.
I'll add the extra entry in the kvm_riscv_vcpu_isa_disable_allowed()
for the v4 patches.
Thanks, Anup, Paul, and Andrew for the patience and detailed
explanation.
Best,
Max Hsu
On Mon, Nov 25, 2024 at 8:08 PM Andrew Jones <ajones@...tanamicro.com> wrote:
>
> On Wed, Nov 20, 2024 at 10:09:34PM +0800, Max Hsu wrote:
> > Add KVM_RISCV_ISA_EXT_SVUKTE for VMM to detect the enablement
> > or disablement the Svukte extension for Guest/VM
> >
> > Reviewed-by: Samuel Holland <samuel.holland@...ive.com>
> > Signed-off-by: Max Hsu <max.hsu@...ive.com>
> > ---
> > arch/riscv/include/uapi/asm/kvm.h | 1 +
> > arch/riscv/kvm/vcpu_onereg.c | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
> > index 4f24201376b17215315cf1fb8888d0a562dc76ac..158f9253658c4c28a533b2bda179fb48bf41e1fc 100644
> > --- a/arch/riscv/include/uapi/asm/kvm.h
> > +++ b/arch/riscv/include/uapi/asm/kvm.h
> > @@ -177,6 +177,7 @@ enum KVM_RISCV_ISA_EXT_ID {
> > KVM_RISCV_ISA_EXT_ZAWRS,
> > KVM_RISCV_ISA_EXT_SMNPM,
> > KVM_RISCV_ISA_EXT_SSNPM,
> > + KVM_RISCV_ISA_EXT_SVUKTE,
> > KVM_RISCV_ISA_EXT_MAX,
> > };
> >
> > diff --git a/arch/riscv/kvm/vcpu_onereg.c b/arch/riscv/kvm/vcpu_onereg.c
> > index 5b68490ad9b75fef6a18289d8c5cf9291594e01e..4c3a77cdeed0956e21e53d1ab4e948a170ac5c5c 100644
> > --- a/arch/riscv/kvm/vcpu_onereg.c
> > +++ b/arch/riscv/kvm/vcpu_onereg.c
> > @@ -43,6 +43,7 @@ static const unsigned long kvm_isa_ext_arr[] = {
> > KVM_ISA_EXT_ARR(SVINVAL),
> > KVM_ISA_EXT_ARR(SVNAPOT),
> > KVM_ISA_EXT_ARR(SVPBMT),
> > + KVM_ISA_EXT_ARR(SVUKTE),
> > KVM_ISA_EXT_ARR(ZACAS),
> > KVM_ISA_EXT_ARR(ZAWRS),
> > KVM_ISA_EXT_ARR(ZBA),
> >
> > --
> > 2.43.2
>
> Anup raised the missing entry in kvm_riscv_vcpu_isa_disable_allowed() in
> the last review. An additional paragraph was added to the cover letter for
> this review, but I think there's still a misunderstanding. If the guest
> can always use the extension (whether it's advertised in its ISA string
> or not), then that means it cannot be disabled from the perspective of
> the VMM. The only ISA extensions which may be disabled are the ones that
> trap on their use, allowing KVM to emulate responses which a physical hart
> without the extension would produce.
>
> Thanks,
> drew
Powered by blists - more mailing lists