All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping()
Date: Tue, 12 Sep 2017 17:36:32 +0100	[thread overview]
Message-ID: <5c21957c-c759-276d-e0e9-cb63954e7adc@citrix.com> (raw)
In-Reply-To: <20170912163209.qf5giosds7p2qkbt@citrix.com>

On 12/09/17 17:32, Wei Liu wrote:
> On Tue, Sep 12, 2017 at 05:30:11PM +0100, Andrew Cooper wrote:
>> On 12/09/17 15:58, Wei Liu wrote:
>>> On Tue, Sep 12, 2017 at 01:14:45PM +0100, Andrew Cooper wrote:
>>>> As with the create side of things, these are largely identical.  Most cases
>>>> are actually destroying the mapping rather than replacing it with a stolen
>>>> entry.
>>>>
>>>> Reimplement their logic in replace_grant_pv_mapping() in a mostly common
>>>> way.
>>>>
>>>> No (intended) change in behaviour from a guests point of view.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
>>>
>>> With two suggestions:
>>>
>>>>  int create_grant_pv_mapping(uint64_t addr, unsigned long frame,
>>>>                              unsigned int flags, unsigned int cache_flags)
>>>>  {
>>>> @@ -4136,12 +3959,14 @@ int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
>>>>  {
>>>>      struct vcpu *curr = current;
>>>>      struct domain *currd = curr->domain;
>>>> -    l1_pgentry_t ol1e;
>>>> -    int rc;
>>>> +    l1_pgentry_t nl1e = l1e_empty(), ol1e, *pl1e;
>>>> +    struct page_info *page;
>>>> +    mfn_t gl1mfn;
>>>> +    int rc = GNTST_general_error;
>>>>      unsigned int grant_pte_flags = grant_to_pte_flags(flags, 0);
>>>>  
>>>>      /*
>>>> -     * On top of the explicit settings done by create_grant_host_mapping()
>>>> +     * On top of the explicit settings done by create_pv_host_mapping()
>>>>       * also open-code relevant parts of adjust_guest_l1e(). Don't mirror
>>>>       * available and cachability flags, though.
>>>>       */
>>>> @@ -4150,24 +3975,96 @@ int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
>>>>                             ? _PAGE_GLOBAL
>>>>                             : _PAGE_GUEST_KERNEL | _PAGE_USER;
>>>>  
>>>> +    /*
>>>> +     * addr comes from Xen's active_entry tracking, and was used successfully
>>>> +     * to create a grant.
>>>> +     *
>>>> +     * The meaning of addr depends on GNTMAP_contains_pte.  It is either a
>>>> +     * machine address of an L1e the guest has nominated to be altered, or a
>>>> +     * linear address we need to look up the appropriate L1e for.
>>>> +     *
>>>> +     * Passing a new_addr of zero is taken to mean destroy.  Passing a
>>>> +     * non-zero new_addr has only ever been available via
>>>> +     * GNTABOP_unmap_and_replace and only when using linear addresses.
>>>> +     */
>>> IMHO this should be moved before the function.
>> Which bit?  The addr and GNTMAP_contains_pte need to be here to explain
>> the curious if statement below.
>>
>> The final paragraph only makes sense in the context of the middle paragraph.
> At least the new_addr == 0 means destroying mapping bit.

I've folded the following incremental delta.

~Andrew

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f05a1d7..202eee2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3958,6 +3958,11 @@ static bool steal_linear_address(unsigned long
linear, l1_pgentry_t *out)
     return okay;
 }
 
+/*
+ * Passing a new_addr of zero is taken to mean destroy.  Passing a non-zero
+ * new_addr has only ever been available via GNTABOP_unmap_and_replace, and
+ * only when !(flags & GNTMAP_contains_pte).
+ */
 int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
                              uint64_t new_addr, unsigned int flags)
 {
@@ -3986,10 +3991,6 @@ int replace_grant_pv_mapping(uint64_t addr,
unsigned long frame,
      * The meaning of addr depends on GNTMAP_contains_pte.  It is either a
      * machine address of an L1e the guest has nominated to be altered,
or a
      * linear address we need to look up the appropriate L1e for.
-     *
-     * Passing a new_addr of zero is taken to mean destroy.  Passing a
-     * non-zero new_addr has only ever been available via
-     * GNTABOP_unmap_and_replace and only when using linear addresses.
      */
     if ( flags & GNTMAP_contains_pte )
     {
@@ -3997,6 +3998,7 @@ int replace_grant_pv_mapping(uint64_t addr,
unsigned long frame,
         if ( new_addr )
             goto out;
 
+        /* Sanity check that we won't clobber the pagetable. */
         if ( !IS_ALIGNED(addr, sizeof(nl1e)) )
         {
             ASSERT_UNREACHABLE();


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-09-12 16:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-12 12:14 [PATCH 0/7] x86/mm: Post XSA-234 cleanup Andrew Cooper
2017-09-12 12:14 ` [PATCH 1/7] x86/mm: Improvements to PV l1e mapping helpers Andrew Cooper
2017-09-12 12:29   ` Wei Liu
2017-09-12 15:22     ` Jan Beulich
2017-09-12 12:14 ` [PATCH 2/7] x86/mm: Factor out the grant flags to pte flags conversion logic Andrew Cooper
2017-09-12 13:28   ` Wei Liu
2017-09-12 15:25     ` Jan Beulich
2017-09-12 12:14 ` [PATCH 3/7] x86/mm: Misc cleanup to {create, replace}_grant_host_mapping() Andrew Cooper
2017-09-12 13:40   ` Wei Liu
2017-09-12 15:25     ` Jan Beulich
2017-09-12 12:14 ` [PATCH 4/7] x86/mm: Combine create_grant_{pte, va}_mapping() Andrew Cooper
2017-09-12 14:04   ` Wei Liu
2017-09-12 15:31   ` Jan Beulich
2017-09-12 12:14 ` [PATCH 5/7] x86/mm: Carve steal_linear_address() out of replace_grant_host_mapping() Andrew Cooper
2017-09-12 14:19   ` Wei Liu
2017-09-12 15:41     ` Jan Beulich
2017-09-12 12:14 ` [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping() Andrew Cooper
2017-09-12 14:58   ` Wei Liu
2017-09-12 16:30     ` Andrew Cooper
2017-09-12 16:32       ` Wei Liu
2017-09-12 16:36         ` Andrew Cooper [this message]
2017-09-12 16:37           ` Wei Liu
2017-09-12 15:46   ` Jan Beulich
2017-09-12 12:14 ` [PATCH 7/7] x86/mm: Prevent 32bit PV guests using out-of-range linear addresses Andrew Cooper
2017-09-12 15:50   ` Jan Beulich
2017-09-12 16:04     ` Andrew Cooper
2017-09-13  8:28       ` Jan Beulich

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=5c21957c-c759-276d-e0e9-cb63954e7adc@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.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 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.