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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 12 Apr 2016, Julien Grall wrote:
> 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?

If it is just one "if" or two the issue, I would keep DOMID_XEN as it is
now and deal with it as a special case.  If we expect that we are going
to grow more "if domain_id == DOMID_XEN" all around the code base, then
I would follow your suggestion and make DOMID_XEN auto-translated. But
we don't need to decide now, we could go with the special if for the
moment and keep this in mind.

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