From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DDvP5-0006wY-FT for qemu-devel@nongnu.org; Tue, 22 Mar 2005 21:15:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DDvOz-0006sl-R5 for qemu-devel@nongnu.org; Tue, 22 Mar 2005 21:15:24 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DDvOz-0006qn-8K for qemu-devel@nongnu.org; Tue, 22 Mar 2005 21:15:21 -0500 Received: from [62.101.193.41] (helo=s-smtp-osl-02.bluecom.no) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DDv3r-0002a7-68 for qemu-devel@nongnu.org; Tue, 22 Mar 2005 20:53:31 -0500 Subject: Re: [Qemu-devel] pciproxy status? From: "Karsten N. Strand" In-Reply-To: <1111494345.4238.75.camel@sherbert> References: <423FF1CA.3000406@nixia.no> <1111494345.4238.75.camel@sherbert> Content-Type: text/plain Date: Wed, 23 Mar 2005 02:53:30 +0100 Message-Id: <1111542810.20184.48.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, 2005-03-22 at 12:25 +0000, Gianni Tedesco wrote: > On Tue, 2005-03-22 at 11:22 +0100, Karsten N. Strand wrote: > >Hi, > >First I must say that I'm extremely impressed with the development of > >qemu, and that I think it's currently one of the most technical > >interesting open source projects these days. Then the question.. > > > >What's the status of the pciproxy patch? Is it still work in progress, > >or have it stalled now? What about pci DMA support? > > Unfortunately it's pretty much stalled due to lack of time. It should > work OK though provided your PCI device is not sharing IRQs. > The card I'm trying to debug is luckily the one and only device in my computer not sharing an IRQ. On the curiosity side of it, looking through the sigirq code I was unable to understand why it wouldn't support shared irqs by just adding the SHIRQ flag to request_irq(). It does provide a unique identifier through the procfs file pointer? Sorry if this is a stupid question, I'm not very experienced with kernel code. > PCI DMA is somewhat tricky to implement (not possible in a general way > without either patching the guest, or invasive patching of the host). > > Maybe by analyzing the logs thus far, you could build some device > specific hooks for figuring out when/how to initiate DMA. Right now it crashes before even producing any output. It might be some change in qemu cvs I have overlooked that breaks the pciproxy patch.. (?) Anyway, I will try to debug it, just want to make myself a bit more familiar with the qemu sources first. > I know the gelato team have got some patches that add new syscalls to > linux for allocating buffers to userspace suitable for PCI DMA - which > is the next thing thats required once you have the address/length of the > buffers and direction of transfer. > I had never heard about that project before, but superficially looking through their wiki this looks like a good approach. This gets me thinking about the possibility of compiling a lightweight kernel with no native IO drivers, and proxying all devices on the PC through it (except some device for debug IO), making it a drop-in transparent debugger for any computer. That would be extremely cool :) Thanks for all the help :) Karsten N. Strand