public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: andre.przywara@arm•com (Andre Przywara)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 07/10] KVM: arm/arm64: vgic: Allow HW interrupts to be queued to a guest
Date: Thu, 11 Jun 2015 10:44:02 +0100	[thread overview]
Message-ID: <55795862.1050407@arm.com> (raw)
In-Reply-To: <557951C6.2090408@arm.com>

On 06/11/2015 10:15 AM, Marc Zyngier wrote:
> On 11/06/15 09:44, Andre Przywara wrote:
>> On 06/08/2015 06:04 PM, Marc Zyngier wrote:
...
>>> @@ -1344,6 +1364,35 @@ static bool vgic_process_maintenance(struct kvm_vcpu *vcpu)
>>>  	return level_pending;
>>>  }
>>>  
>>> +/* Return 1 if HW interrupt went from active to inactive, and 0 otherwise */
>>> +static int vgic_sync_hwirq(struct kvm_vcpu *vcpu, struct vgic_lr vlr)
>>> +{
>>> +	struct irq_phys_map *map;
>>> +	int ret;
>>> +
>>> +	if (!(vlr.state & LR_HW))
>>> +		return 0;
>>> +
>>> +	map = vgic_irq_map_search(vcpu, vlr.irq);
>>
>> I wonder if it's safe to rely on that mapping here. Are we sure that
>> this hasn't changed while the VCPU was running? If I got this correctly,
>> currently only vcpu_reset will actually add a map entry, but I guess in
>> the future there will be more users.
> 
> How can the guest interrupt change? This is HW, as far as the guest is
> concerned. An actual interrupt line. We don't reconfigure the HW live.

I was thinking about the rbtree mapping we introduced. There we map a
guest interrupt to a hardware interrupt. Are we sure that no one tears
down that mapping while we have an LR populated with this pair?
I am not talking about the timer here, but more about future users.

>> Also we rely on the irqdomain mapping to be still the same, but that is
>> probably a safe assumption.
> 
> Like I said before, this *cannot* change.

OK, got it.

> 
>> But I'd still find it more natural to use the hwirq number from the LR
>> at this point. Can't we use irq_find_mapping() here to learn Linux'
>> (current) irq number from that?
> 
> I think you're confused.
> 
> - The guest irq (vlr.irq) is entirely made up, and has no connection
> with reality. it is stable, and cannot change during the lifetime of the
> guest (think of it as a HW irq line).
> 
> - The host hwirq (vlr.hwirq) is stable as well, for the same reason.
> 
> - The Linux IRQ cannot change because we've been given it by the kernel,
> and that's what we use for *everything* as far as the kernel is
> concerned. Its mapping to hwirq is stable as well because this is how we
> talk to the HW.

Not disputing any of them, but:

> - irq_find_mapping gives you the *reverse* mapping (from hwirq to Linux
> irq), and for that to work, you need the domain on which you want to
> apply the translation. This is only useful when actually taking the
> interrupt (i.e. in an interrupt controller driver). I can't see how that
> could make sense here.

So if the guest has acked/EOIed it's IRQ, the GIC at the same time
acked/EOIed the hardware IRQ it found in the LR. Now we assume that this
is the very same as the HW IRQ we found doing our rbtree traversal.
I just wanted to be sure that this is always true and that this mapping
didn't change while the VCPU was running.
If you are sure of this, fine, I was just concerned that someone breaks
this assumption in the future by more dynamically mapping/unmapping
entries (say some irq forwarding user) and we will not notice.

Cheers,
Andre.

> 
> The purpose of this mapping is to, given the guest irq (because that's
> what we inject), what the other values are:
> - hwirq: to provide GICH with the interrupt to deactivate
> - Linux irq: to control the active state through the irqchip state API.
> 
>> Or am I too paranoid here?
> 
> Hope it makes more sense to you now.
> 
> Thanks,
> 
> 	M.
> 

  reply	other threads:[~2015-06-11  9:44 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 17:03 [PATCH 00/10] arm/arm64: KVM: Active interrupt state switching for shared devices Marc Zyngier
2015-06-08 17:03 ` [PATCH 01/10] arm/arm64: KVM: Fix ordering of timer/GIC on guest entry Marc Zyngier
2015-06-09 11:29   ` Alex Bennée
2015-06-30 20:19   ` Christoffer Dall
2015-06-08 17:03 ` [PATCH 02/10] arm/arm64: KVM: Move vgic handling to a non-preemptible section Marc Zyngier
2015-06-09 11:38   ` Alex Bennée
2015-06-30 20:19   ` Christoffer Dall
2015-06-08 17:03 ` [PATCH 03/10] KVM: arm/arm64: vgic: Convert struct vgic_lr to use bitfields Marc Zyngier
2015-06-09 13:12   ` Alex Bennée
2015-06-10 17:23   ` Andre Przywara
2015-06-10 18:04     ` Marc Zyngier
2015-06-08 17:03 ` [PATCH 04/10] KVM: arm/arm64: vgic: Allow HW irq to be encoded in LR Marc Zyngier
2015-06-09 13:21   ` Alex Bennée
2015-06-09 14:03     ` Marc Zyngier
2015-06-17 11:53   ` Eric Auger
2015-06-17 12:39     ` Marc Zyngier
2015-06-17 13:21     ` Peter Maydell
2015-06-17 13:34       ` Marc Zyngier
2015-06-08 17:04 ` [PATCH 05/10] KVM: arm/arm64: vgic: Relax vgic_can_sample_irq for edge IRQs Marc Zyngier
2015-06-30 20:19   ` Christoffer Dall
2015-07-01  9:17     ` Marc Zyngier
2015-07-01 11:58       ` Christoffer Dall
2015-07-01 18:18         ` Marc Zyngier
2015-07-02 16:23           ` Christoffer Dall
2015-07-03  9:50             ` Marc Zyngier
2015-07-03  9:57               ` Peter Maydell
2015-06-08 17:04 ` [PATCH 06/10] KVM: arm/arm64: vgic: Allow dynamic mapping of physical/virtual interrupts Marc Zyngier
2015-06-11  8:43   ` Andre Przywara
2015-06-11  8:56     ` Marc Zyngier
2015-06-15 15:44   ` Eric Auger
2015-06-16  8:28     ` Marc Zyngier
2015-06-16  9:10       ` Eric Auger
2015-06-30 20:19   ` Christoffer Dall
2015-07-01 10:20     ` Marc Zyngier
2015-07-01 11:45       ` Christoffer Dall
2015-06-08 17:04 ` [PATCH 07/10] KVM: arm/arm64: vgic: Allow HW interrupts to be queued to a guest Marc Zyngier
2015-06-11  8:44   ` Andre Przywara
2015-06-11  9:15     ` Marc Zyngier
2015-06-11  9:44       ` Andre Przywara [this message]
2015-06-11 10:02         ` Marc Zyngier
2015-06-15 16:11           ` Eric Auger
2015-06-17 11:51   ` Eric Auger
2015-06-17 12:23     ` Marc Zyngier
2015-06-08 17:04 ` [PATCH 08/10] KVM: arm/arm64: vgic: Add vgic_{get, set}_phys_irq_active Marc Zyngier
2015-06-17 15:11   ` Eric Auger
2015-06-08 17:04 ` [PATCH 09/10] KVM: arm/arm64: timer: Allow the timer to control the active state Marc Zyngier
2015-06-08 17:04 ` [PATCH 10/10] KVM: arm/arm64: vgic: Allow non-shared device HW interrupts Marc Zyngier
2015-06-17 15:11   ` Eric Auger
2015-06-17 15:37     ` Marc Zyngier
2015-06-17 15:50       ` Eric Auger
2015-06-18  8:37         ` Marc Zyngier
2015-06-18 17:51           ` Eric Auger
2015-06-30 20:19   ` Christoffer Dall
2015-07-01  8:26     ` Marc Zyngier
2015-07-01  8:57       ` Christoffer Dall
2015-06-10  8:33 ` [PATCH 00/10] arm/arm64: KVM: Active interrupt state switching for shared devices Eric Auger
2015-06-10  9:03   ` Marc Zyngier
2015-06-10 11:13     ` Eric Auger
2015-06-18  6:51 ` 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=55795862.1050407@arm.com \
    --to=andre.przywara@arm$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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