[Xen-devel] Re: stdvga: slow ioreq

["Christoph Egger" <Christoph.Egger@xxxxxxx>]

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



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