#36 PCI device mapping

[Anonymous]

Implement a Windows PCI device driver that can be
installed on any PCI device in Windows - and a PCI bus
driver in linux. When the device driver is installed on
a device in Windows that device appears on the PCI bus
in linux. This would allow arbitrary PCI devices to be
selected for use in Linux. Now
graphics/sound/USB/wireless can work natively in Linux.

Simon

[deepthi kiran]

Logged In: YES
user_id=2000870
Originator: NO

Hi,

Is this request still open?we would like to takeup this request if it is open.PLease respond it soon

[Henry N.]

Logged In: YES
user_id=579204
Originator: NO

This is still open.
coLinux has no direct hardware access. *All* io are handled by host system, includes physically PCI bus and interrupt controller.

Remember, such implementation would break the design.

[Nobody/Anonymous]

Logged In: NO

I don't know enough about Windows driver design (specifically resource requests) to know whether this is even possible, because such a driver would have to request all the IRQs/IO ports/DMA channels and so forth needed by the hardware, and it might be too late once colinux loads and the linux driver supplies the device-specific details.

If it is possible to set the resources after colinux loaded, then it shouldn't break the design, because all hardware access would still go through the Windows kernel-mode APIs and therefore be properly synchronized. It would however be extremely slow unless the device is designed to be non-chatty (see discussions of emulated I/O ports vs paravirtualization on the mailing lists of kvm, xen, etc).

[Henry N.]

Logged In: YES
user_id=579204
Originator: NO

Reserve a resource on windows side is not the problem. A driver with an inf file and some ntkernel functions would do this.
But, coLinux has no IO, no DMA and other recourses, and no "forwarder" for such things.

coLinux has no trap handler for illegal IO to go into windows. All trap handlers are handled inside Linux self (IO fault, page fault, illegal instruction). That's why you can not access for example the hardware clock "hwclock", and why not can see the host BIOS.

The only forwarder are "interrupt-proxy" and allocate "pseudo-physicaly" memory.

[Nobody/Anonymous]

Logged In: NO

Requirement of this is not cleared for us,please explain this in detail.In this it is mentioned that we need to implement PCI bus in linux,and PCI driver in windows.but in the kernal we have some PCI bus driver under arch/i386/pci know?Please us give us some idea about this

[Nobody/Anonymous]

Logged In: NO

I believe that providing a "forwarder" for DMA,IRQ,IO port access is exactly the point of the feature request. The submitter obviously believed that such commands, in addition to enumeration, are the responsibility of the PCI bus driver in linux (that sounds reasonable enough to me but I don't know if it is true).

So the linux bus driver and Windows PCI stub driver would have to call into colinux to set up a colinux channel (I don't know how the serial/network/framebuffer drivers do this, a message-passing API on top of shared memory I guess?) and then forward generic access to an arbitrary PCI device.

[Henry N.]

Logged In: YES
user_id=579204
Originator: NO

Yes, the previous comment was ok.

The common drivers in arch/i386/pci does all access directly on ioport, or from memory mapped devices. That exactly can only do on windows side. If you would do it for a single port access (outb, inb), then the performance would go down. If you does more as one io access on the windows side, you needs to know exactly the device, so you can wait for next byte to fill up some buffers and give back it to Linux. This overhead is typicaly a full virtualisation.

Let me write a theory example of getting a sector from a special hard disk controller, that not is handled by windows normal ide/scsi disk:

Write a Windows driver startup code to reserve the resources (io, mem, dma, irq).
Make the io/mem/irq public for the Linux driver.
Write a pci handle under Windows for exactly this vendor+id.
Forward pci information vendor+id to Linux pseudo pci list.

Now lets assume Linux would read some data from device.

Linux driver would write a command sequence to the hard disk controller.
Direct io is forbidden. Must create a pseudo command and forward it to windows.
Windows must check that the device is ready, than can write these bytes.
Some times later, the device would generate a hardware IRQ.
In worst case, we are currently in Linux. Linux must forward the IRQ to windows.
The windows driver have an irq handle and will be notify Linux kernel.
Linux would become a virtual interupt. (via message queue)
Linux kernel handle this by calling the Linux interrupt handler.
The Linux interrupt handler for that device would now read the bytes from disk controller.
We must passage to the Windows side again and read the bytes from ioport to shared memory.
Now must post a message to Linux again, that the buffer is filled with data.

After seen this overhead, the question is, why not write the device driver on windows side and give data in a more pseudo message queue, as cobd/network/serial does it?