From: Julien Grall <julien.grall@linaro.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>,
Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel@lists.xensource.com,
Ian Campbell <Ian.Campbell@citrix.com>,
george.dunlap@eu.citrix.com, Tim Deegan <tim@xen.org>,
eddie.dong@intel.com, keir.xen@gmail.com, jun.nakajima@intel.com
Subject: Re: [V6 PATCH 6.2/7] pvh dom0: Add and remove foreign pages
Date: Mon, 16 Dec 2013 23:44:37 +0000 [thread overview]
Message-ID: <52AF9065.6030205@linaro.org> (raw)
In-Reply-To: <20131216152722.4c074d8f@mantra.us.oracle.com>
On 12/16/2013 11:27 PM, Mukesh Rathor wrote:
> On Mon, 16 Dec 2013 08:40:41 +0000
> "Jan Beulich" <JBeulich@suse.com> wrote:
>
>>>>> On 14.12.13 at 03:48, Mukesh Rathor <mukesh.rathor@oracle.com>
>>>>> wrote:
>>>> Also, Jan may have an opinion about whether a teardown operation
>>>> that has to walk each p2m entry would have to be made
>>>> preemptible. I'm not sure where we draw the line on such things.
>>>
>>> Since at present teardown cleanup of foreign is not really that
>>> important as its only applicable to dom0, let me submit another
>>> patch for it on Mon with few ideas. That would also keep this patch
>>> size reasonable, and keep you from having to look at the same code
>>> over and over.
>>>
>>> So, please take a look at the version below with above two fixes. If
>>> you approve it, i can resubmit the entire series rebased to latest
>>> with your ack on Monday, and the series can go in while we resolve
>>> the p2m teardown.
>>
>> Going through the patch again, I'm not seeing any loop being
>> added. Am I missing something here?
>
> Yes. Since the destruction of p2m leaking foreign pages only applies
> to control domain being destroyed, i don't think it is that critical
> that part get into 4.4. So, I'm submitting a separate patch for it,
> like said above.
>
>>> --- a/xen/arch/x86/mm/p2m-ept.c
>>> +++ b/xen/arch/x86/mm/p2m-ept.c
>>> @@ -36,8 +36,6 @@
>>>
>>> #define
>>> atomic_read_ept_entry(__pepte) \
>>> ( (ept_entry_t) { .epte = read_atomic(&(__pepte)->epte) } )
>>> -#define atomic_write_ept_entry(__pepte,
>>> __epte) \
>>> - write_atomic(&(__pepte)->epte, (__epte).epte)
>>>
>>> #define is_epte_present(ept_entry) ((ept_entry)->epte & 0x7)
>>> #define is_epte_superpage(ept_entry) ((ept_entry)->sp)
>>> @@ -46,6 +44,25 @@ static inline bool_t is_epte_valid(ept_entry_t
>>> *e) return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
>>> }
>>>
>>> +static inline void write_ept_entry(ept_entry_t *entryptr,
>>> ept_entry_t *new)
>>
>> So why do you drop the "atomic_" prefix here?
>
> To distinguish it from the older atomic_* macro which did nothing but
> atomically write the entry. But if it helps get your approval, I added
> atomic prefix.
>
>> Also the second parameter could be "const"...
>
> Ok.
>
> Final version below:
>
> thanks
> Mukesh
> ---------------------
>
> In this patch, a new function, p2m_add_foreign(), is added
> to map pages from foreign guest into current dom0 for domU creation.
> Such pages are typed p2m_map_foreign. Another function
> p2m_remove_foreign() is added to remove such pages. Note, it is the
> nature of such pages that a refcnt is held during their stay in the p2m.
> The refcnt is added and released in the low level ept code for convenience.
> The cleanup of foreign pages from p2m upon it's destruction, is submitted
> subsequently under a separate patch.
>
> Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
> ---
> xen/arch/x86/mm.c | 23 +++++++---
> xen/arch/x86/mm/p2m-ept.c | 30 +++++++++++---
> xen/arch/x86/mm/p2m-pt.c | 9 ++++-
> xen/arch/x86/mm/p2m.c | 96 +++++++++++++++++++++++++++++++++++++++++++++
> xen/common/memory.c | 12 +++++-
> xen/include/asm-arm/p2m.h | 8 +++-
> xen/include/asm-x86/p2m.h | 7 +++
> 7 files changed, 169 insertions(+), 16 deletions(-)
Following the discussion we had on ARM thread (see
https://patches.linaro.org/22361/), the approach is to remove specific
patch for p2m foreign on common code. So get_page_from_gfn must handle
reference on foreign mapping.
The code is pretty simple on ARM, see: https://patches.linaro.org/22536/
and I don't see why this kind of modification can't go on x86 part.
Also, can you remove all ARM specific code in this patch?
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2013-12-16 23:44 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 2:38 [V6 PATCH 0/7]: PVH dom0 Mukesh Rathor
2013-12-06 2:38 ` [V6 PATCH 1/7] pvh dom0: move some pv specific code to static functions Mukesh Rathor
2013-12-06 2:38 ` [V6 PATCH 2/7] pvh dom0: construct_dom0 changes Mukesh Rathor
2013-12-06 2:38 ` [V6 PATCH 3/7] pvh dom0: implement XENMEM_add_to_physmap_range for x86 Mukesh Rathor
2013-12-06 2:38 ` [V6 PATCH 4/7] pvh dom0: Introduce p2m_map_foreign Mukesh Rathor
2013-12-09 12:02 ` Tim Deegan
2013-12-06 2:38 ` [V6 PATCH 5/7] pvh: change xsm_add_to_physmap Mukesh Rathor
2013-12-06 2:38 ` [V6 PATCH 6/7] pvh dom0: Add and remove foreign pages Mukesh Rathor
2013-12-06 2:54 ` Mukesh Rathor
2013-12-06 11:46 ` Jan Beulich
2013-12-07 2:09 ` Mukesh Rathor
2013-12-07 2:34 ` [V6 PATCH 6.1/7] " Mukesh Rathor
2013-12-07 16:06 ` Julien Grall
2013-12-09 9:50 ` Jan Beulich
2013-12-10 1:30 ` Mukesh Rathor
2013-12-09 10:31 ` Ian Campbell
2013-12-09 13:46 ` Julien Grall
2013-12-09 12:11 ` Tim Deegan
2013-12-10 2:16 ` Mukesh Rathor
2013-12-09 2:45 ` [V6 PATCH 6/7] " Julien Grall
2013-12-09 2:57 ` Julien Grall
2013-12-10 2:17 ` Mukesh Rathor
2013-12-11 0:27 ` [V6 PATCH 6.2/7] " Mukesh Rathor
2013-12-11 0:44 ` Mukesh Rathor
2013-12-11 1:35 ` Julien Grall
2013-12-11 1:47 ` Mukesh Rathor
2013-12-11 9:23 ` Jan Beulich
2013-12-11 14:29 ` Tim Deegan
2013-12-12 2:46 ` Mukesh Rathor
2013-12-13 2:44 ` Mukesh Rathor
2013-12-13 11:25 ` Tim Deegan
2013-12-13 11:39 ` Jan Beulich
2013-12-13 19:02 ` George Dunlap
2013-12-16 7:47 ` Jan Beulich
2013-12-14 2:48 ` Mukesh Rathor
2013-12-16 8:40 ` Jan Beulich
2013-12-16 23:27 ` Mukesh Rathor
2013-12-16 23:44 ` Julien Grall [this message]
2013-12-17 1:51 ` Mukesh Rathor
2013-12-17 2:33 ` Mukesh Rathor
2013-12-17 10:10 ` Tim Deegan
2013-12-17 23:24 ` Mukesh Rathor
2013-12-18 2:34 ` Mukesh Rathor
2013-12-18 9:51 ` Jan Beulich
2013-12-18 9:53 ` Tim Deegan
2013-12-06 2:38 ` [V6 PATCH 7/7] pvh dom0: add opt_dom0pvh to setup.c 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=52AF9065.6030205@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=Xen-devel@lists.xensource.com \
--cc=eddie.dong@intel.com \
--cc=george.dunlap@eu.citrix.com \
--cc=jun.nakajima@intel.com \
--cc=keir.xen@gmail.com \
--cc=mukesh.rathor@oracle.com \
--cc=tim@xen.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).