Xen devel - Apr 2013 - xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

Hi Gerd,

Using qemu-upstream with pci-passthrough on xen-unstable previously worked fine.
Since commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 (bisected) i see what i
think are timing issues (video device is reporting buffer underruns).

Since that commit changes vnc code, i have disabled vnc (was default enabled,
but i did not use it).
Disabling vnc by using vnc=0 and nographic make thinks work like before.

--
Sander

On Sat, 20 Apr 2013, Sander Eikelenboom wrote:
> Hi Gerd,
> 
> Using qemu-upstream with pci-passthrough on xen-unstable previously worked
fine.
> Since commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 (bisected) i see what
i think are timing issues (video device is reporting buffer underruns).
> 
> Since that commit changes vnc code, i have disabled vnc (was default
enabled, but i did not use it).
> Disabling vnc by using vnc=0 and nographic make thinks work like before.
Are you sure that the bug is related to Xen PCI passthrough (it doesn''t
happen if you don''t assign any devices to the Xen guest)?
I am asking because the Xen PCI passthrough code doesn''t use any
timers,
while this looks like something related to timer and refresh
intervals...

Monday, April 22, 2013, 12:01:02 PM, you wrote:
> On Sat, 20 Apr 2013, Sander Eikelenboom wrote:
>> Hi Gerd,
>> 
>> Using qemu-upstream with pci-passthrough on xen-unstable previously
worked fine.
>> Since commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 (bisected) i see
what i think are timing issues (video device is reporting buffer underruns).
>> 
>> Since that commit changes vnc code, i have disabled vnc (was default
enabled, but i did not use it).
>> Disabling vnc by using vnc=0 and nographic make thinks work like
before.
> Are you sure that the bug is related to Xen PCI passthrough (it
doesn''t
> happen if you don''t assign any devices to the Xen guest)?
> I am asking because the Xen PCI passthrough code doesn''t use any
timers,
> while this looks like something related to timer and refresh
> intervals...

Ok latency issue would perhaps be a better description.
I think something in this change make it worse, hence resulting in the driver of
the passthroughed pci device reporting that it''s buffer was empty (4
times) and then the buffer is filled up with 4 frames where it expected only 1.

Anyhow i noticed that running with "nographic" dramatically reduces
the overhead of the qemu process in dom0 compared to running with graphics.
Which seems strange since it''s a console only linux guest and no vnc
clients are connected ...

--
Sander

On 04/22/13 12:10, Sander Eikelenboom wrote:
> 
> Monday, April 22, 2013, 12:01:02 PM, you wrote:
> 
>> Are you sure that the bug is related to Xen PCI passthrough (it
>> doesn''t happen if you don''t assign any devices to the
Xen guest)? I
>> am asking because the Xen PCI passthrough code doesn''t use any
>> timers, while this looks like something related to timer and
>> refresh intervals...
> Ok latency issue would perhaps be a better description. I think
> something in this change make it worse, hence resulting in the driver
> of the passthroughed pci device reporting that it''s buffer was
empty
> (4 times) and then the buffer is filled up with 4 frames where it
> expected only 1.
irq latencies probably.  Although ... is qemu involved in the irq
delivery path in the first place?

How frequent are these latency spikes?
> Anyhow i noticed that running with "nographic" dramatically
reduces
> the overhead of the qemu process in dom0 compared to running with
> graphics. Which seems strange since it''s a console only linux
guest
> and no vnc clients are connected ...
The gui update rate is adaptive and ranges from .03 seconds minimum to 3
seconds maximum.  With an active guest you''ll see the refresh interval
close to the lowest limit.  With an idle guest (doing no screen updates)
the update rate goes down step by step until it reaches 3 seconds after
a while.

Enable the "console_refresh" tracepoint and you should see the logic
at
work.

With no vnc client connected it should always stay at the maximum (3
seconds).  An vnc screen update every three seconds should not cause a
dramatic change, especially as there is next to nothing to do when the
guest doesn''t update the screen.

cheers,
  Gerd