On 8/11/2020 3:49 PM, Marc Zyngier wrote:
On 2020-08-11 02:48, Jingyi Wang wrote:
Hi Marc,
On 8/5/2020 8:13 PM, Marc Zyngier wrote:
On 2020-08-05 12:54, Jingyi Wang wrote:
Hi all,
Currently, kvm-unit-tests only support GICv3 vLPI injection. May I ask
is there any plan or suggestion on constructing irq bypass mechanism
to test vLPI direct injection in kvm-unit-tests?
I'm not sure what you are asking for here. VLPIs are only delivered
from a HW device, and the offloading mechanism isn't visible from
userspace (you either have an enabled GICv4 implementation, or
you don't).
There are ways to *trigger* device MSIs from userspace and inject
them in a guest, but that's only a debug feature, which shouldn't
be enabled on a production system.
M.
Sorry for the late reply.
As I mentioned before, we want to add vLPI direct injection test
in KUT, meanwhile measure the latency of hardware vLPI injection.
Sure, vLPI is triggered by hardware. Since kernel supports sending
ITS INT command in guest to trigger vLPI, I wonder if it is possible
So can the host.
to add an extra interface to make a vLPI hardware-offload(just as
kvm_vgic_v4_set_forwarding() does). If so, vgic_its_trigger_msi()
can inject vLPI directly instead of using LR.
The interface exists, it is in debugfs. But it mandates that the
device exists. And no, I am not willing to add an extra KVM userspace
API for this.
The whole concept of injecting an INT to measure the performance
of GICv4 is slightly bonkers, actually. Most of the cost is paid
on the injection path (queuing a pair of command, waiting until
the ITS wakes up and generate the signal...).
What you really want to measure is the time from generation of
the LPI by a device until the guest acknowledges the interrupt
to the device itself. and this can only be implemented in the
device.
M.
OK understood. I just thought measuring the latency of the path
kvm->guest can be useful.
Thanks,
Jingyi
