|
From: | Markus Lavin |
Subject: | Re: Use of BQL from thread in PCIe device |
Date: | Wed, 18 Dec 2024 19:10:31 +0000 |
Sorry but I don't quite follow. Which callbacks are we talking about?
Are you saying that it is fine to call pci_dma_read/pci_dma_write/msix_notify from a thread without acquiring any particular lock in advance?
Thanks,
Markus
From: John Levon <levon@movementarian.org>
Sent: Wednesday, December 18, 2024 6:28 PM To: Markus Lavin <markus.lavin@ericsson.com> Cc: qemu-devel@nongnu.org <qemu-devel@nongnu.org> Subject: Re: Use of BQL from thread in PCIe device [You don't often get email from levon@movementarian.org. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
On Wed, Dec 18, 2024 at 04:19:47PM +0000, Markus Lavin wrote: > Hi, > > I think that I might have misunderstood something fundamental about the BQL > (or possibly Qemu in general). > > I have a custom PCIe device that connects to an outside simulation environment > using Unix domain sockets. To deal with bus-mastering from this outside > environment I have a thread created with qemu_thread_create listening to the > socket. > > If I get a read/write/interrupt request over the socket then the thread should > perform a pci_dma_read/pci_dma_write/msix_notify. Since this is called from > the threads context I assumed I should first grab the BQL. Issuing a bql_lock > from the thread however hangs Qemu. > > Is my thinking flawed? The BQL will be already taken for these callbacks higher up in the stack I believe. regards john |
[Prev in Thread] | Current Thread | [Next in Thread] |