[Qemu-devel] FW: [Xen-devel]Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest

[Gonglei (Arei)]

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;
> address@hidden; address@hidden; Anthony Liguori;
> Huangweidong (Hardware); 'address@hidden'; Anthony Liguori;
> 'address@hidden'
> 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:address@hidden
> > > > Sent: Saturday, July 27, 2013 7:51 PM
> > > > To: Gerd Hoffmann
> > > > Cc: Andreas Färber; Hanweidong; Luonengjun; address@hidden;
> > > > address@hidden; 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? 

Thank you so much!
 
 -Gonglei