From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Tamas K Lengyel" <tamas.lengyel@intel.com>,
"Wei Liu" <wl@xen.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"George Dunlap" <george.dunlap@citrix.com>,
Xen-devel <xen-devel@lists.xenproject.org>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes
Date: Wed, 17 Jun 2020 07:21:39 -0600 [thread overview]
Message-ID: <CABfawh=AkBQ6iCOdWpjGvyXykePc7wVC-SZEn13_=q+P-zW4JA@mail.gmail.com> (raw)
In-Reply-To: <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com>
On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 17.06.2020 15:00, Tamas K Lengyel wrote:
> > On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich <jbeulich@suse.com> wrote:
> >> If there are code paths of both kinds, which approach to use in
> >> vmx_load_pdptrs() may need to be chosen based on what
> >> paging_locked_by_me() returns. Or perhaps an unlocked query is
> >> fine in either case?
> >
> > Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be
> > fine. But at that point what is the reason for having the lock
> > ordering at all? Why not just have a single recursive lock and avoid
> > issues like this altogether?
>
> With just a single lock, contention problems we already know we
> have would be even worse. When the current locking model was
> introduced, there was actually a plan to make gfn_lock() more
> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for
> example.
Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an
unlocked query doesn't seem as straightforward because, well, there is
no unlocked version of p2m_get_page_from_gfn which would also do the
"fixups". What seems redundant to me though is that
hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the
paging_lock. Does it really need to take the paging_lock? If it only
held the gfn_lock/p2m_lock then we would have the lock order violation
down the road.
Tamas
next prev parent reply other threads:[~2020-06-17 13:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 19:31 [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes Tamas K Lengyel
2020-06-17 8:23 ` Roger Pau Monné
2020-06-17 12:49 ` Tamas K Lengyel
2020-06-17 14:29 ` Roger Pau Monné
2020-06-17 14:45 ` Tamas K Lengyel
2020-06-17 9:58 ` Jan Beulich
2020-06-17 13:00 ` Tamas K Lengyel
2020-06-17 13:04 ` Jan Beulich
2020-06-17 13:21 ` Tamas K Lengyel [this message]
2020-06-17 13:28 ` Jan Beulich
2020-06-17 13:31 ` Tamas K Lengyel
2020-06-17 13:36 ` Jan Beulich
2020-06-17 13:43 ` Tamas K Lengyel
2020-06-17 14:24 ` Jan Beulich
2020-06-17 14:49 ` Tamas K Lengyel
2020-06-17 15:46 ` Jan Beulich
2020-06-17 15:54 ` Tamas K Lengyel
2020-06-17 15:59 ` 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='CABfawh=AkBQ6iCOdWpjGvyXykePc7wVC-SZEn13_=q+P-zW4JA@mail.gmail.com' \
--to=tamas.k.lengyel@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=tamas.lengyel@intel.com \
--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 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).