qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of BQL from thread in PCIe device


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]