From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>,
George.Dunlap@eu.citrix.com, Tim Deegan <tim@xen.org>,
eddie.dong@intel.com, keir.xen@gmail.com, jun.nakajima@intel.com,
xen-devel@lists.xenproject.org
Subject: Re: [V9 PATCH 6/8] pvh dom0: Add and remove foreign pages
Date: Fri, 25 Apr 2014 18:34:31 -0700 [thread overview]
Message-ID: <20140425183431.0251a6ca@mantra.us.oracle.com> (raw)
In-Reply-To: <20140424190925.62843681@mantra.us.oracle.com>
On Thu, 24 Apr 2014 19:09:25 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Thu, 24 Apr 2014 11:46:41 +0200
> Tim Deegan <tim@xen.org> wrote:
>
> > At 19:21 -0700 on 23 Apr (1398277311), Mukesh Rathor wrote:
> > > On Thu, 17 Apr 2014 14:58:42 +0100
> > > "Jan Beulich" <JBeulich@suse.com> wrote:
> > >
> > > > >>> On 17.04.14 at 14:36, <tim@xen.org> wrote:
> > > > > At 07:50 +0100 on 17 Apr (1397717440), Jan Beulich wrote:
> > > > >> >>> On 17.04.14 at 03:37, <mukesh.rathor@oracle.com> wrote:
> > > > >> > On Wed, 16 Apr 2014 17:00:35 +0100
> > > > >> > "Jan Beulich" <JBeulich@suse.com> wrote:
> >
> > This goes back to having refcounts open-coded. Having the refcounts
> > open-coded around the atomic_write_ept_entry() in ept_set_entry()
> > means there are now places where the epte can change without
> > maintaining the refcount invariants: ept_change_entry_type_page(),
> > for example.
>
> Correct, altho, at present I've checks in p2m paths to not allow
> foreign types to come down to such calls.
>
> > I would _much_ prefer to have atomic_write_ept_entry() DTRT -- it
> > would have to know the difference between leaf and non-leaf entries,
> > and return an error code. I'd also be OK with having two
> > atomic_write ops, one for leaf and one for non-leaf, with
> > appropriate ASSERT()s on the contents.
>
> Ok, how about something like shown further below? (I think
> it would be more simpler to have one atomic_write ops, instead of two)
>
> One thing, on returning error code, since at present there are no
> paths allowing superpages for foreign types, it appears I'd not need
> to worry about undoing the ept_split_super_page(), so I added
> assert in there. Sound right?
>
> Finally, I can leave other callers of atomic_write_ept_entry as is,
> or add ASSERTs for rc == 0. LMK.
>
> thanks for patience,
> mukesh
Tim/Jan,
Ok, so far:
option 1, Jan's suggestion:
- Use my latest patch, but add explicit set of p2m type for intermediate
entries in ept_set_middle_entry() like Jan said.
Good: we won't need to then worry about checking for leaf entries.
Bad: future code can't use the bits for interm entries.
option 2, Tim's suggestion:
- Use my latest patch, but add sp = 1 in leaf entries. Then use level
to figure if we are in superpage. Will work too, but will change the
definition of sp bit, and superpage check will always require checking
for level.
option 3:
- Pass level to atomic_write_ept_entry() and check for foreign only in
case of level == 0, ie leaf entries where foreign can be set.
It appears that information is available at all call sites, and would
be least intrusive in terms of using bits for non-leaf entries.
option 4:
- each call site checks for level and calls either macro for leaf entry
or macro for non-leaf entry. same as 3, but the check is in call site.
I'll think of more options over the weekend, but I think I like option 3
the best. LMK, and I will work on it.
thanks
mukesh
next prev parent reply other threads:[~2014-04-26 1:34 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 0:12 [V9 PATCH 0/8] pvh dom0 patches Mukesh Rathor
2014-04-16 0:12 ` [V9 PATCH 1/8] pvh dom0: move some pv specific code to static functions Mukesh Rathor
2014-04-16 0:12 ` [V9 PATCH 2/8] pvh dom0: construct_dom0 changes Mukesh Rathor
2014-04-16 0:12 ` [V9 PATCH 3/8] pvh dom0: Introduce p2m_map_foreign Mukesh Rathor
2014-04-16 0:12 ` [V9 PATCH 4/8] pvh dom0: Add checks and restrictions for p2m_is_foreign Mukesh Rathor
2014-04-16 15:28 ` Jan Beulich
2014-04-16 0:12 ` [V9 PATCH 5/8] pvh dom0: make xsm_map_gmfn_foreign available for x86 Mukesh Rathor
2014-04-16 14:29 ` Daniel De Graaf
2014-04-16 0:12 ` [V9 PATCH 6/8] pvh dom0: Add and remove foreign pages Mukesh Rathor
2014-04-16 16:00 ` Jan Beulich
2014-04-17 1:37 ` Mukesh Rathor
2014-04-17 6:50 ` Jan Beulich
2014-04-17 12:36 ` Tim Deegan
2014-04-17 13:58 ` Jan Beulich
2014-04-19 0:59 ` Mukesh Rathor
2014-04-21 16:10 ` Jan Beulich
2014-04-24 2:21 ` Mukesh Rathor
2014-04-24 6:44 ` Jan Beulich
2014-04-24 9:46 ` Tim Deegan
2014-04-25 2:09 ` Mukesh Rathor
2014-04-25 6:49 ` Jan Beulich
2014-04-25 23:23 ` Mukesh Rathor
2014-04-26 0:06 ` Mukesh Rathor
2014-04-28 7:23 ` Jan Beulich
2014-04-25 8:55 ` Tim Deegan
2014-04-25 23:29 ` Mukesh Rathor
2014-04-26 1:34 ` Mukesh Rathor [this message]
2014-04-28 8:54 ` Jan Beulich
2014-04-28 9:09 ` Tim Deegan
2014-04-22 0:19 ` Mukesh Rathor
2014-04-22 7:28 ` Jan Beulich
2014-04-23 0:28 ` Mukesh Rathor
2014-04-23 9:03 ` Jan Beulich
2014-04-23 16:13 ` Andres Lagar-Cavilla
2014-04-24 16:37 ` Tim Deegan
2014-04-16 0:12 ` [V9 PATCH 7/8] pvh dom0: check for vioapic null ptr in vioapic_range Mukesh Rathor
2014-04-16 16:05 ` Jan Beulich
2014-04-17 1:44 ` Mukesh Rathor
2014-04-17 6:54 ` Jan Beulich
2014-04-22 0:59 ` Mukesh Rathor
2014-04-22 7:33 ` Jan Beulich
2014-04-23 0:11 ` Mukesh Rathor
2014-04-23 9:07 ` Jan Beulich
2014-04-23 21:18 ` Mukesh Rathor
2014-04-24 6:49 ` Jan Beulich
2014-04-24 23:28 ` Mukesh Rathor
2014-05-06 0:19 ` Mukesh Rathor
2014-05-06 7:44 ` Jan Beulich
2014-05-07 1:07 ` Mukesh Rathor
2014-05-07 6:47 ` Jan Beulich
2014-05-07 23:52 ` Mukesh Rathor
2014-05-08 6:33 ` Jan Beulich
2014-04-16 0:12 ` [V9 PATCH 8/8] pvh dom0: add opt_dom0pvh to setup.c Mukesh Rathor
2014-04-16 12:57 ` Konrad Rzeszutek Wilk
2014-04-16 13:01 ` Andrew Cooper
2014-04-16 16:09 ` Jan Beulich
2014-04-16 14:57 ` [V9 PATCH 0/8] pvh dom0 patches Roger Pau Monné
2014-04-16 21:15 ` Mukesh Rathor
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=20140425183431.0251a6ca@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=eddie.dong@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir.xen@gmail.com \
--cc=tim@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).