On 09/08/18 09:01, Jan Beulich wrote:
> According to the logic in hvm_mmio_assist_process(), 64 bits of data are
> expected with 64-bit addresses, and 32 bits of data with 32-bit ones. I
> don't think this is very reasonable, but I'm also not going to touch the
> consumer side, the more that it is anyway not very helpful for the code
> here to only ever supply 32 bits of data (despite the field being 64
> bits wide, and having been even in the 32-bit days of Xen).
>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
> ---
> RFC: Untested; solely based on the observation of "(no data)" in a trace
> where it was entirely unclear why no data would have been available.
> I just so happened that the guest had more than 4Gb of memory, and
> hence addresses were not representable as 32-bit values.
Unfortunately, I don't think this helps much.
From what I can tell, xentrace_format doesn't understand the TRC_64_FLAG
versions of these events at all, and xenalyze uses:
union {
struct {
unsigned int gpa;
unsigned int data;
} x32;
struct {
unsigned long long gpa;
unsigned int data;
} x64;
} *r = (typeof(r))h->d;
to pull the data back out. AFAICT, this matches what Xen is currently
writing, and is equally wrong.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
