[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:1.9.1.5) 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
bits.
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
len);
void *virtio_memory_map(VirtIODevice *dev, uint64_t addr, uint64_t *plen, int
is_write);
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.
Regards,
Anthony Liguori
- [Qemu-devel] [PATCH 03/15] lsi53c895a: convert to new pci interfaces, (continued)
- [Qemu-devel] [PATCH 03/15] lsi53c895a: convert to new pci interfaces, Anthony Liguori, 2010/02/09
- [Qemu-devel] [PATCH 15/15] pci: byte swap as PCI interface layer, Anthony Liguori, 2010/02/09
- [Qemu-devel] [PATCH 10/15] virtio-pci: convert to new pci interface, Anthony Liguori, 2010/02/09
- [Qemu-devel] [PATCH 11/15] pci: add pci_register_msix_region, Anthony Liguori, 2010/02/09
- [Qemu-devel] [PATCH 14/15] usb-uhci: convert to new pci interface, Anthony Liguori, 2010/02/09
- [Qemu-devel] [PATCH 08/15] es1370: convert to new pci interface, Anthony Liguori, 2010/02/09
- [Qemu-devel] [PATCH 13/15] pcnet: convert to new pci interface, Anthony Liguori, 2010/02/09
- [Qemu-devel] [PATCH 12/15] ne2000: convert to new pci interface, Anthony Liguori, 2010/02/09
- [Qemu-devel] Re: [PATCH 0/15][RFC] New PCI interfaces, Michael S. Tsirkin, 2010/02/10
- Re: [Qemu-devel] [PATCH 0/15][RFC] New PCI interfaces, Blue Swirl, 2010/02/10
- Re: [Qemu-devel] [PATCH 0/15][RFC] New PCI interfaces,
Anthony Liguori <=
- Re: [Qemu-devel] [PATCH 0/15][RFC] New PCI interfaces, Paul Brook, 2010/02/28