[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



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.

 -George

_______________________________________________
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®.