qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Peter Maydell <peter.maydell@linaro.org>,
	Miguel Luis <miguel.luis@oracle.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org,
	Haibo Xu <haibo.xu@linaro.org>, Andrew Jones <drjones@redhat.com>
Subject: Re: [RFC PATCH 2/5] hw/intc/gicv3: add support for setting KVM vGIC maintenance IRQ
Date: Mon, 06 Mar 2023 14:32:36 +0000	[thread overview]
Message-ID: <864jqyympn.wl-maz@kernel.org> (raw)
In-Reply-To: <CAFEAcA9ZzN0Xokh4kFcxtpv9hU512Km1EcaJHLG3JznVDF=Tew@mail.gmail.com>

On Mon, 06 Mar 2023 14:02:33 +0000,
Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On Mon, 27 Feb 2023 at 16:37, Miguel Luis <miguel.luis@oracle.com> wrote:
> >
> > From: Haibo Xu <haibo.xu@linaro.org>
> >
> > Use the VGIC maintenance IRQ if VHE is requested. As per the ARM GIC
> > Architecture Specification for GICv3 and GICv4 Arm strongly recommends that
> > maintenance interrupts are configured to use INTID 25 matching the
> > Server Base System Architecture (SBSA) recomendation.
> 
> What does this mean for QEMU, though? If the issue is
> "KVM doesn't support the maintenance interrupt being anything
> other than INTID 25" then we should say so (and have our code
> error out if the board tries to use some other value).

No, KVM doesn't give two hoots about the INTID, as long as this is a
PPI that is otherwise unused.

> If the
> issue is "the *host* has to be using the right INTID" then I
> would hope that KVM simply doesn't expose the capability if
> the host h/w won't let it work correctly.

No host maintenance interrupt, no NV. This is specially mandatory as
the L1 guest is in (almost) complete control of the ICH_*_EL2
registers and expects MIs to be delivered.

> If KVM can happily
> use any maintenance interrupt ID that the board model wants,
> then we should make that work, rather than hardcoding 25 into
> our gicv3 code.

+1.

I'd eliminate any reference to SBSA, as it has no bearing on either
KVM nor the QEMU GIC code.

I also question the "if VHE is requested". Not having VHE doesn't
preclude virtualisation. Was that supposed to be "virtualisation
extension" instead?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2023-03-06 14:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 16:37 [RFC PATCH 0/5] QEMU v7.2.0 aarch64 Nested Virtualization Support Miguel Luis
2023-02-27 16:37 ` [RFC PATCH 1/5] linux-headers: [kvm, arm64] add the necessary definitions to match host kernel Miguel Luis
2023-02-27 16:49   ` Cornelia Huck
2023-02-28 10:01     ` Miguel Luis
2023-02-27 16:37 ` [RFC PATCH 2/5] hw/intc/gicv3: add support for setting KVM vGIC maintenance IRQ Miguel Luis
2023-03-06 14:02   ` Peter Maydell
2023-03-06 14:32     ` Marc Zyngier [this message]
2023-03-06 20:04       ` Miguel Luis
2023-03-06 18:34     ` Miguel Luis
2023-02-27 16:37 ` [RFC PATCH 3/5] target/arm/kvm: add helper to detect EL2 when using KVM Miguel Luis
2023-02-27 19:27   ` Richard Henderson
2023-02-27 16:37 ` [RFC PATCH 4/5] target/arm: enable feature ARM_FEATURE_EL2 if EL2 is supported Miguel Luis
2023-02-27 19:24   ` Richard Henderson
2023-02-28 12:23     ` Miguel Luis
2023-07-06  8:16   ` Eric Auger
2023-07-14 12:45     ` Miguel Luis
2023-02-27 16:37 ` [RFC PATCH 5/5] arm/virt: provide virtualization extensions to the guest Miguel Luis
2023-02-27 19:26   ` Richard Henderson
2023-02-28 12:31     ` Miguel Luis
2024-02-08 16:55 ` [RFC PATCH 0/5] QEMU v7.2.0 aarch64 Nested Virtualization Support Eric Auger
2024-02-08 17:33   ` Miguel Luis
2024-02-08 18:23     ` Eric Auger

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=864jqyympn.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=cohuck@redhat.com \
    --cc=drjones@redhat.com \
    --cc=haibo.xu@linaro.org \
    --cc=miguel.luis@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@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).