From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Date: Tue, 6 Aug 2013 10:39:54 +0100 Message-ID: References: <33183CC9F5247A488A2544077AF1902080101198@szxeml538-mbs.china.huawei.com> <33183CC9F5247A488A2544077AF19020801011DE@szxeml538-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <33183CC9F5247A488A2544077AF19020801011DE@szxeml538-mbs.china.huawei.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Gonglei (Arei)" Cc: Anthony PERARD , "xen-devel@lists.xen.org" , "qemu-devel@nongnu.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Mon, Aug 5, 2013 at 4:06 PM, Gonglei (Arei) wr= ote: >> -----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 s= creen >> last 13s or so for windows XP guest >> >> On Mon, Aug 5, 2013 at 2:10 PM, Gonglei (Arei) >> wrote: >> > Hi, >> >> -----Original Message----- >> >> From: Gonglei (Arei) >> >> Sent: Tuesday, July 30, 2013 10:01 AM >> >> To: 'Pasi K=E4rkk=E4inen' >> >> Cc: Gerd Hoffmann; Andreas F=E4rber; 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=E4rkk=E4inen [mailto:pasik@iki.fi] >> >> > > > Sent: Saturday, July 27, 2013 7:51 PM >> >> > > > To: Gerd Hoffmann >> >> > > > Cc: Andreas F=E4rber; 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 up= date, >> >> 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 wh= ere >> >> not >> >> > > > > merged upstream. Try asking @ xen-devel. >> >> > > > > >> >> > > > >> >> > > > Yeah, xen qemu-dm must have some optimization for cirrus that i= sn'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 i= f 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 backi= ng 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 I= an and >> >> Anthony. >> >> >> > By analyzing xentrace data, I found that there is lot's of VMEXIT betw= een >> 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 =3D 0x00000000000a0b08 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b0a mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b0c mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b0e mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b10 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b12 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b14 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b16 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b18 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU0 0 (+ 0) NPF [ gpa =3D 0x00000000000a0b1a mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a| tail >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1ec0 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1ee0 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1f00 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1f20 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1f40 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1f60 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1f80 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1fa0 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1fc0 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > CPU2 0 (+ 0) NPF [ gpa =3D 0x00000000000a1fe0 mfn =3D >> 0xffffffffffffffff qual =3D 0x0182 p2mt =3D 0x0004 ] >> > >> > Please see attachment for more information. >> > >> > Because of the lot's of VMEXIT, the cirrus_vga_ioport_write funciton r= eceive >> 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-xenal= yze >> / >> >> 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 res= ults, actually I don't understand the meaning: > > linux-sAGhxH: # xenalyze qemu-upstream.log --summary --with-mmio-enumerat= ion > 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=3D0 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 Oh 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