Andrea Arcangeli wrote:
On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote:
1) You attempt to map a physical address. This effectively is a lock or
pin operation.
lock or pin for what? There's nothing to pin or lock here. Perhaps one
day we'll have to lock or pin against something, dunno, then we'll add
whatever pin or lock, otherwise why don't we also thread qcow2 while
we're at it, sounds more worth it than adding a lock or pin that isn't
actually needed.
Please try to understand what people are suggesting to you. I have no
idea why you bring up threading qcow2. This is not a topic that hasn't
been discussed at great length before. You didn't even fix any of the
comments people made against the series since the last time you posted it.
a) In the process of this, you get a virtual address that you can
manipulate.
That's what can_dma does. If it can, it generates a dma address backed
by ram it does. But if it can't, it won't. This only works for direct I/O.
No, can_dma does two things in one. It checks to see if there physical
region is MMIO, and it returns phys_ram_base + PA otherwise.
This is not helpful though in the general case. It's not an API that
extends well for things like memory hotplug, etc.
If we're not building APIs for the future, what's the point of this
exercise in the first place? virtio already has the bits to do
zero-copy memory transfers.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
