[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API |
Date: |
Tue, 20 Jan 2009 19:42:52 +0200 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090105) |
Ian Jackson wrote:
Avi Kivity writes ("Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping
API"):
The devices we're talking about here don't have a DMA count register.
Which devices ? All devices ever that want to do zero-copy DMA into
the guest ?
IDE, scsi, virtio-blk, virtio-net, e1000, maybe a few more.
They are passed scatter-gather lists, and I don't think they make
guarantees about the order in which they're accessed.
Many devices will be able to make such promises.
If they do, and if guests actually depend on these promises, then we
will not use the new API until someone is sufficiently motivated to send
a patch to enable it.
This DMA will be into RAM, not mmio.
As previously discussed, we might be using bounce buffers even for
RAM, depending on the execution model. You said earlier:
Try it out. I'm sure it will work just fine (if incredibly slowly,
unless you provide multiple bounce buffers).
but here is an example from Jamie of a situation where it won't work
right.
Framebuffers? Those are RAM. USB webcams? These can't be interrupted
by SIGINT. Are you saying a guest depends on an O_DIRECT USB transfer
not affecting memory when a USB cable is pulled out?
We don't have a reliable amount to pass.
A device which _really_ doesn't have a reliable amount to pass, and
which is entitled to scribble all over the RAM it was to DMA to even
if it does only a partial transfer, can simply pass the total transfer
length. That would be no different to your proposal.
I'm suggesting we do that unconditionally (as my patch does) and only
add that complexity when we know it's needed for certain.
--
error compiling committee.c: too many arguments to function
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, (continued)
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Jamie Lokier, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/19
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API,
Avi Kivity <=
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Jamie Lokier, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/20
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Avi Kivity, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Anthony Liguori, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Ian Jackson, 2009/01/20
- [Qemu-devel] Re: Add target memory mapping API, Mike Day, 2009/01/21
- Re: [Qemu-devel] Re: Add target memory mapping API, Avi Kivity, 2009/01/21
- Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API, Gerd Hoffmann, 2009/01/19