Re: [Xen-devel] [PATCH v3 0/6] Support for running secondary emulators

[George Dunlap <dunlapg@xxxxxxxxx>]

On Wed, Mar 5, 2014 at 2:47 PM, Paul Durrant <paul.durrant@xxxxxxxxxx> wrote:
> 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 'savannah3'
> branch, and I have also written a demo emulator to test the code, which can
> be found in my demu.git [2] repo.
>
>
> The modifications are broken down as follows:
>
> Patch #1 basically just moves some code around to make subsequent patches
> more obvious.
>
> Patch #2 tidies up some uses of ioreq_t as suggested by Andrew Cooper.
>
> Patch #3 again is largely code movement, from various places into a new
> hvm_ioreq_server structure. There should be no functional change at this
> stage as the ioreq server is still created at domain initialisation time (as
> were its contents prior to this patch).
>
> Patch #4 is the first functional change. The ioreq server struct
> initialisation is now deferred until something actually tries to play with
> the HVM parameters which reference it. In practice this is QEMU, which
> needs to read the ioreq pfns so it can map them.
>
> Patch #5 is the big one. This moves from a single ioreq server per domain
> to a list. The server that is created when the HVM parameters are reference
> is given id 0 and is considered to be the 'catch all' server which is, after
> all, how QEMU is used. Any secondary emulator, created using the new API
> in xenctrl.h, will have id 1 or above and only gets ioreqs when I/O hits one
> of its registered IO ranges or PCI devices.
>
> Patch #6 pulls the PCI hotplug controller emulation into Xen. This is
> necessary to allow a secondary emulator to hotplug a PCI device into the VM.
> The code implements the controller in the same way as upstream QEMU and thus
> the variant of the DSDT ASL used for upstream QEMU is retained.

Overall looks good -- looking forward to getting this one in.  It
should help unify the "HVM no-emulator" (aka PVH) path as well.

BTW, I see in your "savannah3" branch you have an extra patch not
submitted here, allowing vga=none.  Have you seen Fabio's patch on the
same subject?  It looks a bit more complete:

http://marc.info/?l=xen-devel&m=139306550111524

 -George

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