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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of
> George Dunlap
> Sent: 10 March 2014 18:58
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v3 0/6] Support for running secondary
> emulators
> 
> 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
> 

Yes. I think I notice that just after writing the code ;-) I'll swap over when 
I do savannah4.

  Paul

>  -George

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