On Wed, 20 Aug 2025 00:30:12 +0100,
Coiby Xu <c...@redhat.com> wrote:
>
> On Wed, Aug 13, 2025 at 08:08:28PM +0800, Coiby Xu wrote:
> > On Tue, Aug 12, 2025 at 02:14:25PM +0100, Marc Zyngier wrote:
> [...]
> >>
> >> Can you at the very least share:
>
> Thanks for your patience! I've attached a zip file with the info you
> need. Additionally I've included the dmidecode of guest
> (dmidecode_guest), host machine (dmidecode_host) and the domain info
> of guest (libvirt.xml) in case they may be helpful. If you need further
> info or any experiment I need to do, feel free to let me know! Now I
> have access to the host machine so I can respond much faster.
>
> >>
> >> - the boot log of the guest on its first kernel
>
> Please check file boot_log_1st_kernel
Old kernel. It would have been better to use a vanilla v6.16, so that
we know exactly what you are running. I have zero interest in finding
out what 6.15.9-201.fc42.aarch64 corresponds to in real life.
> >> - the boot log of the guest running kdump
>
> boot_log_2nd_kernel
Same thing.
>
> >>
> >> - the content of /sys/kernel/debug/kvm/$PID-xx/vgic*state* when
> >> running both kernels
>
> vgic-state_{1st,2nd}_kernel
What is the host running? It also looks like a pre-6.16 kernel, which
lacks important information.
>
> >>
> >> - the QEMU command-line to get to run the whole thing
>
> qemu_cmdline
I'm sorry, but that doesn't look like a command line as I know it. I
certainly cannot feed this to QEMU and reproduce your findings.
Now, there is *one* thing that is interesting:
The second vgic_state dump indicates that LPI 8225 is routed to
vcpu-3. Given that your guest boots into the second kernel on vcpu-0,
and that this is the only online vcpu at this stage, the LPI will
never be presented to the CPU (and the vgic has it as pending, which
is what I'd expect).
I'd suggest you instrument the second kernel to try and see why this
affinity is not changed.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
