|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen: Drop xenoprofile support
On 06/01/2026 9:37 am, Oleksii Kurochko wrote:
>
> On 1/6/26 9:53 AM, Jan Beulich wrote:
>> On 06.01.2026 09:43, Oleksii Kurochko wrote:
>>> On 1/5/26 8:57 PM, Andrew Cooper wrote:
>>>> The most recent xenoprof change was 300ef0cb4fde ("x86: Add
>>>> Xenoprofile
>>>> support for AMD Family16h") in 2013, despite there being 42 changes
>>>> worth of
>>>> other cleanup/rearranging since then.
>>>>
>>>> Oprofile themselves dropped Xen support in commit 0c142c3a096d
>>>> ("Remove
>>>> opcontrol and the GUI and processor models dependent on it") in
>>>> 2014, as part
>>>> of releasing version 1.0 and switching over to using operf based on
>>>> the Linux
>>>> perf_event subsystem. Linux's version of this patch was merged in
>>>> commit
>>>> 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021.
>>>>
>>>> Drop xenoprof and all supporting infrastructure, including the
>>>> hypercall, the
>>>> XSM hook and flask vectors which lose their only caller, and even
>>>> shrinks
>>>> struct domain by one pointer which wasn't properly excluded in
>>>> !CONFIG_XENOPROF builds.
>>>>
>>>> Retain the public xenoprof.h header as it is ABI, but note that the
>>>> functionality is removed.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> ---
>>>> CC: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>>> CC: Michal Orzel <michal.orzel@xxxxxxx>
>>>> CC: Jan Beulich <jbeulich@xxxxxxxx>
>>>> CC: Julien Grall <julien@xxxxxxx>
>>>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>> CC: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
>>>> CC: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
>>>>
>>>> Despite appearing to be architecture neutral, the internals of
>>>> Xenoprof were
>>>> entirely x86-specific. Another curiosity is that only the VMX MSR
>>>> hooks
>>>> called passive_domain_do_{rd,wr}msr(), and I can't see how this was
>>>> correct
>>>> for SVM.
>>>>
>>>> The real reason for finally getting around to this is the number of
>>>> MISRA
>>>> violations reported by the eclair-x86_64-allcode job that I don't
>>>> feel like
>>>> fixing.
>>>> ---
>>>> CHANGELOG.md | 3 +
>>>> docs/misc/xen-command-line.pandoc | 6 -
>>>> tools/flask/policy/modules/dom0.te | 2 -
>>>> xen/arch/x86/Makefile | 1 -
>>>> xen/arch/x86/cpu/vpmu_amd.c | 7 -
>>>> xen/arch/x86/cpu/vpmu_intel.c | 6 -
>>>> xen/arch/x86/hvm/svm/entry.S | 1 -
>>>> xen/arch/x86/hvm/svm/svm.c | 2 -
>>>> xen/arch/x86/hvm/vmx/vmx.c | 9 -
>>>> xen/arch/x86/include/asm/xenoprof.h | 95 ---
>>>> xen/arch/x86/oprofile/Makefile | 6 -
>>>> xen/arch/x86/oprofile/backtrace.c | 145 ----
>>>> xen/arch/x86/oprofile/nmi_int.c | 485 ------------
>>>> xen/arch/x86/oprofile/op_counter.h | 41 -
>>>> xen/arch/x86/oprofile/op_model_athlon.c | 547 -------------
>>>> xen/arch/x86/oprofile/op_model_p4.c | 721 -----------------
>>>> xen/arch/x86/oprofile/op_model_ppro.c | 348 ---------
>>>> xen/arch/x86/oprofile/op_x86_model.h | 58 --
>>>> xen/arch/x86/oprofile/xenoprof.c | 106 ---
>>>> xen/arch/x86/traps.c | 4 -
>>>> xen/common/Kconfig | 11 -
>>>> xen/common/Makefile | 1 -
>>>> xen/common/compat/xenoprof.c | 42 -
>>>> xen/common/domain.c | 6 -
>>>> xen/common/xenoprof.c | 977
>>>> ------------------------
>>>> xen/include/Makefile | 1 -
>>>> xen/include/hypercall-defs.c | 6 -
>>>> xen/include/public/xen.h | 2 +-
>>>> xen/include/public/xenoprof.h | 2 +-
>>>> xen/include/xen/sched.h | 3 -
>>>> xen/include/xen/xenoprof.h | 49 --
>>>> xen/include/xsm/dummy.h | 7 -
>>>> xen/include/xsm/xsm.h | 7 -
>>>> xen/xsm/dummy.c | 2 -
>>>> xen/xsm/flask/hooks.c | 35 -
>>>> xen/xsm/flask/policy/access_vectors | 4 -
>>>> 36 files changed, 5 insertions(+), 3743 deletions(-)
>>>> delete mode 100644 xen/arch/x86/include/asm/xenoprof.h
>>>> delete mode 100644 xen/arch/x86/oprofile/Makefile
>>>> delete mode 100644 xen/arch/x86/oprofile/backtrace.c
>>>> delete mode 100644 xen/arch/x86/oprofile/nmi_int.c
>>>> delete mode 100644 xen/arch/x86/oprofile/op_counter.h
>>>> delete mode 100644 xen/arch/x86/oprofile/op_model_athlon.c
>>>> delete mode 100644 xen/arch/x86/oprofile/op_model_p4.c
>>>> delete mode 100644 xen/arch/x86/oprofile/op_model_ppro.c
>>>> delete mode 100644 xen/arch/x86/oprofile/op_x86_model.h
>>>> delete mode 100644 xen/arch/x86/oprofile/xenoprof.c
>>>> delete mode 100644 xen/common/compat/xenoprof.c
>>>> delete mode 100644 xen/common/xenoprof.c
>>>> delete mode 100644 xen/include/xen/xenoprof.h
>>>>
>>>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>>>> index 3aaf5986231c..1663f6878ef2 100644
>>>> --- a/CHANGELOG.md
>>>> +++ b/CHANGELOG.md
>>>> @@ -15,6 +15,9 @@ The format is based on [Keep a
>>>> Changelog](https://keepachangelog.com/en/1.0.0/)
>>>> - The cpuid_mask_* command line options for legacy AMD CPUs.
>>>> These were
>>>> deprecated in Xen 4.7 and noted not to work correctly with
>>>> AMD CPUs from
>>>> 2011 onwards.
>>>> + - Xenoprofile support. Oprofile themselves removed support for
>>>> Xen in 2014
>>>> + prior to the version 1.0 release, and there has been no
>>>> development since
>>>> + before then in Xen.
>>> LGTM:
>>> Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> # CHANGELOG.md
>>>
>>> Nit: It is necessary to drop the extra space before " Oprofile
>>> themselves...".
>> Why would that be? See the other bullet point in context, which also
>> uses a
>> two blanks after the inner full stop. This is deliberate.
>
> I just missed that a similar case was mentioned above. If this is
> deliberate,
> then I’m fine with it. It’s just not obvious (at least, for me) where
> it’s
> acceptable and where it isn’t to have extra spaces.
The hunk looks correct in
https://lore.kernel.org/xen-devel/20260105195717.601500-1-andrew.cooper3@xxxxxxxxxx/T/#u
It's only your reply
https://lore.kernel.org/xen-devel/724e78ef-b6ed-40db-a5c0-bd6473b6fe16@xxxxxxxxx/
where it looks to have whitespace problems, so I suspect that will be a
local MUA problem.
~Andrew
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |