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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Aug 5, 2013 at 4:06 PM, Gonglei (Arei) <arei.gonglei@xxxxxxxxxx> wrote:
>> -----Original Message-----
>> From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of George
>> Dunlap
>> Sent: Monday, August 05, 2013 10:28 PM
>> To: Gonglei (Arei)
>> Cc: xen-devel@xxxxxxxxxxxxx; qemu-devel@xxxxxxxxxx; 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@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
>
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel