[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] arm: xen: foreign mapping PTEs are special.



On Fri, 6 Dec 2013, Ian Campbell wrote:
> On Fri, 2013-12-06 at 17:48 +0000, Stefano Stabellini wrote:
> > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > These mappings are in fact special and require special handling in 
> > > privcmd,
> > > which already exists. Failure to mark the PTE as special on arm64 causes 
> > > all sorts of bad PTE fun.
> > > 
> > > x86 already gets this correct.
> > 
> > Yes, but x86 does that for PV guests, not for autotranslate guests (for
> > which the function return -EINVAL).
> > 
> > Given that in the ARM case we are changing the p2m underneath, why do we
> > also need to mark them special?
> 
> It's not about the p2m, it's about the handling in privcmd wrt setup and
> teardown of the stage one mapping which goes along with the p2m
> manipulations.
> 
> Without this the normal rmap counting kicks in and complains about the
> mapcount being -1.

In the case of PV guests we need to mark the pte special because there
is no struct page associated to it: the userspace virtual address is
mapped to a foreign mfn. No dom0 pages are involved.

In this case we do have a corresponding physical address and a
corresponding struct page in dom0.  In fact the dom0 page is a
xenballooned_pages allocated by alloc_empty_pages.

What exactly is the kernel complaining about? Didn't we allocate the
pages correctly? Didn't we call get_page appropriately?
There must be a way to make the mapcount happy without marking the pages
as special.


Also consider that on 3.13-rc2 pte_mkspecial on arm is implemented as:

static inline pte_t pte_mkspecial(pte_t pte) { return pte; }

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.