On 8/26/07, Blue Swirl <[EMAIL PROTECTED]> wrote: > On 8/26/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote: > > Paul Brook wrote: > > >>>> pci_gdma.diff: Convert PCI devices and targets > > >>>> > > >>>> Any comments? The patches are a bit intrusive and I can't test the > > >>>> targets except that they compile. > > >>> Shouldn't the PCI DMA object be a property of the PCI bus? > > >>> ie. we don't want/need to pass it round as a separate parameter. It can > > >>> be inferred form the device/bus. > > >> I agree. Moreover the DMA is bus specific so I don't see a need to add a > > >> generic DMA layer. > > > > > > I can see use for a generic DMA interface. It has some nice possibilities > > > for > > > devices which can connect via a variety of busses and maybe for layering > > > different busses within a system. > > > > > > However I don't know how well this will work in practice for the machines > > > qemu > > > currently emulates. > > > > I can see more uses for a simple bus interface which could be used at > > least for ISA devices. The API should include bus read/write functions > > (which can be used to implement DMA) and functions to allocate/free a > > memory region as we have for the CPU bus. > > > > Of course the same must be added for PCI buses so that the PCI memory > > area can be mapped at any position in the CPU address space. > > Nice idea. The functions in exec.c could be made more generic by > extending them with an object parameter, for example > int cpu_register_io_memory(int io_index, > CPUReadMemoryFunc **mem_read, > CPUWriteMemoryFunc **mem_write, > void *opaque) > would become > int bus_register_io_memory(void *opaque, > int io_index, > CPUReadMemoryFunc **mem_read, > CPUWriteMemoryFunc **mem_write, > void *io_opaque) > > The opaque object would be struct PCIBus for PCI devices, something > other for ISA. The ISA DMA DREQ signal is still a problem, or could we > use qemu_irq for that too?
On second thought, there is a huge difference between a write access originating from CPU destined for the device and the device writing to main memory. The CPU address could be 0xf000 1000, which may translate to a bus address of 0x1000, as an example. The device could write to main memory using the same bus address 0x1000, but this time the IOMMU would map this to for example 0x1234 5000, or without an IOMMU it would be just 0x1000. So for the CPU physical address to bus address translation, my proposal would work. But the system does not work in the direction of device to memory, which was the original problem. The devices in the same bus could access each other as well. How would these accesses be identified, so that they are not device to memory accesses? Maybe I have missed something important?