Re: [PATCH] hw/intc/arm_gicv3_kvm: Avoid reading ICC_CTLR_EL1 from kernel in cpuif reset

[Peter Maydell <peter.maydell@linaro.org>]

On Tue, 14 Oct 2025 at 14:23, Salil Mehta <salil.mehta@huawei.com> wrote:
>
> Hi Peter,
>
> > From: qemu-devel-bounces+salil.mehta=huawei.com@nongnu.org <qemu-
> > devel-bounces+salil.mehta=huawei.com@nongnu.org> On Behalf Of Salil
> > Mehta via
> > Sent: Tuesday, October 14, 2025 11:41 AM
> > To: Peter Maydell <peter.maydell@linaro.org>; qemu-devel@nongnu.org
> >
> > Hi Peter,
> >
> > > From: qemu-devel-bounces+salil.mehta=huawei.com@nongnu.org
> > <qemu-
> > > devel-bounces+salil.mehta=huawei.com@nongnu.org> On Behalf Of Peter
> > > Maydell
> > > Sent: Tuesday, October 14, 2025 11:25 AM
> > > To: qemu-devel@nongnu.org
> > >
> > > Currently in arm_gicv3_icc_reset() we read the kernel's value of
> > > ICC_CTLR_EL1 as part of resetting the CPU interface.  This mostly
> > > works, but we're actually breaking an assumption the kernel makes that
> > > userspace only accesses the in-kernel GIC data when the VM is totally
> > > paused, which may not be the case if a single vCPU is being reset.
> > > The effect is that it's possible that the read attempt returns EBUSY.
> > >
> > > Avoid this by reading the kernel's value of the reset ICC_CTLR_EL1
> > > once in device realize. This brings ICC_CTLR_EL1 into line with the
> > > other cpuif registers, where we assume we know what the kernel is
> > > resetting them to and just update QEMU's data structures in
> > arm_gicv3_icc_reset().
> > >
> > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> > > ---
> > > I've only tested this fairly lightly, but it seems to work.
> > > Salil, does this fix the EBUSY issues you were seeing ?
> >
> >
> > Let me try this and get back to you.  Also, just to let you know that -EBUSY
> > can return from other places as well. Please check  my reply in the other mail-
> > chain.
>
>
> Got this.
>
> (gdb) handle SIGUSR1 nostop noprint pass
> Signal        Stop      Print   Pass to program Description
> SIGUSR1       No        No      Yes             User defined signal 1
> (gdb) run
> Starting program:
> /opt/workspace/code/qemu/qemu/build/qemu-system-aarch64 --enable-kvm -machine virt,gic-version=3 -cpu host -smp cpus=2,disabledcpus=2 -m 300M -kernel /opt/workspace/code/linux/linux/arch/arm64/boot/Image
> -initrd /opt/workspace/code/filesystem/rootfs.cpio.gz -append console=ttyAMA0\ root=/dev/ram\ earlycon\ rdinit=/init\ maxcpus=1\ acpi=force -nographic -bios /opt/workspace/code/uefi/edk2/Build/ArmVirtQemu-AARCH64/RELEASE_GCC5/FV/QEMU_EFI.fd
> [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
> [New Thread 0xfffff5b5eb40 (LWP 31994)]
> [New Thread 0xfffff4e88b40 (LWP 31996)]
> [New Thread 0xffffd4dfeb40 (LWP 31997)]
> Unexpected error in kvm_device_access() at ../accel/kvm/kvm-all.c:3475:
> qemu-system-aarch64: KVM_GET_DEVICE_ATTR failed: Group 6 attr
> 0x000000000000c664: Inappropriate ioctl for device

Does it do this consistently, or only sometimes? What
host kernel version are you running? And what QEMU
commit (plus this patch)?

I'm guessing from that "disabledcpus=2" part that you're
running some not-yet-upstream set of QEMU patches. Please
drop those, and test only with this, to rule out the
possibility of some bug/unexpected interaction with those.

thanks
-- PMM