xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Rusty Russell <rusty@au1.ibm.com>
Cc: virtio-dev@lists.oasis-open.org, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	ian@bromium.com, Anthony Liguori <anthony@codemonkey.ws>,
	sasha.levin@oracle.com, xen-devel@lists.xenproject.org
Subject: Re: [virtio-dev] Re: VIRTIO - compatibility with different virtualization solutions
Date: Tue, 25 Feb 2014 16:12:47 -0500	[thread overview]
Message-ID: <20140225211247.GC5827@phenom.dumpdata.com> (raw)
In-Reply-To: <87vbw458jr.fsf@rustcorp.com.au>

On Tue, Feb 25, 2014 at 11:10:24AM +1030, Rusty Russell wrote:
> Anthony Liguori <anthony@codemonkey.ws> writes:
> > On Thu, Feb 20, 2014 at 4:54 PM, Rusty Russell <rusty@au1.ibm.com> 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.

It could. But why do it - the backend can choose it as well to do it
and perhaps even do some translation of the payload as it sees fit.

Or it can map it - and if using DPDK for example - one has
memory pages shared between the domains all the time - where you
just need to map once.

> 
> Cheers,
> Rusty.
> 

  parent reply	other threads:[~2014-02-28 13:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-17 13:23 VIRTIO - compatibility with different virtualization solutions Daniel Kiper
2014-02-19  0:26 ` Rusty Russell
     [not found] ` <87vbwcaqxe.fsf@rustcorp.com.au>
2014-02-19  4:42   ` Anthony Liguori
2014-02-20  1:31     ` Rusty Russell
     [not found]     ` <87ha7ubme0.fsf@rustcorp.com.au>
2014-02-20 12:28       ` Stefano Stabellini
2014-02-20 20:28       ` Daniel Kiper
2014-02-21  2:50       ` Anthony Liguori
2014-02-21 10:05         ` Wei Liu
2014-02-21 15:01           ` Konrad Rzeszutek Wilk
2014-02-25  0:33             ` Rusty Russell
     [not found]             ` <87y51058vf.fsf@rustcorp.com.au>
2014-02-25 21:09               ` Konrad Rzeszutek Wilk
2014-02-19 10:09   ` Ian Campbell
2014-02-20  7:48     ` Rusty Russell
     [not found]     ` <8761oab4y7.fsf@rustcorp.com.au>
2014-02-20 20:37       ` Daniel Kiper
     [not found]       ` <20140220203704.GG3441@olila.local.net-space.pl>
2014-02-21  0:54         ` [virtio-dev] " Rusty Russell
     [not found]         ` <8761o99tft.fsf@rustcorp.com.au>
2014-02-21  3:00           ` Anthony Liguori
2014-02-25  0:40             ` Rusty Russell
     [not found]             ` <87vbw458jr.fsf@rustcorp.com.au>
2014-02-25 21:12               ` Konrad Rzeszutek Wilk [this message]
2014-02-26  9:38               ` Ian Campbell
2014-02-21 10:21           ` Wei Liu
2014-02-21 15:11           ` Konrad Rzeszutek Wilk
2014-03-03  5:52             ` Rusty Russell
     [not found]             ` <87ppm325i6.fsf@rustcorp.com.au>
2014-03-04 23:16               ` Michael S. Tsirkin
2014-02-19 10:11   ` Ian Campbell
2014-03-10  7:54 ` Is: Wrap-up Was: " Daniel Kiper
     [not found] ` <20140310075423.GE31874@olila.local.net-space.pl>
2014-03-10 11:19   ` Fabio Fantoni
2014-03-11 14:29     ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140225211247.GC5827@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=anthony@codemonkey.ws \
    --cc=daniel.kiper@oracle.com \
    --cc=ian@bromium.com \
    --cc=rusty@au1.ibm.com \
    --cc=sasha.levin@oracle.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).