From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Christoph Egger" Subject: Re: stdvga: slow ioreq Date: Mon, 5 Nov 2007 18:56:02 +0200 Message-ID: <200711051756.02748.Christoph.Egger@amd.com> References: <200711051205.05004.Christoph.Egger@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: Robert Phillips List-Id: xen-devel@lists.xenproject.org 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= =20 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 th= e=20 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 redu= ce > 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 !=3D 1 t= ake > the slow route. > > Our experience is that the few ioreqs handled this way are far out number= ed > 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 wrote: > > Hello Ropert! > > > > Since changeset 16285 (xen-staging), I get the following output when I > > launch > > a HVM guest and VGABios is running: > > > > > > -----------------------------------------------------------------------= =2D- > >-------------- (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 > > > > -----------------------------------------------------------------------= =2D- > >----------------- > > > > 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 = !=3D > > 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=E4ftsanschrift): > > Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland > > Registergericht Dresden: HRA 4896 > > vertretungsberechtigter Komplement=E4r: > > AMD Saxony LLC (Sitz Wilmington, Delaware, USA) > > Gesch=E4ftsf=FChrer der AMD Saxony LLC: > > Dr. Hans-R. Deppe, Thomas McCoy =2D-=20 AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Gesch=E4ftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplement=E4r: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Gesch=E4ftsf=FChrer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy