All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/13] arm64: KVM: GICv3 ITS emulation
Date: Mon, 08 Jun 2015 09:23:12 +0100	[thread overview]
Message-ID: <557550F0.5070106@arm.com> (raw)
In-Reply-To: <01ad01d0a1b7$d4d4fe40$7e7efac0$@samsung.com>

Hi Pavel,

On 08/06/15 07:53, Pavel Fedin wrote:
>  Hello everybody!
> 
>> The GICv3 ITS (Interrupt Translation Service) is a part of the
>> ARM GICv3 interrupt controller used for implementing MSIs.
>> It specifies a new kind of interrupts (LPIs), which are mapped to
>> establish a connection between a device, its MSI payload value and
>> the target processor the IRQ is eventually delivered to.
>> In order to allow using MSIs in an ARM64 KVM guest, we emulate this
>> ITS widget in the kernel.
> 
>  I have tested the patch and got some more ideas for future extension...
> 
>  First of all, it would be nice to have a possibility to directly inject LPIs by number.
> This will be useful for irqfd support in qemu.

Well, that poses the question of what we emulate. We expose the
emulation of an ITS, hence no direct access to the LPI space. What we
could do would be allow LPI injection if not ITS is instantiated in the
kernel. But a mix of the two is likely to in contradiction with the
architecture.

>  Next, irqfd support currently poses a problem. We need to somehow know IRQ number from
> MSI-X data (device ID plus event ID). ITS has all this information, so it would be nice to
> be able to query for the translation from within userspace. The question is - how to do
> it? Should we add some ioctl for this purpose? Currently i am experimenting with extra
> KVM_TRANSLATE_MSI ioctl which, given MSI data, would return LPI number.

I'm afraid this is not enough. A write to GICR_TRANSLATER (DID+EID)
results in a (LPI,CPU) pair. Can you easily express the CPU part in
irqfd (this is a genuine question, I'm not familiar enough with that
part of the core)?

>  Actually before your patch came out i have almost done the same thing. But instead i
> decided to implement ITS in qemu while leaving LPI handling to kernel. In this case my
> qemu would have everything needed.
>  By the way, why did you decide to put everything into kernel? Yes, in-kernel emulation is
> faster, but ITS is not accessed frequently.

It may be interesting to find out what would be the implications if we
were to put it in userspace.

The obvious one would be that we'd have to duplicate the code in both
QEMU and kvmtool, and I don't think anyone fancies that. Another concern
would be the support of GICv4, which relies on the command queue
handling to be handled in the kernel (the GICv4 handling is basically a
command translation system, and I'm not prepared to let userspace inject
commands in the host ITS).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: Pavel Fedin <p.fedin@samsung.com>,
	Andre Przywara <Andre.Przywara@arm.com>,
	"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>
Cc: "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 00/13] arm64: KVM: GICv3 ITS emulation
Date: Mon, 08 Jun 2015 09:23:12 +0100	[thread overview]
Message-ID: <557550F0.5070106@arm.com> (raw)
In-Reply-To: <01ad01d0a1b7$d4d4fe40$7e7efac0$@samsung.com>

Hi Pavel,

On 08/06/15 07:53, Pavel Fedin wrote:
>  Hello everybody!
> 
>> The GICv3 ITS (Interrupt Translation Service) is a part of the
>> ARM GICv3 interrupt controller used for implementing MSIs.
>> It specifies a new kind of interrupts (LPIs), which are mapped to
>> establish a connection between a device, its MSI payload value and
>> the target processor the IRQ is eventually delivered to.
>> In order to allow using MSIs in an ARM64 KVM guest, we emulate this
>> ITS widget in the kernel.
> 
>  I have tested the patch and got some more ideas for future extension...
> 
>  First of all, it would be nice to have a possibility to directly inject LPIs by number.
> This will be useful for irqfd support in qemu.

Well, that poses the question of what we emulate. We expose the
emulation of an ITS, hence no direct access to the LPI space. What we
could do would be allow LPI injection if not ITS is instantiated in the
kernel. But a mix of the two is likely to in contradiction with the
architecture.

>  Next, irqfd support currently poses a problem. We need to somehow know IRQ number from
> MSI-X data (device ID plus event ID). ITS has all this information, so it would be nice to
> be able to query for the translation from within userspace. The question is - how to do
> it? Should we add some ioctl for this purpose? Currently i am experimenting with extra
> KVM_TRANSLATE_MSI ioctl which, given MSI data, would return LPI number.

I'm afraid this is not enough. A write to GICR_TRANSLATER (DID+EID)
results in a (LPI,CPU) pair. Can you easily express the CPU part in
irqfd (this is a genuine question, I'm not familiar enough with that
part of the core)?

>  Actually before your patch came out i have almost done the same thing. But instead i
> decided to implement ITS in qemu while leaving LPI handling to kernel. In this case my
> qemu would have everything needed.
>  By the way, why did you decide to put everything into kernel? Yes, in-kernel emulation is
> faster, but ITS is not accessed frequently.

It may be interesting to find out what would be the implications if we
were to put it in userspace.

