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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

<sigh> subject line was wrong before...

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxx] On Behalf Of Paul Durrant
> Sent: 08 May 2014 14:24
> To: xen-devel@xxxxxxxxxxxxx
> Subject: [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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel