Re: FAIL Kernel v6.10-evl-rebase - EVL: In function 'do_sysvec_inband': error: duplicate case value

[Philippe Gerum <rpm@xenomai.org>]

Florian Bezdeka <florian.bezdeka@siemens.com> writes:

> On Fri, 2024-07-26 at 21:15 +0200, Philippe Gerum wrote:
>> "Nechita, Ionut" <ionut.nechita@intel.com> writes:
>> 
>> > Hi Xenomai Kernel Team,
>> > 
>> > I notice today one issue when compiling latest version, v6.10-evl-rebase.
>> > 
>> > > > > error: duplicate case value
>> >   160 |         case HYPERVISOR_CALLBACK_VECTOR:
>> > 
>> > # make -j208 bindeb-pkg  LOCALVERSION="-1-lowlatency-evl" ARCH=x86_64
>> >   GEN     debian
>> > Using default distribution of 'unstable' in the changelog
>> > Install lsb-release or set $KDEB_CHANGELOG_DIST explicitly
>> > dpkg-buildpackage --build=binary --no-pre-clean --unsigned-changes -R'make -f debian/rules' -j1 -a$(cat debian/arch)
>> > dpkg-buildpackage: info: source package linux-upstream
>> > dpkg-buildpackage: info: source version 6.10.0-g9ba4271318cf-4
>> > dpkg-buildpackage: info: source distribution unstable
>> > dpkg-buildpackage: info: source changed by root <root@0296de802d65>
>> > dpkg-buildpackage: info: host architecture amd64
>> >  dpkg-source --before-build .
>> >  make -f debian/rules binary
>> > #
>> > # No change to .config
>> > #
>> > mkdir -p /srv/tmpfs-disk1/build/linux-evl/tools/objtool && make O=/srv/tmpfs-disk1/build/linux-evl subdir=tools/objtool --no-print-directory -C objtool
>> >   INSTALL libsubcmd_headers
>> >   CALL    scripts/checksyscalls.sh
>> >   UPD     init/utsversion-tmp.h
>> >   CC      init/version.o
>> >   AR      init/built-in.a
>> >   CHK     kernel/kheaders_data.tar.xz
>> >   CC      arch/x86/kernel/irq_pipeline.o
>> > arch/x86/kernel/irq_pipeline.c: In function 'do_sysvec_inband':
>> > arch/x86/kernel/irq_pipeline.c:160:9: error: duplicate case value
>> >   160 |         case HYPERVISOR_CALLBACK_VECTOR:
>> >       |         ^~~~
>> > arch/x86/kernel/irq_pipeline.c:154:9: note: previously used here
>> >   154 |         case HYPERVISOR_CALLBACK_VECTOR:
>> >       |         ^~~~
>> > make[7]: *** [scripts/Makefile.build:244: arch/x86/kernel/irq_pipeline.o] Error 1
>> > make[7]: *** Waiting for unfinished jobs....
>> > make[6]: *** [scripts/Makefile.build:485: arch/x86/kernel] Error 2
>> > make[5]: *** [scripts/Makefile.build:485: arch/x86] Error 2
>> > make[5]: *** Waiting for unfinished jobs....
>> > make[4]: *** [Makefile:1934: .] Error 2
>> > make[3]: *** [debian/rules:74: build-arch] Error 2
>> > dpkg-buildpackage: error: make -f debian/rules binary subprocess returned exit status 2
>> > make[2]: *** [scripts/Makefile.package:121: bindeb-pkg] Error 2
>> > make[1]: *** [/srv/tmpfs-disk1/build/linux-evl/Makefile:1555: bindeb-pkg] Error 2
>> > make: *** [Makefile:240: __sub-make] Error 2
>> > 
>> > 
>> > BR,
>> > Ionut Nechita
>> 
>> Mm, do_sysvec_inband() is wrong when it comes to dealing with
>> HYPERVISOR_CALLBACK_VECTOR. We need a global pointer to the
>> hypervisor-specific handler, that would be set up by the guest init code
>> which traps the vector. We cannot ask do_sysvec_inband() to figure out
>> this information, it depends on which hypervisor trapped that vector in
>> the first place.
>
> Exactly. It was me duplicating the "wrong" ACRN implementation while
> introducing the async page fault handling for KVM.
>

Strictly speaking, the bug was there prior to that addition, the async
pf patch only revealed it (I'm hereby claiming authorship of that bug! :)

> I think there is no way to look at the IDT and check which gate was
> loaded by the hypervisor guest code.
>
> I haven't checked yet if that would work, but at least the KVM
> implementation enables a static branch (kvm_async_pf_enabled) when
> loading the IDT gate. Maybe we can check if this one is active. If so,
> it's KVM we are running on.

kvm_async_pf_enabled seems to be controlled by a paravirt capability
flag. Would we receive significant information from
kvm_arch_para_features() <- cpuid_eax() in case KVM is not there?

>
> There seems no such static branch for the ACRN code...
>>

IIUC, we cannot have more than a single guest allowed to hook that
vector anyway, so could we just track who's doing that in the places
where this vector is trapped, e.g. by setting up some global function
pointer referring to the proper handler which do_sysvec_inband() would
call upon HYPERVISOR_CALLBACK_VECTOR event?

-- 
Philippe.