All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: NAHieu <nahieu@gmail.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Tony Breeds <tony@bakeyournoodle.com>
Subject: Re: [BUNDLE] Testing a simpler inter-domain transport
Date: Sun, 05 Feb 2006 22:13:32 +1100	[thread overview]
Message-ID: <1139138012.12830.8.camel@localhost.localdomain> (raw)
In-Reply-To: <5d7aca950602050226l18e59831sc0306a3ec859798f@mail.gmail.com>

On Sun, 2006-02-05 at 19:26 +0900, NAHieu wrote:
> On 2/5/06, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > Hi all,
> >
> >         I've finally found time to resurrect my "share" code, update it for Xen
> > 3.0 and (with Tony Breeds' help) created a simple LAN driver.  You can
> > find the bundle here:
> >
> >         http://ozlabs.org/~rusty/xen/xen-share-2006-02-05.hg
> 
> Rusty, could you tell us what this code does???

Strange, there's a README.xen-share file in that dir, but Apache doesn't
seem to show it.  I've put an explicit index in there now, but here's
the README.xen-share file:

Introduction to the Xen Share Code

Goal
----
To produce a simple interdomain transport which has device-like
characteristics.

Method
------
We need mapped I/O, interrupts and DMA.  For mapped I/O, dom0
explicitly creates "sharable" pages for the devices to use, using the
dom0 ops:

	DOM0_CREATESHAREDPAGES(num-pages)
	- Returns physically contiguous pages as a sharable region.
	DOM0_DESTROYSHAREDPAGES(pfn)
	- Free the shared pages once no domain is referencing them (see below)
	DOM0_GRANTSHAREDPAGES(domain, pfn)
	- Allow this domain access to these shared pages.

These are mapped by the domain using the multiplexed "share_op"
hypercall:
	XEN_SHARE_get(pfn,evtchn)
	- Returns a non-negative lowest-possible "peer id".  The
	  evtchn is used to notify of all events which occur on this
	  region.  The pages can then be mapped.
	XEN_SHARE_drop(pfn)
	- Drops the shared pages.

We have a method of receiving and sending notifications, based on
addresses within the shared region:

	XEN_SHARE_watch(address, u32 *decaddr)
	- When someone triggers this address (see below), atomically
	  decrement decaddr: if it hits 0, raise the eventchannel.
	XEN_SHARE_trigger(address)
	- Trigger any watches on this address (see above).

Finally, there is a method for registering scatter-gather lists for
input or output:

	XEN_SHARE_sg_register(pfn, read/write, #sgs, sg[], u32 *lenaddr)
	- Register an array of machine address/length pairs associated
	  with this share.  When it's used (see below), the length will be
	  written at lenaddr, the sg unregistered, and the event
	  channel raised.
	XEN_SHARE_sg_unregister(pfn, sg_addr)
	- Unregister the scatter-gather list with this first address.
	XEN_SHARE_sg_xfer(pfn, read/write, peerid, #sgs, sg[])
	- Copy from these virtual address/length pairs to this peer
	  associated with this share.  Returns the number of bytes
	  actually transferred.

These mechanisms create an efficient and simple way of writing virtual
drivers which behave like normal device drivers.

Future optimizations / improvements:

(1) The hypervisor code uses dumb linked lists, which could be arrays
    and hashes.

(2) The hypervisor currently always copies, but could page-flip.  This
    needs involve guest awareness in the non-shadow-pagetable model
    (the hypervisor *could* reach in and update the pfn array).

(3) The hypervisor should probably use the smallest possible sg entry.

(4) The entire protocol can be transparently remoted by the hypervisor.

(5) A trusted partition could ask the hypervisor for the sg list
    details for a domain, which it could then program directly into a
    device.

(6) The code isn't PAE friendly, and actually hands addresses in some
    places.  These should be fixed.

(7) The decaddr trick is a cute idea for interrupt mitigation, but
    currently unused and probably unnecessary.  It could be turned
    into a simple "set this to 1".

(8) Perhaps the hypervisor should wake at offset 0 whenever someone
    drops the share.


-- 
 ccontrol: http://ozlabs.org/~rusty/ccontrol

  reply	other threads:[~2006-02-05 11:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-05  3:38 [BUNDLE] Testing a simpler inter-domain transport Rusty Russell
2006-02-05 10:26 ` NAHieu
2006-02-05 11:13   ` Rusty Russell [this message]
2006-02-05 16:56 ` Anthony Liguori
2006-02-06  4:40   ` Rusty Russell
2006-02-08 10:12 ` Daniel Veillard
2006-02-08 10:23   ` Rusty Russell
2006-02-08 10:34     ` Muli Ben-Yehuda
2006-02-08 10:46       ` Daniel Veillard
2006-02-08 10:54         ` Muli Ben-Yehuda
2006-02-08 17:49     ` Matt Mackall
2006-02-08 11:04   ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2006-02-06 20:01 Magenheimer, Dan (HP Labs Fort Collins)
2006-02-07  0:10 ` Rusty Russell
2006-02-06 20:48 Yang, Fred
2006-02-06 21:38 Magenheimer, Dan (HP Labs Fort Collins)
2006-02-08  1:31 Magenheimer, Dan (HP Labs Fort Collins)
2006-02-08  2:55 ` Hollis Blanchard
2006-02-10  3:15 ` Rusty Russell
2006-02-10 17:54 Magenheimer, Dan (HP Labs Fort Collins)
2006-02-12 23:39 King, Steven R
2006-02-12 23:59 ` Ronald G Minnich
2006-02-13  2:32 ` Rusty Russell
2006-02-13  9:38 ` Daniel Veillard
2006-02-13  3:24 King, Steven R
2006-02-13  3:47 ` Rusty Russell

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=1139138012.12830.8.camel@localhost.localdomain \
    --to=rusty@rustcorp.com.au \
    --cc=nahieu@gmail.com \
    --cc=tony@bakeyournoodle.com \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.