* Re: FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-05 14:28 ` [Qemu-devel] [Xen-devel] " George Dunlap
@ 2013-08-05 15:06 ` Gonglei (Arei)
2013-08-05 15:06 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
1 sibling, 0 replies; 7+ messages in thread
From: Gonglei (Arei) @ 2013-08-05 15:06 UTC (permalink / raw)
To: George Dunlap; +Cc: Anthony PERARD, Stefano Stabellini, qemu-devel, xen-devel
> -----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: 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [Xen-devel] FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-05 14:28 ` [Qemu-devel] [Xen-devel] " George Dunlap
2013-08-05 15:06 ` Gonglei (Arei)
@ 2013-08-05 15:06 ` Gonglei (Arei)
2013-08-06 9:39 ` George Dunlap
2013-08-06 9:39 ` [Qemu-devel] [Xen-devel] " George Dunlap
1 sibling, 2 replies; 7+ messages in thread
From: Gonglei (Arei) @ 2013-08-05 15:06 UTC (permalink / raw)
To: George Dunlap; +Cc: Anthony PERARD, Stefano Stabellini, qemu-devel, xen-devel
> -----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: 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-05 15:06 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
@ 2013-08-06 9:39 ` George Dunlap
2013-08-06 9:39 ` [Qemu-devel] [Xen-devel] " George Dunlap
1 sibling, 0 replies; 7+ messages in thread
From: George Dunlap @ 2013-08-06 9:39 UTC (permalink / raw)
To: Gonglei (Arei); +Cc: Anthony PERARD, xen-devel, qemu-devel, Stefano Stabellini
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: 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [Xen-devel] FW: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-05 15:06 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
2013-08-06 9:39 ` George Dunlap
@ 2013-08-06 9:39 ` George Dunlap
1 sibling, 0 replies; 7+ messages in thread
From: George Dunlap @ 2013-08-06 9:39 UTC (permalink / raw)
To: Gonglei (Arei); +Cc: Anthony PERARD, xen-devel, qemu-devel, Stefano Stabellini
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: 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
^ permalink raw reply [flat|nested] 7+ messages in thread