Re: [Xen-devel] [PATCH v4 0/9] add xenalyze to staging

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 06/15/2015 01:44 PM, Julien Grall wrote:
> Hi George,
> 
> On 15/06/2015 10:23, George Dunlap wrote:
>> On 06/10/2015 12:21 AM, Julien Grall wrote:
>>> On 09/06/2015 07:38, George Dunlap wrote:
>>>> On 06/09/2015 12:31 PM, Julien Grall wrote:
>>>>> On 09/06/2015 06:18, Olaf Hering wrote:
>>>>>> On Wed, Jun 03, Julien Grall wrote:
>>>>>>
>>>>>>> xentrace is not working as we don't have the infrastructure for ARM
>>>>>>> in Xen.
>>>>>>
>>>>>> Why is that? After a very quick look __trace_var is available
>>>>>> unconditionally.
>>>>>
>>>>> Multiple reasons, the shared page for trace is not correctly exposed,
>>>>> __trace_var/__trace_hypercall is not even used on ARM. I may miss some
>>>>> other bugs that I didn't spot while looking to the code.
>>>>
>>>> Code in xen/common will generate traces (e.g., the scheduling code), so
>>>> useful traces are already in place for ARM, even if no arm-specific
>>>> code
>>>> has trace points yet.
>>>>
>>>>> So I don't think we should build a non-working binary until someone
>>>>> fixes the various problem of the trace system on ARM.
>>>>
>>>> If the shared page really doesn't work, then yes, we should probably
>>>> not
>>>> build it on ARM for the release.
>>>>
>>>> Would it be very difficult to get working?
>>>
>>> I don't think this is very difficult. But it's not trivial and will
>>> require some work in order to properly bring up xentrace on ARM.
>>>
>>> There was a thread about it last year [1] with Globallogic. I gave some
>>> insight [2] on what to fix in order to get xentrace for ARM.
>>>
>>> Note that on x86 for foreign mapping, the check for xen domid is open
>>> opencode the check for xen domid (see p2m_add_foreign).
>>>
>>> Also, one things I forgot to mention last year is foreign mapping is
>>> always RW in the stage 2 P2M. Although, AFAIU, trace buffer should be
>>> mapped RO in order to avoid the guest writing in it (see
>>> share_xen_page_with_guest).
>>
>> On the contrary, the trace buffer uses the traditional Xen
>> producer/consumer interface for transferring data.  The user-space
>> consumer needs to modify the consumer pointer to let Xen know that there
>> is space to produce more trace records.  The tracing code in the
>> hypervisor is programmed defensively to make sure that a buggy consumer
>> can't crash the hypervisor.
> 
> I think we are not talking about the same things. My comment was a
> reference to the call to xen_share_page_with_privileged_guests in
> xen/common/trace.c
> 
> AFAIU, the code request to share read-only the page (i.e the guest can't
> write in this memory).
> 
> The page will be mapped with the foreign mapping hypercall (the foreign
> domid is xen_dom) always with RW not matter the shared attribute (i.e RW
> or RO).

Oh, right -- the trace *buffers* are read-write, but there's a "trace
info" struct that contains an array of the mfns that make up the
buffers.  *That* is read-only, since there's no reason for the guest to
modify it.

Is this an issue because for ARM you have to attach Xen's mfn to a pfn
in the guest?  Is this also an issue with PVH?

 -George

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