Hello!
I also have an implementation of GSI routing on ARM, basically a rebase
of my old/first implementation of irqfd
(https://patches.linaro.org/32261/) based on irqchip gsi routing qemu
part (https://lists.gnu.org/archive/html/qemu-devel/2014-07/msg01090.html).
I took a glance at it,
On 06/17/2015 01:46 PM, Pavel Fedin wrote:
Hello!
Yes, I am about to get a v2 ready, but mostly with some fixes. If you
want to work on top of it, I can push a WIP branch to my repo.
Thank you but no need to hurry up. I am busy with other things too. And,
anyway, i work on top of my
Hello!
Yes, I am about to get a v2 ready, but mostly with some fixes. If you
want to work on top of it, I can push a WIP branch to my repo.
Thank you but no need to hurry up. I am busy with other things too. And,
anyway, i work on top of my own branch here.
As Marc mentioned before, this
: IRQFD support with GICv3 ITS (WAS: RE: [PATCH 00/13] arm64: KVM:
GICv3 ITS
emulation)
Hi!
indeed in newly added qemu kvm-all.c kvm_arch_msi_data_to_gsi we could
call a new ioctl that translates the data + deviceid? into an LPI and
program irqfd with that LPI. This is done once when
Hello!
Hmmm. You may not have noticed it, but we're actually all are quite busy
at the moment (hint, we're at -rc8, and the next merge window is about
to open).
Ok ok, i do not mind of course. :) Just i expected at least some, quick reply.
It's like
talking to a person while he/she
-ker...@lists.infradead.org;
kvm@vger.kernel.org
Subject: RE: IRQFD support with GICv3 ITS (WAS: RE: [PATCH 00/13] arm64:
KVM: GICv3 ITS
emulation)
Hi!
indeed in newly added qemu kvm-all.c kvm_arch_msi_data_to_gsi we could
call a new ioctl that translates the data + deviceid? into an LPI
...@linaro.org
Cc: kvm...@lists.cs.columbia.edu; linux-arm-ker...@lists.infradead.org;
kvm@vger.kernel.org
Subject: RE: IRQFD support with GICv3 ITS (WAS: RE: [PATCH 00/13] arm64:
KVM: GICv3 ITS
emulation)
Hi!
indeed in newly added qemu kvm-all.c kvm_arch_msi_data_to_gsi we could
call a new
Hi! I have researched the promised third bug in your implementation. It
reproduces if you
start qemu with -S switch, and then immediately exit it without actually
running the OS.
In KVM vGIC initialization is lazy and performed when first vCPU is booted up
for the
first time. Consequently, if
Hello guys!
Currently on ARM, irqfd supports routing an host eventfd towards a
virtual SPI:
eventfd - vSPI = gsi+32
parameters of irqfd are the eventfd and the gsi.
Yes, but this works only with GICv2m, because it actually turns MSI data into
SPI number.
ITS works in a completely
Hi,
On 06/10/2015 10:31 AM, Pavel Fedin wrote:
Hello guys!
Currently on ARM, irqfd supports routing an host eventfd towards a
virtual SPI:
eventfd - vSPI = gsi+32
parameters of irqfd are the eventfd and the gsi.
Yes, but this works only with GICv2m, because it actually turns MSI data
Hello!
KVM GSI routing, even if only used for MSI routing then mandates to
build entries for non MSI IRQs, using irqchip routing entries. Then you
draw the irqchip.c kvm_irq_routing_table
chip[KVM_NR_IRQCHIPS][KVM_IRQCHIP_NUM_PINS] static allocation issue.
Sorry for this add-on, needed
Hi!
indeed in newly added qemu kvm-all.c kvm_arch_msi_data_to_gsi we could
call a new ioctl that translates the data + deviceid? into an LPI and
program irqfd with that LPI. This is done once when setting irqfd up.
This also means extending irqfd support to lpi injection, gsi being the
LPI
On 06/08/2015 12:54 PM, Pavel Fedin wrote:
Hi!
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)?
Currently on ARM,
On 08/06/15 11:54, Pavel Fedin wrote:
Hi!
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)?
But... As far as i
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
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
Hi!
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)?
But... As far as i could understand, LPI is added to a
17 matches
Mail list logo
