Re: [PATCH 1/3] x86/hvm/trace: Use a different trace type for AMD processors
On 26/04/2024 4:29 pm, George Dunlap wrote: > On Fri, Apr 26, 2024 at 4:18 PM Andrew Cooper > 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 >>> --- >>> 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. > 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
Re: [PATCH 1/3] x86/hvm/trace: Use a different trace type for AMD processors
On Fri, Apr 26, 2024 at 4:18 PM Andrew Cooper wrote: > > 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 ? Oops, yes. > > 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. > > Also add lines in `formats` for xentrace_format. > > Personally I'd have put patch 3 first, and reduced the churn here. I actually meant to add an `RFC` to the third patch. I'd already implemented this by the time you suggested ripping it out. Doing it this way doesn't add much overhead if we do end up ripping out xentrace_format, and does save time if we don't. > > Signed-off-by: George Dunlap > > --- > > 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. 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. :-) Since I'm planning on re-submitting your series if you don't (unless you really object), this way should minimize churn. I'm happy to post a branch to gitlab if anyone wants to see the combined result. -George
Re: [PATCH 1/3] x86/hvm/trace: Use a different trace type for AMD processors
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 > --- > 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
