On 26/04/2024 4:29 pm, George Dunlap wrote: > On Fri, Apr 26, 2024 at 4:18 PM Andrew Cooper <[email protected]> > wrote: >> On 26/04/2024 3:32 pm, George Dunlap wrote: >>> 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. > Yeah, I thought about that. If nobody argues to keep it, I guess I'll > rip it out for v2.
That's the way I'd suggest going. >>> Signed-off-by: George Dunlap <[email protected]> >>> --- >>> NB that this patch goes on top of Andrew's trace cleanup series: >>> >>> https://lore.kernel.org/xen-devel/[email protected]/ >> The delta in Xen is trivial. I'm happy if you want to commit this, and >> I can rebase over it. > It's trivial in part *because of* your series. Without your series I > would have had to do a bunch of munging around with DO_TRC_BLAH_BLAH > to make it compile. In fact, I started doing it directly on staging, > but quickly moved onto your series to save myself some time. :-) Ah. I'll be refreshing mine next week. Given that it's missed everything since 4.16, I'm not intending to let it miss this one... But I've still got a few things which need to go out before the past-post deadline. ~Andrew
