lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 15 Sep 2011 14:37:27 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	David Vrabel <david.vrabel@...rix.com>
CC:	xen-devel@...ts.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/6] xen: don't call vmalloc_sync_all() when mapping foreign
 pages

On 09/15/2011 05:40 AM, David Vrabel wrote:
> This set of pages avoids the need to call vmalloc_sync_all() when
> mapping foreign pages.  Two new functions are adding for mapping
> foreign pages onto RAM pages instead of vmalloc space.
>
> This does waste a page of RAM for each mapped page.  In the future a
> ballooned page could be used instead (once the API for getting a
> ballooned page with the right GFP flags is available).

You can allocate a pfn, free ("balloon out") the underlying mfn, and
replace it with a granted page; it doesn't need any particular new
infrastructure.

But that said, if you want to allocate virtual addresses for mapping
granted pages, then alloc_vm_area() is the right thing to use.  You need
to make sure you touch the pages from within the kernel before passing
those addresses to a hypercall to make sure the mappings are established
within the current task (possibly within a no-preempt region to
guarantee that nothing odd happens).  Or alternatively, you could switch
the current pagetable to init_mm for the hypercall (if it isn't already)
- since that's the reference pagetable - assuming you're not passing
usermode virtual addresses to the hypercall.

This series is relying on regular ram mappings are already synced to all
tasks, but I'm not sure that's necessarily guaranteed (for example, if
you hotplug new memory into the domain, the new pages won't be mapped
into every mm unless they're synced).

    J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