On 09/01/2011 12:00 AM, David Gibson wrote:
This patch adds functions to pci.[ch] to perform PCI DMA operations. At
present, these are just stubs which perform directly cpu physical memory
accesses.
Using these stubs, however, distinguishes PCI device DMA transactions from
other accesses to
On Fri, Sep 02, 2011 at 02:38:25PM +1000, David Gibson wrote:
I'd prefer the stubs to be inline. Not just as an optimization:
it also makes it easier to grok what goes on in the common
no-iommu case.
To elaborate on my earlier mail. The problem with making them inlines
is that the
On Fri, Sep 2, 2011 at 8:35 AM, Avi Kivity a...@redhat.com wrote:
On 09/01/2011 07:32 PM, Anthony Liguori wrote:
True. But I still think it's the right thing.
We can't really pass a MemoryRegion as the source address, since there
is no per-device MemoryRegion.
Couldn't the PCI bus expose
On 09/01/2011 07:32 PM, Anthony Liguori wrote:
True. But I still think it's the right thing.
We can't really pass a MemoryRegion as the source address, since there
is no per-device MemoryRegion.
Couldn't the PCI bus expose 255 MemoryRegions though?
What would those mean? A MemoryRegion
On 09/01/2011 07:05 PM, Anthony Liguori wrote:
The challenge is what you do about something like ne2k where the core
chipset can either be a PCI device or an ISA device. You would have
to implement a wrapper around pci_dma_rw() in order to turn it into
cpu_physical_memory_rw when doing ISA.
On 09/01/2011 09:25 PM, Anthony Liguori wrote:
I think this is the wrong approach given the introduction of the memory API.
I think we should have a generic memory access function that takes a
MemoryRegion as it's first argument.
The PCI bus should then expose one memory region for each
On Fri, Sep 02, 2011 at 11:37:25AM +0300, Avi Kivity wrote:
On 09/01/2011 07:05 PM, Anthony Liguori wrote:
The challenge is what you do about something like ne2k where the core
chipset can either be a PCI device or an ISA device. You would have
to implement a wrapper around
This patch adds functions to pci.[ch] to perform PCI DMA operations. At
present, these are just stubs which perform directly cpu physical memory
accesses.
Using these stubs, however, distinguishes PCI device DMA transactions from
other accesses to physical memory, which will allow PCI IOMMU
On Thu, Sep 01, 2011 at 03:00:54PM +1000, David Gibson wrote:
This patch adds functions to pci.[ch] to perform PCI DMA operations. At
present, these are just stubs which perform directly cpu physical memory
accesses.
Using these stubs, however, distinguishes PCI device DMA transactions from
On 09/01/2011 12:00 AM, David Gibson wrote:
This patch adds functions to pci.[ch] to perform PCI DMA operations. At
present, these are just stubs which perform directly cpu physical memory
accesses.
Using these stubs, however, distinguishes PCI device DMA transactions from
other accesses to
On 09/01/2011 06:55 PM, Anthony Liguori wrote:
On 09/01/2011 12:00 AM, David Gibson wrote:
This patch adds functions to pci.[ch] to perform PCI DMA operations. At
present, these are just stubs which perform directly cpu physical memory
accesses.
Using these stubs, however, distinguishes PCI
On 09/01/2011 11:03 AM, Avi Kivity wrote:
On 09/01/2011 06:55 PM, Anthony Liguori wrote:
On 09/01/2011 12:00 AM, David Gibson wrote:
This patch adds functions to pci.[ch] to perform PCI DMA operations. At
present, these are just stubs which perform directly cpu physical memory
accesses.
Using
On 09/01/2011 07:05 PM, Anthony Liguori wrote:
I think the patchset is fine. It routes all access through pci_dma_rw(),
which accepts a PCIDevice. We can later define pci_dma_rw() in terms of
the memory API and get the benefit of the memory hierarchy.
The challenge is what you do about
On 09/01/2011 11:11 AM, Avi Kivity wrote:
On 09/01/2011 07:05 PM, Anthony Liguori wrote:
I think the patchset is fine. It routes all access through pci_dma_rw(),
which accepts a PCIDevice. We can later define pci_dma_rw() in terms of
the memory API and get the benefit of the memory hierarchy.
On Thu, Sep 01, 2011 at 11:05:48AM -0500, Anthony Liguori wrote:
On 09/01/2011 11:03 AM, Avi Kivity wrote:
On 09/01/2011 06:55 PM, Anthony Liguori wrote:
On 09/01/2011 12:00 AM, David Gibson wrote:
[snip]
The challenge is what you do about something like ne2k where the
core chipset can either
On Thu, Sep 01, 2011 at 06:35:51PM +0300, Michael S. Tsirkin wrote:
On Thu, Sep 01, 2011 at 03:00:54PM +1000, David Gibson wrote:
[snip]
+DECLARE_LDST_DMA(ub, b, 8);
+DECLARE_LDST_DMA(uw, w, 16);
+DECLARE_LDST_DMA(l, l, 32);
+DECLARE_LDST_DMA(q, q, 64);
+
+#undef DECLARE_LDST_DMA
+
On Thu, Sep 01, 2011 at 07:03:34PM +0300, Avi Kivity wrote:
On 09/01/2011 06:55 PM, Anthony Liguori wrote:
On 09/01/2011 12:00 AM, David Gibson wrote:
This patch adds functions to pci.[ch] to perform PCI DMA operations. At
present, these are just stubs which perform directly cpu physical
On Thu, Sep 01, 2011 at 06:35:51PM +0300, Michael S. Tsirkin wrote:
On Thu, Sep 01, 2011 at 03:00:54PM +1000, David Gibson wrote:
[snip]
+#define DECLARE_LDST_DMA(_lname, _sname, _bits) \
+uint##_bits##_t ld##_lname##_pci_dma(PCIDevice *dev, dma_addr_t addr);
\
+void
18 matches
Mail list logo
