[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/15][RFC] New PCI interfaces

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/15][RFC] New PCI interfaces
Date: Wed, 10 Feb 2010 13:29:18 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 02/10/2010 12:34 PM, Blue Swirl wrote:
On Wed, Feb 10, 2010 at 12:01 AM, Anthony Liguori<address@hidden>  wrote:
This is a work in progress that I wanted to share giving some of the discussions
around rwhandlers.  The idea is to make PCI devices have a common set of
functions to interact with the CPU that is driven entirely through the PCI bus.

I've tested the network card conversions, but have not yet tested the other
By itself, the patches look OK. But given that the conclusion of the
generic DMA discussion was to aim for mapping approach (in order to
prepare for zero copy DMA), I wonder how the patches fit to the larger
picture. Perhaps instead of pci specific functions, a more generic
memory object with read and write methods could be introduced, which
would be more useful in the longer term?

This is a good point and it's something that needs to be addressed for the virtio conversion.

I was thinking:

void *pci_memory_map(PCIDevice *dev, pcibus_t addr, pcibus_t *plen, int is_write);

void pci_memory_unmap(PCIDevice *dev, void *buf, pcibus_t *plen, int is_write, pcibus_t access_len);

Not too surprising.

Since virtio devices can live on two busses (sysbus with Syborg or PCI), we need to introduce a set of virtio specific functions.

void virtio_memory_read(VirtIODevice *dev, uint64_t addr, void *buf, int len);
void virtio_memory_write(VirtIODevice *dev, uint64_t addr, const void *buf, int 
void *virtio_memory_map(VirtIODevice *dev, uint64_t addr, uint64_t *plen, int 
void virtio_memory_unmap(VirtIODevice *dev, uint64_t addr, uint64_t *plen, int 
is_write, uint64_t access_len);

Inside the VirtIODevice, there would be corresponding function pointers, and 
depending on whether it was a PCI device or a Syborg device, it would call 
pci_memory_map or cpu_physical_memory_map.

If we introduced a consistent address type, it would be possible to make 
generic memory access functions that used a state variable to mask this from 
the user.

I personally prefer the explicit interfaces though.  It makes it easy to look 
at a PCI device and see that it only uses PCI interfaces.  I also think that 
some bus concepts will be difficult to abstract in a generic way.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]