Re: [PATCH 2/3] tools/xenalyze: Ignore HVM_EMUL events harder

[George Dunlap <george.dunlap@xxxxxxxxx>]

On Fri, Apr 26, 2024 at 4:06 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 26/04/2024 3:32 pm, George Dunlap wrote:
> > To unify certain common sanity checks, checks are done very early in
> > processing based only on the top-level type.
> >
> > Unfortunately, when TRC_HVM_EMUL was introduced, it broke some of the
> > assumptions about how the top-level types worked.  Namely, traces of
> > this type will show up outside of HVM contexts: in idle domains and in
> > PV domains.
> >
> > Make an explicit exception for TRC_HVM_EMUL types in a number of places:
> >
> >  - Pass the record info pointer to toplevel_assert_check, so that it
> >    can exclude TRC_HVM_EMUL records from idle and vcpu data_mode
> >    checks
> >
> >  - Don't attempt to set the vcpu data_type in hvm_process for
> >    TRC_HVM_EMUL records.
> >
> > Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxx>
>
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>
> Although I'm tempted to say that if records of this type show up outside
> of HVM context, then it's misnamed or we've got an error in Xen.  Any
> view on which?

I didn't add them; they seem to be about doing emulation of devices on
behalf of an HVM domain.  But since some of these are things like
timers and such, the actual code ends up being run in random contexts;
probably interrupt contexts (which of course can occur when a non-HVM
guest is running).

One example of an event that showed up this way was
TRC_HVM_EMUL_RTC_STOP_TIMER, which is traced from
xen/arch/x86/hvm/rtc.c:rtc_pf_callback().  I didn't trace back how it
came to be called while a PV guest was running, but it was pretty
obvious that it was legit.

It would certainly make the xenalyze code cleaner to make a separate
top-level tracing category for them; but they certainly do seem to be
directly related to HVM, so doing so would seem to be putting the cart
before the horse, as they say (although I could be convinced
otherwise).

 -George