Re: [kvm-unit-tests PATCH v3 00/10] arm/arm64: Add IPI/LPI/vtimer latency test

From: Jingyi Wang <wangjingyi11@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: <drjones@redhat.com>, <kvm@vger.kernel.org>,
	<kvmarm@lists.cs.columbia.edu>, <eric.auger@redhat.com>,
	<wanghaibin.wang@huawei.com>, <yuzenghui@huawei.com>
Subject: Re: [kvm-unit-tests PATCH v3 00/10] arm/arm64: Add IPI/LPI/vtimer latency test
Date: Mon, 17 Aug 2020 09:46:17 +0800	[thread overview]
Message-ID: <d9aa5414-490e-179f-d789-3c929ffe0727@huawei.com> (raw)
In-Reply-To: <b175763e4f4f08ecdae46e6e87b0bc81@kernel.org>

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