From: Jan Beulich <jbeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
George Dunlap <George.Dunlap@eu.citrix.com>
Subject: Re: [PATCH 5/5] x86/p2m: split write_p2m_entry() hook
Date: Fri, 13 Nov 2020 10:52:58 +0100 [thread overview]
Message-ID: <40055cf5-ab16-ad73-4446-3f8f730a6613@suse.com> (raw)
In-Reply-To: <20201112175221.GB43943@deinos.phlegethon.org>
On 12.11.2020 18:52, Tim Deegan wrote:
> At 15:04 +0100 on 12 Nov (1605193496), Jan Beulich wrote:
>> On 12.11.2020 14:07, Roger Pau Monné wrote:
>>> On Thu, Nov 12, 2020 at 01:29:33PM +0100, Jan Beulich wrote:
>>>> I agree with all this. If only it was merely about TLB flushes. In
>>>> the shadow case, shadow_blow_all_tables() gets invoked, and that
>>>> one - looking at the other call sites - wants the paging lock held.
> [...]
>>> The post hook for shadow could pick the lock again, as I don't think
>>> the removal of the tables needs to be strictly done inside of the same
>>> locked region?
>>
>> I think it does, or else a use of the now stale tables may occur
>> before they got blown away. Tim?
>
> Is this the call to shadow_blow_tables() in the write_p2m_entry path?
Yes.
> I think it would be safe to drop and re-take the paging lock there as
> long as the call happens before the write is considered to have
> finished.
>
> But it would not be a useful performance improvement - any update that
> takes this path is going to be very slow regardless. So unless you
> have another pressing reason to split it up, I would be inclined to
> leave it as it is. That way it's easier to see that the locking is
> correct.
Thanks for the clarification.
Roger - what's your view at this point?
Jan
next prev parent reply other threads:[~2020-11-13 9:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 9:20 [PATCH 0/5] x86/p2m: hook adjustments Jan Beulich
2020-10-28 9:22 ` [PATCH 1/5] x86/p2m: paging_write_p2m_entry() is a private function Jan Beulich
2020-11-10 10:27 ` Roger Pau Monné
2020-11-10 10:32 ` Jan Beulich
2020-10-28 9:22 ` [PATCH 2/5] x86/p2m: collapse the two ->write_p2m_entry() hooks Jan Beulich
2020-10-29 20:36 ` Tim Deegan
2020-11-10 11:06 ` Roger Pau Monné
2020-11-10 13:51 ` Jan Beulich
2020-11-18 9:44 ` Roger Pau Monné
2020-10-28 9:23 ` [PATCH 3/5] x86/p2m: suppress audit_p2m hook when possible Jan Beulich
2020-11-10 11:30 ` Roger Pau Monné
2020-11-10 13:21 ` Jan Beulich
2020-11-10 14:01 ` Roger Pau Monné
2020-10-28 9:24 ` [PATCH 4/5] x86/HAP: move nested-P2M flush calculations out of locked region Jan Beulich
2020-11-10 11:38 ` Roger Pau Monné
2020-10-28 9:24 ` [PATCH 5/5] x86/p2m: split write_p2m_entry() hook Jan Beulich
2020-10-29 20:46 ` Tim Deegan
2020-11-10 13:59 ` Roger Pau Monné
2020-11-10 14:50 ` Jan Beulich
2020-11-11 12:17 ` Roger Pau Monné
2020-11-12 12:29 ` Jan Beulich
2020-11-12 13:07 ` Roger Pau Monné
2020-11-12 14:04 ` Jan Beulich
2020-11-12 17:52 ` Tim Deegan
2020-11-13 9:52 ` Jan Beulich [this message]
2020-11-18 9:22 ` Roger Pau Monné
2020-11-18 9:31 ` Roger Pau Monné
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=40055cf5-ab16-ad73-4446-3f8f730a6613@suse.com \
--to=jbeulich@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=tim@xen.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.