[Qemu-devel] pciproxy status?

[Qemu-devel] pciproxy status?

[Karsten N. Strand]

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?

The reason I ask is because I want to try to reverse engineer my 
EMU-1820 pci soundcard, with the intention of getting it supported in 
linux. And qemu with pciproxy support seems like the perfect tool for 
this job.

My progress so far:

Got the newest qemu cvs to compile with the pciproxy 0.3 patch with a 
few modifications, installed Windows XP without any troubles at all (I'm 
impressed! :), and booted up qemu-softmmu with -pciproxy 02:06.2 (or 
something like that). The card was detected in the virtual machine, and 
I started installation of the driver. After accepting the unsigned 
driver, qemu hanged, and I couldn't get any response in the vm.

At that point I had to go to bed (3 hours sleep before work is a minimum 
:P), so I haven't had the chance to investigate the hang further yet. 
However I suspects that in any case it probably needs DMA support 
through the pci proxy, since soundcards usually do..

If anyone is interested I can post the updated patch later (right now 
I'm at work, and the code is at home). Any thoughts or comments on this  
would be very appreciated :)

Kind regards,
Karsten N. Strand

Re: [Qemu-devel] pciproxy status?

[Gianni Tedesco]

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.

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.

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.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import

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

Re: [Qemu-devel] pciproxy status?

[Gianni Tedesco]

On Wed, 2005-03-23 at 02:53 +0100, Karsten N. Strand wrote:
>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.

Well shared IRQs are just a bit dodgy. If we get an IRQ we wont know
which device it is for so if we send a signal to the qemu first, the
guest OS will look on its ISR list for that IRQ, find the proxied
device, find that it wasn't that, and ACK the IRQ. But because PCI IRQs
are level triggered it gets immediately reasserted and locks up the
guest OS in an interrupt storm. Conversely if you send the signal after
checking all host ISRs then there is a window where if qemu is killed,
the IRQ storm happens on the host. SIGIRQ patch needs to make the kernel
send the IRQ-signal and wait for qemu to tell it when to ACK the PIC.

Anyway, thats all academic since I just checked and the qemu patches on
my site aren't even using SIGIRQ yet. So I should correct my previous
statement. It should work provided the card isn't using IRQs (so just
accessing registers).

>> 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.

Have you tried putting a printf at the beginning of ioread() / iowrite()
et al in the pciproxy code? the 0.2 version of the patch has the
printfs() removed...

>> 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 :)

Heh, well a while back a guy was working on running BIOS code through
qemu (which was booted directly from the disk) and just copying all i/o
transactions to the ISA serial port. With a bit of work, a system like
that could log just about anything :)

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import