Avi Kivity wrote:
> Ian Jackson wrote:
>> I think there is continued value in being able to emulate a guest
>> whose physical address space exceeds the virtual address space in the
>> host. The whole assumption that all guest accessible RAM is mapped at
>> once, contiguously, is I think wrong.
>
> If Xen has a problem with 64-bit hosts, we can try to
> accommodate it,
Yes, this is the whole point. Flesh out the DMA api in a way that Xen
can use it. Large memory guests are only one reason why Xen needs
map/unmap. The other one is grant table support.
> but to have 32-bit qemu/tcg or qemu/kvm support large
> address spaces is pointless IMO.
You don't have to support that.
I think the DMA api should look like this in the end:
struct qemu_dma_ops {
map(...);
xfer(...);
unmap(...);
};
The qemu/xen implementation would actually map/unmap.
For qemu/tcg and qemu/kvm which has all guest memory permanently mapped
map() would be a guest-physical -> host-virtual address translation and
unmap() would be a nop (or refcount--).
cheers,
Gerd
--
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
