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

[Julien Grall <julien.grall@arm.com>]

Hi George,

On 11/04/2016 10:52, George Dunlap wrote:
> On Fri, Apr 8, 2016 at 6:58 PM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 08/04/16 16:49, Jan Beulich wrote:
>>>>>> On 08.04.16 at 12:42, <julien.grall@arm.com> 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@lists.xen.org
http://lists.xen.org/xen-devel