[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 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?

> 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.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.