The obvious one would be that we'd have to duplicate the code in both
QEMU and kvmtool, and I don't think anyone fancies that. Another concern
would be the support of GICv4, which relies on the command queue
handling to be handled in the kernel (the GICv4 handling is basically a
command translation system, and I'm not prepared to let userspace inject
commands in the host ITS).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2015-06-08  8:23 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-29  9:53 [PATCH 00/13] arm64: KVM: GICv3 ITS emulation Andre Przywara
2015-05-29  9:53 ` Andre Przywara
2015-05-29  9:53 ` [PATCH 01/13] KVM: arm/arm64: VGIC: don't track used LRs in the distributor Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-12 17:23   ` Eric Auger
2015-05-29  9:53 ` [PATCH 02/13] KVM: extend struct kvm_msi to hold a 32-bit device ID Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-09  8:49   ` Eric Auger
2015-06-09  8:49     ` Eric Auger
2015-06-28 19:12   ` Christoffer Dall
2015-06-28 19:12     ` Christoffer Dall
2015-06-29 14:53     ` Andre Przywara
2015-06-29 14:53       ` Andre Przywara
2015-06-29 15:02       ` Christoffer Dall
2015-06-29 15:02         ` Christoffer Dall
2015-05-29  9:53 ` [PATCH 03/13] KVM: arm/arm64: add emulation model specific destroy function Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-09  8:51   ` Eric Auger
2015-06-09  8:51     ` Eric Auger
2015-06-28 19:14   ` Christoffer Dall
2015-06-28 19:14     ` Christoffer Dall
2015-05-29  9:53 ` [PATCH 04/13] KVM: arm64: Introduce new MMIO region for the ITS base address Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-09  8:52   ` Eric Auger
2015-06-09  8:52     ` Eric Auger
2015-06-11 15:12     ` Andre Przywara
2015-06-11 15:12       ` Andre Przywara
2015-05-29  9:53 ` [PATCH 05/13] KVM: arm64: handle ITS related GICv3 redistributor registers Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-09  8:52   ` Eric Auger
2015-06-09  8:52     ` Eric Auger
2015-06-12 17:03     ` Andre Przywara
2015-06-12 17:03       ` Andre Przywara
2015-05-29  9:53 ` [PATCH 06/13] KVM: arm64: introduce ITS emulation file with stub functions Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-09  9:23   ` Eric Auger
2015-06-09  9:23     ` Eric Auger
2015-05-29  9:53 ` [PATCH 07/13] KVM: arm64: implement basic ITS register handlers Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-09 13:34   ` Eric Auger
2015-06-09 13:34     ` Eric Auger
2015-06-28 19:36   ` Christoffer Dall
2015-06-28 19:36     ` Christoffer Dall
2015-05-29  9:53 ` [PATCH 08/13] KVM: arm64: add data structures to model ITS interrupt translation Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-09 15:59   ` Eric Auger
2015-06-09 15:59     ` Eric Auger
2015-05-29  9:53 ` [PATCH 09/13] KVM: arm64: handle pending bit for LPIs in ITS emulation Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-09 15:59   ` Eric Auger
2015-06-09 15:59     ` Eric Auger
2015-06-11 15:46     ` Andre Przywara
2015-06-11 15:46       ` Andre Przywara
2015-06-11 16:01       ` Marc Zyngier
2015-06-11 16:01         ` Marc Zyngier
2015-06-11 18:24         ` Eric Auger
2015-06-11 18:24           ` Eric Auger
2015-05-29  9:53 ` [PATCH 10/13] KVM: arm64: sync LPI properties and status between guest and KVM Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-11 17:44   ` Eric Auger
2015-06-11 17:44     ` Eric Auger
2015-06-28 19:33   ` Christoffer Dall
2015-06-28 19:33     ` Christoffer Dall
2015-05-29  9:53 ` [PATCH 11/13] KVM: arm64: implement ITS command queue command handlers Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-12 15:28   ` Eric Auger
2015-06-12 15:28     ` Eric Auger
2015-06-28 19:41   ` Christoffer Dall
2015-06-28 19:41     ` Christoffer Dall
2015-07-03 15:57     ` Andre Przywara
2015-07-03 15:57       ` Andre Przywara
2015-07-03 21:01       ` Christoffer Dall
2015-07-03 21:01         ` Christoffer Dall
2015-05-29  9:53 ` [PATCH 12/13] KVM: arm64: implement MSI injection in ITS emulation Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-11 17:43   ` Eric Auger
2015-06-11 17:43     ` Eric Auger
2015-07-06 16:46     ` Andre Przywara
2015-07-06 16:46       ` Andre Przywara
2015-07-07  8:13       ` Christoffer Dall
2015-07-07  8:13         ` Christoffer Dall
2015-05-29  9:53 ` [PATCH 13/13] KVM: arm64: enable ITS emulation as a virtual MSI controller Andre Przywara
2015-05-29  9:53   ` Andre Przywara
2015-06-12 16:05   ` Eric Auger
2015-06-12 16:05     ` Eric Auger
2015-06-18  8:43   ` Eric Auger
2015-06-18  8:43     ` Eric Auger
2015-06-18 14:22     ` Andre Przywara
2015-06-18 14:22       ` Andre Przywara
2015-06-18 15:03       ` Pavel Fedin
2015-06-18 15:03         ` Pavel Fedin
2015-06-18 19:20         ` Andre Przywara
2015-06-18 19:20           ` Andre Przywara
2015-06-08  6:53 ` [PATCH 00/13] arm64: KVM: GICv3 ITS emulation Pavel Fedin
2015-06-08  6:53   ` Pavel Fedin
2015-06-08  8:23   ` Marc Zyngier [this message]
2015-06-08  8:23     ` Marc Zyngier
2015-06-08 10:54     ` Pavel Fedin
2015-06-08 10:54       ` Pavel Fedin
2015-06-08 17:13       ` Marc Zyngier
2015-06-08 17:13         ` Marc Zyngier
2015-06-09  8:12       ` Eric Auger
2015-06-09  8:12         ` Eric Auger
2015-06-10 12:18 ` Pavel Fedin

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=557550F0.5070106@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.