Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework

[Blue Swirl]

On 8/26/07, Blue Swirl <address@hidden> wrote:
> On 8/26/07, Fabrice Bellard <address@hidden> 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?