qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Phil Dennis-Jordan <phil@philjordan.eu>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, philmd@linaro.org, akihiko.odaki@daynix.com
Subject: Re: [PATCH] system/runstate: Fix regression, clarify BQL status of exit notifiers
Date: Thu, 16 Jan 2025 09:34:26 +0100	[thread overview]
Message-ID: <96e9b9f98fc6800728bc524646f73ac31a0ddf71.camel@infradead.org> (raw)
In-Reply-To: <CAAibmn22AxOYRy4yWxcdsX4VooRGiqvpCNG4dRNnKWEcMbtwgg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3282 bytes --]

On Wed, 2025-01-15 at 20:17 +0100, Phil Dennis-Jordan wrote:
> 
> BQL_LOCK_GUARD expands to a call to bql_auto_lock(), which in turn
> defends against recursive locking by checking bql_locked(). 
> 
> https://gitlab.com/qemu-project/qemu/-/blob/master/include/qemu/main-loop.h#L377
> 
> I think that should make it safe?

Looks like it. I did this to test:

--- a/hw/i386/kvm/xen_evtchn.c
+++ b/hw/i386/kvm/xen_evtchn.c
@@ -451,6 +451,10 @@ void xen_evtchn_set_callback_level(int level)
         if (level && !s->extern_gsi_level) {
             kvm_xen_set_callback_asserted();
         }
+        if (level) {
+            printf("Exiting, BQL held\n");
+            exit(77);
+        }
     }
 }
 
--- a/system/runstate.c
+++ b/system/runstate.c
@@ -851,6 +851,7 @@ void qemu_remove_exit_notifier(Notifier *notify)
 static void qemu_run_exit_notifiers(void)
 {
     BQL_LOCK_GUARD();
+    printf("%s has BQL\n", __func__);
     notifier_list_notify(&exit_notifiers, NULL);
 }
 

So the first time a Xen guest's callback IRQ is asserted, it exited
with the BQL held, and qemu_run_exit_notifiers() didn't get stuck.

[    0.521568] ACPI: \_SB_.GSIF: Enabled at IRQ 21
Exiting, BQL held
qemu_run_exit_notifiers has BQL


The actual cleanup of the XenDevice did then deadlock on the Xen evtchn
port_lock, which had *also* been held when my hack exited in the evtchn
code. But that one is expected.

#0  0x00007fc5b2a7b0c0 in __lll_lock_wait () at /lib64/libc.so.6
#1  0x00007fc5b2a81d81 in pthread_mutex_lock@@GLIBC_2.2.5 ()
    at /lib64/libc.so.6
#2  0x0000558286c07a63 in qemu_mutex_lock_impl
    (mutex=0x558294179998, file=0x558286f9b905 "../hw/i386/kvm/xen_evtchn.c", line=2147) at ../util/qemu-thread-posix.c:95
#3  0x00005582868d774f in xen_be_evtchn_unbind (xc=0x5582939b3810, port=2)
    at ../hw/i386/kvm/xen_evtchn.c:2147
#4  0x000055828679e0a9 in qemu_xen_evtchn_unbind
    (xc=<optimized out>, port=<optimized out>)
    at /home/dwmw2/git/qemu/include/hw/xen/xen_backend_ops.h:91
#5  xen_device_unbind_event_channel
    (xendev=<optimized out>, channel=0x5582939b4cb0, errp=0x0)
    at ../hw/xen/xen-bus.c:961
#6  0x00005582865f64b9 in xen_console_disconnect
    (xendev=xendev@entry=0x5582942df4a0, errp=errp@entry=0x0)
    at ../hw/char/xen_console.c:298
#7  0x00005582865f6673 in xen_console_unrealize (xendev=0x5582942df4a0)
    at ../hw/char/xen_console.c:411
#8  0x000055828679e201 in xen_device_unrealize (dev=<optimized out>)
    at ../hw/xen/xen-bus.c:988
#9  0x0000558286c0da5f in notifier_list_notify (list=<optimized out>, data=0x0)
    at ../util/notify.c:39
#10 0x00007fc5b2a2a461 in __run_exit_handlers () at /lib64/libc.so.6
#11 0x00007fc5b2a2a52e in exit () at /lib64/libc.so.6
#12 0x00005582868d86dd in xen_evtchn_set_callback_level (level=1)
    at ../hw/i386/kvm/xen_evtchn.c:456
#13 0x00005582868d7c74 in inject_callback
    (s=0x558294179650, vcpu=<optimized out>) at ../hw/i386/kvm/xen_evtchn.c:548
#14 do_set_port_compat
    (s=<optimized out>, port=<optimized out>, shinfo=<optimized out>, vcpu_info=<optimized out>) at ../hw/i386/kvm/xen_evtchn.c:921
#15 set_port_pending (s=s@entry=0x558294179650, port=<optimized out>)
    at ../hw/i386/kvm/xen_evtchn.c:963


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

      reply	other threads:[~2025-01-16  8:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-12 21:26 [PATCH] system/runstate: Fix regression, clarify BQL status of exit notifiers Phil Dennis-Jordan
2025-01-15 18:01 ` David Woodhouse
2025-01-15 19:05 ` Paolo Bonzini
2025-01-15 19:17   ` Phil Dennis-Jordan
2025-01-16  8:34     ` David Woodhouse [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=96e9b9f98fc6800728bc524646f73ac31a0ddf71.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=akihiko.odaki@daynix.com \
    --cc=pbonzini@redhat.com \
    --cc=phil@philjordan.eu \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).