Re: [Xen-devel] no default ioreq server?

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 12 June 2015 16:52
> To: Paul Durrant
> Cc: xen-devel
> Subject: RE: no default ioreq server?
> 
> >>> On 12.06.15 at 17:39, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 12 June 2015 15:41
> >> To: Paul Durrant
> >> Cc: xen-devel
> >> Subject: no default ioreq server?
> >>
> >> Paul,
> >>
> >> looks like guests nowadays run without a default ioreq server. Is
> >> that intended to be that way? Having noticed it and having looked
> >> at qemuu I certainly can't see how one would be set up. Yet
> >> without one send_timeoffset_req() can't possibly work, and after
> >> having seen "Unsuccessful timeoffset update" every once in a while
> >> over the last couple of weeks I finally took the time to look into
> >> what this would be caused by. Considering that reading the
> >> respective HVM params appears to be intentionally bypassed by
> >> qemuu, I also can't immediately see how this should be fixed.
> >
> >   Upstream QEMU actually ignored these ioreqs anyway (see
> > http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-
> unstable.git;f=xen-hvm.c;
> > hb=HEAD#l951),
> 
> Which is a bug / missing functionality afaict, or is there any
> replacement functionality in qemuu?
> 

Not that I am aware of. I don't know why it was left out.

> > so I wasn't too worried that there was any regression in
> > moving away from it being a default server. I agree the printks are a bit
> > annoying though (and they are straight printks rather than gdprintks).
> >
> >   I guess there's a couple of ways to tackle it. Either we have another hvm
> > op to allow an emulator to ask for TIMEOFFSET ioreqs, or we just broadcast
> > them. The latter is pretty simple to implement.
> 
> I.e. I guess that's the way to go then.
> 

Yes, I think so. I'm in the neighbourhood with my emulation cleanup series so 
I'll chuck together a patch.

  Paul

> Jan


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