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

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

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



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