Re: [Xen-devel] [PATCH RFC] x86/HVM: meet xentrace's expectations on emulation event data

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.08.18 at 16:22, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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 <jbeulich@xxxxxxxx>
>> ---
>> 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.

Are you sure? You've not quoted the relevant other half:

    union {
        unsigned event;
        struct {
            unsigned minor:8,
                x64:1,
                write:2;
        };
    } mevt = { .event = ri->event };

with the check then being

    if(mevt.x64) {

If what consumer and producer matched in (good or bad) behavior,
I'd expect "(no data)" to not appear here, but it was definitely
observed (on an older Xen version) by Olaf.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel