[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
On Mon, Aug 5, 2013 at 2:10 PM, Gonglei (Arei) <arei.gonglei@xxxxxxxxxx> wrote: > Hi, >> -----Original Message----- >> From: Gonglei (Arei) >> Sent: Tuesday, July 30, 2013 10:01 AM >> To: 'Pasi Kärkkäinen' >> Cc: Gerd Hoffmann; Andreas Färber; Hanweidong; Luonengjun; >> qemu-devel@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx; Anthony Liguori; >> Huangweidong (Hardware); 'Ian.Jackson@xxxxxxxxxxxxx'; Anthony Liguori; >> 'aliguori@xxxxxxxxxx' >> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show >> blank screen last 13s or so for windows XP guest >> >> > On Mon, Jul 29, 2013 at 08:48:54AM +0000, Gonglei (Arei) wrote: >> > > > -----Original Message----- >> > > > From: Pasi Kärkkäinen [mailto:pasik@xxxxxx] >> > > > Sent: Saturday, July 27, 2013 7:51 PM >> > > > To: Gerd Hoffmann >> > > > Cc: Andreas Färber; Hanweidong; Luonengjun; qemu-devel@xxxxxxxxxx; >> > > > xen-devel@xxxxxxxxxxxxx; Gonglei (Arei); Anthony Liguori; Huangweidong >> > > > (Hardware) >> > > > Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, >> show >> > > > blank screen last 13s or so for windows XP guest >> > > > >> > > > On Fri, Jul 26, 2013 at 12:19:16PM +0200, Gerd Hoffmann wrote: >> > > > > >> > > > > Maybe the xen guys did some optimizations in qemu-dm which where >> not >> > > > > merged upstream. Try asking @ xen-devel. >> > > > > >> > > > >> > > > Yeah, xen qemu-dm must have some optimization for cirrus that isn't in >> > > > upstream qemu. >> > > >> > > Hi, Pasi. Would you give me some more details? Thanks! >> > > >> > >> > Unfortunately I don't have any more details.. I was just assuming if xen >> > qemu-dm is fast, >> > but upstream qemu is slow, there might be some optimization in xen >> > qemu-dm .. >> > >> > Did you check the xen qemu-dm (traditional) history / commits? >> > >> > -- Pasi >> >> Yes, I did. I tried to reproduce the issue with qemu-dm by fall backing >> history >> commit. >> But the qemu-dm mainline merged other branches, such as branch 'upstream' >> and branch 'qemu', >> so that I can not complied the xen-4.1.2/tools project well. CC'ing Ian and >> Anthony. >> > By analyzing xentrace data, I found that there is lot's of VMEXIT between > memory region 0xa0000~0xaffff with upstream qemu, > but only 256 VMEXIT on traditional qemu-dm, when Windows XP guest booting up > or change the method connecting the VM from VNC(RDP) to RDP(VNC): > > linux-sAGhxH:# cat qemu-upstrem.log |grep 0x00000000000a|wc -l > 640654 > linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a|wc -l > 256 > And the 256 VMEXIT of qemu-dm as the same as the top 256 VMEXIT of > qemu-upstream > > linux-sAGhxH:# cat qemu-upstream.log |grep 0x00000000000a| tail > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b08 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0a mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0c mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0e mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b10 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b12 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b14 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b16 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b18 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b1a mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a| tail > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ec0 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ee0 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f00 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f20 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f40 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f60 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f80 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fa0 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fc0 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fe0 mfn = > 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ] > > Please see attachment for more information. > > Because of the lot's of VMEXIT, the cirrus_vga_ioport_write funciton receive > little scheduling, > and cirrus_vga_write_gr execution interval of more than 32ms twice per, so > that the blank screen time over 13 second with upstream qemu on Xen. > I don't know why the Windows XP guest access the memory region > 0xa0000~0xaffff with upstream qemu but with traditional qemu-dm is not, > Anyone can give me some suggestion? Anthony Perard is probably the best person to answer this question, but unfortunately he's on holiday at the moment. It might be interesting to see what xenalyze tells you about what it sees in the trace: http://blog.xen.org/index.php/2012/09/27/tracing-with-xentrace-and-xenalyze/ I think you'll want to use "--summary --with-mmio-enumeration". -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |