qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 2/5] hw/intc/gicv3: add support for setting KVM vGIC main


From: Miguel Luis
Subject: Re: [RFC PATCH 2/5] hw/intc/gicv3: add support for setting KVM vGIC maintenance IRQ
Date: Mon, 6 Mar 2023 20:04:35 +0000

Hi Marc,

> On 6 Mar 2023, at 13:32, Marc Zyngier <maz@kernel.org> wrote:
> 
> 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?
> 

s/VHE/virtualization extension/

I’ve noted it has been a recurring confusion on my part. Will fix. :)

Thank you,
Miguel

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]