[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |