On 18.04.2024 15:25, Sergiy Kibrik wrote:
> 16.04.24 14:05, Andrew Cooper:
>> On 16/04/2024 7:35 am, Sergiy Kibrik wrote:
>>> diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
>>> index 35561fe51d..d3d7b8fb2e 100644
>>> --- a/xen/arch/x86/cpu/Makefile
>>> +++ b/xen/arch/x86/cpu/Makefile
>>> @@ -10,4 +10,6 @@ obj-y += intel.o
>>> obj-y += intel_cacheinfo.o
>>> obj-y += mwait-idle.o
>>> obj-y += shanghai.o
>>> -obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
>>> +obj-y += vpmu.o
>>> +obj-$(CONFIG_SVM) += vpmu_amd.o
>>> +obj-$(CONFIG_VMX) += vpmu_intel.o
>>
>> I'm afraid this breaks perf counters on PV guests. These files are
>> joint guest-type implementations.
>>
>> Seeing as you leave vpmu.o alone, I guess that all you're actually
>> wanting to do is compile out vpmu_intel.o? In which case, use
>> CONFIG_{AMD,INTEL} rather than CONFIG_{SVM,VMX} please.
>>
>
> Thanks for pointing that out.
> I think I'll just exclude this patch from the series, and make a
> separate series with CONFIG_{AMD,INTEL} option and code separation that
> unrelated to VMX/SVM & HVM/PV, only to CPUs themselves.
>
> BTW, how would you suggest CONFIG_{AMD,INTEL} shall relate to
> CONFIG_{SVM,VMX}? Should CONFIG_VMX just plainly depend on CONFIG_AMD,
> or more complex relations needed?
The answer to this, from my perspective, is actually one of the reasons
why I would have wished we'd have separate CONFIG_INTEL and
CONFIG_INTEL_CPU. I'd then suggest to have VMX simply default to INTEL,
permitting at least experts to select it also when INTEL=n. Perhaps that
would still be the best approach even with this INTEL / INTEL_CPU
distinction.
Jan
