Re: [Xen-devel] Re: stdvga: slow ioreq

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

Yes, I guess you're using TightVNC? I always have much better experience
with RealVNC.

 -- Keir

On 15/11/07 14:58, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote:

> 
> The HVM guest window resizing problem via VNC is NOT a Xen/Qemu bug.
> The actual problem is the vncviewer client lacking support for the
> DesktopSize VNC pseudo-encoding. Clients missing this feature don't
> get notified from the server.
> 
> Looking a little around, I found two VNC clients which support this:
> RealVNC and ggivnc (SVN(!) version, http://www.lysator.liu.se/~peda/ggivnc/).
> 
> Christoph
> 
> 
> On Thursday 08 November 2007 13:49:47 Christoph Egger wrote:
>> My OpenSuSE 10.2 HVM guest is 64bit.
>> 
>> I just found a workaround:
>> Close the vnc client and re-connect. Then the vnc client uses
>> a larger window and I can actually see the cursor line.
>> 
>> This behaviour looks very much to me that the vnc server code
>> does not notify the client about graphic mode changes.
>> 
>> Christoph
>> 
>> On Tuesday 06 November 2007 17:26:45 Dave Lively wrote:
>>> Hi Christoph -
>>>   I'm trying to reproduce the behavior you're seeing.  Is your guest
>>> 32- or 64-bit?
>>> 
>>> Dave
>>> 
>>> On 11/5/07, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
>>>> An obvious bug I am seeing (but is not indicated by this certain
>>>> diagnostic message) is a scrolling bug. It appears when I boot a HVM
>>>> guest that uses a graphic mode (e.g. OpenSuSE 10.2). I am connected via
>>>> VNC to it. I don't see the line where the cursor is. I have to blindely
>>>> guess when the guest expects me to log in. After a (blind) successful
>>>> login, I have to type something like 'ls' several times, until I see
>>>> what I actually typed and the output of what I typed.
>>>> The latest changeset I tried is 16317 and the bug is reproducable.
>>>> The oldest changeset I tried so far is 16281 and this issue was
>>>> reproducable there, too. I hope, that helps.
>>>> 
>>>> Christoph
>>>> 
>>>> On Monday 05 November 2007 17:38:24 Robert Phillips wrote:
>>>>> Hi Christoph,
>>>>> 
>>>>> What you are seeing is (I hope) just an annoying diagnostic.  If you
>>>>> reduce your guest log level or eliminate the gdprintk() the problem
>>>>> should go away.
>>>>> 
>>>>> The diagnostic is warning that the ioreq could not be placed in the
>>>>> buffered iopage so it is being sent synchronously to qemu.
>>>>> The ioreq could not be placed in the buffered iopage because it
>>>>> couldn't be condensed into the (new) format.
>>>>> The new format has no room to store 'count' so ioreqs with count != 1
>>>>> take the slow route.
>>>>> 
>>>>> Our experience is that the few ioreqs handled this way are far out
>>>>> numbered by the condensable ioreqs
>>>>> and since far more condensable ioreqs now fit in the buffered iopage
>>>>> (than would fit with the old format)
>>>>> the performance improvement is substantial.
>>>>> 
>>>>> If the diagnostic is pointless and annoying, it should be eliminated.
>>>>> 
>>>>> -- Robert Phillips
>>>>> 
>>>>> On 11/5/07, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
>>>>>> Hello Ropert!
>>>>>> 
>>>>>> Since changeset 16285 (xen-staging), I get the following output
>>>>>> when I launch
>>>>>> a HVM guest and VGABios is running:
>>>>>> 
>>>>>> 
>>>>>> -------------------------------------------------------------------
>>>>>> -- ---- -------------- (XEN) intercept.c:172:d1 slow ioreq. type:1
>>>>>> size:1 addr:0xa0000 dir:0 ptr:1
>>>>>> df:0 count:16
>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0020
>>>>>> dir:0 ptr:1
>>>>>> df:0 count:16
>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0040
>>>>>> dir:0 ptr:1
>>>>>> df:0 count:16
>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0060
>>>>>> dir:0 ptr:1
>>>>>> df:0 count:16
>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0080
>>>>>> dir:0 ptr:1
>>>>>> df:0 count:16
>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa00a0
>>>>>> dir:0 ptr:1
>>>>>> df:0 count:16
>>>>>> [...]
>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa1fe0
>>>>>> dir:0 ptr:1
>>>>>> df:0 count:16
>>>>>> 
>>>>>> -------------------------------------------------------------------
>>>>>> -- ---- -----------------
>>>>>> 
>>>>>> This is not the full output (to keep this mail readable). The
>>>>>> address output
>>>>>> starts from 0xa0000 and goes to 0xa1fe0 and it always increases by
>>>>>> 0x20. (So you can generate the full output yourself :)
>>>>>> 
>>>>>> The output comes from xen/arch/x86/intercept.c, function
>>>>>> hvm_buffered_io_send().
>>>>>> It is this code snippet:
>>>>>> 
>>>>>>     /* Return 0 for the cases we can't deal with. */
>>>>>>     if ( (p->addr > 0xffffful) || p->data_is_ptr || p->df ||
>>>>>> (p->count != 1) )
>>>>>>     {
>>>>>>         gdprintk(XENLOG_DEBUG, "slow ioreq. type:%d size:%"PRIu64"
>>>>>> addr:0x%"
>>>>>>                  PRIx64" dir:%d ptr:%d df:%d count:%"PRIu64"\n",
>>>>>>                  p->type, p->size, p->addr, !!p->dir,
>>>>>>                  !!p->data_is_ptr, !!p->df, p->count);
>>>>>>         return 0;
>>>>>>     }
>>>>>> 
>>>>>> It looks like the problem was there before changeset 16285 but got
>>>>>> uncovered
>>>>>> with the addition of the debug output.
>>>>>> 
>>>>>> Christoph
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel