From: Anthony Liguori <anthony@codemonkey.ws>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: chrisw@redhat.com, avi@redhat.com,
Gerd Hoffmann <kraxel@redhat.com>,
kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Date: Fri, 12 Dec 2008 13:39:26 -0600 [thread overview]
Message-ID: <4942BDEE.7020003@codemonkey.ws> (raw)
In-Reply-To: <4942B841.6010900@codemonkey.ws>
Anthony Liguori wrote:
> Andrea Arcangeli wrote:
>> From: Andrea Arcangeli <aarcange@redhat.com>
>>
>> Add can_dma and post_dma methods needed before/after direct IO to guest
>> physical memory.
>>
>
> I think any API based on a can_dma abstraction is wrong. The
> write_post_dma thing is equally wrong.
>
> The concept of "dma" that you're introducing is not correct.
>
> The DMA API should have the following properties:
>
> 1) You attempt to map a physical address. This effectively is a lock
> or pin operation.
> a) In the process of this, you get a virtual address that you can
> manipulate.
> 2) You do your IO to the virtual address
> 3) You indicate how much of the memory you have dirtied
> 4) You unmap or unlock that memory region. The virtual address is now
> no longer valid.
>
> This could correspond to a:
>
> void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t
> size, int is_write);
>
> void cpu_physical_memory_unmap(target_physical_addr_t addr, ram_addr_t
> size, void *mapping, int is_dirty);
Let me clarify this a bit more. The problem we're trying to address
today is the encapsulating knowledge of phys_ram_base. We want to
minimize the amount of code that makes any assumptions about
phys_ram_base. Your current API still accesses phys_ram_base directly
in the PCI DMA API. The only real improvement compared to the current
virtio code is that you properly handle MMIO. This is not just about
layout but this also includes the fact that in the future, guest memory
could be discontiguous in QEMU (think memory hotplug).
Or, in the case of Xen, it may not be possible to have all of guest
memory mapped at any given time. The API that I propose above limits
the knowledge of how to access guest memory to exec.c and makes it very
easy to deal with discontiguous or even partially mapped guest memory in
QEMU. Any other APIs built around it (like a PCI DMA API) don't have to
have any special knowledge about how guest memory is stored.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2008-12-12 19:39 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 18:16 [Qemu-devel] [PATCH 0 of 5] dma api v3 Andrea Arcangeli
2008-12-12 18:16 ` [Qemu-devel] [PATCH 1 of 5] fix cpu_physical_memory len Andrea Arcangeli
2008-12-12 19:06 ` [Qemu-devel] " Anthony Liguori
2008-12-12 19:26 ` Andrea Arcangeli
2008-12-12 18:16 ` [Qemu-devel] [PATCH 2 of 5] add can_dma/post_dma for direct IO Andrea Arcangeli
2008-12-12 19:00 ` Blue Swirl
2008-12-12 19:18 ` Anthony Liguori
2008-12-12 20:05 ` Blue Swirl
2008-12-12 20:10 ` Anthony Liguori
2008-12-12 19:15 ` [Qemu-devel] " Anthony Liguori
2008-12-12 19:37 ` Andrea Arcangeli
2008-12-12 20:09 ` Anthony Liguori
2008-12-12 20:25 ` Gerd Hoffmann
2008-12-12 19:39 ` Anthony Liguori [this message]
2008-12-13 9:22 ` Avi Kivity
2008-12-13 16:45 ` Anthony Liguori
2008-12-13 19:48 ` Avi Kivity
2008-12-13 21:07 ` Anthony Liguori
2008-12-14 6:03 ` Avi Kivity
2008-12-14 19:10 ` Anthony Liguori
2008-12-14 19:49 ` Avi Kivity
2008-12-14 23:08 ` Anthony Liguori
2008-12-15 0:57 ` Paul Brook
2008-12-15 2:09 ` Anthony Liguori
2008-12-15 6:23 ` Avi Kivity
2008-12-15 18:35 ` Blue Swirl
2008-12-15 22:06 ` Anthony Liguori
2008-12-16 9:41 ` Avi Kivity
2008-12-16 16:55 ` Blue Swirl
2008-12-16 17:09 ` Avi Kivity
2008-12-16 17:48 ` Anthony Liguori
2008-12-16 18:11 ` Blue Swirl
2008-12-16 15:57 ` Blue Swirl
2008-12-16 16:29 ` Paul Brook
2008-12-16 16:35 ` Blue Swirl
2008-12-14 17:30 ` Jamie Lokier
2008-12-13 14:39 ` Andrea Arcangeli
2008-12-13 16:46 ` Anthony Liguori
2008-12-13 16:53 ` Andrea Arcangeli
2008-12-13 17:54 ` Andreas Färber
2008-12-13 21:11 ` Anthony Liguori
2008-12-14 16:47 ` Andrea Arcangeli
2008-12-14 17:01 ` Avi Kivity
2008-12-14 17:15 ` Andrea Arcangeli
2008-12-14 19:59 ` Avi Kivity
2008-12-22 16:44 ` Ian Jackson
2008-12-22 19:44 ` Avi Kivity
2008-12-23 0:03 ` Thiemo Seufer
2008-12-23 1:02 ` Andrea Arcangeli
2008-12-23 17:31 ` Avi Kivity
2008-12-22 19:46 ` Avi Kivity
2009-01-05 10:27 ` Gerd Hoffmann
2008-12-13 22:47 ` Anthony Liguori
2008-12-14 6:07 ` Avi Kivity
2008-12-12 18:16 ` [Qemu-devel] [PATCH 3 of 5] rename dma.c to isa_dma.c Andrea Arcangeli
2008-12-12 18:16 ` [Qemu-devel] [PATCH 4 of 5] dma api Andrea Arcangeli
2008-12-12 18:55 ` Blue Swirl
2008-12-12 18:16 ` [Qemu-devel] [PATCH 5 of 5] bdrv_aio_readv/writev Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4942BDEE.7020003@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=aarcange@redhat.com \
--cc=avi@redhat.com \
--cc=chrisw@redhat.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).