From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v4 0/9] add xenalyze to staging Date: Mon, 15 Jun 2015 13:44:31 +0100 Message-ID: <557EC8AF.7060606@gmail.com> References: <1432369458-7587-1-git-send-email-olaf@aepfle.de> <1433326259.7108.53.camel@citrix.com> <556ED87F.50204@citrix.com> <20150609101859.GA10083@aepfle.de> <5576CE9B.4050101@citrix.com> <5576D03B.1060801@eu.citrix.com> <557774FD.60209@citrix.com> <557E99A1.4090108@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <557E99A1.4090108@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Julien Grall , Olaf Hering Cc: Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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). Regards, -- Julien Grall