Re: [Xen-devel] [RFC PATCH 1/5] Support for running secondary emulators

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Matt Wilson [mailto:mswilson@xxxxxxxxx] On Behalf Of Matt Wilson
> Sent: 03 March 2014 22:41
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [RFC PATCH 1/5] Support for running secondary
> emulators
> 
> On Mon, Mar 03, 2014 at 01:34:41PM +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Matt Wilson [mailto:mswilson@xxxxxxxxx] On Behalf Of Matt
> Wilson
> > > Sent: 01 March 2014 22:25
> > > To: Paul Durrant
> > > Cc: xen-devel@xxxxxxxxxxxxx
> > > Subject: Re: [Xen-devel] [RFC PATCH 1/5] Support for running secondary
> > > emulators
> > >
> > > On Thu, Jan 30, 2014 at 02:19:45PM +0000, Paul Durrant 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.
> > > >
> > > [...]
> > >
> > > Hi Paul,
> > >
> > > I'm coming back to play with this after a few weeks and I'm having
> > > trouble getting things going. It seems that I'm crashing early when
> > > hvmloader is programming the PCI-ISA bridge link routes.
> 
> [...]
> 
> > > Any quick ideas before I go instrumenting things?
> > >
> >
> >
> > Matt,
> >
> > I've re-worked the patches a bit and am about to submit them non-RFC
> > this time. I had a look at the shared page setup given what you saw
> > and I can't find a memset anywhere to init the shared ioreq state so
> > I suspect your problem is just uninitialized mem (and I guess I may
> > not have seen it as I usually only run up a couple of VMs before I
> > need to do a host reboot so I'm probably getting freshly scrubbed
> > pages every time). So, I'll stick a memset in my new patch and
> > hopefully you can give the new code a spin once I've posted it.
> 
> I'm not sure... I tossed a scrub_one_page(page); in hvm_set_ioreq_page()
> but that didn't seem to help.
> 

Looking more closely, I'm guessing (given the log messages) that the IO in 
question was the first PCI config space write, which should hit the new cf8 
handler in xen (which will indeed set the io emulation status to unhandleable) 
but it should then find the ioreq server (which was clearly created) and QEMU 
should handle the IO. Looking at the code in hvmemul_do_io though, if it gets 
as far as actually running the cf8 handler, I don't see how it can return with 
unhandleable which suggests maybe the vcpu emulation status is already hosed 
before the config space IO was attempted.
I've not been able to repro in my testing so far though. What sort of guest 
were you kicking off?

  Paul

> I'll give your next series a spin when you post them (or push to your
> git repository).
> 
> --msw

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