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

[Julien Grall <julien.grall@xxxxxxx>]

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?

Regards,

--
Julien Grall

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