[Qemu-devel] xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Qemu-devel] xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Sander Eikelenboom]

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

Re: xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Stefano Stabellini]

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

Re: [Qemu-devel] xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Stefano Stabellini]

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

Re: [Qemu-devel] xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Sander Eikelenboom]

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

Re: [Qemu-devel] xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Gerd Hoffmann]

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

Re: xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Gerd Hoffmann]

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

Re: xen-unstable qemu-upstream: pci-passthrough timing issues due to commit 0f7b2864d0d0c3ef2801f9214d8c510c80a220d1 when vnc enabled

[Sander Eikelenboom]

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