Re: [Qemu-devel] pciproxy status?

[Karsten N. Strand]

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