On 26/04/2024 3:32 pm, George Dunlap wrote: > A long-standing usability sub-optimality with xenalyze is the > necessity to specify `--svm-mode` when analyzing AMD processors. This > fundamentally comes about because the same trace event ID is used for > both VMX and SVM, but the contents of the trace must be interpreted > differently. > > Instead, allocate separate trace events for VMX and SVM vmexits in > Xen; this will allow all readers to properly intrepret the meaning of
interpret ? > the vmexit reason. > > In xenalyze, first remove the redundant call to init_hvm_data(); > there's no way to get to hvm_vmexit_process() without it being already > initialized by the set_vcpu_type call in hvm_process(). > > Replace this with set_hvm_exit_reson_data(), and move setting of > hvm->exit_reason_* into that function. > > Modify hvm_process and hvm_vmexit_process to handle all four potential > values appropriately. > > If SVM entries are encountered, set opt.svm_mode so that other > SVM-specific functionality is triggered. Given that xenalyze is now closely tied to Xen, and that we're technically changing the ABI here, is there any point keeping `--svm-mode` ? I'm unsure of the utility of reading the buggy trace records from an older version of Xen. > Also add lines in `formats` for xentrace_format. Personally I'd have put patch 3 first, and reduced the churn here. > Signed-off-by: George Dunlap <george.dun...@cloud.com> > --- > NB that this patch goes on top of Andrew's trace cleanup series: > > https://lore.kernel.org/xen-devel/20240318163552.3808695-1-andrew.coop...@citrix.com/ The delta in Xen is trivial. I'm happy if you want to commit this, and I can rebase over it. ~Andrew
