[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH v6 1/9] Support for running secondary emulators



This patch series adds the ioreq server interface which I mentioned in
my talk at the Xen developer summit in Edinburgh at the end of last year.
The code is based on work originally done by Julien Grall but has been
re-written to allow existing versions of QEMU to work unmodified.

The code is available in my xen.git [1] repo on xenbits, under the 'savannah6'
branch, and I have also written a demo emulator to test the code, which can
be found in my demu.git [2] repo.


The series has been re-worked since v5. The modifications are now broken
down as follows:

Patch #1 is a pre-series tidy-up. No semantic change.

Patch #2 moves some code around to centralize use of the ioreq_t data
structure.

Patch #3 introduces the new hvm_ioreq_server structure.

Patch #4 defers creation of the ioreq server until something actually
reads one of the HVM parameters concerned with emulation.

Patch #5 adds an implementation of asprintf() for Xen.

Patch #6 adds an extra argument to rangeset_new() to allow ranges per
set to be limited.

Patch #7 makes the single ioreq server of previous patches into the
default ioreq server and introduces an API for creating secondary servers.

Patch #8 adds an enable/disable operation to the API for secondary servers
which makes sure that they cannot be active whilst their shared pages are
present in the guest's P2M.

Patch #9 adds makes handling buffered ioreqs optional for secondary servers.
This saves a page of memory per server.

The hotplug controller patch of previous versions of this series has
been dropped to give me more time for testing, and possible re-factoring.
This means that, for now, bus rescans will need to be invoked from within
the guest to notice devices provided by secondary emulators coming and going.

The demo emulator can simply be invoked from a shell. The emulated
device is not an awful lot of use at this stage - it appears as a SCSI
controller with one IO BAR and one MEM BAR and has no intrinsic
functionality... but then it is only supposed to be demo :-)

  Paul

[1] http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git
[2] http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git

v2:
 - First non-RFC posting

v3:
 - Addressed comments from Jan Beulich

v4:
 - Addressed comments from Ian Campbell and George Dunlap
 - Series heavily re-worked, 2 patches added

v5:
 - One more patch added to separate out a bug-fix, as requested by
   Jan Beulich
 - Switched to using rangesets as suggested by Jan Beulich
 - Changed domain restore path as requested by Ian Campbell
 - Added documentation for new hypercalls and libxenctrl API as requested
   by Ian Campbell
 - Added handling of multi-byte GPE I/O as suggested by Jan Beulich

v6:
 - Bugfix patch dropped as it has already been taken
 - Addressed various comments from Jan Beulich and Ian Campbell
 - Split out the addition of asprintf() into a separate patch
 - Dropped hotplug controller patch for now, to allow more time for testing
 - Split out rangeset patch and make range limit optional parameter
 - Added missing XSM checks


_______________________________________________
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®.