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 <[email protected]> Sent: Wednesday, December 18, 2024 6:28 PM To: Markus Lavin <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Use of BQL from thread in PCIe device [You don't often get email from [email protected]. 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
