From: Marc Zyngier <marc.zyngier@arm.com>
To: Heyi Guo <guoheyi@huawei.com>
Cc: linux-kernel@vger.kernel.org, kvmarm <kvmarm@lists.cs.columbia.edu>
Subject: Re: ARM/gic-v4: deadlock occurred
Date: Mon, 06 May 2019 10:21:10 +0100 [thread overview]
Message-ID: <86k1f49bw9.wl-marc.zyngier@arm.com> (raw)
In-Reply-To: <db3bb9c1-8b3a-760d-057f-b8fb6914809b@huawei.com>
On Sun, 05 May 2019 12:15:51 +0100,
Heyi Guo <guoheyi@huawei.com> wrote:
>
> BTW since its_irq_set_vcpu_affinity() is already in atomic context,
> do we really need a separate lock its_dev->event_map.vlpi_lock? I
> didn't find anywhere outside its_irq_set_vcpu_affinity() call chain
> acquires this lock.
The reason is that the vlpi_maps array covers the whole of the
generating device, and not just a single interrupt. Relying on the
irq_desc lock to protect the array wouldn't work, as you could still
have concurrent accesses to the array (map, unmap and get all access
the same data).
So one way or another, we need some form of mutual exclusion at this
level. I guess one of the design mistakes that we have in the current
code is that there is no "device wide" operation, and that we rely on
map/unmap to perform the allocations on demand in the low level code.
What we could potentially do would be to move this allocation higher
up in the stack, and track the first time an LPI is turned into a VLPI
at that level. That's an invasive change though...
Thanks,
M.
--
Jazz is not dead, it just smell funny.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
prev parent reply other threads:[~2019-05-06 9:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9efe0260-4a84-7489-ecdd-2e9561599320@huawei.com>
2019-05-05 10:38 ` ARM/gic-v4: deadlock occurred Marc Zyngier
2019-05-05 11:07 ` Heyi Guo
2019-05-08 12:31 ` Marc Zyngier
2019-05-08 13:01 ` Heyi Guo
2019-05-09 7:48 ` Marc Zyngier
2019-05-09 11:37 ` Heyi Guo
2019-07-13 11:08 ` Guoheyi
2019-07-13 11:37 ` Marc Zyngier
2019-07-15 6:32 ` Guoheyi
2019-07-15 9:07 ` Marc Zyngier
2019-07-15 10:43 ` Guoheyi
2019-07-15 11:13 ` Marc Zyngier
2019-07-15 12:48 ` Guoheyi
2019-05-05 11:15 ` Heyi Guo
2019-05-06 9:21 ` Marc Zyngier [this message]
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=86k1f49bw9.wl-marc.zyngier@arm.com \
--to=marc.zyngier@arm.com \
--cc=guoheyi@huawei.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-kernel@vger.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).