kvmarm.lists.cs.columbia.edu archive mirror
 help / color / mirror / Atom feed
From: Jingyi Wang <wangjingyi11@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu
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

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2020-08-17  1:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31  7:42 [kvm-unit-tests PATCH v3 00/10] arm/arm64: Add IPI/LPI/vtimer latency test Jingyi Wang
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 01/10] arm64: microbench: get correct ipi received num Jingyi Wang
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 02/10] arm64: microbench: Generalize ipi test names Jingyi Wang
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 03/10] arm64: microbench: gic: Add ipi latency test for gicv4.1 support kvm Jingyi Wang
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 04/10] arm64: its: Handle its command queue wrapping Jingyi Wang
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 05/10] arm64: microbench: its: Add LPI latency test Jingyi Wang
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 06/10] arm64: microbench: Allow each test to specify its running times Jingyi Wang
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 07/10] arm64: microbench: Add time limit for each individual test Jingyi Wang
2020-08-01 16:13   ` Andrew Jones
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 08/10] arm64: microbench: Add vtimer latency test Jingyi Wang
2020-08-01 16:22   ` Andrew Jones
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 09/10] arm64: microbench: Add test->post() to further process test results Jingyi Wang
2020-08-01 17:03   ` Andrew Jones
2020-07-31  7:42 ` [kvm-unit-tests PATCH v3 10/10] arm64: microbench: Add timer_post() to get actual PPI latency Jingyi Wang
2020-07-31 12:01 ` [kvm-unit-tests PATCH v3 00/10] arm/arm64: Add IPI/LPI/vtimer latency test Andrew Jones
2020-08-03  2:15   ` Jingyi Wang
2020-08-01 17:40 ` Andrew Jones
2020-08-05 11:54 ` Jingyi Wang
2020-08-05 12:13   ` Marc Zyngier
2020-08-11  1:48     ` Jingyi Wang
2020-08-11  7:49       ` Marc Zyngier
2020-08-17  1:46         ` Jingyi Wang [this message]
2020-08-17  8:26           ` Marc Zyngier

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=d9aa5414-490e-179f-d789-3c929ffe0727@huawei.com \
    --to=wangjingyi11@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=maz@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).