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

Re: [Xen-devel] [PATCH v3 2/5] xentrace: Memory/Page Mapping support for DOMID_XEN on ARM

Hi George,

On 11/04/2016 10:52, George Dunlap wrote:
On Fri, Apr 8, 2016 at 6:58 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
On 08/04/16 16:49, Jan Beulich wrote:
On 08.04.16 at 12:42, <julien.grall@xxxxxxx> wrote:
On 04/04/16 19:48, Benjamin Sanda wrote:
+    else
+    {
+        /* retrieve the page to determine read/write or read only mapping */
+        mfn = paddr >> PAGE_SHIFT;
+        if (mfn_valid(mfn))
+        {
+            page = mfn_to_page(mfn);
+            *t = (page->u.inuse.type_info == PGT_writable_page ?
+                                p2m_ram_rw : p2m_ram_ro);
Unfortunately, xenmem_add_to_physmap_one will ignore the return type and
will always map using the type p2m_map_foreign. I would introduce
a new type p2m_map_foreign_ro to allow read-only foreign mapping.

I've looked at the x86 code (p2m_add_foreign) and I haven't been able to
find how the page will be mapped read-only in the guest P2M.
get_page_from_gfn will always return p2m_raw_rw for DOMID_XEN as it's a
non translated domain.

Andrew and Jan, do you know how this is supposed to work when xentrace
is used in a HVM domain? Does x86 Xen always mapped Read-Write the page?
I don't think that case is being taken care of right now: xentrace
is to be used by privileged guests only anyway, and the only
HVM-like privileged guest would be a PVHv1 Dom0 (which likely
no-one cared about to make work with xentrace so far).

Answer to questions of the form "Has anyone considered $X for a
privileged HVM domain on x86" are almost always "No".

The real question is whether the domain making the mapping needs to
write into the pages or not.  If xentrace has to update shared pointers,
then it needs to be rw.  If it simply consumes the data without any
backwards notification, then it should be ro.

It does access shared pointers, and so needs at lest one page to be
rw.  At the moment there's sort of two levels: the "trace info"
page(s), mapped RO, which has the list of all the MFNs used for the
actual trace data, and the trace data MFNs themselves, which are
mapped RW.

Re Julien's question about how DOMID_XEN pages are marked RO on x86
when get_page_from_gfn() always returns p2m_ram_rw: The answer is that
get_page_from_gfn() is only really used by the p2m code.  For PV
guests, it's the page type that restricts a page's type to RO or RW.
trace.c calls share_xen_page_with_privileged_guests(), which on x86
calls xen/arch/x86/mm.c:share_xen_page_with_guest(), which sets the
type to PGT_writable_page.

Thank you for the explanation.

The ARM implementation of share_xen_page_with_guest is nearly the same as the x86 one. However, the type is never used so far for the P2M code.

So far, all ARM domains have been auto-translated. DOMID_XEN is the first non auto-translated domain.

We could make DOMID_XEN an auto-translated domain by introducing page table for dummy domain. This would make the code cleaner but use more memory (allocation of 3 level of page tables).

Stefano, do you have any opinions on this?


Julien Grall

Xen-devel mailing list



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