From: Marc Zyngier <marc.zyngier@arm.com> To: "Yang, Shunyong" <shunyong.yang@hxt-semitech.com>, "cdall@kernel.org" <cdall@kernel.org> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>, "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>, "Zheng, Joey" <yu.zheng@hxt-semitech.com>, "will.deacon@arm.com" <will.deacon@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "david.daney@cavium.com" <david.daney@cavium.com>, "eric.auger@redhat.com" <eric.auger@redhat.com> Subject: Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling Date: Mon, 12 Mar 2018 10:09:01 +0000 [thread overview] Message-ID: <103f560a-d7ad-ba6c-e129-eda172312576@arm.com> (raw) In-Reply-To: <1520822024.2985.12.camel@hxt-semitech.com> On 12/03/18 02:33, Yang, Shunyong wrote: > Hi, Marc, > > On Sun, 2018-03-11 at 12:17 +0000, Marc Zyngier wrote: >> On Sun, 11 Mar 2018 01:55:08 +0000 >> Christoffer Dall <cdall@kernel.org> wrote: >> >>> >>> On Sat, Mar 10, 2018 at 12:20 PM, Marc Zyngier <marc.zyngier@arm.co >>> m> wrote: >>>> >>>> On Fri, 09 Mar 2018 21:36:12 +0000, >>>> Christoffer Dall wrote: >>>>> >>>>> >>>>> On Thu, Mar 08, 2018 at 05:28:44PM +0000, Marc Zyngier wrote: >>>>>> >>>>>> I'd be more confident if we did forbid P+A for such >>>>>> interrupts >>>>>> altogether, as they really feel like another kind of HW >>>>>> interrupt. >>>>> How about a slightly bigger hammer: Can we avoid doing P+A for >>>>> level >>>>> interrupts completely? I don't think that really makes much >>>>> sense, and >>>>> I think we simply everything if we just come back out and >>>>> resample the >>>>> line. For an edge, something like a network card, there's a >>>>> potential >>>>> performance win to appending a new pending state, but I doubt >>>>> that this >>>>> is the case for level interrupts. >>>> I started implementing the same thing yesterday. Somehow, it >>>> feels >>>> slightly better to have the same flow for all level interrupts, >>>> including the timer, and we only use the MI on EOI as a way to >>>> trigger >>>> the next state of injection. Still testing, but looking good so >>>> far. >>>> >>>> I'm still puzzled that we have this level-but-not-quite behaviour >>>> for >>>> VFIO interrupts. At some point, it is going to bite us badly. >>>> >>> Where is the departure from level-triggered behavior with VFIO? As >>> far as I can tell, the GIC flow of the interrupts will be just a >>> level >>> interrupt, >> The GIC is fine, I believe. What is not exactly fine is the >> signalling >> from the device, which will never be dropped until the EOI has been >> detected. >> >>> >>> but we just need to make sure the resamplefd mechanism is >>> supported for both types of interrupts. Whether or not that's a >>> decent mechanism seems orthogonal to me, but that's a discussion >>> for >>> another day I think. >> Given that VFIO is built around this mechanism, I don't think we have >> a >> choice but to support it. Anyway, I came up with the following patch, >> which I tested on Seattle with mtty. It also survived my usual >> hammering of cyclictest, hackbench and bulk VM installs. >> >> Shunyong, could you please give it a go? >> >> Thanks, >> >> M. >> > > I have tested the patch. It works on QDF2400 platform > and kvm_notify_acked_irq() is called when state is idle. Thanks a lot for testing. > > BTW, I have following questions when I was debugging the issue. > Coud you please give me some help? > 1)what does "mi" mean in gic code? such as lr_signals_eoi_mi(); MI stands for Maintenance Interrupts. Life is too short to write that all the time ;-) > 2)In some __hyp_text code where printk() will cause "HYP panic:", such > as in __kvm_vcpu_run(). How can I output debug information? You can't. None of the kernel is mapped at EL2 on pre-VHE hardware. You'll need to find indirect ways of outputting information (store data in memory, and output it once you're back to EL1). Thanks again, M. -- Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling Date: Mon, 12 Mar 2018 10:09:01 +0000 [thread overview] Message-ID: <103f560a-d7ad-ba6c-e129-eda172312576@arm.com> (raw) In-Reply-To: <1520822024.2985.12.camel@hxt-semitech.com> On 12/03/18 02:33, Yang, Shunyong wrote: > Hi, Marc, > > On Sun, 2018-03-11 at 12:17 +0000, Marc Zyngier wrote: >> On Sun, 11 Mar 2018 01:55:08 +0000 >> Christoffer Dall <cdall@kernel.org> wrote: >> >>> >>> On Sat, Mar 10, 2018 at 12:20 PM, Marc Zyngier <marc.zyngier@arm.co >>> m> wrote: >>>> >>>> On Fri, 09 Mar 2018 21:36:12 +0000, >>>> Christoffer Dall wrote:?? >>>>> >>>>> >>>>> On Thu, Mar 08, 2018 at 05:28:44PM +0000, Marc Zyngier wrote:?? >>>>>> >>>>>> I'd be more confident if we did forbid P+A for such >>>>>> interrupts >>>>>> altogether, as they really feel like another kind of HW >>>>>> interrupt.?? >>>>> How about a slightly bigger hammer:??Can we avoid doing P+A for >>>>> level >>>>> interrupts completely???I don't think that really makes much >>>>> sense, and >>>>> I think we simply everything if we just come back out and >>>>> resample the >>>>> line.??For an edge, something like a network card, there's a >>>>> potential >>>>> performance win to appending a new pending state, but I doubt >>>>> that this >>>>> is the case for level interrupts.?? >>>> I started implementing the same thing yesterday. Somehow, it >>>> feels >>>> slightly better to have the same flow for all level interrupts, >>>> including the timer, and we only use the MI on EOI as a way to >>>> trigger >>>> the next state of injection. Still testing, but looking good so >>>> far. >>>> >>>> I'm still puzzled that we have this level-but-not-quite behaviour >>>> for >>>> VFIO interrupts. At some point, it is going to bite us badly. >>>> ? >>> Where is the departure from level-triggered behavior with VFIO???As >>> far as I can tell, the GIC flow of the interrupts will be just a >>> level >>> interrupt,? >> The GIC is fine, I believe. What is not exactly fine is the >> signalling >> from the device, which will never be dropped until the EOI has been >> detected. >> >>> >>> but we just need to make sure the resamplefd mechanism is >>> supported for both types of interrupts.??Whether or not that's a >>> decent mechanism seems orthogonal to me, but that's a discussion >>> for >>> another day I think. >> Given that VFIO is built around this mechanism, I don't think we have >> a >> choice but to support it. Anyway, I came up with the following patch, >> which I tested on Seattle with mtty. It also survived my usual >> hammering of cyclictest, hackbench??and bulk VM installs. >> >> Shunyong, could you please give it a go? >> >> Thanks, >> >> M. >> > > I have tested the patch. It works on QDF2400 platform > and?kvm_notify_acked_irq() is called when state is idle. Thanks a lot for testing. > > BTW, I have following questions when I was debugging the issue. > Coud you please give me some help? > 1)what does "mi" mean in gic code? such as lr_signals_eoi_mi(); MI stands for Maintenance Interrupts. Life is too short to write that all the time ;-) > 2)In some __hyp_text?code where printk() will cause "HYP panic:", such > as in __kvm_vcpu_run(). How can I output debug information? You can't. None of the kernel is mapped at EL2 on pre-VHE hardware. You'll need to find indirect ways of outputting information (store data in memory, and output it once you're back to EL1). Thanks again, M. -- Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2018-03-12 10:09 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-08 7:01 [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling Shunyong Yang 2018-03-08 7:01 ` Shunyong Yang 2018-03-08 7:01 ` Shunyong Yang 2018-03-08 8:57 ` Auger Eric 2018-03-08 8:57 ` Auger Eric 2018-03-08 9:31 ` [此邮件可能存在风险] " Yang, Shunyong 2018-03-08 9:31 ` Yang, Shunyong 2018-03-08 11:01 ` Marc Zyngier 2018-03-08 11:01 ` Marc Zyngier 2018-03-08 15:29 ` Auger Eric 2018-03-08 15:29 ` Auger Eric 2018-03-08 9:49 ` Marc Zyngier 2018-03-08 9:49 ` Marc Zyngier 2018-03-08 9:49 ` Marc Zyngier 2018-03-08 11:54 ` Marc Zyngier 2018-03-08 11:54 ` Marc Zyngier 2018-03-08 16:09 ` Auger Eric 2018-03-08 16:09 ` Auger Eric 2018-03-08 16:19 ` Christoffer Dall 2018-03-08 16:19 ` Christoffer Dall 2018-03-08 17:28 ` Marc Zyngier 2018-03-08 17:28 ` Marc Zyngier 2018-03-08 18:12 ` Auger Eric 2018-03-08 18:12 ` Auger Eric 2018-03-09 3:14 ` Yang, Shunyong 2018-03-09 3:14 ` Yang, Shunyong 2018-03-09 9:40 ` Marc Zyngier 2018-03-09 9:40 ` Marc Zyngier 2018-03-09 13:10 ` Auger Eric 2018-03-09 13:10 ` Auger Eric 2018-03-09 13:37 ` Marc Zyngier 2018-03-09 13:37 ` Marc Zyngier 2018-03-09 9:12 ` Marc Zyngier 2018-03-09 9:12 ` Marc Zyngier 2018-03-09 13:18 ` Auger Eric 2018-03-09 13:18 ` Auger Eric 2018-03-09 21:36 ` Christoffer Dall 2018-03-09 21:36 ` Christoffer Dall 2018-03-10 12:20 ` Marc Zyngier 2018-03-10 12:20 ` Marc Zyngier 2018-03-11 1:55 ` Christoffer Dall 2018-03-11 1:55 ` Christoffer Dall 2018-03-11 12:17 ` Marc Zyngier 2018-03-11 12:17 ` Marc Zyngier 2018-03-12 2:33 ` Yang, Shunyong 2018-03-12 2:33 ` Yang, Shunyong 2018-03-12 10:09 ` Marc Zyngier [this message] 2018-03-12 10:09 ` Marc Zyngier 2018-03-08 16:10 ` Christoffer Dall 2018-03-08 16:10 ` Christoffer Dall
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=103f560a-d7ad-ba6c-e129-eda172312576@arm.com \ --to=marc.zyngier@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=cdall@kernel.org \ --cc=david.daney@cavium.com \ --cc=eric.auger@redhat.com \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=shunyong.yang@hxt-semitech.com \ --cc=will.deacon@arm.com \ --cc=yu.zheng@hxt-semitech.com \ /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: linkBe 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.