On Wed, 2024-12-18 at 14:38 +0100, Thomas Huth wrote:
> On 18/12/2024 13.40, Thomas Huth wrote:
> > On 18/12/2024 12.48, David Woodhouse wrote:
> > > On 18 December 2024 12:32:49 CET, Thomas Huth <[email protected]> wrote:
> > > > Use the serial console to execute the commands in the guest instead
> > > > of using ssh since we don't have ssh support in the functional
> > > > framework yet.
> > > > 
> > > > Signed-off-by: Thomas Huth <[email protected]>
> > > 
> > > Hm, but serial is lossy and experience shows that it leads to flaky tests 
> > > if the guest (or host) misses bytes. While SSH would just go slower.
> > 
> > The issue with the serial console should be fixed since:
> > 
> >   https://gitlab.com/qemu-project/qemu/-/commit/cdad03b74f759857d784e074755
> > 
> > We didn't see any more issues with all the other tests since that has been 
> > merged.

Fair enough, thanks. In that case:

Acked-by: David Woodhouse <[email protected]>

> But FWIW, there seems to be another issue with this test. While running it 
> multiple times, I sometimes see test_kvm_xen_guest_novector_noapic hanging. 
> According to the console output, the guest waits in vain for a device:
> 
> 2024-12-18 14:32:58,606: Initializing XFRM netlink socket
> 2024-12-18 14:32:58,607: NET: Registered PF_INET6 protocol family
> 2024-12-18 14:32:58,609: Segment Routing with IPv6
> 2024-12-18 14:32:58,609: In-situ OAM (IOAM) with IPv6
> 2024-12-18 14:32:58,610: NET: Registered PF_PACKET protocol family
> 2024-12-18 14:32:58,610: 8021q: 802.1Q VLAN Support v1.8
> 2024-12-18 14:32:58,611: 9pnet: Installing 9P2000 support
> 2024-12-18 14:32:58,613: NET: Registered PF_VSOCK protocol family
> 2024-12-18 14:32:58,614: IPI shorthand broadcast: enabled
> 2024-12-18 14:32:58,619: sched_clock: Marking stable (551147059, 
> -6778955)->(590359530, -45991426)
> 2024-12-18 14:32:59,507: tsc: Refined TSC clocksource calibration: 2495.952 
> MHz
> 2024-12-18 14:32:59,508: clocksource: tsc: mask: 0xffffffffffffffff 
> max_cycles: 0x23fa49fc138, max_idle_ns: 440795295059 ns
> 2024-12-18 14:32:59,509: clocksource: Switched to clocksource tsc
> 2024-12-18 14:33:28,667: xenbus_probe_frontend: Waiting for devices to 
> initialise: 25s...20s...15s...10s...5s...0s...
> 
> Have you seen this problem before?

That seems like event channel interrupts aren't being routed to the
legacy i8259 PIC. I've certainly seen that kind of thing before,
especially when asserted level-triggered interrupts weren't correctly
being asserted. But I don't expect that of QEMU. I'll see if I can
reproduce; thanks.

How often does it happen?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to