stdvga: slow ioreq

stdvga: slow ioreq

[Christoph Egger]

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


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: stdvga: slow ioreq

[Christoph Egger]

IMO, the diagnostic message should only appear, if it indicates
a bug. If the diagnostic message is really pointless it should be removed.
If the diagnostic messages may indicate bugs but have many false positives,
then the if-condition should be fixed.

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@amd.com> 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
> >
> >
> > --
> > AMD Saxony, Dresden, Germany
> > Operating System Research Center
> >
> > Legal Information:
> > AMD Saxony Limited Liability Company & Co. KG
> > Sitz (Geschäftsanschrift):
> >    Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
> > Registergericht Dresden: HRA 4896
> > vertretungsberechtigter Komplementär:
> >    AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
> > Geschäftsführer der AMD Saxony LLC:
> >    Dr. Hans-R. Deppe, Thomas McCoy



-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: Re: stdvga: slow ioreq

[Keir Fraser]

On 5/11/07 16:56, "Christoph Egger" <Christoph.Egger@amd.com> 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.

If it isn't fixed this week then I'll yank it from 3.2.0.

 -- Keir

Re: Re: stdvga: slow ioreq

[Christoph Egger]

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@amd.com> 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@amd.com> 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


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: Re: stdvga: slow ioreq

[Christoph Egger]

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@amd.com> 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@amd.com> 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



-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: Re: stdvga: slow ioreq

[Keir Fraser]

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@amd.com> 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@amd.com> 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@amd.com> 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
> 
> 

Re: Re: stdvga: slow ioreq

[Christoph Egger]

Yes, I did. Now I am happily using the svn version of ggivnc.
RealVNC is windows-only, but my development & testing network
is heterogen.

Christoph

On Thursday 15 November 2007 16:08:09 Keir Fraser wrote:
> 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@amd.com> 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@amd.com> 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@amd.com> 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



-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: Re: stdvga: slow ioreq

[Keir Fraser]

There is a Linux RealVNC client. But glad you found a viewer that works for
you anyhow!

 -- Keir


On 16/11/07 11:01, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> 
> Yes, I did. Now I am happily using the svn version of ggivnc.
> RealVNC is windows-only, but my development & testing network
> is heterogen.
> 
> Christoph
> 
> On Thursday 15 November 2007 16:08:09 Keir Fraser wrote:
>> 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@amd.com> 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@amd.com> 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@amd.com> 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
> 
>