[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.