xentrace, arm, hvm

xentrace, arm, hvm

[Pavlo Suikov]

[-- Attachment #1.1: Type: text/plain, Size: 728 bytes --]

Hi,

has anyone used xentrace on arm with HVM domains? As far as I observe, it
fails to map trace buffers from Xen restricted heap:

xc_map_foreign_batch() call with DOMID_XEN permissions leads to
xenmem_add_to_physmap_one() and then to rcu_lock_domain_by_any_id(), which
fails to find DOMID_XEN in the domain hash (and it doesn't seem at all that
dummy domains are added to this hash). Actually I don't see how this could
work at all since there are no obvious checks for either arch or domain
type (PV or HVM) along the way.

Any advice is appreciated, thanks in advance.

Suikov Pavlo
GlobalLogic
M +38.066.667.1296  S psujkov
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt

[-- Attachment #1.2: Type: text/html, Size: 2827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: xentrace, arm, hvm

[Julien Grall]

On 02/03/2014 05:32 PM, Pavlo Suikov wrote:
> Hi,

Hello,

> has anyone used xentrace on arm with HVM domains? As far as I observe,
> it fails to map trace buffers from Xen restricted heap:

> xc_map_foreign_batch() call with DOMID_XEN permissions leads to
> xenmem_add_to_physmap_one() and then to rcu_lock_domain_by_any_id(),
> which fails to find DOMID_XEN in the domain hash (and it doesn't seem at
> all that dummy domains are added to this hash). Actually I don't see how
> this could work at all since there are no obvious checks for either arch
> or domain type (PV or HVM) along the way.

After a quick look to Xen, it seems that xentrace was only working for
x86 PV (the issue will be the same on PVH). It was working because PV
domain uses mmu_update hypercall. In this function, x86 has a specific
case for DOMID_XEN (see get_pg_owner).

To support xentrace on ARM, we will need at least:
  - to replace rcu_lock_domain_by_any_id() by a a similar function
  - to add stubs for trace in arm code

BTW, when I tried xentrace I have this following error in kernel log
messages:
Failed to map pfn to mfn rc:0:-3 pfn:1e9d0 mfn:fdfbe
xen_privcmd: unable to unmap MFN range: leaking 1 pages. rc=-2

Is it normal that Linux is trying to unmap a page that has failed to map
ealier?

Sincerely yours,

-- 
Julien Grall

Re: xentrace, arm, hvm

[Pavlo Suikov]

[-- Attachment #1.1: Type: text/plain, Size: 443 bytes --]

Well,

> To support xentrace on ARM, we will need at least:

I would readily do that if you give me some directions on where to look at,
or a high-level explanation of:

> - to replace rcu_lock_domain_by_any_id() by a a similar function

What semantics should this function have?

> - to add stubs for trace in arm code

Is there an example of what functionality should be stubbed in arm code?

Thanks for the answer and best regards,
  Pavlo

[-- Attachment #1.2: Type: text/html, Size: 595 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: xentrace, arm, hvm

[Julien Grall]

On 04/02/14 12:39, Pavlo Suikov wrote:
> Well,

Hello,

Ian/Stefano may have a better answer than me on this part :).

>  > To support xentrace on ARM, we will need at least:
>
> I would readily do that if you give me some directions on where to look
> at, or a high-level explanation of:
>
>  > - to replace rcu_lock_domain_by_any_id() by a a similar function
>
> What semantics should this function have?

I would copy in part get_pg_owner (arch/x86/mm/mm.c) in the ARM code. 
The check "unlikely(paging_mode_translate(curr))" will always fail on ARM.

>  > - to add stubs for trace in arm code
>
> Is there an example of what functionality should be stubbed in arm code?
>

You can look at __trace_hypercall_entry on x86, and x86/entry.S where 
the function is called.

Sincerely yours,


-- 
Julien Grall

Re: xentrace, arm, hvm

[Ian Campbell]

On Tue, 2014-02-04 at 13:31 +0000, Julien Grall wrote:
> 
> On 04/02/14 12:39, Pavlo Suikov wrote:
> > Well,
> 
> Hello,
> 
> Ian/Stefano may have a better answer than me on this part :).

I know next to nothing about this tracing stuff. Probably best just to
dig in and ask questions as issues arise.

> 
> >  > To support xentrace on ARM, we will need at least:
> >
> > I would readily do that if you give me some directions on where to look
> > at, or a high-level explanation of:
> >
> >  > - to replace rcu_lock_domain_by_any_id() by a a similar function
> >
> > What semantics should this function have?
> 
> I would copy in part get_pg_owner (arch/x86/mm/mm.c) in the ARM code. 
> The check "unlikely(paging_mode_translate(curr))" will always fail on ARM.

Depending on how much is shared making it a common function might be
better.

> 
> >  > - to add stubs for trace in arm code
> >
> > Is there an example of what functionality should be stubbed in arm code?
> >
> 
> You can look at __trace_hypercall_entry on x86, and x86/entry.S where 
> the function is called.
> 
> Sincerely yours,
> 
> 

Re: xentrace, arm, hvm

[Pavlo Suikov]

[-- Attachment #1.1: Type: text/plain, Size: 1019 bytes --]

Hi,

>
> >  > To support xentrace on ARM, we will need at least:
> >
> > I would readily do that if you give me some directions on where to look
> > at, or a high-level explanation of:
> >
> >  > - to replace rcu_lock_domain_by_any_id() by a a similar function
> >
> > What semantics should this function have?
>
> I would copy in part get_pg_owner (arch/x86/mm/mm.c) in the ARM code.
> The check "unlikely(paging_mode_translate(curr))" will always fail on ARM.

> Probably best just to dig in and ask questions as issues arise.

After making a quick workaround to rcu_lock DOMAIN_XEN on arm (in the quite
same manner it is done in x86) I've faced different problem.
Specifically, p2m_lookup
for an address in the xen restricted heap fails on the very first map
call: p2m_map_first
returns zero page due to both p2m->first_level and p2m_first_level_index(addr)
equal to zero. As far as I understand xen simply does not know how to make
p2m translation for it's own restricted heap on arm. Am I right?

Regards,
  Pavlo

[-- Attachment #1.2: Type: text/html, Size: 4361 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: xentrace, arm, hvm

[Julien Grall]

On 08/02/14 15:51, Pavlo Suikov wrote:
> Hi,

Hi Pavlo,

>>
>> >  > To support xentrace on ARM, we will need at least:
>> >
>> > I would readily do that if you give me some directions on where to look
>> > at, or a high-level explanation of:
>> >
>> >  > - to replace rcu_lock_domain_by_any_id() by a a similar function
>> >
>> > What semantics should this function have?
>>
>> I would copy in part get_pg_owner (arch/x86/mm/mm.c) in the ARM code.
>> The check "unlikely(paging_mode_translate(curr))" will always fail on ARM.
>
>> Probably best just todig in and ask questions as issues arise.
>
> After making a quick workaround to rcu_lock DOMAIN_XEN on arm (in the
> quite same manner it is done in x86) I've faced different problem.
> Specifically, p2m_lookup for an address in the xen restricted heap fails
> on the very first map call: p2m_map_first returns zero page due to both
> p2m->first_level and p2m_first_level_index(addr) equal to zero. As far
> as I understand xen simply does not know how to make p2m translation for
> it's own restricted heap on arm. Am I right?

For DOMID_XEN, the p2m is not initialized. When xentrace requests to map 
a page by directly giving the mfn (machine frame number), so there is no 
need of translation.

I would either add a specific case for DOMID_XEN in get_page_from_gfn or 
p2m_lookup.

Regards,

-- 
Julien Grall

Re: xentrace, arm, hvm

[Julien Grall]

Hi Pavlo,

On 08/02/14 15:51, Pavlo Suikov wrote:
> After making a quick workaround to rcu_lock DOMAIN_XEN on arm (in the
> quite same manner it is done in x86) I've faced different problem.
> Specifically, p2m_lookup for an address in the xen restricted heap fails
> on the very first map call: p2m_map_first returns zero page due to both
> p2m->first_level and p2m_first_level_index(addr) equal to zero. As far
> as I understand xen simply does not know how to make p2m translation for
> it's own restricted heap on arm. Am I right?

Another thing to take into account, xen heap pages can be mapped 
read-only or read-write. You will have to check that when the page is 
mapped into the domain.

-- 
Julien Grall