From: Wei Liu <wei.liu2@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, 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:37:42 +0100 [thread overview]
Message-ID: <20170912163742.r2f2nya25g2jwach@citrix.com> (raw)
In-Reply-To: <5c21957c-c759-276d-e0e9-cb63954e7adc@citrix.com>
On Tue, Sep 12, 2017 at 05:36:32PM +0100, Andrew Cooper wrote:
> 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();
>
LGTM. Thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-09-12 16:37 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
2017-09-12 16:37 ` Wei Liu [this message]
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=20170912163742.r2f2nya25g2jwach@citrix.com \
--to=wei.liu2@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@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 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).