All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Wei Liu <wl@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 1/5] evtchn: drop acquiring of per-channel lock from send_guest_{global,vcpu}_virq()
Date: Thu, 3 Dec 2020 10:46:34 +0100	[thread overview]
Message-ID: <c15b1e7e-ed9c-b597-2fc1-b8cf89999c55@suse.com> (raw)
In-Reply-To: <70170293-a9a7-282a-dde6-7ed73fc2da48@xen.org>

On 02.12.2020 20:03, Julien Grall wrote:
> On 23/11/2020 13:28, Jan Beulich wrote:
>> The per-vCPU virq_lock, which is being held anyway, together with there
>> not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
>> is zero, provide sufficient guarantees. 
> 
> I agree that the per-vCPU virq_lock is going to be sufficient, however 
> dropping the lock also means the event channel locking is more complex 
> to understand (the long comment that was added proves it).
> 
> In fact, the locking in the event channel code was already proven to be 
> quite fragile, therefore I think this patch is not worth the risk.

I agree this is a very reasonable position to take. I probably
would even have remained silent if in the meantime the
spin_lock()s there hadn't changed to read_trylock()s. I really
think we want to limit this unusual locking model to where we
strictly need it. And this change eliminates 50% of them, with
the added benefit of making the paths more lightweight.

Jan


  reply	other threads:[~2020-12-03  9:46 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23 13:26 [PATCH v3 0/5] evtchn: (not so) recent XSAs follow-on Jan Beulich
2020-11-23 13:28 ` [PATCH v3 1/5] evtchn: drop acquiring of per-channel lock from send_guest_{global,vcpu}_virq() Jan Beulich
2020-12-02 19:03   ` Julien Grall
2020-12-03  9:46     ` Jan Beulich [this message]
2020-12-09  9:53       ` Julien Grall
2020-12-09 14:24         ` Jan Beulich
2020-11-23 13:28 ` [PATCH v3 2/5] evtchn: avoid access tearing for ->virq_to_evtchn[] accesses Jan Beulich
2020-12-02 21:14   ` Julien Grall
2020-11-23 13:28 ` [PATCH v3 3/5] evtchn: convert vIRQ lock to an r/w one Jan Beulich
2020-12-09 11:16   ` Julien Grall
2020-11-23 13:29 ` [PATCH v3 4/5] evtchn: convert domain event " Jan Beulich
2020-12-09 11:54   ` Julien Grall
2020-12-11 10:32     ` Jan Beulich
2020-12-11 10:57       ` Julien Grall
2020-12-14  9:40         ` Jan Beulich
2020-12-21 17:45           ` Julien Grall
2020-12-22  9:46             ` Jan Beulich
2020-12-23 11:22               ` Julien Grall
2020-12-23 12:57                 ` Jan Beulich
2020-12-23 13:19                   ` Julien Grall
2020-12-23 13:36                     ` Jan Beulich
2020-11-23 13:30 ` [PATCH v3 5/5] evtchn: don't call Xen consumer callback with per-channel lock held Jan Beulich
2020-11-30 10:39   ` Isaila Alexandru
2020-12-02 21:10   ` Julien Grall
2020-12-03 10:09     ` Jan Beulich
2020-12-03 14:40       ` Tamas K Lengyel
2020-12-04 11:28       ` Julien Grall
2020-12-04 11:48         ` Jan Beulich
2020-12-04 11:51           ` Julien Grall
2020-12-04 12:01             ` Jan Beulich
2020-12-04 15:09               ` Julien Grall
2020-12-07  8:02                 ` Jan Beulich
2020-12-07 17:22                   ` Julien Grall
2020-12-04 15:21         ` Tamas K Lengyel
2020-12-04 15:29           ` Julien Grall
2020-12-04 19:15             ` Tamas K Lengyel
2020-12-04 19:22               ` Julien Grall
2020-12-04 21:23                 ` Tamas K Lengyel
2020-12-07 15:28               ` Jan Beulich
2020-12-07 17:30                 ` Julien Grall
2020-12-07 17:35                   ` Tamas K Lengyel
2020-12-23 13:12                     ` Jan Beulich
2020-12-23 13:33                       ` Julien Grall
2020-12-23 13:41                         ` Jan Beulich
2020-12-23 14:44                           ` Julien Grall
2020-12-23 14:56                             ` Jan Beulich
2020-12-23 15:08                               ` Julien Grall
2020-12-23 15:15                             ` Tamas K Lengyel

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=c15b1e7e-ed9c-b597-2fc1-b8cf89999c55@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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 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.