From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v4 0/9] add xenalyze to staging Date: Wed, 3 Jun 2015 11:42:37 +0100 Message-ID: <556EDA1D.6060300@eu.citrix.com> References: <1432369458-7587-1-git-send-email-olaf@aepfle.de> <1433326259.7108.53.camel@citrix.com> <556ED87F.50204@citrix.com> <556ED935.7000705@citrix.com> <556ED943.8010108@eu.citrix.com> <556ED9BC.3000407@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <556ED9BC.3000407@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: Andrew Cooper , Julien Grall , Ian Campbell , Olaf Hering Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 06/03/2015 11:41 AM, Andrew Cooper wrote: > On 03/06/15 11:38, George Dunlap wrote: >> On 06/03/2015 11:38 AM, Andrew Cooper wrote: >>> On 03/06/15 11:35, Julien Grall wrote: >>>> On 03/06/2015 11:10, Ian Campbell wrote: >>>>> On Sat, 2015-05-23 at 08:24 +0000, Olaf Hering wrote: >>>>>> Having xenalyze in the source tree makes it much easier to keep private >>>>>> debug code in hypervisor and xenalyze in sync. It helped alot while >>>>>> debugging the root cause for commit >>>>>> 607e8494c42397fb249191904066cace6ac9a880. >>>>> I'm afraid it doesn't build on arm64. >>>>> >>>>> Some of these actually look like non-arch specific failures (e.g. >>>>> conflicts with register_t from system headers) or issues which should >>>>> probably be addressed with xenalyze in tree (e.g. NR_CPUS ought to be >>>>> available directly now?) or with some trivial #ifdef modifications. >>>>> >>>>> That said, I don't know that xentrace actually works on ARM nor that >>>>> xenalyze could analyse such traces even with the build issues addressed, >>>>> so I'd be equally happy if this was just made x86 only. >>>> xentrace is not working as we don't have the infrastructure for ARM in >>>> Xen. >>>> >>>> Compiling xentrace & co only for x86 would be the more sensible solution. >>> Agreed, from the x86 side. (It would also be nice for xentrace to gain >>> AMD support at some point.) >> I take it you mean ARM support? > > I very much mean AMD, not ARM. Have you ever tried xentracing an AMD > HVM guest to try and work out which vmexits are occurring? It worked just fine the last time I tried it (which was admittedly several years ago). If you're using xenalyze you need to add "--svm-mode", since the VMEXIT numbers are all different than on Intel. If AMD tracing really has broken in the mean time that's a regression that will probably be an easy fix. -George