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

[George Dunlap <george.dunlap@eu.citrix.com>]

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