* [Qemu-devel] FW: [Xen-devel]Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
@ 2013-08-05 13:10 Gonglei (Arei)
2013-08-05 14:28 ` FW: Cirrus " George Dunlap
2013-08-05 14:28 ` [Qemu-devel] [Xen-devel] " George Dunlap
0 siblings, 2 replies; 7+ messages in thread
From: Gonglei (Arei) @ 2013-08-05 13:10 UTC (permalink / raw)
To: xen-devel, qemu-devel
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
^ 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 13:10 [Qemu-devel] FW: [Xen-devel]Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Gonglei (Arei)
2013-08-05 14:28 ` FW: Cirrus " George Dunlap
@ 2013-08-05 14:28 ` George Dunlap
2013-08-05 15:06 ` Gonglei (Arei)
2013-08-05 15:06 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
1 sibling, 2 replies; 7+ messages in thread
From: George Dunlap @ 2013-08-05 14:28 UTC (permalink / raw)
To: Gonglei (Arei); +Cc: Anthony PERARD, Stefano Stabellini, qemu-devel, xen-devel
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
^ 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 13:10 [Qemu-devel] FW: [Xen-devel]Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Gonglei (Arei)
@ 2013-08-05 14:28 ` George Dunlap
2013-08-05 14:28 ` [Qemu-devel] [Xen-devel] " George Dunlap
1 sibling, 0 replies; 7+ messages in thread
From: George Dunlap @ 2013-08-05 14:28 UTC (permalink / raw)
To: Gonglei (Arei); +Cc: Anthony PERARD, Stefano Stabellini, qemu-devel, xen-devel
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
^ 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 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 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
* 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
end of thread, other threads:[~2013-08-06 9:40 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-05 13:10 [Qemu-devel] FW: [Xen-devel]Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Gonglei (Arei)
2013-08-05 14:28 ` FW: Cirrus " George Dunlap
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)
2013-08-06 9:39 ` George Dunlap
2013-08-06 9:39 ` [Qemu-devel] [Xen-devel] " George Dunlap
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.