Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Ben Horgan <ben.horgan@arm.com>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
	Marc Zyngier <maz@kernel.org>, Mingwei Zhang <mizhang@google.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 0/3] KVM: arm64: Allow vGICv4 configuration per VM
Date: Thu, 15 May 2025 17:48:30 +0100	[thread overview]
Message-ID: <89c75451-8a30-42c1-ba2a-a63b818a1a04@arm.com> (raw)
In-Reply-To: <CAJHc60w1rYc9guoideuKpKaukuCyvxu3S7Fidoy3Lh94+_xDiw@mail.gmail.com>

Hi,

On 5/15/25 16:55, Raghavendra Rao Ananta wrote:
> On Thu, May 15, 2025 at 3:30 AM Ben Horgan <ben.horgan@arm.com> wrote:
>>
>> Hi,
>>
>> On 5/14/25 20:21, Raghavendra Rao Ananta wrote:
>>> Hello,
>>>
>>> When kvm-arm.vgic_v4_enable=1, KVM adds support for direct interrupt
>>> injection by default to all the VMs in the system, aka GICv4. A
>>> shortcoming of the GIC architecture is that there's an absolute limit on
>>> the number of vPEs that can be tracked by the ITS. It is possible that
>>> an operator is running a mix of VMs on a system, only wanting to provide
>>> a specific class of VMs with hardware interrupt injection support.
>>>
>>> To support this, introduce a GIC attribute, KVM_DEV_ARM_VGIC_CONFIG_GICV4,
>>> for the userspace to enable or disable vGICv4 for a given VM.
>>>
>>> The attribute allows the configuration only when vGICv4 is enabled in KVM,
>>> else it acts a read-only attribute returning
>>> KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE as the value.
>> What's the reason for the cmdline enable continuing to be absolute in
>> the disable case? I wonder if this is unnecessarily restrictive.
>>
>> Couldn't KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE be reserved for
>> hardware that doesn't support vgic_v4 and if kvm-arm.vgic_v4_enable=0,
>> or omitted, on supporting hardware then default to
>> KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE but allow it to be overridden? I
>> don't think this changes the behaviour when your new attribute is not used.
> 
> KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE is reserved for the exact
> situation that you mentioned (no GICv4 h/w support  or if cmdline is
> disabled/omitted).
> Regarding defaulting to KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE,
> wouldn't it change the existing expectations, i.e., vGICv4 is enabled
> if available and set by cmdline?
I was suggesting keeping the defaults the same when your new gic 
attribute is untouched but in the same way that it overrides enable to 
disable you could also allow it to override disable to enable.

Based on Marc's comments this does not seem desirable. As things are 
now, and with your changes, setting kvm-arm.vgic_v4_enable=1 at boot 
implies a promise that vgic_v4 works on the system. As there is broken 
hardware we can't take this promise for granted.
> 
> Thank you.
> Raghavendra

Thanks,

Ben


      reply	other threads:[~2025-05-15 16:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-14 19:21 [PATCH 0/3] KVM: arm64: Allow vGICv4 configuration per VM Raghavendra Rao Ananta
2025-05-14 19:21 ` [PATCH 1/3] kvm: arm64: Add support for KVM_DEV_ARM_VGIC_CONFIG_GICV4 attr Raghavendra Rao Ananta
2025-05-14 19:21 ` [PATCH 2/3] docs: kvm: devices/arm-vgic-v3: Document " Raghavendra Rao Ananta
2025-05-14 19:21 ` [PATCH 3/3] KVM: selftests: Extend vgic_init to test GICv4 config attr Raghavendra Rao Ananta
2025-05-15 10:30 ` [PATCH 0/3] KVM: arm64: Allow vGICv4 configuration per VM Ben Horgan
2025-05-15 10:48   ` Marc Zyngier
2025-05-15 15:55   ` Raghavendra Rao Ananta
2025-05-15 16:48     ` Ben Horgan [this message]

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=89c75451-8a30-42c1-ba2a-a63b818a1a04@arm.com \
    --to=ben.horgan@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=mizhang@google.com \
    --cc=oliver.upton@linux.dev \
    --cc=rananta@google.com \
    /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