From: Christoffer Dall <cdall@kernel.org> To: Marc Zyngier <marc.zyngier@arm.com> Cc: Shunyong Yang <shunyong.yang@hxt-semitech.com>, ard.biesheuvel@linaro.org, will.deacon@arm.com, eric.auger@redhat.com, david.daney@cavium.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, Joey Zheng <yu.zheng@hxt-semitech.com> Subject: Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling Date: Fri, 9 Mar 2018 13:36:12 -0800 [thread overview] Message-ID: <20180309213612.GD1917@lvm> (raw) In-Reply-To: <86r2oubho3.wl-marc.zyngier@arm.com> On Thu, Mar 08, 2018 at 05:28:44PM +0000, Marc Zyngier wrote: > On Thu, 08 Mar 2018 16:19:00 +0000, > Christoffer Dall wrote: > > > > On Thu, Mar 08, 2018 at 11:54:27AM +0000, Marc Zyngier wrote: > > > On 08/03/18 09:49, Marc Zyngier wrote: [...] > > > The state is now pending, we've really EOI'd the interrupt, and > > > yet lr_signals_eoi_mi() returns false, since the state is not 0. > > > The result is that we won't signal anything on the corresponding > > > irqfd, which people complain about. Meh. > > > > So the core of the problem is that when we've entered the guest with > > PENDING+ACTIVE and when we exit (for some reason) we don't signal the > > resamplefd, right? The solution seems to me that we don't ever do > > PENDING+ACTIVE if you need to resample after each deactivate. What > > would be the point of appending a pending state that you only know to be > > valid after a resample anyway? > > The question is then to identify that a given source needs to be > signalled back to VFIO. Calling into the eventfd code on the hot path > is pretty horrid (I'm not sure if we can really call into this with > interrupts disabled, for example). > This feels like a bad layering violation to me as well. > > > > > > > > Example 2: > > > P+A -> guest EOI -> P -> delayed MI -> guest IAR -> A -> MI fires > > > > We could be more clever and do the following calculation on every exit: > > > > If you enter with P, and exit with either A or 0, then signal. > > > > If you enter with P+A, and you exit with either P, A, or 0, then signal. > > > > Wouldn't that also solve it? (Although I have a feeling you'd miss some > > exits in this case). > > 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. The timer would be unaffected, because it's a HW interrupt. Thanks, -Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: cdall@kernel.org (Christoffer Dall) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling Date: Fri, 9 Mar 2018 13:36:12 -0800 [thread overview] Message-ID: <20180309213612.GD1917@lvm> (raw) In-Reply-To: <86r2oubho3.wl-marc.zyngier@arm.com> On Thu, Mar 08, 2018 at 05:28:44PM +0000, Marc Zyngier wrote: > On Thu, 08 Mar 2018 16:19:00 +0000, > Christoffer Dall wrote: > > > > On Thu, Mar 08, 2018 at 11:54:27AM +0000, Marc Zyngier wrote: > > > On 08/03/18 09:49, Marc Zyngier wrote: [...] > > > The state is now pending, we've really EOI'd the interrupt, and > > > yet lr_signals_eoi_mi() returns false, since the state is not 0. > > > The result is that we won't signal anything on the corresponding > > > irqfd, which people complain about. Meh. > > > > So the core of the problem is that when we've entered the guest with > > PENDING+ACTIVE and when we exit (for some reason) we don't signal the > > resamplefd, right? The solution seems to me that we don't ever do > > PENDING+ACTIVE if you need to resample after each deactivate. What > > would be the point of appending a pending state that you only know to be > > valid after a resample anyway? > > The question is then to identify that a given source needs to be > signalled back to VFIO. Calling into the eventfd code on the hot path > is pretty horrid (I'm not sure if we can really call into this with > interrupts disabled, for example). > This feels like a bad layering violation to me as well. > > > > > > > > Example 2: > > > P+A -> guest EOI -> P -> delayed MI -> guest IAR -> A -> MI fires > > > > We could be more clever and do the following calculation on every exit: > > > > If you enter with P, and exit with either A or 0, then signal. > > > > If you enter with P+A, and you exit with either P, A, or 0, then signal. > > > > Wouldn't that also solve it? (Although I have a feeling you'd miss some > > exits in this case). > > 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. The timer would be unaffected, because it's a HW interrupt. Thanks, -Christoffer
next prev parent reply other threads:[~2018-03-09 21:36 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 [this message] 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 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=20180309213612.GD1917@lvm \ --to=cdall@kernel.org \ --cc=ard.biesheuvel@linaro.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=marc.zyngier@arm.com \ --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.