Gonglei (Arei)
2013-Aug-05 13:10 UTC
FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
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@nongnu.org; xen-devel@lists.xen.org; Anthony Liguori; > Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; Anthony Liguori; > 'aliguori@us.ibm.com' > 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@iki.fi] > > > > Sent: Saturday, July 27, 2013 7:51 PM > > > > To: Gerd Hoffmann > > > > Cc: Andreas Färber; Hanweidong; Luonengjun; qemu-devel@nongnu.org; > > > > xen-devel@lists.xen.org; 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
George Dunlap
2013-Aug-05 14:28 UTC
Re: 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@huawei.com> 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@nongnu.org; xen-devel@lists.xen.org; Anthony Liguori; >> Huangweidong (Hardware); ''Ian.Jackson@eu.citrix.com''; Anthony Liguori; >> ''aliguori@us.ibm.com'' >> 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@iki.fi] >> > > > Sent: Saturday, July 27, 2013 7:51 PM >> > > > To: Gerd Hoffmann >> > > > Cc: Andreas Färber; Hanweidong; Luonengjun; qemu-devel@nongnu.org; >> > > > xen-devel@lists.xen.org; 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
Gonglei (Arei)
2013-Aug-05 15:06 UTC
Re: FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
> -----Original Message----- > From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George > Dunlap > Sent: Monday, August 05, 2013 10:28 PM > To: Gonglei (Arei) > Cc: xen-devel@lists.xen.org; qemu-devel@nongnu.org; Anthony PERARD; > Stefano Stabellini > Subject: 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@huawei.com> > 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@nongnu.org; xen-devel@lists.xen.org; Anthony Liguori; > >> Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; Anthony Liguori; > >> 'aliguori@us.ibm.com' > >> 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@iki.fi] > >> > > > Sent: Saturday, July 27, 2013 7:51 PM > >> > > > To: Gerd Hoffmann > >> > > > Cc: Andreas Färber; Hanweidong; Luonengjun; > qemu-devel@nongnu.org; > >> > > > xen-devel@lists.xen.org; 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". > > -GeorgeHi, George. I analyze the xentrace data by xenalyze, and get the next results, actually I don't understand the meaning: linux-sAGhxH: # xenalyze qemu-upstream.log --summary --with-mmio-enumeration Using VMX hardware-assisted virtualization. scan_for_new_pcpu: Activating pcpu 0 at offset 0 Creating vcpu 0 for dom 32768 scan_for_new_pcpu: Activating pcpu 1 at offset 4180 Creating vcpu 1 for dom 32768 init_pcpus: through first trace write, done for now. hvm_generic_postprocess: Strange, exit 2c(APIC_ACCESS) missing a handler WARNING: Not enumerationg MMIO in VGA range. Use --mmio-enumeration-skip-vga=0 to override. hvm_generic_postprocess: Strange, exit 0(EXCEPTION_NMI) missing a handler hvm_generic_postprocess: HVM evt 0 in 2c and 0! read_record: read returned zero, deactivating pcpu 1 deactivate_pcpu: setting d32768v1 to state LOST deactivate_pcpu: Setting max_active_pcpu to 0 read_record: read returned zero, deactivating pcpu 0 deactivate_pcpu: setting d32768v0 to state LOST deactivate_pcpu: Setting max_active_pcpu to -1 Total time: 4.71 seconds (using cpu speed 2.40 GHz) --- Log volume summary --- - cpu 0 - gen : 3292 hvm : 47935940 +-vmentry: 8055696 +-vmexit : 13426160 +-handler: 26454084 - cpu 1 - gen : 12 hvm : 574408 +-vmentry: 158424 +-vmexit : 264040 +-handler: 151944 linux-sAGhxH: # xenalyze qemu-dm.log --summary --with-mmio-enumeration Using VMX hardware-assisted virtualization. scan_for_new_pcpu: Activating pcpu 2 at offset 0 Creating vcpu 2 for dom 32768 scan_for_new_pcpu: Activating pcpu 3 at offset 6012 Creating vcpu 3 for dom 32768 init_pcpus: through first trace write, done for now. hvm_generic_postprocess: Strange, exit 2c(APIC_ACCESS) missing a handler WARNING: Not enumerationg MMIO in VGA range. Use --mmio-enumeration-skip-vga=0 to override. hvm_generic_postprocess: Strange, exit 0(EXCEPTION_NMI) missing a handler hvm_generic_postprocess: HVM evt 0 in 2c and 0! read_record: read returned zero, deactivating pcpu 3 deactivate_pcpu: setting d32768v3 to state LOST deactivate_pcpu: Setting max_active_pcpu to 2 read_record: read returned zero, deactivating pcpu 2 deactivate_pcpu: setting d32768v2 to state LOST deactivate_pcpu: Setting max_active_pcpu to -1 Total time: 4.71 seconds (using cpu speed 2.40 GHz) --- Log volume summary --- - cpu 2 - gen : 180 hvm : 4139172 +-vmentry: 1030356 +-vmexit : 1717280 +-handler: 1391536 - cpu 3 - gen : 148 hvm : 2452600 +-vmentry: 676188 +-vmexit : 1126980 +-handler: 649432 -Gonglei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
George Dunlap
2013-Aug-06 09:39 UTC
Re: FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
On Mon, Aug 5, 2013 at 4:06 PM, Gonglei (Arei) <arei.gonglei@huawei.com> wrote:>> -----Original Message----- >> From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George >> Dunlap >> Sent: Monday, August 05, 2013 10:28 PM >> To: Gonglei (Arei) >> Cc: xen-devel@lists.xen.org; qemu-devel@nongnu.org; Anthony PERARD; >> Stefano Stabellini >> Subject: 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@huawei.com> >> 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@nongnu.org; xen-devel@lists.xen.org; Anthony Liguori; >> >> Huangweidong (Hardware); ''Ian.Jackson@eu.citrix.com''; Anthony Liguori; >> >> ''aliguori@us.ibm.com'' >> >> 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@iki.fi] >> >> > > > Sent: Saturday, July 27, 2013 7:51 PM >> >> > > > To: Gerd Hoffmann >> >> > > > Cc: Andreas Färber; Hanweidong; Luonengjun; >> qemu-devel@nongnu.org; >> >> > > > xen-devel@lists.xen.org; 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 > > Hi, George. I analyze the xentrace data by xenalyze, and get the next results, actually I don''t understand the meaning: > > linux-sAGhxH: # xenalyze qemu-upstream.log --summary --with-mmio-enumeration > Using VMX hardware-assisted virtualization. > scan_for_new_pcpu: Activating pcpu 0 at offset 0 > Creating vcpu 0 for dom 32768 > scan_for_new_pcpu: Activating pcpu 1 at offset 4180 > Creating vcpu 1 for dom 32768 > init_pcpus: through first trace write, done for now. > hvm_generic_postprocess: Strange, exit 2c(APIC_ACCESS) missing a handler > WARNING: Not enumerationg MMIO in VGA range. Use --mmio-enumeration-skip-vga=0 to override. > hvm_generic_postprocess: Strange, exit 0(EXCEPTION_NMI) missing a handler > hvm_generic_postprocess: HVM evt 0 in 2c and 0! > read_record: read returned zero, deactivating pcpu 1 > deactivate_pcpu: setting d32768v1 to state LOST > deactivate_pcpu: Setting max_active_pcpu to 0 > read_record: read returned zero, deactivating pcpu 0 > deactivate_pcpu: setting d32768v0 to state LOST > deactivate_pcpu: Setting max_active_pcpu to -1 > Total time: 4.71 seconds (using cpu speed 2.40 GHz) > --- Log volume summary --- > - cpu 0 - > gen : 3292 > hvm : 47935940 > +-vmentry: 8055696 > +-vmexit : 13426160 > +-handler: 26454084 > - cpu 1 - > gen : 12 > hvm : 574408 > +-vmentry: 158424 > +-vmexit : 264040 > +-handler: 151944Oh right -- it looks like you only enabled tracing of HVM events; in order to track vcpus as they move across pcpus (which was the core functionality I was looking for when I created xenalyze), you need to enable schedule traces as well. So you''d at least need 0xaf000. I almost always just trace with "-e all". -George