From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
dcrisan@flexiant.com, alex@alex.org.uk, ian.campbell@citrix.com
Subject: Re: [PATCH v4 2/2] xen/m2p: use GNTTABOP_unmap_and_replace to reinstate the original mapping
Date: Fri, 9 Aug 2013 11:26:01 -0400 [thread overview]
Message-ID: <20130809152601.GB5637@phenom.dumpdata.com> (raw)
In-Reply-To: <1375627181-14948-2-git-send-email-stefano.stabellini@eu.citrix.com>
On Sun, Aug 04, 2013 at 03:39:41PM +0100, Stefano Stabellini wrote:
> GNTTABOP_unmap_grant_ref unmaps a grant and replaces it with a 0
> mapping instead of reinstating the original mapping.
> Doing so separately would be racy.
>
> To unmap a grant and reinstate the original mapping atomically we use
> GNTTABOP_unmap_and_replace.
> GNTTABOP_unmap_and_replace doesn't work with GNTMAP_contains_pte, so
> don't use it for kmaps. GNTTABOP_unmap_and_replace zeroes the mapping
> passed in new_addr so we have to reinstate it, however that is a
> per-cpu mapping only used for balloon scratch pages, so we can be sure that
> it's not going to be accessed while the mapping is not valid.
This looks to be depend on a new structure, which is not in Linux kernel?
Are you missing a dependency patch?
Shouldn't we use some logic to figure out which hypercall to use if the
hypervisor does not support it?
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> CC: alex@alex.org.uk
> CC: dcrisan@flexiant.com
> ---
> arch/x86/xen/p2m.c | 22 +++++++++++++++-------
> drivers/xen/gntdev.c | 11 ++---------
> 2 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 95fb2aa..0d4ec35 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -161,6 +161,7 @@
> #include <asm/xen/page.h>
> #include <asm/xen/hypercall.h>
> #include <asm/xen/hypervisor.h>
> +#include <xen/balloon.h>
> #include <xen/grant_table.h>
>
> #include "multicalls.h"
> @@ -967,7 +968,10 @@ int m2p_remove_override(struct page *page,
> if (kmap_op != NULL) {
> if (!PageHighMem(page)) {
> struct multicall_space mcs;
> - struct gnttab_unmap_grant_ref *unmap_op;
> + struct gnttab_unmap_and_replace *unmap_op;
> + struct page *scratch_page = get_balloon_scratch_page();
> + unsigned long scratch_page_address = (unsigned long)
> + __va(page_to_pfn(scratch_page) << PAGE_SHIFT);
>
> /*
> * It might be that we queued all the m2p grant table
> @@ -990,21 +994,25 @@ int m2p_remove_override(struct page *page,
> }
>
> mcs = xen_mc_entry(
> - sizeof(struct gnttab_unmap_grant_ref));
> + sizeof(struct gnttab_unmap_and_replace));
> unmap_op = mcs.args;
> unmap_op->host_addr = kmap_op->host_addr;
> + unmap_op->new_addr = scratch_page_address;
> unmap_op->handle = kmap_op->handle;
> - unmap_op->dev_bus_addr = 0;
>
> MULTI_grant_table_op(mcs.mc,
> - GNTTABOP_unmap_grant_ref, unmap_op, 1);
> + GNTTABOP_unmap_and_replace, unmap_op, 1);
>
> xen_mc_issue(PARAVIRT_LAZY_MMU);
>
> - set_pte_at(&init_mm, address, ptep,
> - pfn_pte(pfn, PAGE_KERNEL));
> - __flush_tlb_single(address);
> + mcs = __xen_mc_entry(0);
> + MULTI_update_va_mapping(mcs.mc, scratch_page_address,
> + pfn_pte(page_to_pfn(get_balloon_scratch_page()),
> + PAGE_KERNEL_RO), 0);
> + xen_mc_issue(PARAVIRT_LAZY_MMU);
> +
> kmap_op->host_addr = 0;
> + put_balloon_scratch_page();
> }
> }
>
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 3c8803f..51f4c95 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -270,19 +270,12 @@ static int map_grant_pages(struct grant_map *map)
> * with find_grant_ptes.
> */
> for (i = 0; i < map->count; i++) {
> - unsigned level;
> unsigned long address = (unsigned long)
> pfn_to_kaddr(page_to_pfn(map->pages[i]));
> - pte_t *ptep;
> - u64 pte_maddr = 0;
> BUG_ON(PageHighMem(map->pages[i]));
>
> - ptep = lookup_address(address, &level);
> - pte_maddr = arbitrary_virt_to_machine(ptep).maddr;
> - gnttab_set_map_op(&map->kmap_ops[i], pte_maddr,
> - map->flags |
> - GNTMAP_host_map |
> - GNTMAP_contains_pte,
> + gnttab_set_map_op(&map->kmap_ops[i], address,
> + map->flags | GNTMAP_host_map,
> map->grants[i].ref,
> map->grants[i].domid);
> }
> --
> 1.7.2.5
>
next prev parent reply other threads:[~2013-08-09 15:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-04 14:38 [PATCH v4 0/2] make ballooned out pages have a valid mapping at all times Stefano Stabellini
2013-08-04 14:39 ` [PATCH v4 1/2] xen/balloon: set a mapping for ballooned out pages Stefano Stabellini
2013-08-04 14:39 ` Stefano Stabellini
2013-08-04 14:39 ` [PATCH v4 2/2] xen/m2p: use GNTTABOP_unmap_and_replace to reinstate the original mapping Stefano Stabellini
2013-08-04 14:39 ` Stefano Stabellini
2013-08-09 15:26 ` Konrad Rzeszutek Wilk [this message]
2013-08-13 11:17 ` Stefano Stabellini
2013-08-13 11:17 ` Stefano Stabellini
2013-08-13 13:11 ` Konrad Rzeszutek Wilk
2013-08-13 15:38 ` Stefano Stabellini
2013-08-13 15:38 ` Stefano Stabellini
2013-08-05 14:53 ` [PATCH v4 0/2] make ballooned out pages have a valid mapping at all times David Vrabel
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=20130809152601.GB5637@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=alex@alex.org.uk \
--cc=dcrisan@flexiant.com \
--cc=ian.campbell@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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.