From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH v3 00/15] Mem_event and mem_access for ARM Date: Tue, 2 Sep 2014 11:47:49 +0200 Message-ID: References: <1409581329-2607-1-git-send-email-tklengyel@sec.in.tum.de> <5404CF8B.8030603@linaro.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5411856871282790264==" Return-path: In-Reply-To: <5404CF8B.8030603@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: Ian Campbell , Tim Deegan , Ian Jackson , "xen-devel@lists.xen.org" , Stefano Stabellini , Andres Lagar-Cavilla , Jan Beulich , Daniel De Graaf , Tamas K Lengyel List-Id: xen-devel@lists.xenproject.org --===============5411856871282790264== Content-Type: multipart/alternative; boundary=001a11c13e7e2fa9d70502120310 --001a11c13e7e2fa9d70502120310 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 1, 2014 at 9:56 PM, Julien Grall wrote: > Hello Tamas > > On 01/09/14 10:21, Tamas K Lengyel wrote: > > The ARM virtualization extension provides 2-stage paging, a similar > mechanisms > > to Intel's EPT, which can be used to trace the memory accesses performed > by > > the guest systems. This series moves the mem_access and mem_event > codebase > > into Xen common, performs some code cleanup and architecture specific > division > > of components, then sets up the necessary infrastructure in the ARM code > > to deliver the event on R/W/X traps. Finally, we turn on the compilation > of > > mem_access and mem_event on ARM and perform the necessary changes to the > > tools side. > > > > This version of the series has been fully tested and is functional on an > > Arndale board. > > domain_get_maximum_gpfn used in common code is defined as -ENOSYS. > > Right, and I don't really understand why the safety check that uses this function never triggers in mem_access with this function just returning -errno. I've sent a patch a month ago on the mailing list about it (see patch > below). > > Ian: Can you reconsider to apply the patch? (I will also reply to the > thread). FYI, > I have a patch to fix xc_dom_gnttab_hvm_seed in libxc. I will try to send > it next week. > > Regards, > > ==================================================================== > > commit 7aa592b7a6f357b0003cd523e446d9d91dc96730 > Author: Julien Grall > Date: Mon Jun 30 17:21:13 2014 +0100 > > xen/arm: Implement domain_get_maximum_gpfn > > The function domain_get_maximum_gpfn is returning the maximum gpfn ever > mapped in the guest. We can use d->arch.p2m.max_mapped_gfn for this > purpose. > > Signed-off-by: Julien Grall > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 0a243b0..e4a1e5e 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -954,7 +954,7 @@ int page_is_ram_type(unsigned long mfn, unsigned long > mem_type) > > unsigned long domain_get_maximum_gpfn(struct domain *d) > { > - return -ENOSYS; > + return d->arch.p2m.max_mapped_gfn; > } > > void share_xen_page_with_guest(struct page_info *page, > > > > -- > Julien Grall > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > --001a11c13e7e2fa9d70502120310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 1, 2014 at 9:56 PM, Julien Grall <= julien.grall@l= inaro.org> wrote:
Hello Tamas

On 01/09/14 10:21, Tamas K Lengyel wrote:
> The ARM virtualization extension provides 2-stage paging, a similar me= chanisms
> to Intel's EPT, which can be used to trace the memory accesses per= formed by
> the guest systems. This series moves the mem_access and mem_event code= base
> into Xen common, performs some code cleanup and architecture specific = division
> of components, then sets up the necessary infrastructure in the ARM co= de
> to deliver the event on R/W/X traps. Finally, we turn on the compilati= on of
> mem_access and mem_event on ARM and perform the necessary changes to t= he
> tools side.
>
> This version of the series has been fully tested and is functional on = an
> Arndale board.

domain_get_maximum_gpfn used in common code is defined as -ENOSYS.

Right, and I don't really understa= nd why the safety check that uses this function never triggers in mem_acces= s with this function just returning -errno.

I've sent a patch a month ago on the mailing list about it (see patch b= elow).

Ian: Can you reconsider to apply the patch? (I will also reply to the threa= d). FYI,
I have a patch to fix xc_dom_gnttab_hvm_seed in libxc. I will try to send i= t next week.

Regards,

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

commit 7aa592b7a6f357b0003cd523e446d9d91dc96730
Author: Julien Grall <julien.= grall@linaro.org>
Date:=A0 =A0Mon Jun 30 17:21:13 2014 +0100

=A0 =A0 xen/arm: Implement domain_get_maximum_gpfn

=A0 =A0 The function domain_get_maximum_gpfn is returning the maximum gpfn = ever
=A0 =A0 mapped in the guest. We can use d->arch.p2m.max_mapped_gfn for t= his purpose.

=A0 =A0 Signed-off-by: Julien Grall <julien.grall@linaro.org>

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0a243b0..e4a1e5e 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -954,7 +954,7 @@ int page_is_ram_type(unsigned long mfn, unsigned long m= em_type)

=A0unsigned long domain_get_maximum_gpfn(struct domain *d)
=A0{
-=A0 =A0 return -ENOSYS;
+=A0 =A0 return d->arch.p2m.max_mapped_gfn;
=A0}

=A0void share_xen_page_with_guest(struct page_info *page,



--
Julien Grall

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

--001a11c13e7e2fa9d70502120310-- --===============5411856871282790264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5411856871282790264==--