Hi Marc,
On 3/20/20 11:05 AM, Marc Zyngier wrote:
> Hi Eric,
>
> On 2020-03-20 08:11, Auger Eric wrote:
>> Hi Marc,
>> On 3/4/20 9:33 PM, Marc Zyngier wrote:
>>> Most of the GICv3 emulation code that deals with SGIs now has to be
>>> aware of the v4.1 capabilities in order to benefit from it.
>>>
>>> Add such support, keyed on the interrupt having the hw flag set and
>>> being a SGI.
>>>
>>> Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
>>> ---
>>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 15 +++++-
>>> virt/kvm/arm/vgic/vgic-mmio.c | 88 ++++++++++++++++++++++++++++++--
>>> 2 files changed, 96 insertions(+), 7 deletions(-)
>>>
>
> [...]
>
>>> @@ -113,7 +125,21 @@ void vgic_mmio_write_senable(struct kvm_vcpu *vcpu,
>>> struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid +
>>> i);
>>>
>>> raw_spin_lock_irqsave(&irq->irq_lock, flags);
>>> - if (vgic_irq_is_mapped_level(irq)) {
>>> + if (irq->hw && vgic_irq_is_sgi(irq->intid)) {
>>> + if (!irq->enabled) {
>>> + struct irq_data *data;
>>> +
>>> + irq->enabled = true;
>>> + data = &irq_to_desc(irq->host_irq)->irq_data;
>>> + while (irqd_irq_disabled(data))
>>> + enable_irq(irq->host_irq);
>> could you explain me why the while() is requested?
>
> Ah, interesting question: disable_irq() (and its variants) can nest. This
> means that if you have done two disable_irq(), you must do two enable_irq()
> to get back to the interrupt being enabled.
>
> The locking should ensure that this nesting doesn't happen, but I'm
> paranoid
> (see the GICv4.0 doorbell handling). It also makes it easier to reason
> about
> the initial state.
OK! thank you for this explanation.
Thanks
Eric
>
> [...]
>
>> Reviewed-by: Eric Auger <eric.auger@xxxxxxxxxx>
>
> Thanks!
>
> M.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
