[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [virtio-dev] Re: VIRTIO - compatibility with different virtualization solutions
On Tue, 2014-02-25 at 11:10 +1030, Rusty Russell wrote: > Anthony Liguori <anthony@xxxxxxxxxxxxx> writes: > > On Thu, Feb 20, 2014 at 4:54 PM, Rusty Russell <rusty@xxxxxxxxxxx> wrote: > >> On the other hand, if we wanted a more Xen-like setup, it would looke > >> like this: > >> > >> 1) Abstract away the "physical addresses" to "handles" in the standard, > >> and allow some platform-specific mapping setup and teardown. > > > > At the risk of beating a dead horse, passing handles (grant > > references) is going to be slow. > ... > > I really think the best paths forward for virtio on Xen are either (1) > > reject the memory isolation thing and leave things as is or (2) assume > > bounce buffering at the transport layer (by using the PCI DMA API). > > Xen can get memory isolation back by doing the copy in the hypervisor. > I've always liked that approach because it doesn't alter the guest > semantics, but it's very different from what Xen does now. Doing the copy in the hypervisor still uses grant references, since the hypervisor needs to know what the source domain is permitting access to for the target domain (or vice versa if you do the copy the other way) and grant tables are the mechanism which achieves this. See the already existing GNTTABOP_copy[0] for example, it is used in the existing Xen PV driver pairs (e.g. network receive into domU). Ian. [0] http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,grant_table.h.html#EnumVal_GNTTABOP_copy _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |