* [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
@ 2013-07-25 13:13 Gonglei (Arei)
2013-07-25 13:54 ` Fabio Fantoni
` (3 more replies)
0 siblings, 4 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-25 13:13 UTC (permalink / raw)
To: qemu-devel, xen-devel; +Cc: Hanweidong, Luonengjun, Huangweidong (Hardware)
Hi,
I found a problem: For windows XP guest booting by qemu upstream,
using the RDP(Remote Desktop Protocol) and VNC protocol to connect the windows XP guest
which booting by Qemu upstream respectively. the VNC client will become blank screen last
13 seconds or so on XEN platform, and last 2 seconds on KVM. And through debugging,
the cirrus VGA card does not produce dirty pages during the blank screen's times.
When -vga is changed from cirrus to std the issue goes away and the update proceeds at normal speed.
In addition, when using the Qemu-dm replace Qemu upstream on XEN platform,
the cirrus VGA works good and the issue goes away also.
Today, lots of googling have seen the same behavior:
https://github.com/joyent/smartos-live/issues/215
http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
etc...
But, I test the latest qemu-1.5.1, the problem exist firmly.
Any ideas? Thanks!
Best Regards!
-Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 13:13 [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Gonglei (Arei)
2013-07-25 13:54 ` Fabio Fantoni
@ 2013-07-25 13:54 ` Fabio Fantoni
2013-07-25 14:21 ` Gonglei (Arei)
2013-07-25 14:21 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
2013-07-26 2:09 ` [Qemu-devel] " Anthony Liguori
2013-07-26 2:09 ` Anthony Liguori
3 siblings, 2 replies; 49+ messages in thread
From: Fabio Fantoni @ 2013-07-25 13:54 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
> Hi,
> I found a problem: For windows XP guest booting by qemu upstream,
> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the windows XP guest
> which booting by Qemu upstream respectively. the VNC client will become blank screen last
> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through debugging,
> the cirrus VGA card does not produce dirty pages during the blank screen's times.
>
> When -vga is changed from cirrus to std the issue goes away and the update proceeds at normal speed.
> In addition, when using the Qemu-dm replace Qemu upstream on XEN platform,
> the cirrus VGA works good and the issue goes away also.
>
> Today, lots of googling have seen the same behavior:
>
> https://github.com/joyent/smartos-live/issues/215
> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> etc...
>
> But, I test the latest qemu-1.5.1, the problem exist firmly.
>
> Any ideas? Thanks!
>
> Best Regards!
> -Gonglei
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
I've seen the perfomance problem too with vnc when I started to try
upstream qemu. I already reported it on the end of 2011 but no solution yet.
I found spice as an alternative: qxl vga will not work on xen until SSE
support will be added on hvm domU, but spice is usable with stdvga and
performance is better that vnc. Combined with vdagent and usb
redirection it makes a perfect vkvm, and more.
Spice basic support in xl is already present and for more features I
posted some patches here but they are not included in upstream for now.
Cirrus vga drivers are also old and have limitations on both windows and
linux and they can add other problems, they are probably not good for
recent os/de.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 13:13 [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Gonglei (Arei)
@ 2013-07-25 13:54 ` Fabio Fantoni
2013-07-25 13:54 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: Fabio Fantoni @ 2013-07-25 13:54 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
> Hi,
> I found a problem: For windows XP guest booting by qemu upstream,
> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the windows XP guest
> which booting by Qemu upstream respectively. the VNC client will become blank screen last
> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through debugging,
> the cirrus VGA card does not produce dirty pages during the blank screen's times.
>
> When -vga is changed from cirrus to std the issue goes away and the update proceeds at normal speed.
> In addition, when using the Qemu-dm replace Qemu upstream on XEN platform,
> the cirrus VGA works good and the issue goes away also.
>
> Today, lots of googling have seen the same behavior:
>
> https://github.com/joyent/smartos-live/issues/215
> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> etc...
>
> But, I test the latest qemu-1.5.1, the problem exist firmly.
>
> Any ideas? Thanks!
>
> Best Regards!
> -Gonglei
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
I've seen the perfomance problem too with vnc when I started to try
upstream qemu. I already reported it on the end of 2011 but no solution yet.
I found spice as an alternative: qxl vga will not work on xen until SSE
support will be added on hvm domU, but spice is usable with stdvga and
performance is better that vnc. Combined with vdagent and usb
redirection it makes a perfect vkvm, and more.
Spice basic support in xl is already present and for more features I
posted some patches here but they are not included in upstream for now.
Cirrus vga drivers are also old and have limitations on both windows and
linux and they can add other problems, they are probably not good for
recent os/de.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 13:54 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
2013-07-25 14:21 ` Gonglei (Arei)
@ 2013-07-25 14:21 ` Gonglei (Arei)
2013-07-25 14:50 ` Fabio Fantoni
1 sibling, 1 reply; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-25 14:21 UTC (permalink / raw)
To: Fabio Fantoni
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: Thursday, July 25, 2013 9:55 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> Luonengjun; Huangweidong (Hardware)
> Subject: Re: [Xen-devel] Cirrus VGA slow screen update, show blank screen last
> 13s or so for windows XP guest
>
> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
> > Hi,
> > I found a problem: For windows XP guest booting by qemu upstream,
> > using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
> windows XP guest
> > which booting by Qemu upstream respectively. the VNC client will become
> blank screen last
> > 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
> debugging,
> > the cirrus VGA card does not produce dirty pages during the blank screen's
> times.
> >
> > When -vga is changed from cirrus to std the issue goes away and the
> update proceeds at normal speed.
> > In addition, when using the Qemu-dm replace Qemu upstream on XEN
> platform,
> > the cirrus VGA works good and the issue goes away also.
> >
> > Today, lots of googling have seen the same behavior:
> >
> > https://github.com/joyent/smartos-live/issues/215
> > http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> > etc...
> >
> > But, I test the latest qemu-1.5.1, the problem exist firmly.
> >
> > Any ideas? Thanks!
> >
> > Best Regards!
> > -Gonglei
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> I've seen the perfomance problem too with vnc when I started to try
> upstream qemu. I already reported it on the end of 2011 but no solution yet.
> I found spice as an alternative: qxl vga will not work on xen until SSE
> support will be added on hvm domU, but spice is usable with stdvga and
> performance is better that vnc. Combined with vdagent and usb
> redirection it makes a perfect vkvm, and more.
> Spice basic support in xl is already present and for more features I
> posted some patches here but they are not included in upstream for now.
> Cirrus vga drivers are also old and have limitations on both windows and
> linux and they can add other problems, they are probably not good for
> recent os/de.
Thanks for responding. I don't understand why the Qemu-dm works well
but the upstream qemu is not for the same windows XP guest image.
Does the Cirrus vga emulation have some differences between qemu-dm
and unstream qemu ?
-Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 13:54 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
@ 2013-07-25 14:21 ` Gonglei (Arei)
2013-07-25 14:21 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
1 sibling, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-25 14:21 UTC (permalink / raw)
To: Fabio Fantoni
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: Thursday, July 25, 2013 9:55 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> Luonengjun; Huangweidong (Hardware)
> Subject: Re: [Xen-devel] Cirrus VGA slow screen update, show blank screen last
> 13s or so for windows XP guest
>
> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
> > Hi,
> > I found a problem: For windows XP guest booting by qemu upstream,
> > using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
> windows XP guest
> > which booting by Qemu upstream respectively. the VNC client will become
> blank screen last
> > 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
> debugging,
> > the cirrus VGA card does not produce dirty pages during the blank screen's
> times.
> >
> > When -vga is changed from cirrus to std the issue goes away and the
> update proceeds at normal speed.
> > In addition, when using the Qemu-dm replace Qemu upstream on XEN
> platform,
> > the cirrus VGA works good and the issue goes away also.
> >
> > Today, lots of googling have seen the same behavior:
> >
> > https://github.com/joyent/smartos-live/issues/215
> > http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> > etc...
> >
> > But, I test the latest qemu-1.5.1, the problem exist firmly.
> >
> > Any ideas? Thanks!
> >
> > Best Regards!
> > -Gonglei
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> I've seen the perfomance problem too with vnc when I started to try
> upstream qemu. I already reported it on the end of 2011 but no solution yet.
> I found spice as an alternative: qxl vga will not work on xen until SSE
> support will be added on hvm domU, but spice is usable with stdvga and
> performance is better that vnc. Combined with vdagent and usb
> redirection it makes a perfect vkvm, and more.
> Spice basic support in xl is already present and for more features I
> posted some patches here but they are not included in upstream for now.
> Cirrus vga drivers are also old and have limitations on both windows and
> linux and they can add other problems, they are probably not good for
> recent os/de.
Thanks for responding. I don't understand why the Qemu-dm works well
but the upstream qemu is not for the same windows XP guest image.
Does the Cirrus vga emulation have some differences between qemu-dm
and unstream qemu ?
-Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 14:21 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
@ 2013-07-25 14:50 ` Fabio Fantoni
0 siblings, 0 replies; 49+ messages in thread
From: Fabio Fantoni @ 2013-07-25 14:50 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
Il 25/07/2013 16:21, Gonglei (Arei) ha scritto:
>
>> -----Original Message-----
>> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
>> Sent: Thursday, July 25, 2013 9:55 PM
>> To: Gonglei (Arei)
>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>> Luonengjun; Huangweidong (Hardware)
>> Subject: Re: [Xen-devel] Cirrus VGA slow screen update, show blank screen last
>> 13s or so for windows XP guest
>>
>> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
>>> Hi,
>>> I found a problem: For windows XP guest booting by qemu upstream,
>>> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
>> windows XP guest
>>> which booting by Qemu upstream respectively. the VNC client will become
>> blank screen last
>>> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
>> debugging,
>>> the cirrus VGA card does not produce dirty pages during the blank screen's
>> times.
>>> When -vga is changed from cirrus to std the issue goes away and the
>> update proceeds at normal speed.
>>> In addition, when using the Qemu-dm replace Qemu upstream on XEN
>> platform,
>>> the cirrus VGA works good and the issue goes away also.
>>>
>>> Today, lots of googling have seen the same behavior:
>>>
>>> https://github.com/joyent/smartos-live/issues/215
>>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
>>> etc...
>>>
>>> But, I test the latest qemu-1.5.1, the problem exist firmly.
>>>
>>> Any ideas? Thanks!
>>>
>>> Best Regards!
>>> -Gonglei
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> I've seen the perfomance problem too with vnc when I started to try
>> upstream qemu. I already reported it on the end of 2011 but no solution yet.
>> I found spice as an alternative: qxl vga will not work on xen until SSE
>> support will be added on hvm domU, but spice is usable with stdvga and
>> performance is better that vnc. Combined with vdagent and usb
>> redirection it makes a perfect vkvm, and more.
>> Spice basic support in xl is already present and for more features I
>> posted some patches here but they are not included in upstream for now.
>> Cirrus vga drivers are also old and have limitations on both windows and
>> linux and they can add other problems, they are probably not good for
>> recent os/de.
> Thanks for responding. I don't understand why the Qemu-dm works well
> but the upstream qemu is not for the same windows XP guest image.
> Does the Cirrus vga emulation have some differences between qemu-dm
> and unstream qemu ?
>
> -Gonglei
I did test on cirrus vga a long time ago, last was on videoram settings
patch.
Try to increase videoram setting to see if you see an increasing in
performances and/or the problem persists.
On my tests the performance seem identical.
Probably the causes of video problems with upstream qemu are some
hardcoding on xen (probably on hvmloader and fixed seabios tables).
I wasn't able to found exactly problem.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
@ 2013-07-25 14:50 ` Fabio Fantoni
0 siblings, 0 replies; 49+ messages in thread
From: Fabio Fantoni @ 2013-07-25 14:50 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
Il 25/07/2013 16:21, Gonglei (Arei) ha scritto:
>
>> -----Original Message-----
>> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
>> Sent: Thursday, July 25, 2013 9:55 PM
>> To: Gonglei (Arei)
>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>> Luonengjun; Huangweidong (Hardware)
>> Subject: Re: [Xen-devel] Cirrus VGA slow screen update, show blank screen last
>> 13s or so for windows XP guest
>>
>> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
>>> Hi,
>>> I found a problem: For windows XP guest booting by qemu upstream,
>>> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
>> windows XP guest
>>> which booting by Qemu upstream respectively. the VNC client will become
>> blank screen last
>>> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
>> debugging,
>>> the cirrus VGA card does not produce dirty pages during the blank screen's
>> times.
>>> When -vga is changed from cirrus to std the issue goes away and the
>> update proceeds at normal speed.
>>> In addition, when using the Qemu-dm replace Qemu upstream on XEN
>> platform,
>>> the cirrus VGA works good and the issue goes away also.
>>>
>>> Today, lots of googling have seen the same behavior:
>>>
>>> https://github.com/joyent/smartos-live/issues/215
>>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
>>> etc...
>>>
>>> But, I test the latest qemu-1.5.1, the problem exist firmly.
>>>
>>> Any ideas? Thanks!
>>>
>>> Best Regards!
>>> -Gonglei
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> I've seen the perfomance problem too with vnc when I started to try
>> upstream qemu. I already reported it on the end of 2011 but no solution yet.
>> I found spice as an alternative: qxl vga will not work on xen until SSE
>> support will be added on hvm domU, but spice is usable with stdvga and
>> performance is better that vnc. Combined with vdagent and usb
>> redirection it makes a perfect vkvm, and more.
>> Spice basic support in xl is already present and for more features I
>> posted some patches here but they are not included in upstream for now.
>> Cirrus vga drivers are also old and have limitations on both windows and
>> linux and they can add other problems, they are probably not good for
>> recent os/de.
> Thanks for responding. I don't understand why the Qemu-dm works well
> but the upstream qemu is not for the same windows XP guest image.
> Does the Cirrus vga emulation have some differences between qemu-dm
> and unstream qemu ?
>
> -Gonglei
I did test on cirrus vga a long time ago, last was on videoram settings
patch.
Try to increase videoram setting to see if you see an increasing in
performances and/or the problem persists.
On my tests the performance seem identical.
Probably the causes of video problems with upstream qemu are some
hardcoding on xen (probably on hvmloader and fixed seabios tables).
I wasn't able to found exactly problem.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 14:50 ` Fabio Fantoni
(?)
@ 2013-07-26 1:57 ` Gonglei (Arei)
2013-07-26 8:10 ` Fabio Fantoni
2013-07-26 8:10 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
-1 siblings, 2 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-26 1:57 UTC (permalink / raw)
To: Fabio Fantoni
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
> >> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
> >>> Hi,
> >>> I found a problem: For windows XP guest booting by qemu upstream,
> >>> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
> >> windows XP guest
> >>> which booting by Qemu upstream respectively. the VNC client will become
> >> blank screen last
> >>> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
> >> debugging,
> >>> the cirrus VGA card does not produce dirty pages during the blank screen's
> >> times.
> >>> When -vga is changed from cirrus to std the issue goes away and the
> >> update proceeds at normal speed.
> >>> In addition, when using the Qemu-dm replace Qemu upstream on XEN
> >> platform,
> >>> the cirrus VGA works good and the issue goes away also.
> >>>
> >>> Today, lots of googling have seen the same behavior:
> >>>
> >>> https://github.com/joyent/smartos-live/issues/215
> >>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> >>> etc...
> >>>
> >>> But, I test the latest qemu-1.5.1, the problem exist firmly.
> >>>
> >>> Any ideas? Thanks!
> >>>
> >>> Best Regards!
> >>> -Gonglei
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> >> I've seen the perfomance problem too with vnc when I started to try
> >> upstream qemu. I already reported it on the end of 2011 but no solution yet.
> >> I found spice as an alternative: qxl vga will not work on xen until SSE
> >> support will be added on hvm domU, but spice is usable with stdvga and
> >> performance is better that vnc. Combined with vdagent and usb
> >> redirection it makes a perfect vkvm, and more.
> >> Spice basic support in xl is already present and for more features I
> >> posted some patches here but they are not included in upstream for now.
> >> Cirrus vga drivers are also old and have limitations on both windows and
> >> linux and they can add other problems, they are probably not good for
> >> recent os/de.
> > Thanks for responding. I don't understand why the Qemu-dm works well
> > but the upstream qemu is not for the same windows XP guest image.
> > Does the Cirrus vga emulation have some differences between qemu-dm
> > and unstream qemu ?
> >
> > -Gonglei
> I did test on cirrus vga a long time ago, last was on videoram settings
> patch.
> Try to increase videoram setting to see if you see an increasing in
> performances and/or the problem persists.
> On my tests the performance seem identical.
I set the videoram 8M, because of the upstream qemu will crash if the videoram
less than 8M On the Xen prlatform, and the qemu's log show:
qemu: hardware error: xen: failed to populate ram at 7fc00000
CPU #0:
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=0
0000000
etc...
> Probably the causes of video problems with upstream qemu are some
> hardcoding on xen (probably on hvmloader and fixed seabios tables).
> I wasn't able to found exactly problem.
Next, I will compare them.
-Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 14:50 ` Fabio Fantoni
(?)
(?)
@ 2013-07-26 1:57 ` Gonglei (Arei)
-1 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-26 1:57 UTC (permalink / raw)
To: Fabio Fantoni
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
> >> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
> >>> Hi,
> >>> I found a problem: For windows XP guest booting by qemu upstream,
> >>> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
> >> windows XP guest
> >>> which booting by Qemu upstream respectively. the VNC client will become
> >> blank screen last
> >>> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
> >> debugging,
> >>> the cirrus VGA card does not produce dirty pages during the blank screen's
> >> times.
> >>> When -vga is changed from cirrus to std the issue goes away and the
> >> update proceeds at normal speed.
> >>> In addition, when using the Qemu-dm replace Qemu upstream on XEN
> >> platform,
> >>> the cirrus VGA works good and the issue goes away also.
> >>>
> >>> Today, lots of googling have seen the same behavior:
> >>>
> >>> https://github.com/joyent/smartos-live/issues/215
> >>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> >>> etc...
> >>>
> >>> But, I test the latest qemu-1.5.1, the problem exist firmly.
> >>>
> >>> Any ideas? Thanks!
> >>>
> >>> Best Regards!
> >>> -Gonglei
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> >> I've seen the perfomance problem too with vnc when I started to try
> >> upstream qemu. I already reported it on the end of 2011 but no solution yet.
> >> I found spice as an alternative: qxl vga will not work on xen until SSE
> >> support will be added on hvm domU, but spice is usable with stdvga and
> >> performance is better that vnc. Combined with vdagent and usb
> >> redirection it makes a perfect vkvm, and more.
> >> Spice basic support in xl is already present and for more features I
> >> posted some patches here but they are not included in upstream for now.
> >> Cirrus vga drivers are also old and have limitations on both windows and
> >> linux and they can add other problems, they are probably not good for
> >> recent os/de.
> > Thanks for responding. I don't understand why the Qemu-dm works well
> > but the upstream qemu is not for the same windows XP guest image.
> > Does the Cirrus vga emulation have some differences between qemu-dm
> > and unstream qemu ?
> >
> > -Gonglei
> I did test on cirrus vga a long time ago, last was on videoram settings
> patch.
> Try to increase videoram setting to see if you see an increasing in
> performances and/or the problem persists.
> On my tests the performance seem identical.
I set the videoram 8M, because of the upstream qemu will crash if the videoram
less than 8M On the Xen prlatform, and the qemu's log show:
qemu: hardware error: xen: failed to populate ram at 7fc00000
CPU #0:
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=0
0000000
etc...
> Probably the causes of video problems with upstream qemu are some
> hardcoding on xen (probably on hvmloader and fixed seabios tables).
> I wasn't able to found exactly problem.
Next, I will compare them.
-Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 13:13 [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Gonglei (Arei)
2013-07-25 13:54 ` Fabio Fantoni
2013-07-25 13:54 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
@ 2013-07-26 2:09 ` Anthony Liguori
2013-07-26 3:08 ` Gonglei (Arei)
2013-07-26 3:08 ` Gonglei (Arei)
2013-07-26 2:09 ` Anthony Liguori
3 siblings, 2 replies; 49+ messages in thread
From: Anthony Liguori @ 2013-07-26 2:09 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
Windows XP uses VGA planar mode during boot up. This means that to
set a pixel requires 3 MMIO operations (one for the red pixel, one for
the green pixel, one for the blue pixel). KVM has an optimization
called MMIO coalescing which avoids a heavy weight exit for planar
mode exits. I guess Xen doesn't have an optimization like this.
Regards,
Anthony Liguori
On Thu, Jul 25, 2013 at 8:13 AM, Gonglei (Arei) <arei.gonglei@huawei.com> wrote:
> Hi,
> I found a problem: For windows XP guest booting by qemu upstream,
> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the windows XP guest
> which booting by Qemu upstream respectively. the VNC client will become blank screen last
> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through debugging,
> the cirrus VGA card does not produce dirty pages during the blank screen's times.
>
> When -vga is changed from cirrus to std the issue goes away and the update proceeds at normal speed.
> In addition, when using the Qemu-dm replace Qemu upstream on XEN platform,
> the cirrus VGA works good and the issue goes away also.
>
> Today, lots of googling have seen the same behavior:
>
> https://github.com/joyent/smartos-live/issues/215
> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> etc...
>
> But, I test the latest qemu-1.5.1, the problem exist firmly.
>
> Any ideas? Thanks!
>
> Best Regards!
> -Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-25 13:13 [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Gonglei (Arei)
` (2 preceding siblings ...)
2013-07-26 2:09 ` [Qemu-devel] " Anthony Liguori
@ 2013-07-26 2:09 ` Anthony Liguori
3 siblings, 0 replies; 49+ messages in thread
From: Anthony Liguori @ 2013-07-26 2:09 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
Windows XP uses VGA planar mode during boot up. This means that to
set a pixel requires 3 MMIO operations (one for the red pixel, one for
the green pixel, one for the blue pixel). KVM has an optimization
called MMIO coalescing which avoids a heavy weight exit for planar
mode exits. I guess Xen doesn't have an optimization like this.
Regards,
Anthony Liguori
On Thu, Jul 25, 2013 at 8:13 AM, Gonglei (Arei) <arei.gonglei@huawei.com> wrote:
> Hi,
> I found a problem: For windows XP guest booting by qemu upstream,
> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the windows XP guest
> which booting by Qemu upstream respectively. the VNC client will become blank screen last
> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through debugging,
> the cirrus VGA card does not produce dirty pages during the blank screen's times.
>
> When -vga is changed from cirrus to std the issue goes away and the update proceeds at normal speed.
> In addition, when using the Qemu-dm replace Qemu upstream on XEN platform,
> the cirrus VGA works good and the issue goes away also.
>
> Today, lots of googling have seen the same behavior:
>
> https://github.com/joyent/smartos-live/issues/215
> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
> etc...
>
> But, I test the latest qemu-1.5.1, the problem exist firmly.
>
> Any ideas? Thanks!
>
> Best Regards!
> -Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 2:09 ` [Qemu-devel] " Anthony Liguori
2013-07-26 3:08 ` Gonglei (Arei)
@ 2013-07-26 3:08 ` Gonglei (Arei)
2013-07-26 3:20 ` Anthony Liguori
2013-07-26 3:20 ` Anthony Liguori
1 sibling, 2 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-26 3:08 UTC (permalink / raw)
To: Anthony Liguori
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
> -----Original Message-----
> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> Sent: Friday, July 26, 2013 10:09 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> Luonengjun; Huangweidong (Hardware)
> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> last 13s or so for windows XP guest
>
> Windows XP uses VGA planar mode during boot up. This means that to
> set a pixel requires 3 MMIO operations (one for the red pixel, one for
> the green pixel, one for the blue pixel). KVM has an optimization
> called MMIO coalescing which avoids a heavy weight exit for planar
> mode exits. I guess Xen doesn't have an optimization like this.
>
> Regards,
>
> Anthony Liguori
Thanks, Anthony.
I tested the Windows XP guest again on KVM and XEN, and I found:
1. Windows XP will show blank screen during boot up as the same as
the protocol switch between VNC and RDP.
2. Standard VGA works well, what's difference between cirrus and standard VGA for the guest?
3. Why does the traditional qemu has no blank screen problem on cirrus VGA emulation ?
Eagerly looking forward to your reply!
-Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 2:09 ` [Qemu-devel] " Anthony Liguori
@ 2013-07-26 3:08 ` Gonglei (Arei)
2013-07-26 3:08 ` Gonglei (Arei)
1 sibling, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-26 3:08 UTC (permalink / raw)
To: Anthony Liguori
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
> -----Original Message-----
> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> Sent: Friday, July 26, 2013 10:09 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> Luonengjun; Huangweidong (Hardware)
> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> last 13s or so for windows XP guest
>
> Windows XP uses VGA planar mode during boot up. This means that to
> set a pixel requires 3 MMIO operations (one for the red pixel, one for
> the green pixel, one for the blue pixel). KVM has an optimization
> called MMIO coalescing which avoids a heavy weight exit for planar
> mode exits. I guess Xen doesn't have an optimization like this.
>
> Regards,
>
> Anthony Liguori
Thanks, Anthony.
I tested the Windows XP guest again on KVM and XEN, and I found:
1. Windows XP will show blank screen during boot up as the same as
the protocol switch between VNC and RDP.
2. Standard VGA works well, what's difference between cirrus and standard VGA for the guest?
3. Why does the traditional qemu has no blank screen problem on cirrus VGA emulation ?
Eagerly looking forward to your reply!
-Gonglei
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 3:08 ` Gonglei (Arei)
@ 2013-07-26 3:20 ` Anthony Liguori
2013-07-26 6:41 ` Gonglei (Arei)
` (3 more replies)
2013-07-26 3:20 ` Anthony Liguori
1 sibling, 4 replies; 49+ messages in thread
From: Anthony Liguori @ 2013-07-26 3:20 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
<arei.gonglei@huawei.com> wrote:
>> -----Original Message-----
>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>> Sent: Friday, July 26, 2013 10:09 AM
>> To: Gonglei (Arei)
>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>> Luonengjun; Huangweidong (Hardware)
>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>> last 13s or so for windows XP guest
>>
>> Windows XP uses VGA planar mode during boot up. This means that to
>> set a pixel requires 3 MMIO operations (one for the red pixel, one for
>> the green pixel, one for the blue pixel). KVM has an optimization
>> called MMIO coalescing which avoids a heavy weight exit for planar
>> mode exits. I guess Xen doesn't have an optimization like this.
>>
>> Regards,
>>
>> Anthony Liguori
>
> Thanks, Anthony.
> I tested the Windows XP guest again on KVM and XEN, and I found:
> 1. Windows XP will show blank screen during boot up as the same as
> the protocol switch between VNC and RDP.
> 2. Standard VGA works well, what's difference between cirrus and standard VGA for the guest?
Cirrus predates VESA. VESA has a linear framebuffer mode and WinXP
can use VESA modes (provided that VESA drivers are installed). A
linear framebuffer mode requires no exits to update individual pixels.
Instead, there is a timer that fires 30-60 times a second to handle
any pixels that have been dirtied during that period.
> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA emulation ?
This is one of the few cases where TCG is actually faster than KVM or
Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
even with KVM, an MMIO exit is at least a couples thousand cycles.
It's worse with Xen because dom0 has to be scheduled.
If you search a bit for the V2E project, there was an attempt to
combine TCG emulation with hardware virtualization specifically to
handle cases like this. Coalesced MMIO was good enough for KVM though
that something like V2E wasn't pursued for KVM.
Regards,
Anthony Liguori
> Eagerly looking forward to your reply!
>
> -Gonglei
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 3:08 ` Gonglei (Arei)
2013-07-26 3:20 ` Anthony Liguori
@ 2013-07-26 3:20 ` Anthony Liguori
1 sibling, 0 replies; 49+ messages in thread
From: Anthony Liguori @ 2013-07-26 3:20 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
<arei.gonglei@huawei.com> wrote:
>> -----Original Message-----
>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>> Sent: Friday, July 26, 2013 10:09 AM
>> To: Gonglei (Arei)
>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>> Luonengjun; Huangweidong (Hardware)
>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>> last 13s or so for windows XP guest
>>
>> Windows XP uses VGA planar mode during boot up. This means that to
>> set a pixel requires 3 MMIO operations (one for the red pixel, one for
>> the green pixel, one for the blue pixel). KVM has an optimization
>> called MMIO coalescing which avoids a heavy weight exit for planar
>> mode exits. I guess Xen doesn't have an optimization like this.
>>
>> Regards,
>>
>> Anthony Liguori
>
> Thanks, Anthony.
> I tested the Windows XP guest again on KVM and XEN, and I found:
> 1. Windows XP will show blank screen during boot up as the same as
> the protocol switch between VNC and RDP.
> 2. Standard VGA works well, what's difference between cirrus and standard VGA for the guest?
Cirrus predates VESA. VESA has a linear framebuffer mode and WinXP
can use VESA modes (provided that VESA drivers are installed). A
linear framebuffer mode requires no exits to update individual pixels.
Instead, there is a timer that fires 30-60 times a second to handle
any pixels that have been dirtied during that period.
> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA emulation ?
This is one of the few cases where TCG is actually faster than KVM or
Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
even with KVM, an MMIO exit is at least a couples thousand cycles.
It's worse with Xen because dom0 has to be scheduled.
If you search a bit for the V2E project, there was an attempt to
combine TCG emulation with hardware virtualization specifically to
handle cases like this. Coalesced MMIO was good enough for KVM though
that something like V2E wasn't pursued for KVM.
Regards,
Anthony Liguori
> Eagerly looking forward to your reply!
>
> -Gonglei
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 3:20 ` Anthony Liguori
2013-07-26 6:41 ` Gonglei (Arei)
@ 2013-07-26 6:41 ` Gonglei (Arei)
2013-07-26 10:02 ` Andreas Färber
` (3 more replies)
2013-07-26 8:18 ` [Qemu-devel] " Gonglei (Arei)
2013-07-26 8:18 ` Gonglei (Arei)
3 siblings, 4 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-26 6:41 UTC (permalink / raw)
To: Anthony Liguori
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
> -----Original Message-----
> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> Sent: Friday, July 26, 2013 11:21 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> Luonengjun; Huangweidong (Hardware)
> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> last 13s or so for windows XP guest
>
> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
> <arei.gonglei@huawei.com> wrote:
> >> -----Original Message-----
> >> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> >> Sent: Friday, July 26, 2013 10:09 AM
> >> To: Gonglei (Arei)
> >> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> >> Luonengjun; Huangweidong (Hardware)
> >> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank
> screen
> >> last 13s or so for windows XP guest
> >>
> >> Windows XP uses VGA planar mode during boot up. This means that to
> >> set a pixel requires 3 MMIO operations (one for the red pixel, one for
> >> the green pixel, one for the blue pixel). KVM has an optimization
> >> called MMIO coalescing which avoids a heavy weight exit for planar
> >> mode exits. I guess Xen doesn't have an optimization like this.
> >>
> >> Regards,
> >>
> >> Anthony Liguori
> >
> > Thanks, Anthony.
> > I tested the Windows XP guest again on KVM and XEN, and I found:
> > 1. Windows XP will show blank screen during boot up as the same as
> > the protocol switch between VNC and RDP.
> > 2. Standard VGA works well, what's difference between cirrus and standard
> VGA for the guest?
>
> Cirrus predates VESA. VESA has a linear framebuffer mode and WinXP
> can use VESA modes (provided that VESA drivers are installed). A
> linear framebuffer mode requires no exits to update individual pixels.
> Instead, there is a timer that fires 30-60 times a second to handle
> any pixels that have been dirtied during that period.
>
> > 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
> emulation ?
>
> This is one of the few cases where TCG is actually faster than KVM or
> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
> even with KVM, an MMIO exit is at least a couples thousand cycles.
> It's worse with Xen because dom0 has to be scheduled.
Perhaps I did not express clearly what I mean at #3.
I don't understand why the qemu-dm(qemu-0.10.2) works well
but the upstream qemu(begin with qemu-0.14) is not for the
same windows XP guest image in cirrus vga emulation. Does
the cirrus vga emulation have some differences between
qemu-dm and unstream qemu ?
Thank you so much!
-Gonglei
>
> If you search a bit for the V2E project, there was an attempt to
> combine TCG emulation with hardware virtualization specifically to
> handle cases like this. Coalesced MMIO was good enough for KVM though
> that something like V2E wasn't pursued for KVM.
>
> Regards,
>
> Anthony Liguori
>
> > Eagerly looking forward to your reply!
> >
> > -Gonglei
> >
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 3:20 ` Anthony Liguori
@ 2013-07-26 6:41 ` Gonglei (Arei)
2013-07-26 6:41 ` Gonglei (Arei)
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-26 6:41 UTC (permalink / raw)
To: Anthony Liguori
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
> -----Original Message-----
> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> Sent: Friday, July 26, 2013 11:21 AM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> Luonengjun; Huangweidong (Hardware)
> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> last 13s or so for windows XP guest
>
> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
> <arei.gonglei@huawei.com> wrote:
> >> -----Original Message-----
> >> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> >> Sent: Friday, July 26, 2013 10:09 AM
> >> To: Gonglei (Arei)
> >> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> >> Luonengjun; Huangweidong (Hardware)
> >> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank
> screen
> >> last 13s or so for windows XP guest
> >>
> >> Windows XP uses VGA planar mode during boot up. This means that to
> >> set a pixel requires 3 MMIO operations (one for the red pixel, one for
> >> the green pixel, one for the blue pixel). KVM has an optimization
> >> called MMIO coalescing which avoids a heavy weight exit for planar
> >> mode exits. I guess Xen doesn't have an optimization like this.
> >>
> >> Regards,
> >>
> >> Anthony Liguori
> >
> > Thanks, Anthony.
> > I tested the Windows XP guest again on KVM and XEN, and I found:
> > 1. Windows XP will show blank screen during boot up as the same as
> > the protocol switch between VNC and RDP.
> > 2. Standard VGA works well, what's difference between cirrus and standard
> VGA for the guest?
>
> Cirrus predates VESA. VESA has a linear framebuffer mode and WinXP
> can use VESA modes (provided that VESA drivers are installed). A
> linear framebuffer mode requires no exits to update individual pixels.
> Instead, there is a timer that fires 30-60 times a second to handle
> any pixels that have been dirtied during that period.
>
> > 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
> emulation ?
>
> This is one of the few cases where TCG is actually faster than KVM or
> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
> even with KVM, an MMIO exit is at least a couples thousand cycles.
> It's worse with Xen because dom0 has to be scheduled.
Perhaps I did not express clearly what I mean at #3.
I don't understand why the qemu-dm(qemu-0.10.2) works well
but the upstream qemu(begin with qemu-0.14) is not for the
same windows XP guest image in cirrus vga emulation. Does
the cirrus vga emulation have some differences between
qemu-dm and unstream qemu ?
Thank you so much!
-Gonglei
>
> If you search a bit for the V2E project, there was an attempt to
> combine TCG emulation with hardware virtualization specifically to
> handle cases like this. Coalesced MMIO was good enough for KVM though
> that something like V2E wasn't pursued for KVM.
>
> Regards,
>
> Anthony Liguori
>
> > Eagerly looking forward to your reply!
> >
> > -Gonglei
> >
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 1:57 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
2013-07-26 8:10 ` Fabio Fantoni
@ 2013-07-26 8:10 ` Fabio Fantoni
1 sibling, 0 replies; 49+ messages in thread
From: Fabio Fantoni @ 2013-07-26 8:10 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
Il 26/07/2013 03:57, Gonglei (Arei) ha scritto:
>
>
>>>> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
>>>>> Hi,
>>>>> I found a problem: For windows XP guest booting by qemu upstream,
>>>>> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
>>>> windows XP guest
>>>>> which booting by Qemu upstream respectively. the VNC client will become
>>>> blank screen last
>>>>> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
>>>> debugging,
>>>>> the cirrus VGA card does not produce dirty pages during the blank screen's
>>>> times.
>>>>> When -vga is changed from cirrus to std the issue goes away and the
>>>> update proceeds at normal speed.
>>>>> In addition, when using the Qemu-dm replace Qemu upstream on XEN
>>>> platform,
>>>>> the cirrus VGA works good and the issue goes away also.
>>>>>
>>>>> Today, lots of googling have seen the same behavior:
>>>>>
>>>>> https://github.com/joyent/smartos-live/issues/215
>>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
>>>>> etc...
>>>>>
>>>>> But, I test the latest qemu-1.5.1, the problem exist firmly.
>>>>>
>>>>> Any ideas? Thanks!
>>>>>
>>>>> Best Regards!
>>>>> -Gonglei
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>>> I've seen the perfomance problem too with vnc when I started to try
>>>> upstream qemu. I already reported it on the end of 2011 but no solution yet.
>>>> I found spice as an alternative: qxl vga will not work on xen until SSE
>>>> support will be added on hvm domU, but spice is usable with stdvga and
>>>> performance is better that vnc. Combined with vdagent and usb
>>>> redirection it makes a perfect vkvm, and more.
>>>> Spice basic support in xl is already present and for more features I
>>>> posted some patches here but they are not included in upstream for now.
>>>> Cirrus vga drivers are also old and have limitations on both windows and
>>>> linux and they can add other problems, they are probably not good for
>>>> recent os/de.
>>> Thanks for responding. I don't understand why the Qemu-dm works well
>>> but the upstream qemu is not for the same windows XP guest image.
>>> Does the Cirrus vga emulation have some differences between qemu-dm
>>> and unstream qemu ?
>>>
>>> -Gonglei
>> I did test on cirrus vga a long time ago, last was on videoram settings
>> patch.
>> Try to increase videoram setting to see if you see an increasing in
>> performances and/or the problem persists.
>> On my tests the performance seem identical.
> I set the videoram 8M, because of the upstream qemu will crash if the videoram
> less than 8M On the Xen prlatform, and the qemu's log show:
>
> qemu: hardware error: xen: failed to populate ram at 7fc00000
> CPU #0:
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
> EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0000 00000000 0000ffff 00009300
> CS =f000 ffff0000 0000ffff 00009b00
> SS =0000 00000000 0000ffff 00009300
> DS =0000 00000000 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT= 00000000 0000ffff
> IDT= 00000000 0000ffff
> CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=00000000 DR1=00000000 DR2=00000000 DR3=0
> 0000000
> etc...
This is because xen reserve ram for video specified by videoram
parameter but upstream qemu forces to 8 mb in any case.
This should be fixed after this patch:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2e814a017155b885e4d4b5a88dc05e7367a9722a
Is included on xen 4.3 and also backported to 4.2.2.
>> Probably the causes of video problems with upstream qemu are some
>> hardcoding on xen (probably on hvmloader and fixed seabios tables).
>> I wasn't able to found exactly problem.
> Next, I will compare them.
>
> -Gonglei
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 1:57 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
@ 2013-07-26 8:10 ` Fabio Fantoni
2013-07-26 8:10 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
1 sibling, 0 replies; 49+ messages in thread
From: Fabio Fantoni @ 2013-07-26 8:10 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
Il 26/07/2013 03:57, Gonglei (Arei) ha scritto:
>
>
>>>> Il 25/07/2013 15:13, Gonglei (Arei) ha scritto:
>>>>> Hi,
>>>>> I found a problem: For windows XP guest booting by qemu upstream,
>>>>> using the RDP(Remote Desktop Protocol) and VNC protocol to connect the
>>>> windows XP guest
>>>>> which booting by Qemu upstream respectively. the VNC client will become
>>>> blank screen last
>>>>> 13 seconds or so on XEN platform, and last 2 seconds on KVM. And through
>>>> debugging,
>>>>> the cirrus VGA card does not produce dirty pages during the blank screen's
>>>> times.
>>>>> When -vga is changed from cirrus to std the issue goes away and the
>>>> update proceeds at normal speed.
>>>>> In addition, when using the Qemu-dm replace Qemu upstream on XEN
>>>> platform,
>>>>> the cirrus VGA works good and the issue goes away also.
>>>>>
>>>>> Today, lots of googling have seen the same behavior:
>>>>>
>>>>> https://github.com/joyent/smartos-live/issues/215
>>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg02105.html
>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574988
>>>>> etc...
>>>>>
>>>>> But, I test the latest qemu-1.5.1, the problem exist firmly.
>>>>>
>>>>> Any ideas? Thanks!
>>>>>
>>>>> Best Regards!
>>>>> -Gonglei
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>>> I've seen the perfomance problem too with vnc when I started to try
>>>> upstream qemu. I already reported it on the end of 2011 but no solution yet.
>>>> I found spice as an alternative: qxl vga will not work on xen until SSE
>>>> support will be added on hvm domU, but spice is usable with stdvga and
>>>> performance is better that vnc. Combined with vdagent and usb
>>>> redirection it makes a perfect vkvm, and more.
>>>> Spice basic support in xl is already present and for more features I
>>>> posted some patches here but they are not included in upstream for now.
>>>> Cirrus vga drivers are also old and have limitations on both windows and
>>>> linux and they can add other problems, they are probably not good for
>>>> recent os/de.
>>> Thanks for responding. I don't understand why the Qemu-dm works well
>>> but the upstream qemu is not for the same windows XP guest image.
>>> Does the Cirrus vga emulation have some differences between qemu-dm
>>> and unstream qemu ?
>>>
>>> -Gonglei
>> I did test on cirrus vga a long time ago, last was on videoram settings
>> patch.
>> Try to increase videoram setting to see if you see an increasing in
>> performances and/or the problem persists.
>> On my tests the performance seem identical.
> I set the videoram 8M, because of the upstream qemu will crash if the videoram
> less than 8M On the Xen prlatform, and the qemu's log show:
>
> qemu: hardware error: xen: failed to populate ram at 7fc00000
> CPU #0:
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
> EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0000 00000000 0000ffff 00009300
> CS =f000 ffff0000 0000ffff 00009b00
> SS =0000 00000000 0000ffff 00009300
> DS =0000 00000000 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT= 00000000 0000ffff
> IDT= 00000000 0000ffff
> CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=00000000 DR1=00000000 DR2=00000000 DR3=0
> 0000000
> etc...
This is because xen reserve ram for video specified by videoram
parameter but upstream qemu forces to 8 mb in any case.
This should be fixed after this patch:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2e814a017155b885e4d4b5a88dc05e7367a9722a
Is included on xen 4.3 and also backported to 4.2.2.
>> Probably the causes of video problems with upstream qemu are some
>> hardcoding on xen (probably on hvmloader and fixed seabios tables).
>> I wasn't able to found exactly problem.
> Next, I will compare them.
>
> -Gonglei
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 3:20 ` Anthony Liguori
2013-07-26 6:41 ` Gonglei (Arei)
2013-07-26 6:41 ` Gonglei (Arei)
@ 2013-07-26 8:18 ` Gonglei (Arei)
2013-07-26 8:18 ` Gonglei (Arei)
3 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-26 8:18 UTC (permalink / raw)
To: Gonglei (Arei), Anthony Liguori
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
I got VMEXIT counts by xentrace When using the VNC protocol grab
the RDP to connect Windows XP guest. the time-interval of running
xentrace is five seconds.The number of VMEXIT (EXIT_REASON_EPT_VIOLATION)
in unstream qemu far greater than qemu-dm.
the command likes:
xentrace -D -T 5 -c 0x03 -e 0x0008f000 data/xentrace_$dt.log
The results of qemu upstream:
linux-sAGhxH:/home/sdb/gonglei/xentrace # ./xentrace.sh
change evtmask to 0x8f000
change cpumask to 0x3
Start analyze xentrace-format_2013-0726-1444.log ...
VMExitCode VMExitReason VMExitCnt VMExitTicks
0x0000000000 EXIT_REASON_EXCEPTION_NMI 447 329716
0x0000000001 EXIT_REASON_EXTERNAL_INTERRUPT 1126 3039311
0x0000000007 EXIT_REASON_PENDING_VIRT_INTR 1865 1608939
0x000000001c EXIT_REASON_CR_ACCESS 350 913047
0x000000001d EXIT_REASON_DR_ACCESS 4 8266
0x000000001e EXIT_REASON_IO_INSTRUCTION 7669 258978672
0x000000002b EXIT_REASON_TPR_BELOW_THRESHOLD 1203 1535626
0x000000002c EXIT_REASON_APIC_ACCESS 12971 106012627
0x0000000030 EXIT_REASON_EPT_VIOLATION 657459 5808859252
Total 683094 6181285456
The results of traditional qemu-dm:
linux-sAGhxH:/home/sdb/gonglei/xentrace # ./xentrace.sh
change evtmask to 0x8f000
change cpumask to 0xc
Start analyze xentrace-format_2013-0726-1451.log ...
VMExitCode VMExitReason VMExitCnt VMExitTicks
0x0000000000 EXIT_REASON_EXCEPTION_NMI 8693 6344766
0x0000000001 EXIT_REASON_EXTERNAL_INTERRUPT 3587 10601657
0x0000000007 EXIT_REASON_PENDING_VIRT_INTR 8086 6555873
0x000000000a EXIT_REASON_CPUID 34 56060
0x000000001c EXIT_REASON_CR_ACCESS 1424 3757518
0x000000001d EXIT_REASON_DR_ACCESS 13 27297
0x000000001e EXIT_REASON_IO_INSTRUCTION 21250 492487340
0x000000002b EXIT_REASON_TPR_BELOW_THRESHOLD 6458 8184132
0x000000002c EXIT_REASON_APIC_ACCESS 61749 506233523
0x0000000030 EXIT_REASON_EPT_VIOLATION 20329 261274392
0x0000000036 EXIT_REASON_WBINVD 2 2027
Total 131625 1295524585
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Friday, July 26, 2013 2:41 PM
> To: 'Anthony Liguori'
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> Luonengjun; Huangweidong (Hardware)
> Subject: RE: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> last 13s or so for windows XP guest
>
>
>
> > -----Original Message-----
> > From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> > Sent: Friday, July 26, 2013 11:21 AM
> > To: Gonglei (Arei)
> > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> > Luonengjun; Huangweidong (Hardware)
> > Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> > last 13s or so for windows XP guest
> >
> > On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
> > <arei.gonglei@huawei.com> wrote:
> > >> -----Original Message-----
> > >> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> > >> Sent: Friday, July 26, 2013 10:09 AM
> > >> To: Gonglei (Arei)
> > >> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> > >> Luonengjun; Huangweidong (Hardware)
> > >> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank
> > screen
> > >> last 13s or so for windows XP guest
> > >>
> > >> Windows XP uses VGA planar mode during boot up. This means that to
> > >> set a pixel requires 3 MMIO operations (one for the red pixel, one for
> > >> the green pixel, one for the blue pixel). KVM has an optimization
> > >> called MMIO coalescing which avoids a heavy weight exit for planar
> > >> mode exits. I guess Xen doesn't have an optimization like this.
> > >>
> > >> Regards,
> > >>
> > >> Anthony Liguori
> > >
> > > Thanks, Anthony.
> > > I tested the Windows XP guest again on KVM and XEN, and I found:
> > > 1. Windows XP will show blank screen during boot up as the same as
> > > the protocol switch between VNC and RDP.
> > > 2. Standard VGA works well, what's difference between cirrus and standard
> > VGA for the guest?
> >
> > Cirrus predates VESA. VESA has a linear framebuffer mode and WinXP
> > can use VESA modes (provided that VESA drivers are installed). A
> > linear framebuffer mode requires no exits to update individual pixels.
> > Instead, there is a timer that fires 30-60 times a second to handle
> > any pixels that have been dirtied during that period.
> >
> > > 3. Why does the traditional qemu has no blank screen problem on cirrus
> VGA
> > emulation ?
> >
> > This is one of the few cases where TCG is actually faster than KVM or
> > Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
> > even with KVM, an MMIO exit is at least a couples thousand cycles.
> > It's worse with Xen because dom0 has to be scheduled.
>
> Perhaps I did not express clearly what I mean at #3.
> I don't understand why the qemu-dm(qemu-0.10.2) works well
> but the upstream qemu(begin with qemu-0.14) is not for the
> same windows XP guest image in cirrus vga emulation. Does
> the cirrus vga emulation have some differences between
> qemu-dm and unstream qemu ?
>
> Thank you so much!
>
> -Gonglei
> >
> > If you search a bit for the V2E project, there was an attempt to
> > combine TCG emulation with hardware virtualization specifically to
> > handle cases like this. Coalesced MMIO was good enough for KVM though
> > that something like V2E wasn't pursued for KVM.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> > > Eagerly looking forward to your reply!
> > >
> > > -Gonglei
> > >
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 3:20 ` Anthony Liguori
` (2 preceding siblings ...)
2013-07-26 8:18 ` [Qemu-devel] " Gonglei (Arei)
@ 2013-07-26 8:18 ` Gonglei (Arei)
3 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-26 8:18 UTC (permalink / raw)
To: Gonglei (Arei), Anthony Liguori
Cc: Hanweidong, Luonengjun, qemu-devel, Huangweidong (Hardware), xen-devel
I got VMEXIT counts by xentrace When using the VNC protocol grab
the RDP to connect Windows XP guest. the time-interval of running
xentrace is five seconds.The number of VMEXIT (EXIT_REASON_EPT_VIOLATION)
in unstream qemu far greater than qemu-dm.
the command likes:
xentrace -D -T 5 -c 0x03 -e 0x0008f000 data/xentrace_$dt.log
The results of qemu upstream:
linux-sAGhxH:/home/sdb/gonglei/xentrace # ./xentrace.sh
change evtmask to 0x8f000
change cpumask to 0x3
Start analyze xentrace-format_2013-0726-1444.log ...
VMExitCode VMExitReason VMExitCnt VMExitTicks
0x0000000000 EXIT_REASON_EXCEPTION_NMI 447 329716
0x0000000001 EXIT_REASON_EXTERNAL_INTERRUPT 1126 3039311
0x0000000007 EXIT_REASON_PENDING_VIRT_INTR 1865 1608939
0x000000001c EXIT_REASON_CR_ACCESS 350 913047
0x000000001d EXIT_REASON_DR_ACCESS 4 8266
0x000000001e EXIT_REASON_IO_INSTRUCTION 7669 258978672
0x000000002b EXIT_REASON_TPR_BELOW_THRESHOLD 1203 1535626
0x000000002c EXIT_REASON_APIC_ACCESS 12971 106012627
0x0000000030 EXIT_REASON_EPT_VIOLATION 657459 5808859252
Total 683094 6181285456
The results of traditional qemu-dm:
linux-sAGhxH:/home/sdb/gonglei/xentrace # ./xentrace.sh
change evtmask to 0x8f000
change cpumask to 0xc
Start analyze xentrace-format_2013-0726-1451.log ...
VMExitCode VMExitReason VMExitCnt VMExitTicks
0x0000000000 EXIT_REASON_EXCEPTION_NMI 8693 6344766
0x0000000001 EXIT_REASON_EXTERNAL_INTERRUPT 3587 10601657
0x0000000007 EXIT_REASON_PENDING_VIRT_INTR 8086 6555873
0x000000000a EXIT_REASON_CPUID 34 56060
0x000000001c EXIT_REASON_CR_ACCESS 1424 3757518
0x000000001d EXIT_REASON_DR_ACCESS 13 27297
0x000000001e EXIT_REASON_IO_INSTRUCTION 21250 492487340
0x000000002b EXIT_REASON_TPR_BELOW_THRESHOLD 6458 8184132
0x000000002c EXIT_REASON_APIC_ACCESS 61749 506233523
0x0000000030 EXIT_REASON_EPT_VIOLATION 20329 261274392
0x0000000036 EXIT_REASON_WBINVD 2 2027
Total 131625 1295524585
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Friday, July 26, 2013 2:41 PM
> To: 'Anthony Liguori'
> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> Luonengjun; Huangweidong (Hardware)
> Subject: RE: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> last 13s or so for windows XP guest
>
>
>
> > -----Original Message-----
> > From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> > Sent: Friday, July 26, 2013 11:21 AM
> > To: Gonglei (Arei)
> > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> > Luonengjun; Huangweidong (Hardware)
> > Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> > last 13s or so for windows XP guest
> >
> > On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
> > <arei.gonglei@huawei.com> wrote:
> > >> -----Original Message-----
> > >> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> > >> Sent: Friday, July 26, 2013 10:09 AM
> > >> To: Gonglei (Arei)
> > >> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> > >> Luonengjun; Huangweidong (Hardware)
> > >> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank
> > screen
> > >> last 13s or so for windows XP guest
> > >>
> > >> Windows XP uses VGA planar mode during boot up. This means that to
> > >> set a pixel requires 3 MMIO operations (one for the red pixel, one for
> > >> the green pixel, one for the blue pixel). KVM has an optimization
> > >> called MMIO coalescing which avoids a heavy weight exit for planar
> > >> mode exits. I guess Xen doesn't have an optimization like this.
> > >>
> > >> Regards,
> > >>
> > >> Anthony Liguori
> > >
> > > Thanks, Anthony.
> > > I tested the Windows XP guest again on KVM and XEN, and I found:
> > > 1. Windows XP will show blank screen during boot up as the same as
> > > the protocol switch between VNC and RDP.
> > > 2. Standard VGA works well, what's difference between cirrus and standard
> > VGA for the guest?
> >
> > Cirrus predates VESA. VESA has a linear framebuffer mode and WinXP
> > can use VESA modes (provided that VESA drivers are installed). A
> > linear framebuffer mode requires no exits to update individual pixels.
> > Instead, there is a timer that fires 30-60 times a second to handle
> > any pixels that have been dirtied during that period.
> >
> > > 3. Why does the traditional qemu has no blank screen problem on cirrus
> VGA
> > emulation ?
> >
> > This is one of the few cases where TCG is actually faster than KVM or
> > Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
> > even with KVM, an MMIO exit is at least a couples thousand cycles.
> > It's worse with Xen because dom0 has to be scheduled.
>
> Perhaps I did not express clearly what I mean at #3.
> I don't understand why the qemu-dm(qemu-0.10.2) works well
> but the upstream qemu(begin with qemu-0.14) is not for the
> same windows XP guest image in cirrus vga emulation. Does
> the cirrus vga emulation have some differences between
> qemu-dm and unstream qemu ?
>
> Thank you so much!
>
> -Gonglei
> >
> > If you search a bit for the V2E project, there was an attempt to
> > combine TCG emulation with hardware virtualization specifically to
> > handle cases like this. Coalesced MMIO was good enough for KVM though
> > that something like V2E wasn't pursued for KVM.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> > > Eagerly looking forward to your reply!
> > >
> > > -Gonglei
> > >
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 6:41 ` Gonglei (Arei)
2013-07-26 10:02 ` Andreas Färber
@ 2013-07-26 10:02 ` Andreas Färber
2013-07-26 10:19 ` Gerd Hoffmann
2013-07-26 10:19 ` Gerd Hoffmann
2013-07-26 12:29 ` Fabio Fantoni
2013-07-26 12:29 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
3 siblings, 2 replies; 49+ messages in thread
From: Andreas Färber @ 2013-07-26 10:02 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Gerd Hoffmann,
Anthony Liguori, Huangweidong (Hardware)
Am 26.07.2013 08:41, schrieb Gonglei (Arei):
>> -----Original Message-----
>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>> Sent: Friday, July 26, 2013 11:21 AM
>> To: Gonglei (Arei)
>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>> Luonengjun; Huangweidong (Hardware)
>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>> last 13s or so for windows XP guest
>>
>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
>> <arei.gonglei@huawei.com> wrote:
>>> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
>> emulation ?
>>
>> This is one of the few cases where TCG is actually faster than KVM or
>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
>> even with KVM, an MMIO exit is at least a couples thousand cycles.
>> It's worse with Xen because dom0 has to be scheduled.
>
> Perhaps I did not express clearly what I mean at #3.
> I don't understand why the qemu-dm(qemu-0.10.2) works well
> but the upstream qemu(begin with qemu-0.14) is not for the
> same windows XP guest image in cirrus vga emulation. Does
> the cirrus vga emulation have some differences between
> qemu-dm and unstream qemu ?
I don't know about qemu-dm, but QEMU switched from a home-grown pixel
handling to pixman library sometime around 1.4. CC'ing Gerd.
(And 1.5 switched the default GUI backend from SDL to GTK, which may
again show some performance differences.)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 6:41 ` Gonglei (Arei)
@ 2013-07-26 10:02 ` Andreas Färber
2013-07-26 10:02 ` Andreas Färber
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: Andreas Färber @ 2013-07-26 10:02 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Gerd Hoffmann,
Anthony Liguori, Huangweidong (Hardware)
Am 26.07.2013 08:41, schrieb Gonglei (Arei):
>> -----Original Message-----
>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>> Sent: Friday, July 26, 2013 11:21 AM
>> To: Gonglei (Arei)
>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>> Luonengjun; Huangweidong (Hardware)
>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>> last 13s or so for windows XP guest
>>
>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
>> <arei.gonglei@huawei.com> wrote:
>>> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
>> emulation ?
>>
>> This is one of the few cases where TCG is actually faster than KVM or
>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
>> even with KVM, an MMIO exit is at least a couples thousand cycles.
>> It's worse with Xen because dom0 has to be scheduled.
>
> Perhaps I did not express clearly what I mean at #3.
> I don't understand why the qemu-dm(qemu-0.10.2) works well
> but the upstream qemu(begin with qemu-0.14) is not for the
> same windows XP guest image in cirrus vga emulation. Does
> the cirrus vga emulation have some differences between
> qemu-dm and unstream qemu ?
I don't know about qemu-dm, but QEMU switched from a home-grown pixel
handling to pixman library sometime around 1.4. CC'ing Gerd.
(And 1.5 switched the default GUI backend from SDL to GTK, which may
again show some performance differences.)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 10:02 ` Andreas Färber
@ 2013-07-26 10:19 ` Gerd Hoffmann
2013-07-26 10:27 ` Andreas Färber
` (3 more replies)
2013-07-26 10:19 ` Gerd Hoffmann
1 sibling, 4 replies; 49+ messages in thread
From: Gerd Hoffmann @ 2013-07-26 10:19 UTC (permalink / raw)
To: Andreas Färber
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Gonglei (Arei),
Anthony Liguori, Huangweidong (Hardware)
On 07/26/13 12:02, Andreas Färber wrote:
> Am 26.07.2013 08:41, schrieb Gonglei (Arei):
>>> -----Original Message-----
>>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>>> Sent: Friday, July 26, 2013 11:21 AM
>>> To: Gonglei (Arei)
>>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>>> Luonengjun; Huangweidong (Hardware)
>>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>>> last 13s or so for windows XP guest
>>>
>>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
>>> <arei.gonglei@huawei.com> wrote:
>>>> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
>>> emulation ?
>>>
>>> This is one of the few cases where TCG is actually faster than KVM or
>>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
>>> even with KVM, an MMIO exit is at least a couples thousand cycles.
>>> It's worse with Xen because dom0 has to be scheduled.
>>
>> Perhaps I did not express clearly what I mean at #3.
>> I don't understand why the qemu-dm(qemu-0.10.2) works well
>> but the upstream qemu(begin with qemu-0.14) is not for the
>> same windows XP guest image in cirrus vga emulation. Does
>> the cirrus vga emulation have some differences between
>> qemu-dm and unstream qemu ?
>
> I don't know about qemu-dm, but QEMU switched from a home-grown pixel
> handling to pixman library sometime around 1.4. CC'ing Gerd.
0.14 != 1.4 ;)
Also pixman isn't used everywhere, there is still home-grown pixel
handling code in qemu. I often replace it when I touch it for some
reason, but we are far away from a full-pixman qemu. The cirrus blit
ops havn't been touched btw, it's still the old code.
Maybe the xen guys did some optimizations in qemu-dm which where not
merged upstream. Try asking @ xen-devel.
Beside that the standard vga usually is the better choice anyway as it
supports more video memory and higher resolutions than cirrus.
cheers,
Gerd
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 10:02 ` Andreas Färber
2013-07-26 10:19 ` Gerd Hoffmann
@ 2013-07-26 10:19 ` Gerd Hoffmann
1 sibling, 0 replies; 49+ messages in thread
From: Gerd Hoffmann @ 2013-07-26 10:19 UTC (permalink / raw)
To: Andreas Färber
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Gonglei (Arei),
Anthony Liguori, Huangweidong (Hardware)
On 07/26/13 12:02, Andreas Färber wrote:
> Am 26.07.2013 08:41, schrieb Gonglei (Arei):
>>> -----Original Message-----
>>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>>> Sent: Friday, July 26, 2013 11:21 AM
>>> To: Gonglei (Arei)
>>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>>> Luonengjun; Huangweidong (Hardware)
>>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>>> last 13s or so for windows XP guest
>>>
>>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
>>> <arei.gonglei@huawei.com> wrote:
>>>> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
>>> emulation ?
>>>
>>> This is one of the few cases where TCG is actually faster than KVM or
>>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
>>> even with KVM, an MMIO exit is at least a couples thousand cycles.
>>> It's worse with Xen because dom0 has to be scheduled.
>>
>> Perhaps I did not express clearly what I mean at #3.
>> I don't understand why the qemu-dm(qemu-0.10.2) works well
>> but the upstream qemu(begin with qemu-0.14) is not for the
>> same windows XP guest image in cirrus vga emulation. Does
>> the cirrus vga emulation have some differences between
>> qemu-dm and unstream qemu ?
>
> I don't know about qemu-dm, but QEMU switched from a home-grown pixel
> handling to pixman library sometime around 1.4. CC'ing Gerd.
0.14 != 1.4 ;)
Also pixman isn't used everywhere, there is still home-grown pixel
handling code in qemu. I often replace it when I touch it for some
reason, but we are far away from a full-pixman qemu. The cirrus blit
ops havn't been touched btw, it's still the old code.
Maybe the xen guys did some optimizations in qemu-dm which where not
merged upstream. Try asking @ xen-devel.
Beside that the standard vga usually is the better choice anyway as it
supports more video memory and higher resolutions than cirrus.
cheers,
Gerd
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 10:19 ` Gerd Hoffmann
2013-07-26 10:27 ` Andreas Färber
@ 2013-07-26 10:27 ` Andreas Färber
2013-07-27 11:06 ` Gonglei (Arei)
2013-07-27 11:51 ` Pasi Kärkkäinen
2013-07-27 11:51 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
3 siblings, 1 reply; 49+ messages in thread
From: Andreas Färber @ 2013-07-26 10:27 UTC (permalink / raw)
To: Gerd Hoffmann, Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Anthony Liguori,
Huangweidong (Hardware)
Am 26.07.2013 12:19, schrieb Gerd Hoffmann:
> On 07/26/13 12:02, Andreas Färber wrote:
>> Am 26.07.2013 08:41, schrieb Gonglei (Arei):
>>>> -----Original Message-----
>>>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>>>> Sent: Friday, July 26, 2013 11:21 AM
>>>> To: Gonglei (Arei)
>>>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>>>> Luonengjun; Huangweidong (Hardware)
>>>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>>>> last 13s or so for windows XP guest
>>>>
>>>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
>>>> <arei.gonglei@huawei.com> wrote:
>>>>> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
>>>> emulation ?
>>>>
>>>> This is one of the few cases where TCG is actually faster than KVM or
>>>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
>>>> even with KVM, an MMIO exit is at least a couples thousand cycles.
>>>> It's worse with Xen because dom0 has to be scheduled.
>>>
>>> Perhaps I did not express clearly what I mean at #3.
>>> I don't understand why the qemu-dm(qemu-0.10.2) works well
>>> but the upstream qemu(begin with qemu-0.14) is not for the
>>> same windows XP guest image in cirrus vga emulation. Does
>>> the cirrus vga emulation have some differences between
>>> qemu-dm and unstream qemu ?
>>
>> I don't know about qemu-dm, but QEMU switched from a home-grown pixel
>> handling to pixman library sometime around 1.4. CC'ing Gerd.
>
> 0.14 != 1.4 ;)
Oops! In that case, Gonglei, try to reproduce the issue with upstream
0.10 and use git-bisect to find out when things got slower between
v0.10.2..v0.14.0. It would be unrealistic to expect us to remember all
Cirrus-related changes from 2-4 years ago. ;)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 10:19 ` Gerd Hoffmann
@ 2013-07-26 10:27 ` Andreas Färber
2013-07-26 10:27 ` Andreas Färber
` (2 subsequent siblings)
3 siblings, 0 replies; 49+ messages in thread
From: Andreas Färber @ 2013-07-26 10:27 UTC (permalink / raw)
To: Gerd Hoffmann, Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Anthony Liguori,
Huangweidong (Hardware)
Am 26.07.2013 12:19, schrieb Gerd Hoffmann:
> On 07/26/13 12:02, Andreas Färber wrote:
>> Am 26.07.2013 08:41, schrieb Gonglei (Arei):
>>>> -----Original Message-----
>>>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>>>> Sent: Friday, July 26, 2013 11:21 AM
>>>> To: Gonglei (Arei)
>>>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>>>> Luonengjun; Huangweidong (Hardware)
>>>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>>>> last 13s or so for windows XP guest
>>>>
>>>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
>>>> <arei.gonglei@huawei.com> wrote:
>>>>> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
>>>> emulation ?
>>>>
>>>> This is one of the few cases where TCG is actually faster than KVM or
>>>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
>>>> even with KVM, an MMIO exit is at least a couples thousand cycles.
>>>> It's worse with Xen because dom0 has to be scheduled.
>>>
>>> Perhaps I did not express clearly what I mean at #3.
>>> I don't understand why the qemu-dm(qemu-0.10.2) works well
>>> but the upstream qemu(begin with qemu-0.14) is not for the
>>> same windows XP guest image in cirrus vga emulation. Does
>>> the cirrus vga emulation have some differences between
>>> qemu-dm and unstream qemu ?
>>
>> I don't know about qemu-dm, but QEMU switched from a home-grown pixel
>> handling to pixman library sometime around 1.4. CC'ing Gerd.
>
> 0.14 != 1.4 ;)
Oops! In that case, Gonglei, try to reproduce the issue with upstream
0.10 and use git-bisect to find out when things got slower between
v0.10.2..v0.14.0. It would be unrealistic to expect us to remember all
Cirrus-related changes from 2-4 years ago. ;)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 6:41 ` Gonglei (Arei)
` (2 preceding siblings ...)
2013-07-26 12:29 ` Fabio Fantoni
@ 2013-07-26 12:29 ` Fabio Fantoni
3 siblings, 0 replies; 49+ messages in thread
From: Fabio Fantoni @ 2013-07-26 12:29 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Anthony Liguori,
Huangweidong (Hardware)
Il 26/07/2013 08:41, Gonglei (Arei) ha scritto:
>
>> -----Original Message-----
>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>> Sent: Friday, July 26, 2013 11:21 AM
>> To: Gonglei (Arei)
>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>> Luonengjun; Huangweidong (Hardware)
>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>> last 13s or so for windows XP guest
>>
>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
>> <arei.gonglei@huawei.com> wrote:
>>>> -----Original Message-----
>>>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>>>> Sent: Friday, July 26, 2013 10:09 AM
>>>> To: Gonglei (Arei)
>>>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>>>> Luonengjun; Huangweidong (Hardware)
>>>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank
>> screen
>>>> last 13s or so for windows XP guest
>>>>
>>>> Windows XP uses VGA planar mode during boot up. This means that to
>>>> set a pixel requires 3 MMIO operations (one for the red pixel, one for
>>>> the green pixel, one for the blue pixel). KVM has an optimization
>>>> called MMIO coalescing which avoids a heavy weight exit for planar
>>>> mode exits. I guess Xen doesn't have an optimization like this.
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>> Thanks, Anthony.
>>> I tested the Windows XP guest again on KVM and XEN, and I found:
>>> 1. Windows XP will show blank screen during boot up as the same as
>>> the protocol switch between VNC and RDP.
>>> 2. Standard VGA works well, what's difference between cirrus and standard
>> VGA for the guest?
>>
>> Cirrus predates VESA. VESA has a linear framebuffer mode and WinXP
>> can use VESA modes (provided that VESA drivers are installed). A
>> linear framebuffer mode requires no exits to update individual pixels.
>> Instead, there is a timer that fires 30-60 times a second to handle
>> any pixels that have been dirtied during that period.
>>
>>> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
>> emulation ?
>>
>> This is one of the few cases where TCG is actually faster than KVM or
>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
>> even with KVM, an MMIO exit is at least a couples thousand cycles.
>> It's worse with Xen because dom0 has to be scheduled.
> Perhaps I did not express clearly what I mean at #3.
> I don't understand why the qemu-dm(qemu-0.10.2) works well
> but the upstream qemu(begin with qemu-0.14) is not for the
> same windows XP guest image in cirrus vga emulation. Does
> the cirrus vga emulation have some differences between
> qemu-dm and unstream qemu ?
Probably can be useful try to see here:
https://github.com/xenserver/qemu-xen-4.2.pg/tree/master/master
Probably there are one or more patches not upstreamed that can solve one
or more problems.
>
> Thank you so much!
>
> -Gonglei
>> If you search a bit for the V2E project, there was an attempt to
>> combine TCG emulation with hardware virtualization specifically to
>> handle cases like this. Coalesced MMIO was good enough for KVM though
>> that something like V2E wasn't pursued for KVM.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> Eagerly looking forward to your reply!
>>>
>>> -Gonglei
>>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 6:41 ` Gonglei (Arei)
2013-07-26 10:02 ` Andreas Färber
2013-07-26 10:02 ` Andreas Färber
@ 2013-07-26 12:29 ` Fabio Fantoni
2013-07-26 12:29 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
3 siblings, 0 replies; 49+ messages in thread
From: Fabio Fantoni @ 2013-07-26 12:29 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Anthony Liguori,
Huangweidong (Hardware)
Il 26/07/2013 08:41, Gonglei (Arei) ha scritto:
>
>> -----Original Message-----
>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>> Sent: Friday, July 26, 2013 11:21 AM
>> To: Gonglei (Arei)
>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>> Luonengjun; Huangweidong (Hardware)
>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
>> last 13s or so for windows XP guest
>>
>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
>> <arei.gonglei@huawei.com> wrote:
>>>> -----Original Message-----
>>>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
>>>> Sent: Friday, July 26, 2013 10:09 AM
>>>> To: Gonglei (Arei)
>>>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
>>>> Luonengjun; Huangweidong (Hardware)
>>>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank
>> screen
>>>> last 13s or so for windows XP guest
>>>>
>>>> Windows XP uses VGA planar mode during boot up. This means that to
>>>> set a pixel requires 3 MMIO operations (one for the red pixel, one for
>>>> the green pixel, one for the blue pixel). KVM has an optimization
>>>> called MMIO coalescing which avoids a heavy weight exit for planar
>>>> mode exits. I guess Xen doesn't have an optimization like this.
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>> Thanks, Anthony.
>>> I tested the Windows XP guest again on KVM and XEN, and I found:
>>> 1. Windows XP will show blank screen during boot up as the same as
>>> the protocol switch between VNC and RDP.
>>> 2. Standard VGA works well, what's difference between cirrus and standard
>> VGA for the guest?
>>
>> Cirrus predates VESA. VESA has a linear framebuffer mode and WinXP
>> can use VESA modes (provided that VESA drivers are installed). A
>> linear framebuffer mode requires no exits to update individual pixels.
>> Instead, there is a timer that fires 30-60 times a second to handle
>> any pixels that have been dirtied during that period.
>>
>>> 3. Why does the traditional qemu has no blank screen problem on cirrus VGA
>> emulation ?
>>
>> This is one of the few cases where TCG is actually faster than KVM or
>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
>> even with KVM, an MMIO exit is at least a couples thousand cycles.
>> It's worse with Xen because dom0 has to be scheduled.
> Perhaps I did not express clearly what I mean at #3.
> I don't understand why the qemu-dm(qemu-0.10.2) works well
> but the upstream qemu(begin with qemu-0.14) is not for the
> same windows XP guest image in cirrus vga emulation. Does
> the cirrus vga emulation have some differences between
> qemu-dm and unstream qemu ?
Probably can be useful try to see here:
https://github.com/xenserver/qemu-xen-4.2.pg/tree/master/master
Probably there are one or more patches not upstreamed that can solve one
or more problems.
>
> Thank you so much!
>
> -Gonglei
>> If you search a bit for the V2E project, there was an attempt to
>> combine TCG emulation with hardware virtualization specifically to
>> handle cases like this. Coalesced MMIO was good enough for KVM though
>> that something like V2E wasn't pursued for KVM.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> Eagerly looking forward to your reply!
>>>
>>> -Gonglei
>>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 10:27 ` Andreas Färber
@ 2013-07-27 11:06 ` Gonglei (Arei)
0 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-27 11:06 UTC (permalink / raw)
To: Andreas Färber, Gerd Hoffmann
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Anthony Liguori,
Huangweidong (Hardware)
> -----Original Message-----
> From: Andreas Färber [mailto:afaerber@suse.de]
> Sent: Friday, July 26, 2013 6:28 PM
> To: Gerd Hoffmann; Gonglei (Arei)
> Cc: Anthony Liguori; Hanweidong; Luonengjun; qemu-devel@nongnu.org;
> Huangweidong (Hardware); xen-devel@lists.xen.org
> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> last 13s or so for windows XP guest
>
> Am 26.07.2013 12:19, schrieb Gerd Hoffmann:
> > On 07/26/13 12:02, Andreas Färber wrote:
> >> Am 26.07.2013 08:41, schrieb Gonglei (Arei):
> >>>> -----Original Message-----
> >>>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> >>>> Sent: Friday, July 26, 2013 11:21 AM
> >>>> To: Gonglei (Arei)
> >>>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> >>>> Luonengjun; Huangweidong (Hardware)
> >>>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank
> screen
> >>>> last 13s or so for windows XP guest
> >>>>
> >>>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
> >>>> <arei.gonglei@huawei.com> wrote:
> >>>>> 3. Why does the traditional qemu has no blank screen problem on cirrus
> VGA
> >>>> emulation ?
> >>>>
> >>>> This is one of the few cases where TCG is actually faster than KVM or
> >>>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
> >>>> even with KVM, an MMIO exit is at least a couples thousand cycles.
> >>>> It's worse with Xen because dom0 has to be scheduled.
> >>>
> >>> Perhaps I did not express clearly what I mean at #3.
> >>> I don't understand why the qemu-dm(qemu-0.10.2) works well
> >>> but the upstream qemu(begin with qemu-0.14) is not for the
> >>> same windows XP guest image in cirrus vga emulation. Does
> >>> the cirrus vga emulation have some differences between
> >>> qemu-dm and unstream qemu ?
> >>
> >> I don't know about qemu-dm, but QEMU switched from a home-grown pixel
> >> handling to pixman library sometime around 1.4. CC'ing Gerd.
> >
> > 0.14 != 1.4 ;)
>
> Oops! In that case, Gonglei, try to reproduce the issue with upstream
> 0.10 and use git-bisect to find out when things got slower between
> v0.10.2..v0.14.0. It would be unrealistic to expect us to remember all
> Cirrus-related changes from 2-4 years ago. ;)
On KVM:
I reproduced the issues that the VNC client show blank screen when Windows XP guest booting up
from qemu-kvm-0.11.0 to latest qemu-1.5.1. I wanted to test qemu-kvm-0.10, but I didn't
know the right command on it. The command beginning with qemu-kvm-0.11.0 is:
./qemu-system-x86_64 -name winXP -m 2048 -smp 2 -drive file=/mnt/sdd/image/winxp_sp3_32_2U_cn -vnc 0.0.0.0:2 -vga cirrus
Hoping to help, thanks!
-Gonglei
>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
@ 2013-07-27 11:06 ` Gonglei (Arei)
0 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-27 11:06 UTC (permalink / raw)
To: Andreas Färber, Gerd Hoffmann
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Anthony Liguori,
Huangweidong (Hardware)
> -----Original Message-----
> From: Andreas Färber [mailto:afaerber@suse.de]
> Sent: Friday, July 26, 2013 6:28 PM
> To: Gerd Hoffmann; Gonglei (Arei)
> Cc: Anthony Liguori; Hanweidong; Luonengjun; qemu-devel@nongnu.org;
> Huangweidong (Hardware); xen-devel@lists.xen.org
> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen
> last 13s or so for windows XP guest
>
> Am 26.07.2013 12:19, schrieb Gerd Hoffmann:
> > On 07/26/13 12:02, Andreas Färber wrote:
> >> Am 26.07.2013 08:41, schrieb Gonglei (Arei):
> >>>> -----Original Message-----
> >>>> From: Anthony Liguori [mailto:anthony@codemonkey.ws]
> >>>> Sent: Friday, July 26, 2013 11:21 AM
> >>>> To: Gonglei (Arei)
> >>>> Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org; Hanweidong;
> >>>> Luonengjun; Huangweidong (Hardware)
> >>>> Subject: Re: [Qemu-devel] Cirrus VGA slow screen update, show blank
> screen
> >>>> last 13s or so for windows XP guest
> >>>>
> >>>> On Thu, Jul 25, 2013 at 10:08 PM, Gonglei (Arei)
> >>>> <arei.gonglei@huawei.com> wrote:
> >>>>> 3. Why does the traditional qemu has no blank screen problem on cirrus
> VGA
> >>>> emulation ?
> >>>>
> >>>> This is one of the few cases where TCG is actually faster than KVM or
> >>>> Xen. In TCG, an MMIO exit is converted to a function call. OTOH,
> >>>> even with KVM, an MMIO exit is at least a couples thousand cycles.
> >>>> It's worse with Xen because dom0 has to be scheduled.
> >>>
> >>> Perhaps I did not express clearly what I mean at #3.
> >>> I don't understand why the qemu-dm(qemu-0.10.2) works well
> >>> but the upstream qemu(begin with qemu-0.14) is not for the
> >>> same windows XP guest image in cirrus vga emulation. Does
> >>> the cirrus vga emulation have some differences between
> >>> qemu-dm and unstream qemu ?
> >>
> >> I don't know about qemu-dm, but QEMU switched from a home-grown pixel
> >> handling to pixman library sometime around 1.4. CC'ing Gerd.
> >
> > 0.14 != 1.4 ;)
>
> Oops! In that case, Gonglei, try to reproduce the issue with upstream
> 0.10 and use git-bisect to find out when things got slower between
> v0.10.2..v0.14.0. It would be unrealistic to expect us to remember all
> Cirrus-related changes from 2-4 years ago. ;)
On KVM:
I reproduced the issues that the VNC client show blank screen when Windows XP guest booting up
from qemu-kvm-0.11.0 to latest qemu-1.5.1. I wanted to test qemu-kvm-0.10, but I didn't
know the right command on it. The command beginning with qemu-kvm-0.11.0 is:
./qemu-system-x86_64 -name winXP -m 2048 -smp 2 -drive file=/mnt/sdd/image/winxp_sp3_32_2U_cn -vnc 0.0.0.0:2 -vga cirrus
Hoping to help, thanks!
-Gonglei
>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 10:19 ` Gerd Hoffmann
` (2 preceding siblings ...)
2013-07-27 11:51 ` Pasi Kärkkäinen
@ 2013-07-27 11:51 ` Pasi Kärkkäinen
2013-07-29 8:48 ` Gonglei (Arei)
2013-07-29 8:48 ` Gonglei (Arei)
3 siblings, 2 replies; 49+ messages in thread
From: Pasi Kärkkäinen @ 2013-07-27 11:51 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Gonglei (Arei),
Anthony Liguori, Andreas Färber, Huangweidong (Hardware)
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.
> Beside that the standard vga usually is the better choice anyway as it
> supports more video memory and higher resolutions than cirrus.
>
One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
Is there one for the emulated stdvga adapter?
-- Pasi
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-26 10:19 ` Gerd Hoffmann
2013-07-26 10:27 ` Andreas Färber
2013-07-26 10:27 ` Andreas Färber
@ 2013-07-27 11:51 ` Pasi Kärkkäinen
2013-07-27 11:51 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
3 siblings, 0 replies; 49+ messages in thread
From: Pasi Kärkkäinen @ 2013-07-27 11:51 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Gonglei (Arei),
Anthony Liguori, Andreas Färber, Huangweidong (Hardware)
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.
> Beside that the standard vga usually is the better choice anyway as it
> supports more video memory and higher resolutions than cirrus.
>
One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
Is there one for the emulated stdvga adapter?
-- Pasi
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-27 11:51 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
@ 2013-07-29 8:48 ` Gonglei (Arei)
2013-07-29 10:58 ` [Qemu-devel] " Pasi Kärkkäinen
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
2013-07-29 8:48 ` Gonglei (Arei)
1 sibling, 2 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-29 8:48 UTC (permalink / raw)
To: Pasi Kärkkäinen, Gerd Hoffmann
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Anthony Liguori,
Andreas Färber, Huangweidong (Hardware)
> -----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!
-Gonglei
> > Beside that the standard vga usually is the better choice anyway as it
> > supports more video memory and higher resolutions than cirrus.
> >
>
> One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
> Is there one for the emulated stdvga adapter?
>
> -- Pasi
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-27 11:51 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
2013-07-29 8:48 ` Gonglei (Arei)
@ 2013-07-29 8:48 ` Gonglei (Arei)
1 sibling, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-29 8:48 UTC (permalink / raw)
To: Pasi Kärkkäinen, Gerd Hoffmann
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Anthony Liguori,
Andreas Färber, Huangweidong (Hardware)
> -----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!
-Gonglei
> > Beside that the standard vga usually is the better choice anyway as it
> > supports more video memory and higher resolutions than cirrus.
> >
>
> One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
> Is there one for the emulated stdvga adapter?
>
> -- Pasi
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 8:48 ` Gonglei (Arei)
2013-07-29 10:58 ` [Qemu-devel] " Pasi Kärkkäinen
@ 2013-07-29 10:58 ` Pasi Kärkkäinen
2013-07-30 2:01 ` Gonglei (Arei)
` (5 more replies)
1 sibling, 6 replies; 49+ messages in thread
From: Pasi Kärkkäinen @ 2013-07-29 10:58 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Gerd Hoffmann,
Anthony Liguori, Andreas Färber, Huangweidong (Hardware)
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
> -Gonglei
>
> > > Beside that the standard vga usually is the better choice anyway as it
> > > supports more video memory and higher resolutions than cirrus.
> > >
> >
> > One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
> > Is there one for the emulated stdvga adapter?
> >
> > -- Pasi
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 8:48 ` Gonglei (Arei)
@ 2013-07-29 10:58 ` Pasi Kärkkäinen
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
1 sibling, 0 replies; 49+ messages in thread
From: Pasi Kärkkäinen @ 2013-07-29 10:58 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Hanweidong, Luonengjun, qemu-devel, xen-devel, Gerd Hoffmann,
Anthony Liguori, Andreas Färber, Huangweidong (Hardware)
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
> -Gonglei
>
> > > Beside that the standard vga usually is the better choice anyway as it
> > > supports more video memory and higher resolutions than cirrus.
> > >
> >
> > One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
> > Is there one for the emulated stdvga adapter?
> >
> > -- Pasi
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
@ 2013-07-30 2:01 ` Gonglei (Arei)
2013-07-30 2:01 ` [Qemu-devel] " Gonglei (Arei)
` (4 subsequent siblings)
5 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-30 2:01 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: aliguori, Hanweidong, Ian.Jackson, Luonengjun, qemu-devel,
xen-devel, Gerd Hoffmann, Anthony Liguori, Andreas Färber,
Huangweidong (Hardware)
> 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.
-Gonglei
>
> > -Gonglei
> >
> > > > Beside that the standard vga usually is the better choice anyway as it
> > > > supports more video memory and higher resolutions than cirrus.
> > > >
> > >
> > > One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
> > > Is there one for the emulated stdvga adapter?
> > >
> > > -- Pasi
> >
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
2013-07-30 2:01 ` Gonglei (Arei)
@ 2013-07-30 2:01 ` Gonglei (Arei)
2013-08-16 9:09 ` Gonglei (Arei)
` (3 subsequent siblings)
5 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-07-30 2:01 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: aliguori, Hanweidong, Ian.Jackson, Luonengjun, qemu-devel,
xen-devel, Gerd Hoffmann, Anthony Liguori, Andreas Färber,
Huangweidong (Hardware)
> 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.
-Gonglei
>
> > -Gonglei
> >
> > > > Beside that the standard vga usually is the better choice anyway as it
> > > > supports more video memory and higher resolutions than cirrus.
> > > >
> > >
> > > One of the reasons to use emulated Cirrus is that there's a KMS driver for it.
> > > Is there one for the emulated stdvga adapter?
> > >
> > > -- Pasi
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
` (2 preceding siblings ...)
2013-08-16 9:09 ` Gonglei (Arei)
@ 2013-08-16 9:09 ` Gonglei (Arei)
2013-08-17 9:04 ` Gonglei (Arei)
2013-08-17 9:04 ` Gonglei (Arei)
5 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-08-16 9:09 UTC (permalink / raw)
To: Gonglei (Arei), Pasi Kärkkäinen
Cc: Hanweidong, Ian.Jackson, Yanqiangjun, Luonengjun, qemu-devel,
xen-devel, Yangxiaowei, Gerd Hoffmann, Anthony Liguori,
Andreas Färber, Huangweidong (Hardware)
Hi, all
I compared the traditional qemu-dm and upstream qemu,
and I found the upstream qemu will create the expansion ROM at f3000000, but qemu-dm don't.
the details as below (by "lspci -vnnn"):
1) traditional qemu-dm:
00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] (prog-if 00 [VGA controller])
Subsystem: XenSource, Inc. Device [5853:0001]
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f0000000 (32-bit, prefetchable) [size=32M]
Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
Kernel modules: cirrusfb
2) upstream qemu:
00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] (prog-if 00 [VGA controller])
Subsystem: XenSource, Inc. Device [5853:0001]
Physical Slot: 2
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f0000000 (32-bit, prefetchable) [size=32M]
Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at f3000000 [disabled] [size=64K]
Kernel modules: cirrusfb
I tried to simply delete the expansion ROM at function pci_add_option_rom, such as
//pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
but the VNC viewer only can see black screen, but RDP works well.
Any ideas about the cirrus's expansion ROM?
Slow screen refresh has any relationship with cirrus's expansion ROM?
Thank you in advance!
BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
static int stdvga_intercept_mmio(ioreq_t *p)
{
struct domain *d = current->domain;
struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
int buf = 0, rc;
static int count_1 = 0;
static int count_2 = 0;
if ( p->size > 8 )
{
gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
return X86EMUL_UNHANDLEABLE;
}
spin_lock(&s->lock);
if ( s->stdvga && s->cache )
{
switch ( p->type )
{
case IOREQ_TYPE_COPY:
buf = mmio_move(s, p);
count_1++;
if (count_1 % 1000 == 0)
gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move, count_1=%d\n", count_1);
if ( !buf )
s->cache = 0;
break;
default:
gdprintk(XENLOG_WARNING, "unsupported mmio request type:%d "
"addr:0x%04x data:0x%04x size:%d count:%d state:%d "
"isptr:%d dir:%d df:%d\n",
p->type, (int)p->addr, (int)p->data, (int)p->size,
(int)p->count, p->state,
p->data_is_ptr, p->dir, p->df);
s->cache = 0;
}
}
else
{
buf = (p->dir == IOREQ_WRITE);
count_2++;
if (count_2 % 5000 == 0)
gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n", count_2);
}
rc = (buf && hvm_buffered_io_send(p));
spin_unlock(&s->lock);
return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
}
and I got the below result with upstream qemu and tranditional qemu-dm:
1) traditional qemu-dm:
(XEN) stdvga.c:152:d2 entering stdvga and caching modes
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
(XEN) stdvga.c:156:d2 leaving stdvga
2) upstream qemu:
(XEN) stdvga.c:152:d1 entering stdvga and caching modes
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
(XEN) stdvga.c:156:d1 leaving stdvga
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
... ... //Omit some similar
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000 than traditional qemu-dm.
Best Regards!
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Monday, August 05, 2013 8:50 PM
> To: 'Gonglei (Arei)'; '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'
> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
> Hi,
>
> > -----Original Message-----
> > From: Gonglei (Arei)
> > Sent: Tuesday, July 30, 2013 10:01 AM
> > To: 'Pasi Kärkkäinen'
> > Cc: Gerd Hoffmann; Andreas Färber; Hanweidong; Luonengjun;
> > qemu-devel@nongnu.org; xen-devel@lists.xen.org; Anthony Liguori;
> > Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; Anthony Liguori;
> > 'aliguori@us.ibm.com'
> > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > blank screen last 13s or so for windows XP guest
> >
> > > On Mon, Jul 29, 2013 at 08:48:54AM +0000, Gonglei (Arei) wrote:
> > > > > -----Original Message-----
> > > > > From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> > > > > Sent: Saturday, July 27, 2013 7:51 PM
> > > > > To: Gerd Hoffmann
> > > > > Cc: Andreas Färber; Hanweidong; Luonengjun;
> qemu-devel@nongnu.org;
> > > > > xen-devel@lists.xen.org; Gonglei (Arei); Anthony Liguori; Huangweidong
> > > > > (Hardware)
> > > > > Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update,
> > show
> > > > > blank screen last 13s or so for windows XP guest
> > > > >
> > > > > On Fri, Jul 26, 2013 at 12:19:16PM +0200, Gerd Hoffmann wrote:
> > > > > >
> > > > > > Maybe the xen guys did some optimizations in qemu-dm which where
> > not
> > > > > > merged upstream. Try asking @ xen-devel.
> > > > > >
> > > > >
> > > > > Yeah, xen qemu-dm must have some optimization for cirrus that isn't in
> > > > > upstream qemu.
> > > >
> > > > Hi, Pasi. Would you give me some more details? Thanks!
> > > >
> > >
> > > Unfortunately I don't have any more details.. I was just assuming if xen
> > > qemu-dm is fast,
> > > but upstream qemu is slow, there might be some optimization in xen
> > > qemu-dm ..
> > >
> > > Did you check the xen qemu-dm (traditional) history / commits?
> > >
> > > -- Pasi
> >
> > Yes, I did. I tried to reproduce the issue with qemu-dm by fall backing history
> > commit.
> > But the qemu-dm mainline merged other branches, such as branch
> 'upstream'
> > and branch 'qemu',
> > so that I can not complied the xen-4.1.2/tools project well. CC'ing Ian and
> > Anthony.
> >
> By analyzing xentrace data, I found that there is lot's of VMEXIT between
> memory region 0xa0000~0xaffff with upstream qemu,
> but only 256 VMEXIT on traditional qemu-dm, when Windows XP guest booting
> up or change the method connecting the VM from VNC(RDP) to RDP(VNC):
>
> linux-sAGhxH:# cat qemu-upstrem.log |grep 0x00000000000a|wc -l
> 640654
> linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a|wc -l
> 256
> And the 256 VMEXIT of qemu-dm as the same as the top 256 VMEXIT of
> qemu-upstream
>
> linux-sAGhxH:# cat qemu-upstream.log |grep 0x00000000000a| tail
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b08 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0a mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0c mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0e mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b10 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b12 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b14 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b16 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b18 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b1a mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a| tail
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ec0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ee0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f00 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f20 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f40 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f60 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f80 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fa0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fc0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fe0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
>
> Please see attachment for more information.
>
> Because of the lot's of VMEXIT, the cirrus_vga_ioport_write funciton receive
> little scheduling,
> and cirrus_vga_write_gr execution interval of more than 32ms twice per, so
> that the blank screen time over 13 second with upstream qemu on Xen.
> I don't know why the Windows XP guest access the memory region
> 0xa0000~0xaffff with upstream qemu but with traditional qemu-dm is not,
> Anyone can give me some suggestion?
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
2013-07-30 2:01 ` Gonglei (Arei)
2013-07-30 2:01 ` [Qemu-devel] " Gonglei (Arei)
@ 2013-08-16 9:09 ` Gonglei (Arei)
2013-08-16 9:09 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
` (2 subsequent siblings)
5 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-08-16 9:09 UTC (permalink / raw)
To: Gonglei (Arei), Pasi Kärkkäinen
Cc: Hanweidong, Ian.Jackson, Yanqiangjun, Luonengjun, qemu-devel,
xen-devel, Yangxiaowei, Gerd Hoffmann, Anthony Liguori,
Andreas Färber, Huangweidong (Hardware)
Hi, all
I compared the traditional qemu-dm and upstream qemu,
and I found the upstream qemu will create the expansion ROM at f3000000, but qemu-dm don't.
the details as below (by "lspci -vnnn"):
1) traditional qemu-dm:
00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] (prog-if 00 [VGA controller])
Subsystem: XenSource, Inc. Device [5853:0001]
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f0000000 (32-bit, prefetchable) [size=32M]
Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
Kernel modules: cirrusfb
2) upstream qemu:
00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] (prog-if 00 [VGA controller])
Subsystem: XenSource, Inc. Device [5853:0001]
Physical Slot: 2
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f0000000 (32-bit, prefetchable) [size=32M]
Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at f3000000 [disabled] [size=64K]
Kernel modules: cirrusfb
I tried to simply delete the expansion ROM at function pci_add_option_rom, such as
//pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
but the VNC viewer only can see black screen, but RDP works well.
Any ideas about the cirrus's expansion ROM?
Slow screen refresh has any relationship with cirrus's expansion ROM?
Thank you in advance!
BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
static int stdvga_intercept_mmio(ioreq_t *p)
{
struct domain *d = current->domain;
struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
int buf = 0, rc;
static int count_1 = 0;
static int count_2 = 0;
if ( p->size > 8 )
{
gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
return X86EMUL_UNHANDLEABLE;
}
spin_lock(&s->lock);
if ( s->stdvga && s->cache )
{
switch ( p->type )
{
case IOREQ_TYPE_COPY:
buf = mmio_move(s, p);
count_1++;
if (count_1 % 1000 == 0)
gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move, count_1=%d\n", count_1);
if ( !buf )
s->cache = 0;
break;
default:
gdprintk(XENLOG_WARNING, "unsupported mmio request type:%d "
"addr:0x%04x data:0x%04x size:%d count:%d state:%d "
"isptr:%d dir:%d df:%d\n",
p->type, (int)p->addr, (int)p->data, (int)p->size,
(int)p->count, p->state,
p->data_is_ptr, p->dir, p->df);
s->cache = 0;
}
}
else
{
buf = (p->dir == IOREQ_WRITE);
count_2++;
if (count_2 % 5000 == 0)
gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n", count_2);
}
rc = (buf && hvm_buffered_io_send(p));
spin_unlock(&s->lock);
return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
}
and I got the below result with upstream qemu and tranditional qemu-dm:
1) traditional qemu-dm:
(XEN) stdvga.c:152:d2 entering stdvga and caching modes
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
(XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
(XEN) stdvga.c:156:d2 leaving stdvga
2) upstream qemu:
(XEN) stdvga.c:152:d1 entering stdvga and caching modes
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
(XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
(XEN) stdvga.c:156:d1 leaving stdvga
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
... ... //Omit some similar
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
(XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000 than traditional qemu-dm.
Best Regards!
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Monday, August 05, 2013 8:50 PM
> To: 'Gonglei (Arei)'; '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'
> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
> Hi,
>
> > -----Original Message-----
> > From: Gonglei (Arei)
> > Sent: Tuesday, July 30, 2013 10:01 AM
> > To: 'Pasi Kärkkäinen'
> > Cc: Gerd Hoffmann; Andreas Färber; Hanweidong; Luonengjun;
> > qemu-devel@nongnu.org; xen-devel@lists.xen.org; Anthony Liguori;
> > Huangweidong (Hardware); 'Ian.Jackson@eu.citrix.com'; Anthony Liguori;
> > 'aliguori@us.ibm.com'
> > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > blank screen last 13s or so for windows XP guest
> >
> > > On Mon, Jul 29, 2013 at 08:48:54AM +0000, Gonglei (Arei) wrote:
> > > > > -----Original Message-----
> > > > > From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> > > > > Sent: Saturday, July 27, 2013 7:51 PM
> > > > > To: Gerd Hoffmann
> > > > > Cc: Andreas Färber; Hanweidong; Luonengjun;
> qemu-devel@nongnu.org;
> > > > > xen-devel@lists.xen.org; Gonglei (Arei); Anthony Liguori; Huangweidong
> > > > > (Hardware)
> > > > > Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update,
> > show
> > > > > blank screen last 13s or so for windows XP guest
> > > > >
> > > > > On Fri, Jul 26, 2013 at 12:19:16PM +0200, Gerd Hoffmann wrote:
> > > > > >
> > > > > > Maybe the xen guys did some optimizations in qemu-dm which where
> > not
> > > > > > merged upstream. Try asking @ xen-devel.
> > > > > >
> > > > >
> > > > > Yeah, xen qemu-dm must have some optimization for cirrus that isn't in
> > > > > upstream qemu.
> > > >
> > > > Hi, Pasi. Would you give me some more details? Thanks!
> > > >
> > >
> > > Unfortunately I don't have any more details.. I was just assuming if xen
> > > qemu-dm is fast,
> > > but upstream qemu is slow, there might be some optimization in xen
> > > qemu-dm ..
> > >
> > > Did you check the xen qemu-dm (traditional) history / commits?
> > >
> > > -- Pasi
> >
> > Yes, I did. I tried to reproduce the issue with qemu-dm by fall backing history
> > commit.
> > But the qemu-dm mainline merged other branches, such as branch
> 'upstream'
> > and branch 'qemu',
> > so that I can not complied the xen-4.1.2/tools project well. CC'ing Ian and
> > Anthony.
> >
> By analyzing xentrace data, I found that there is lot's of VMEXIT between
> memory region 0xa0000~0xaffff with upstream qemu,
> but only 256 VMEXIT on traditional qemu-dm, when Windows XP guest booting
> up or change the method connecting the VM from VNC(RDP) to RDP(VNC):
>
> linux-sAGhxH:# cat qemu-upstrem.log |grep 0x00000000000a|wc -l
> 640654
> linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a|wc -l
> 256
> And the 256 VMEXIT of qemu-dm as the same as the top 256 VMEXIT of
> qemu-upstream
>
> linux-sAGhxH:# cat qemu-upstream.log |grep 0x00000000000a| tail
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b08 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0a mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0c mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b0e mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b10 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b12 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b14 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b16 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b18 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU0 0 (+ 0) NPF [ gpa = 0x00000000000a0b1a mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> linux-sAGhxH:# cat qemu-dm.log |grep 0x00000000000a| tail
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ec0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1ee0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f00 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f20 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f40 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f60 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1f80 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fa0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fc0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x00000000000a1fe0 mfn =
> 0xffffffffffffffff qual = 0x0182 p2mt = 0x0004 ]
>
> Please see attachment for more information.
>
> Because of the lot's of VMEXIT, the cirrus_vga_ioport_write funciton receive
> little scheduling,
> and cirrus_vga_write_gr execution interval of more than 32ms twice per, so
> that the blank screen time over 13 second with upstream qemu on Xen.
> I don't know why the Windows XP guest access the memory region
> 0xa0000~0xaffff with upstream qemu but with traditional qemu-dm is not,
> Anyone can give me some suggestion?
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
` (3 preceding siblings ...)
2013-08-16 9:09 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
@ 2013-08-17 9:04 ` Gonglei (Arei)
2013-08-20 19:45 ` [Qemu-devel] " Konrad Rzeszutek Wilk
2013-08-20 19:45 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2013-08-17 9:04 ` Gonglei (Arei)
5 siblings, 2 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-08-17 9:04 UTC (permalink / raw)
To: Gonglei (Arei), Pasi Kärkkäinen, vgabios-developers
Cc: ggrebus, bguthro, Hanweidong, Ian.Jackson, Yanqiangjun,
Luonengjun, qemu-devel, xen-devel, Yangxiaowei, Gerd Hoffmann,
Anthony Liguori, keir.fraser, Andreas Färber,
Huangweidong (Hardware)
Hi,
The fundamental reason is traditional qemu-dm and upstream qemu using a different vgabios-cirrus.bin,
qemu-dm is using xen-4.1.2/tools/firmware/vgabios/ VGABIOS-lgpl-latest.cirrus.bin,
but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
the pivotal patch is :
# HG changeset patch
# User Keir Fraser <keir@xensource.com>
# Date 1193391667 -3600
# Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
# Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
Signed-off-by: Ben Guthro <bguthro@virtualron.com>
Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c
--- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100
+++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100
@@ -1489,14 +1489,26 @@
mov dx, #0x3ce
out dx, ax
push ax
- mov cx, #0xa000
- mov es, cx
- xor di, di
+
+;; Windows Vista appears to be emulating this sequence as part of changing
+;; screen resolution, but it generates 4096 writes per iteration.
+;; Instead, use a magic register sequence to write the whole bank.
+;;mov cx, #0xa000
+;;mov es, cx
+;;xor di, di
+;;mov ax, si
+;;mov cx, #8192
+;;cld
+;;rep
+;; stosw
mov ax, si
- mov cx, #8192
- cld
- rep
- stosw
+ shl ax, #8
+ mov al, #0xfe
+ out dx, ax ;; Low byte of value to be written to the bank
+ mov ax, si
+ mov al, #0xff
+ out dx, ax ;; High byte and trigger the write
+
pop ax
inc ah
cmp ah, bl
diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c
--- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100
+++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100
@@ -294,6 +294,7 @@
static void cirrus_bitblt_reset(CirrusVGAState *s);
static void cirrus_update_memory_access(CirrusVGAState *s);
+static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val);
/***************************************
*
@@ -1497,6 +1498,17 @@
case 0x31: // BLT STATUS/START
cirrus_write_bitblt(s, reg_value);
break;
+
+ // Extension to allow BIOS to clear 16K VRAM bank in one operation
+ case 0xFE:
+ s->gr[reg_index] = reg_value; // Lower byte of value to be written
+ break;
+ case 0xFF: {
+ target_phys_addr_t addr;
+ for (addr = 0xa0000; addr < 0xa4000; addr += 2)
+ cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
+ }
+ break;
default:
#ifdef DEBUG_CIRRUS
printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,
By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
And I test the latest vgabios-0.7a come from
http://www.nongnu.org/vgabios/#DOWNLOAD
but the problem of blank screen remain.
Best Regards!
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Friday, August 16, 2013 5:10 PM
> To: Gonglei (Arei); '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';
> Yanqiangjun; Yangxiaowei
> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
> Hi, all
> I compared the traditional qemu-dm and upstream qemu,
> and I found the upstream qemu will create the expansion ROM at f3000000,
> but qemu-dm don't.
> the details as below (by "lspci -vnnn"):
>
> 1) traditional qemu-dm:
> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
> (prog-if 00 [VGA controller])
> Subsystem: XenSource, Inc. Device [5853:0001]
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f0000000 (32-bit, prefetchable) [size=32M]
> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> Kernel modules: cirrusfb
>
> 2) upstream qemu:
> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
> (prog-if 00 [VGA controller])
> Subsystem: XenSource, Inc. Device [5853:0001]
> Physical Slot: 2
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f0000000 (32-bit, prefetchable) [size=32M]
> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> Expansion ROM at f3000000 [disabled] [size=64K]
> Kernel modules: cirrusfb
>
> I tried to simply delete the expansion ROM at function pci_add_option_rom,
> such as
>
> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>
> but the VNC viewer only can see black screen, but RDP works well.
> Any ideas about the cirrus's expansion ROM?
> Slow screen refresh has any relationship with cirrus's expansion ROM?
> Thank you in advance!
>
> BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
> static int stdvga_intercept_mmio(ioreq_t *p)
> {
> struct domain *d = current->domain;
> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
> int buf = 0, rc;
> static int count_1 = 0;
> static int count_2 = 0;
>
> if ( p->size > 8 )
> {
> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
> return X86EMUL_UNHANDLEABLE;
> }
>
> spin_lock(&s->lock);
>
> if ( s->stdvga && s->cache )
> {
> switch ( p->type )
> {
> case IOREQ_TYPE_COPY:
> buf = mmio_move(s, p);
> count_1++;
> if (count_1 % 1000 == 0)
> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
> count_1=%d\n", count_1);
> if ( !buf )
> s->cache = 0;
> break;
> default:
> gdprintk(XENLOG_WARNING, "unsupported mmio request
> type:%d "
> "addr:0x%04x data:0x%04x size:%d count:%d
> state:%d "
> "isptr:%d dir:%d df:%d\n",
> p->type, (int)p->addr, (int)p->data, (int)p->size,
> (int)p->count, p->state,
> p->data_is_ptr, p->dir, p->df);
> s->cache = 0;
> }
> }
> else
> {
> buf = (p->dir == IOREQ_WRITE);
> count_2++;
> if (count_2 % 5000 == 0)
> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
> count_2);
> }
>
> rc = (buf && hvm_buffered_io_send(p));
>
> spin_unlock(&s->lock);
>
> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
> }
>
> and I got the below result with upstream qemu and tranditional qemu-dm:
>
> 1) traditional qemu-dm:
> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
> (XEN) stdvga.c:156:d2 leaving stdvga
>
> 2) upstream qemu:
> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
> (XEN) stdvga.c:156:d1 leaving stdvga
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
> ... ... //Omit some similar
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>
> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
> than traditional qemu-dm.
>
> Best Regards!
>
> -Gonglei
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
` (4 preceding siblings ...)
2013-08-17 9:04 ` Gonglei (Arei)
@ 2013-08-17 9:04 ` Gonglei (Arei)
5 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-08-17 9:04 UTC (permalink / raw)
To: Gonglei (Arei), Pasi Kärkkäinen, vgabios-developers
Cc: ggrebus, bguthro, Hanweidong, Ian.Jackson, Yanqiangjun,
Luonengjun, qemu-devel, xen-devel, Yangxiaowei, Gerd Hoffmann,
Anthony Liguori, keir.fraser, Andreas Färber,
Huangweidong (Hardware)
Hi,
The fundamental reason is traditional qemu-dm and upstream qemu using a different vgabios-cirrus.bin,
qemu-dm is using xen-4.1.2/tools/firmware/vgabios/ VGABIOS-lgpl-latest.cirrus.bin,
but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
the pivotal patch is :
# HG changeset patch
# User Keir Fraser <keir@xensource.com>
# Date 1193391667 -3600
# Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
# Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
Signed-off-by: Ben Guthro <bguthro@virtualron.com>
Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c
--- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100
+++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100
@@ -1489,14 +1489,26 @@
mov dx, #0x3ce
out dx, ax
push ax
- mov cx, #0xa000
- mov es, cx
- xor di, di
+
+;; Windows Vista appears to be emulating this sequence as part of changing
+;; screen resolution, but it generates 4096 writes per iteration.
+;; Instead, use a magic register sequence to write the whole bank.
+;;mov cx, #0xa000
+;;mov es, cx
+;;xor di, di
+;;mov ax, si
+;;mov cx, #8192
+;;cld
+;;rep
+;; stosw
mov ax, si
- mov cx, #8192
- cld
- rep
- stosw
+ shl ax, #8
+ mov al, #0xfe
+ out dx, ax ;; Low byte of value to be written to the bank
+ mov ax, si
+ mov al, #0xff
+ out dx, ax ;; High byte and trigger the write
+
pop ax
inc ah
cmp ah, bl
diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c
--- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100
+++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100
@@ -294,6 +294,7 @@
static void cirrus_bitblt_reset(CirrusVGAState *s);
static void cirrus_update_memory_access(CirrusVGAState *s);
+static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val);
/***************************************
*
@@ -1497,6 +1498,17 @@
case 0x31: // BLT STATUS/START
cirrus_write_bitblt(s, reg_value);
break;
+
+ // Extension to allow BIOS to clear 16K VRAM bank in one operation
+ case 0xFE:
+ s->gr[reg_index] = reg_value; // Lower byte of value to be written
+ break;
+ case 0xFF: {
+ target_phys_addr_t addr;
+ for (addr = 0xa0000; addr < 0xa4000; addr += 2)
+ cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
+ }
+ break;
default:
#ifdef DEBUG_CIRRUS
printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,
By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
And I test the latest vgabios-0.7a come from
http://www.nongnu.org/vgabios/#DOWNLOAD
but the problem of blank screen remain.
Best Regards!
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Friday, August 16, 2013 5:10 PM
> To: Gonglei (Arei); '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';
> Yanqiangjun; Yangxiaowei
> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
> Hi, all
> I compared the traditional qemu-dm and upstream qemu,
> and I found the upstream qemu will create the expansion ROM at f3000000,
> but qemu-dm don't.
> the details as below (by "lspci -vnnn"):
>
> 1) traditional qemu-dm:
> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
> (prog-if 00 [VGA controller])
> Subsystem: XenSource, Inc. Device [5853:0001]
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f0000000 (32-bit, prefetchable) [size=32M]
> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> Kernel modules: cirrusfb
>
> 2) upstream qemu:
> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
> (prog-if 00 [VGA controller])
> Subsystem: XenSource, Inc. Device [5853:0001]
> Physical Slot: 2
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f0000000 (32-bit, prefetchable) [size=32M]
> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> Expansion ROM at f3000000 [disabled] [size=64K]
> Kernel modules: cirrusfb
>
> I tried to simply delete the expansion ROM at function pci_add_option_rom,
> such as
>
> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>
> but the VNC viewer only can see black screen, but RDP works well.
> Any ideas about the cirrus's expansion ROM?
> Slow screen refresh has any relationship with cirrus's expansion ROM?
> Thank you in advance!
>
> BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
> static int stdvga_intercept_mmio(ioreq_t *p)
> {
> struct domain *d = current->domain;
> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
> int buf = 0, rc;
> static int count_1 = 0;
> static int count_2 = 0;
>
> if ( p->size > 8 )
> {
> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
> return X86EMUL_UNHANDLEABLE;
> }
>
> spin_lock(&s->lock);
>
> if ( s->stdvga && s->cache )
> {
> switch ( p->type )
> {
> case IOREQ_TYPE_COPY:
> buf = mmio_move(s, p);
> count_1++;
> if (count_1 % 1000 == 0)
> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
> count_1=%d\n", count_1);
> if ( !buf )
> s->cache = 0;
> break;
> default:
> gdprintk(XENLOG_WARNING, "unsupported mmio request
> type:%d "
> "addr:0x%04x data:0x%04x size:%d count:%d
> state:%d "
> "isptr:%d dir:%d df:%d\n",
> p->type, (int)p->addr, (int)p->data, (int)p->size,
> (int)p->count, p->state,
> p->data_is_ptr, p->dir, p->df);
> s->cache = 0;
> }
> }
> else
> {
> buf = (p->dir == IOREQ_WRITE);
> count_2++;
> if (count_2 % 5000 == 0)
> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
> count_2);
> }
>
> rc = (buf && hvm_buffered_io_send(p));
>
> spin_unlock(&s->lock);
>
> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
> }
>
> and I got the below result with upstream qemu and tranditional qemu-dm:
>
> 1) traditional qemu-dm:
> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
> (XEN) stdvga.c:156:d2 leaving stdvga
>
> 2) upstream qemu:
> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
> (XEN) stdvga.c:156:d1 leaving stdvga
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
> ... ... //Omit some similar
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>
> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
> than traditional qemu-dm.
>
> Best Regards!
>
> -Gonglei
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-17 9:04 ` Gonglei (Arei)
2013-08-20 19:45 ` [Qemu-devel] " Konrad Rzeszutek Wilk
@ 2013-08-20 19:45 ` Konrad Rzeszutek Wilk
2013-08-21 0:02 ` [Qemu-devel] " Ben Guthro
1 sibling, 1 reply; 49+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-08-20 19:45 UTC (permalink / raw)
To: Gonglei (Arei), benjamin.guthro
Cc: ggrebus, Yangxiaowei, Hanweidong, vgabios-developers,
Yanqiangjun, Ian.Jackson, qemu-devel, Pasi Kärkkäinen,
xen-devel, bguthro, Gerd Hoffmann, Anthony Liguori, Luonengjun,
keir.fraser, Andreas Färber, Huangweidong (Hardware)
On Sat, Aug 17, 2013 at 09:04:29AM +0000, Gonglei (Arei) wrote:
> Hi,
> The fundamental reason is traditional qemu-dm and upstream qemu using a different vgabios-cirrus.bin,
> qemu-dm is using xen-4.1.2/tools/firmware/vgabios/ VGABIOS-lgpl-latest.cirrus.bin,
> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
>
> the pivotal patch is :
>
> # HG changeset patch
> # User Keir Fraser <keir@xensource.com>
> # Date 1193391667 -3600
> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
>
> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
>
> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
>
> diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c
> --- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100
> +++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100
> @@ -1489,14 +1489,26 @@
> mov dx, #0x3ce
> out dx, ax
> push ax
> - mov cx, #0xa000
> - mov es, cx
> - xor di, di
> +
> +;; Windows Vista appears to be emulating this sequence as part of changing
> +;; screen resolution, but it generates 4096 writes per iteration.
> +;; Instead, use a magic register sequence to write the whole bank.
> +;;mov cx, #0xa000
> +;;mov es, cx
> +;;xor di, di
> +;;mov ax, si
> +;;mov cx, #8192
> +;;cld
> +;;rep
> +;; stosw
> mov ax, si
> - mov cx, #8192
> - cld
> - rep
> - stosw
> + shl ax, #8
> + mov al, #0xfe
> + out dx, ax ;; Low byte of value to be written to the bank
> + mov ax, si
> + mov al, #0xff
> + out dx, ax ;; High byte and trigger the write
> +
> pop ax
> inc ah
> cmp ah, bl
> diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c
> --- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100
> +++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100
> @@ -294,6 +294,7 @@
>
> static void cirrus_bitblt_reset(CirrusVGAState *s);
> static void cirrus_update_memory_access(CirrusVGAState *s);
> +static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val);
>
> /***************************************
> *
> @@ -1497,6 +1498,17 @@
> case 0x31: // BLT STATUS/START
> cirrus_write_bitblt(s, reg_value);
> break;
> +
> + // Extension to allow BIOS to clear 16K VRAM bank in one operation
> + case 0xFE:
> + s->gr[reg_index] = reg_value; // Lower byte of value to be written
> + break;
> + case 0xFF: {
> + target_phys_addr_t addr;
> + for (addr = 0xa0000; addr < 0xa4000; addr += 2)
> + cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
> + }
> + break;
> default:
> #ifdef DEBUG_CIRRUS
> printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,
>
> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
>
> And I test the latest vgabios-0.7a come from
> http://www.nongnu.org/vgabios/#DOWNLOAD
> but the problem of blank screen remain.
>
> Best Regards!
> -Gonglei
>
>
> > -----Original Message-----
> > From: Gonglei (Arei)
> > Sent: Friday, August 16, 2013 5:10 PM
> > To: Gonglei (Arei); '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';
> > Yanqiangjun; Yangxiaowei
> > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > blank screen last 13s or so for windows XP guest
> >
> > Hi, all
> > I compared the traditional qemu-dm and upstream qemu,
> > and I found the upstream qemu will create the expansion ROM at f3000000,
> > but qemu-dm don't.
> > the details as below (by "lspci -vnnn"):
> >
> > 1) traditional qemu-dm:
> > 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
> > (prog-if 00 [VGA controller])
> > Subsystem: XenSource, Inc. Device [5853:0001]
> > Flags: bus master, fast devsel, latency 0, IRQ 11
> > Memory at f0000000 (32-bit, prefetchable) [size=32M]
> > Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> > Kernel modules: cirrusfb
> >
> > 2) upstream qemu:
> > 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
> > (prog-if 00 [VGA controller])
> > Subsystem: XenSource, Inc. Device [5853:0001]
> > Physical Slot: 2
> > Flags: bus master, fast devsel, latency 0, IRQ 11
> > Memory at f0000000 (32-bit, prefetchable) [size=32M]
> > Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> > Expansion ROM at f3000000 [disabled] [size=64K]
> > Kernel modules: cirrusfb
> >
> > I tried to simply delete the expansion ROM at function pci_add_option_rom,
> > such as
> >
> > //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
> >
> > but the VNC viewer only can see black screen, but RDP works well.
> > Any ideas about the cirrus's expansion ROM?
> > Slow screen refresh has any relationship with cirrus's expansion ROM?
> > Thank you in advance!
> >
> > BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
> > static int stdvga_intercept_mmio(ioreq_t *p)
> > {
> > struct domain *d = current->domain;
> > struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
> > int buf = 0, rc;
> > static int count_1 = 0;
> > static int count_2 = 0;
> >
> > if ( p->size > 8 )
> > {
> > gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
> > return X86EMUL_UNHANDLEABLE;
> > }
> >
> > spin_lock(&s->lock);
> >
> > if ( s->stdvga && s->cache )
> > {
> > switch ( p->type )
> > {
> > case IOREQ_TYPE_COPY:
> > buf = mmio_move(s, p);
> > count_1++;
> > if (count_1 % 1000 == 0)
> > gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
> > count_1=%d\n", count_1);
> > if ( !buf )
> > s->cache = 0;
> > break;
> > default:
> > gdprintk(XENLOG_WARNING, "unsupported mmio request
> > type:%d "
> > "addr:0x%04x data:0x%04x size:%d count:%d
> > state:%d "
> > "isptr:%d dir:%d df:%d\n",
> > p->type, (int)p->addr, (int)p->data, (int)p->size,
> > (int)p->count, p->state,
> > p->data_is_ptr, p->dir, p->df);
> > s->cache = 0;
> > }
> > }
> > else
> > {
> > buf = (p->dir == IOREQ_WRITE);
> > count_2++;
> > if (count_2 % 5000 == 0)
> > gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
> > count_2);
> > }
> >
> > rc = (buf && hvm_buffered_io_send(p));
> >
> > spin_unlock(&s->lock);
> >
> > return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
> > }
> >
> > and I got the below result with upstream qemu and tranditional qemu-dm:
> >
> > 1) traditional qemu-dm:
> > (XEN) stdvga.c:152:d2 entering stdvga and caching modes
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
> > (XEN) stdvga.c:156:d2 leaving stdvga
> >
> > 2) upstream qemu:
> > (XEN) stdvga.c:152:d1 entering stdvga and caching modes
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
> > (XEN) stdvga.c:156:d1 leaving stdvga
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
> > ... ... //Omit some similar
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
> >
> > Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
> > than traditional qemu-dm.
> >
> > Best Regards!
> >
> > -Gonglei
> >
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-17 9:04 ` Gonglei (Arei)
@ 2013-08-20 19:45 ` Konrad Rzeszutek Wilk
2013-08-20 19:45 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
1 sibling, 0 replies; 49+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-08-20 19:45 UTC (permalink / raw)
To: Gonglei (Arei), benjamin.guthro
Cc: ggrebus, Yangxiaowei, Hanweidong, vgabios-developers,
Yanqiangjun, Ian.Jackson, qemu-devel, xen-devel, bguthro,
Gerd Hoffmann, Anthony Liguori, Luonengjun, keir.fraser,
Andreas Färber, Huangweidong (Hardware)
On Sat, Aug 17, 2013 at 09:04:29AM +0000, Gonglei (Arei) wrote:
> Hi,
> The fundamental reason is traditional qemu-dm and upstream qemu using a different vgabios-cirrus.bin,
> qemu-dm is using xen-4.1.2/tools/firmware/vgabios/ VGABIOS-lgpl-latest.cirrus.bin,
> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
>
> the pivotal patch is :
>
> # HG changeset patch
> # User Keir Fraser <keir@xensource.com>
> # Date 1193391667 -3600
> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
>
> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
>
> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
>
> diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c
> --- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100
> +++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100
> @@ -1489,14 +1489,26 @@
> mov dx, #0x3ce
> out dx, ax
> push ax
> - mov cx, #0xa000
> - mov es, cx
> - xor di, di
> +
> +;; Windows Vista appears to be emulating this sequence as part of changing
> +;; screen resolution, but it generates 4096 writes per iteration.
> +;; Instead, use a magic register sequence to write the whole bank.
> +;;mov cx, #0xa000
> +;;mov es, cx
> +;;xor di, di
> +;;mov ax, si
> +;;mov cx, #8192
> +;;cld
> +;;rep
> +;; stosw
> mov ax, si
> - mov cx, #8192
> - cld
> - rep
> - stosw
> + shl ax, #8
> + mov al, #0xfe
> + out dx, ax ;; Low byte of value to be written to the bank
> + mov ax, si
> + mov al, #0xff
> + out dx, ax ;; High byte and trigger the write
> +
> pop ax
> inc ah
> cmp ah, bl
> diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c
> --- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100
> +++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100
> @@ -294,6 +294,7 @@
>
> static void cirrus_bitblt_reset(CirrusVGAState *s);
> static void cirrus_update_memory_access(CirrusVGAState *s);
> +static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val);
>
> /***************************************
> *
> @@ -1497,6 +1498,17 @@
> case 0x31: // BLT STATUS/START
> cirrus_write_bitblt(s, reg_value);
> break;
> +
> + // Extension to allow BIOS to clear 16K VRAM bank in one operation
> + case 0xFE:
> + s->gr[reg_index] = reg_value; // Lower byte of value to be written
> + break;
> + case 0xFF: {
> + target_phys_addr_t addr;
> + for (addr = 0xa0000; addr < 0xa4000; addr += 2)
> + cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
> + }
> + break;
> default:
> #ifdef DEBUG_CIRRUS
> printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,
>
> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
>
> And I test the latest vgabios-0.7a come from
> http://www.nongnu.org/vgabios/#DOWNLOAD
> but the problem of blank screen remain.
>
> Best Regards!
> -Gonglei
>
>
> > -----Original Message-----
> > From: Gonglei (Arei)
> > Sent: Friday, August 16, 2013 5:10 PM
> > To: Gonglei (Arei); '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';
> > Yanqiangjun; Yangxiaowei
> > Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> > blank screen last 13s or so for windows XP guest
> >
> > Hi, all
> > I compared the traditional qemu-dm and upstream qemu,
> > and I found the upstream qemu will create the expansion ROM at f3000000,
> > but qemu-dm don't.
> > the details as below (by "lspci -vnnn"):
> >
> > 1) traditional qemu-dm:
> > 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
> > (prog-if 00 [VGA controller])
> > Subsystem: XenSource, Inc. Device [5853:0001]
> > Flags: bus master, fast devsel, latency 0, IRQ 11
> > Memory at f0000000 (32-bit, prefetchable) [size=32M]
> > Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> > Kernel modules: cirrusfb
> >
> > 2) upstream qemu:
> > 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
> > (prog-if 00 [VGA controller])
> > Subsystem: XenSource, Inc. Device [5853:0001]
> > Physical Slot: 2
> > Flags: bus master, fast devsel, latency 0, IRQ 11
> > Memory at f0000000 (32-bit, prefetchable) [size=32M]
> > Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> > Expansion ROM at f3000000 [disabled] [size=64K]
> > Kernel modules: cirrusfb
> >
> > I tried to simply delete the expansion ROM at function pci_add_option_rom,
> > such as
> >
> > //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
> >
> > but the VNC viewer only can see black screen, but RDP works well.
> > Any ideas about the cirrus's expansion ROM?
> > Slow screen refresh has any relationship with cirrus's expansion ROM?
> > Thank you in advance!
> >
> > BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
> > static int stdvga_intercept_mmio(ioreq_t *p)
> > {
> > struct domain *d = current->domain;
> > struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
> > int buf = 0, rc;
> > static int count_1 = 0;
> > static int count_2 = 0;
> >
> > if ( p->size > 8 )
> > {
> > gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
> > return X86EMUL_UNHANDLEABLE;
> > }
> >
> > spin_lock(&s->lock);
> >
> > if ( s->stdvga && s->cache )
> > {
> > switch ( p->type )
> > {
> > case IOREQ_TYPE_COPY:
> > buf = mmio_move(s, p);
> > count_1++;
> > if (count_1 % 1000 == 0)
> > gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
> > count_1=%d\n", count_1);
> > if ( !buf )
> > s->cache = 0;
> > break;
> > default:
> > gdprintk(XENLOG_WARNING, "unsupported mmio request
> > type:%d "
> > "addr:0x%04x data:0x%04x size:%d count:%d
> > state:%d "
> > "isptr:%d dir:%d df:%d\n",
> > p->type, (int)p->addr, (int)p->data, (int)p->size,
> > (int)p->count, p->state,
> > p->data_is_ptr, p->dir, p->df);
> > s->cache = 0;
> > }
> > }
> > else
> > {
> > buf = (p->dir == IOREQ_WRITE);
> > count_2++;
> > if (count_2 % 5000 == 0)
> > gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
> > count_2);
> > }
> >
> > rc = (buf && hvm_buffered_io_send(p));
> >
> > spin_unlock(&s->lock);
> >
> > return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
> > }
> >
> > and I got the below result with upstream qemu and tranditional qemu-dm:
> >
> > 1) traditional qemu-dm:
> > (XEN) stdvga.c:152:d2 entering stdvga and caching modes
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
> > (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
> > (XEN) stdvga.c:156:d2 leaving stdvga
> >
> > 2) upstream qemu:
> > (XEN) stdvga.c:152:d1 entering stdvga and caching modes
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
> > (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
> > (XEN) stdvga.c:156:d1 leaving stdvga
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
> > ... ... //Omit some similar
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
> > (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
> >
> > Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
> > than traditional qemu-dm.
> >
> > Best Regards!
> >
> > -Gonglei
> >
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-20 19:45 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
@ 2013-08-21 0:02 ` Ben Guthro
0 siblings, 0 replies; 49+ messages in thread
From: Ben Guthro @ 2013-08-21 0:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: ggrebus, Yangxiaowei, Hanweidong, vgabios-developers,
Yanqiangjun, Ian Jackson, qemu-devel, Pasi Kärkkäinen,
Ben Guthro, bguthro, Gonglei (Arei),
Gerd Hoffmann, Anthony Liguori, Luonengjun, keir.fraser,
xen-devel, Andreas Färber, Huangweidong (Hardware)
On Aug 20, 2013, at 3:45 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
wrote:
> On Sat, Aug 17, 2013 at 09:04:29AM +0000, Gonglei (Arei) wrote:
>> Hi,
>> The fundamental reason is traditional qemu-dm and upstream qemu using a different vgabios-cirrus.bin,
>> qemu-dm is using xen-4.1.2/tools/firmware/vgabios/ VGABIOS-lgpl-latest.cirrus.bin,
>> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
>>
>> the pivotal patch is :
>>
>> # HG changeset patch
>> # User Keir Fraser <keir@xensource.com>
>> # Date 1193391667 -3600
>> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
>> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
>>
>> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
>>
>> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
>> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
>
> Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
FWIW, I took Gary's patch, and made it apply to unstable, at that time.
He was the primary developer, in that case.
That's how I recall it, anyhow...from 6 years ago.
I don't have Gary's new contact info.
Regards,
Ben
>
>>
>> diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c
>> --- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100
>> +++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100
>> @@ -1489,14 +1489,26 @@
>> mov dx, #0x3ce
>> out dx, ax
>> push ax
>> - mov cx, #0xa000
>> - mov es, cx
>> - xor di, di
>> +
>> +;; Windows Vista appears to be emulating this sequence as part of changing
>> +;; screen resolution, but it generates 4096 writes per iteration.
>> +;; Instead, use a magic register sequence to write the whole bank.
>> +;;mov cx, #0xa000
>> +;;mov es, cx
>> +;;xor di, di
>> +;;mov ax, si
>> +;;mov cx, #8192
>> +;;cld
>> +;;rep
>> +;; stosw
>> mov ax, si
>> - mov cx, #8192
>> - cld
>> - rep
>> - stosw
>> + shl ax, #8
>> + mov al, #0xfe
>> + out dx, ax ;; Low byte of value to be written to the bank
>> + mov ax, si
>> + mov al, #0xff
>> + out dx, ax ;; High byte and trigger the write
>> +
>> pop ax
>> inc ah
>> cmp ah, bl
>> diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c
>> --- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100
>> +++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100
>> @@ -294,6 +294,7 @@
>>
>> static void cirrus_bitblt_reset(CirrusVGAState *s);
>> static void cirrus_update_memory_access(CirrusVGAState *s);
>> +static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val);
>>
>> /***************************************
>> *
>> @@ -1497,6 +1498,17 @@
>> case 0x31: // BLT STATUS/START
>> cirrus_write_bitblt(s, reg_value);
>> break;
>> +
>> + // Extension to allow BIOS to clear 16K VRAM bank in one operation
>> + case 0xFE:
>> + s->gr[reg_index] = reg_value; // Lower byte of value to be written
>> + break;
>> + case 0xFF: {
>> + target_phys_addr_t addr;
>> + for (addr = 0xa0000; addr < 0xa4000; addr += 2)
>> + cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
>> + }
>> + break;
>> default:
>> #ifdef DEBUG_CIRRUS
>> printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,
>>
>> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
>>
>> And I test the latest vgabios-0.7a come from
>> http://www.nongnu.org/vgabios/#DOWNLOAD
>> but the problem of blank screen remain.
>>
>> Best Regards!
>> -Gonglei
>>
>>
>>> -----Original Message-----
>>> From: Gonglei (Arei)
>>> Sent: Friday, August 16, 2013 5:10 PM
>>> To: Gonglei (Arei); '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';
>>> Yanqiangjun; Yangxiaowei
>>> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
>>> blank screen last 13s or so for windows XP guest
>>>
>>> Hi, all
>>> I compared the traditional qemu-dm and upstream qemu,
>>> and I found the upstream qemu will create the expansion ROM at f3000000,
>>> but qemu-dm don't.
>>> the details as below (by "lspci -vnnn"):
>>>
>>> 1) traditional qemu-dm:
>>> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: XenSource, Inc. Device [5853:0001]
>>> Flags: bus master, fast devsel, latency 0, IRQ 11
>>> Memory at f0000000 (32-bit, prefetchable) [size=32M]
>>> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>>> Kernel modules: cirrusfb
>>>
>>> 2) upstream qemu:
>>> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: XenSource, Inc. Device [5853:0001]
>>> Physical Slot: 2
>>> Flags: bus master, fast devsel, latency 0, IRQ 11
>>> Memory at f0000000 (32-bit, prefetchable) [size=32M]
>>> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
>>> Expansion ROM at f3000000 [disabled] [size=64K]
>>> Kernel modules: cirrusfb
>>>
>>> I tried to simply delete the expansion ROM at function pci_add_option_rom,
>>> such as
>>>
>>> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>>>
>>> but the VNC viewer only can see black screen, but RDP works well.
>>> Any ideas about the cirrus's expansion ROM?
>>> Slow screen refresh has any relationship with cirrus's expansion ROM?
>>> Thank you in advance!
>>>
>>> BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
>>> static int stdvga_intercept_mmio(ioreq_t *p)
>>> {
>>> struct domain *d = current->domain;
>>> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
>>> int buf = 0, rc;
>>> static int count_1 = 0;
>>> static int count_2 = 0;
>>>
>>> if ( p->size > 8 )
>>> {
>>> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> spin_lock(&s->lock);
>>>
>>> if ( s->stdvga && s->cache )
>>> {
>>> switch ( p->type )
>>> {
>>> case IOREQ_TYPE_COPY:
>>> buf = mmio_move(s, p);
>>> count_1++;
>>> if (count_1 % 1000 == 0)
>>> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
>>> count_1=%d\n", count_1);
>>> if ( !buf )
>>> s->cache = 0;
>>> break;
>>> default:
>>> gdprintk(XENLOG_WARNING, "unsupported mmio request
>>> type:%d "
>>> "addr:0x%04x data:0x%04x size:%d count:%d
>>> state:%d "
>>> "isptr:%d dir:%d df:%d\n",
>>> p->type, (int)p->addr, (int)p->data, (int)p->size,
>>> (int)p->count, p->state,
>>> p->data_is_ptr, p->dir, p->df);
>>> s->cache = 0;
>>> }
>>> }
>>> else
>>> {
>>> buf = (p->dir == IOREQ_WRITE);
>>> count_2++;
>>> if (count_2 % 5000 == 0)
>>> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
>>> count_2);
>>> }
>>>
>>> rc = (buf && hvm_buffered_io_send(p));
>>>
>>> spin_unlock(&s->lock);
>>>
>>> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> and I got the below result with upstream qemu and tranditional qemu-dm:
>>>
>>> 1) traditional qemu-dm:
>>> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
>>> (XEN) stdvga.c:156:d2 leaving stdvga
>>>
>>> 2) upstream qemu:
>>> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
>>> (XEN) stdvga.c:156:d1 leaving stdvga
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
>>> ... ... //Omit some similar
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>>>
>>> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
>>> than traditional qemu-dm.
>>>
>>> Best Regards!
>>>
>>> -Gonglei
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
@ 2013-08-21 0:02 ` Ben Guthro
0 siblings, 0 replies; 49+ messages in thread
From: Ben Guthro @ 2013-08-21 0:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: ggrebus, Yangxiaowei, Hanweidong, vgabios-developers,
Yanqiangjun, Ian Jackson, qemu-devel, Ben Guthro, bguthro,
Gonglei (Arei),
Gerd Hoffmann, Anthony Liguori, Luonengjun, keir.fraser,
xen-devel, Andreas Färber, Huangweidong (Hardware)
On Aug 20, 2013, at 3:45 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
wrote:
> On Sat, Aug 17, 2013 at 09:04:29AM +0000, Gonglei (Arei) wrote:
>> Hi,
>> The fundamental reason is traditional qemu-dm and upstream qemu using a different vgabios-cirrus.bin,
>> qemu-dm is using xen-4.1.2/tools/firmware/vgabios/ VGABIOS-lgpl-latest.cirrus.bin,
>> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
>>
>> the pivotal patch is :
>>
>> # HG changeset patch
>> # User Keir Fraser <keir@xensource.com>
>> # Date 1193391667 -3600
>> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
>> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
>>
>> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO writes.
>>
>> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
>> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
>
> Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
FWIW, I took Gary's patch, and made it apply to unstable, at that time.
He was the primary developer, in that case.
That's how I recall it, anyhow...from 6 years ago.
I don't have Gary's new contact info.
Regards,
Ben
>
>>
>> diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c
>> --- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100
>> +++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100
>> @@ -1489,14 +1489,26 @@
>> mov dx, #0x3ce
>> out dx, ax
>> push ax
>> - mov cx, #0xa000
>> - mov es, cx
>> - xor di, di
>> +
>> +;; Windows Vista appears to be emulating this sequence as part of changing
>> +;; screen resolution, but it generates 4096 writes per iteration.
>> +;; Instead, use a magic register sequence to write the whole bank.
>> +;;mov cx, #0xa000
>> +;;mov es, cx
>> +;;xor di, di
>> +;;mov ax, si
>> +;;mov cx, #8192
>> +;;cld
>> +;;rep
>> +;; stosw
>> mov ax, si
>> - mov cx, #8192
>> - cld
>> - rep
>> - stosw
>> + shl ax, #8
>> + mov al, #0xfe
>> + out dx, ax ;; Low byte of value to be written to the bank
>> + mov ax, si
>> + mov al, #0xff
>> + out dx, ax ;; High byte and trigger the write
>> +
>> pop ax
>> inc ah
>> cmp ah, bl
>> diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c
>> --- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100
>> +++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100
>> @@ -294,6 +294,7 @@
>>
>> static void cirrus_bitblt_reset(CirrusVGAState *s);
>> static void cirrus_update_memory_access(CirrusVGAState *s);
>> +static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val);
>>
>> /***************************************
>> *
>> @@ -1497,6 +1498,17 @@
>> case 0x31: // BLT STATUS/START
>> cirrus_write_bitblt(s, reg_value);
>> break;
>> +
>> + // Extension to allow BIOS to clear 16K VRAM bank in one operation
>> + case 0xFE:
>> + s->gr[reg_index] = reg_value; // Lower byte of value to be written
>> + break;
>> + case 0xFF: {
>> + target_phys_addr_t addr;
>> + for (addr = 0xa0000; addr < 0xa4000; addr += 2)
>> + cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
>> + }
>> + break;
>> default:
>> #ifdef DEBUG_CIRRUS
>> printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,
>>
>> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is fast with upstream qemu.
>>
>> And I test the latest vgabios-0.7a come from
>> http://www.nongnu.org/vgabios/#DOWNLOAD
>> but the problem of blank screen remain.
>>
>> Best Regards!
>> -Gonglei
>>
>>
>>> -----Original Message-----
>>> From: Gonglei (Arei)
>>> Sent: Friday, August 16, 2013 5:10 PM
>>> To: Gonglei (Arei); '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';
>>> Yanqiangjun; Yangxiaowei
>>> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
>>> blank screen last 13s or so for windows XP guest
>>>
>>> Hi, all
>>> I compared the traditional qemu-dm and upstream qemu,
>>> and I found the upstream qemu will create the expansion ROM at f3000000,
>>> but qemu-dm don't.
>>> the details as below (by "lspci -vnnn"):
>>>
>>> 1) traditional qemu-dm:
>>> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: XenSource, Inc. Device [5853:0001]
>>> Flags: bus master, fast devsel, latency 0, IRQ 11
>>> Memory at f0000000 (32-bit, prefetchable) [size=32M]
>>> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>>> Kernel modules: cirrusfb
>>>
>>> 2) upstream qemu:
>>> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: XenSource, Inc. Device [5853:0001]
>>> Physical Slot: 2
>>> Flags: bus master, fast devsel, latency 0, IRQ 11
>>> Memory at f0000000 (32-bit, prefetchable) [size=32M]
>>> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
>>> Expansion ROM at f3000000 [disabled] [size=64K]
>>> Kernel modules: cirrusfb
>>>
>>> I tried to simply delete the expansion ROM at function pci_add_option_rom,
>>> such as
>>>
>>> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>>>
>>> but the VNC viewer only can see black screen, but RDP works well.
>>> Any ideas about the cirrus's expansion ROM?
>>> Slow screen refresh has any relationship with cirrus's expansion ROM?
>>> Thank you in advance!
>>>
>>> BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
>>> static int stdvga_intercept_mmio(ioreq_t *p)
>>> {
>>> struct domain *d = current->domain;
>>> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
>>> int buf = 0, rc;
>>> static int count_1 = 0;
>>> static int count_2 = 0;
>>>
>>> if ( p->size > 8 )
>>> {
>>> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> spin_lock(&s->lock);
>>>
>>> if ( s->stdvga && s->cache )
>>> {
>>> switch ( p->type )
>>> {
>>> case IOREQ_TYPE_COPY:
>>> buf = mmio_move(s, p);
>>> count_1++;
>>> if (count_1 % 1000 == 0)
>>> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
>>> count_1=%d\n", count_1);
>>> if ( !buf )
>>> s->cache = 0;
>>> break;
>>> default:
>>> gdprintk(XENLOG_WARNING, "unsupported mmio request
>>> type:%d "
>>> "addr:0x%04x data:0x%04x size:%d count:%d
>>> state:%d "
>>> "isptr:%d dir:%d df:%d\n",
>>> p->type, (int)p->addr, (int)p->data, (int)p->size,
>>> (int)p->count, p->state,
>>> p->data_is_ptr, p->dir, p->df);
>>> s->cache = 0;
>>> }
>>> }
>>> else
>>> {
>>> buf = (p->dir == IOREQ_WRITE);
>>> count_2++;
>>> if (count_2 % 5000 == 0)
>>> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
>>> count_2);
>>> }
>>>
>>> rc = (buf && hvm_buffered_io_send(p));
>>>
>>> spin_unlock(&s->lock);
>>>
>>> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> and I got the below result with upstream qemu and tranditional qemu-dm:
>>>
>>> 1) traditional qemu-dm:
>>> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
>>> (XEN) stdvga.c:156:d2 leaving stdvga
>>>
>>> 2) upstream qemu:
>>> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
>>> (XEN) stdvga.c:156:d1 leaving stdvga
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
>>> ... ... //Omit some similar
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>>>
>>> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
>>> than traditional qemu-dm.
>>>
>>> Best Regards!
>>>
>>> -Gonglei
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] [Xen-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
2013-08-21 0:02 ` [Qemu-devel] " Ben Guthro
@ 2013-08-27 15:08 ` Gonglei (Arei)
-1 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-08-27 15:08 UTC (permalink / raw)
To: Ben Guthro, Konrad Rzeszutek Wilk
Cc: ggrebus, Yangxiaowei, seabios, Hanweidong, vgabios-developers,
Yanqiangjun, Ian Jackson, qemu-devel, Pasi Kärkkäinen,
xen-devel, bguthro, kevin, Gerd Hoffmann, Anthony Liguori,
Luonengjun, keir.fraser, Andreas Färber,
Huangweidong (Hardware)
[-- Attachment #1: Type: text/plain, Size: 11727 bytes --]
Hi all.
I got another trouble after I using that patch, which windows 2003 32bit guest VNC display wasn't normal,
please see the attached. In addition, windows 2003 64bit guest had a normal display.
I couldn't understand it, anyone can help me? Thanks you in advance.
The patch is:
http://xen.1045712.n5.nabble.com/PATCH-QEMU-Clear-bios-framebuffer-with-minimal-writes-td2511735.html
Best Regards,
-Gonglei
> -----Original Message-----
> Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
>
> On Aug 20, 2013, at 3:45 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>
> wrote:
>
> > On Sat, Aug 17, 2013 at 09:04:29AM +0000, Gonglei (Arei) wrote:
> >> Hi,
> >> The fundamental reason is traditional qemu-dm and upstream qemu using a
> different vgabios-cirrus.bin,
> >> qemu-dm is using xen-4.1.2/tools/firmware/vgabios/
> VGABIOS-lgpl-latest.cirrus.bin,
> >> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
> >>
> >> the pivotal patch is :
> >>
> >> # HG changeset patch
> >> # User Keir Fraser <keir@xensource.com>
> >> # Date 1193391667 -3600
> >> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
> >> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
> >>
> >> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO
> writes.
> >>
> >> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
> >> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
> >
> > Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
>
> FWIW, I took Gary's patch, and made it apply to unstable, at that time.
> He was the primary developer, in that case.
>
> That's how I recall it, anyhow...from 6 years ago.
>
> I don't have Gary's new contact info.
>
> Regards,
> Ben
>
> >
> >>
> >> diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c
> >> --- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100
> >> +++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100
> >> @@ -1489,14 +1489,26 @@
> >> mov dx, #0x3ce
> >> out dx, ax
> >> push ax
> >> - mov cx, #0xa000
> >> - mov es, cx
> >> - xor di, di
> >> +
> >> +;; Windows Vista appears to be emulating this sequence as part of
> changing
> >> +;; screen resolution, but it generates 4096 writes per iteration.
> >> +;; Instead, use a magic register sequence to write the whole bank.
> >> +;;mov cx, #0xa000
> >> +;;mov es, cx
> >> +;;xor di, di
> >> +;;mov ax, si
> >> +;;mov cx, #8192
> >> +;;cld
> >> +;;rep
> >> +;; stosw
> >> mov ax, si
> >> - mov cx, #8192
> >> - cld
> >> - rep
> >> - stosw
> >> + shl ax, #8
> >> + mov al, #0xfe
> >> + out dx, ax ;; Low byte of value to be written to the bank
> >> + mov ax, si
> >> + mov al, #0xff
> >> + out dx, ax ;; High byte and trigger the write
> >> +
> >> pop ax
> >> inc ah
> >> cmp ah, bl
> >> diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c
> >> --- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100
> >> +++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100
> >> @@ -294,6 +294,7 @@
> >>
> >> static void cirrus_bitblt_reset(CirrusVGAState *s);
> >> static void cirrus_update_memory_access(CirrusVGAState *s);
> >> +static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t
> addr, uint32_t val);
> >>
> >> /***************************************
> >> *
> >> @@ -1497,6 +1498,17 @@
> >> case 0x31: // BLT STATUS/START
> >> cirrus_write_bitblt(s, reg_value);
> >> break;
> >> +
> >> + // Extension to allow BIOS to clear 16K VRAM bank in one operation
> >> + case 0xFE:
> >> + s->gr[reg_index] = reg_value; // Lower byte of value to be written
> >> + break;
> >> + case 0xFF: {
> >> + target_phys_addr_t addr;
> >> + for (addr = 0xa0000; addr < 0xa4000; addr += 2)
> >> + cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
> >> + }
> >> + break;
> >> default:
> >> #ifdef DEBUG_CIRRUS
> >> printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,
> >>
> >> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is
> fast with upstream qemu.
> >>
> >> And I test the latest vgabios-0.7a come from
> >> http://www.nongnu.org/vgabios/#DOWNLOAD
> >> but the problem of blank screen remain.
> >>
>> Best Regards!
>> -Gonglei
>>
>>
>>> -----Original Message-----
>>> From: Gonglei (Arei)
>>> Sent: Friday, August 16, 2013 5:10 PM
>>> To: Gonglei (Arei); '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';
>>> Yanqiangjun; Yangxiaowei
>>> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
>>> blank screen last 13s or so for windows XP guest
>>>
>>> Hi, all
>>> I compared the traditional qemu-dm and upstream qemu,
>>> and I found the upstream qemu will create the expansion ROM at f3000000,
>>> but qemu-dm don't.
>>> the details as below (by "lspci -vnnn"):
>>>
>>> 1) traditional qemu-dm:
>>> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: XenSource, Inc. Device [5853:0001]
>>> Flags: bus master, fast devsel, latency 0, IRQ 11
>>> Memory at f0000000 (32-bit, prefetchable) [size=32M]
>>> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>>> Kernel modules: cirrusfb
>>>
>>> 2) upstream qemu:
>>> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: XenSource, Inc. Device [5853:0001]
>>> Physical Slot: 2
>>> Flags: bus master, fast devsel, latency 0, IRQ 11
>>> Memory at f0000000 (32-bit, prefetchable) [size=32M]
>>> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
>>> Expansion ROM at f3000000 [disabled] [size=64K]
>>> Kernel modules: cirrusfb
>>>
>>> I tried to simply delete the expansion ROM at function pci_add_option_rom,
>>> such as
>>>
>>> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>>>
>>> but the VNC viewer only can see black screen, but RDP works well.
>>> Any ideas about the cirrus's expansion ROM?
>>> Slow screen refresh has any relationship with cirrus's expansion ROM?
>>> Thank you in advance!
>>>
>>> BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
>>> static int stdvga_intercept_mmio(ioreq_t *p)
>>> {
>>> struct domain *d = current->domain;
>>> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
>>> int buf = 0, rc;
>>> static int count_1 = 0;
>>> static int count_2 = 0;
>>>
>>> if ( p->size > 8 )
>>> {
>>> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> spin_lock(&s->lock);
>>>
>>> if ( s->stdvga && s->cache )
>>> {
>>> switch ( p->type )
>>> {
>>> case IOREQ_TYPE_COPY:
>>> buf = mmio_move(s, p);
>>> count_1++;
>>> if (count_1 % 1000 == 0)
>>> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
>>> count_1=%d\n", count_1);
>>> if ( !buf )
>>> s->cache = 0;
>>> break;
>>> default:
>>> gdprintk(XENLOG_WARNING, "unsupported mmio request
>>> type:%d "
>>> "addr:0x%04x data:0x%04x size:%d count:%d
>>> state:%d "
>>> "isptr:%d dir:%d df:%d\n",
>>> p->type, (int)p->addr, (int)p->data, (int)p->size,
>>> (int)p->count, p->state,
>>> p->data_is_ptr, p->dir, p->df);
>>> s->cache = 0;
>>> }
>>> }
>>> else
>>> {
>>> buf = (p->dir == IOREQ_WRITE);
>>> count_2++;
>>> if (count_2 % 5000 == 0)
>>> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
>>> count_2);
>>> }
>>>
>>> rc = (buf && hvm_buffered_io_send(p));
>>>
>>> spin_unlock(&s->lock);
>>>
>>> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> and I got the below result with upstream qemu and tranditional qemu-dm:
>>>
>>> 1) traditional qemu-dm:
>>> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
>>> (XEN) stdvga.c:156:d2 leaving stdvga
>>>
>>> 2) upstream qemu:
>>> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
>>> (XEN) stdvga.c:156:d1 leaving stdvga
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
>>> ... ... //Omit some similar
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>>>
>>> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
>>> than traditional qemu-dm.
>>>
>>> Best Regards!
>>>
>>> -Gonglei
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
[-- Attachment #2: win2003.jpg --]
[-- Type: image/jpeg, Size: 143573 bytes --]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest
@ 2013-08-27 15:08 ` Gonglei (Arei)
0 siblings, 0 replies; 49+ messages in thread
From: Gonglei (Arei) @ 2013-08-27 15:08 UTC (permalink / raw)
To: Ben Guthro, Konrad Rzeszutek Wilk
Cc: ggrebus, Yangxiaowei, seabios, Hanweidong, vgabios-developers,
Yanqiangjun, Ian Jackson, qemu-devel, xen-devel, bguthro, kevin,
Gerd Hoffmann, Anthony Liguori, Luonengjun, keir.fraser,
Andreas Färber, Huangweidong (Hardware)
[-- Attachment #1: Type: text/plain, Size: 11727 bytes --]
Hi all.
I got another trouble after I using that patch, which windows 2003 32bit guest VNC display wasn't normal,
please see the attached. In addition, windows 2003 64bit guest had a normal display.
I couldn't understand it, anyone can help me? Thanks you in advance.
The patch is:
http://xen.1045712.n5.nabble.com/PATCH-QEMU-Clear-bios-framebuffer-with-minimal-writes-td2511735.html
Best Regards,
-Gonglei
> -----Original Message-----
> Subject: Re: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
> blank screen last 13s or so for windows XP guest
>
>
> On Aug 20, 2013, at 3:45 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>
> wrote:
>
> > On Sat, Aug 17, 2013 at 09:04:29AM +0000, Gonglei (Arei) wrote:
> >> Hi,
> >> The fundamental reason is traditional qemu-dm and upstream qemu using a
> different vgabios-cirrus.bin,
> >> qemu-dm is using xen-4.1.2/tools/firmware/vgabios/
> VGABIOS-lgpl-latest.cirrus.bin,
> >> but upstream qemu is using qemu-1.2.2/pc-bios/vgabios-cirrus.bin
> >>
> >> the pivotal patch is :
> >>
> >> # HG changeset patch
> >> # User Keir Fraser <keir@xensource.com>
> >> # Date 1193391667 -3600
> >> # Node ID d31f63db5f1e88deadc5461adda07b77c22873d7
> >> # Parent 413107fa49a50e5c61ac390dc1870d8995b2a012
> >>
> >> x86, hvm: Allow Cirrus VGA BIOS to clear framebuffer with minimal PIO
> writes.
> >>
> >> Signed-off-by: Ben Guthro <bguthro@virtualron.com>
> >> Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
> >
> > Ben's new address is <benjamin.guthro@citrix.com>. CC-ing him here.
>
> FWIW, I took Gary's patch, and made it apply to unstable, at that time.
> He was the primary developer, in that case.
>
> That's how I recall it, anyhow...from 6 years ago.
>
> I don't have Gary's new contact info.
>
> Regards,
> Ben
>
> >
> >>
> >> diff -r 413107fa49a5 -r d31f63db5f1e tools/firmware/vgabios/clext.c
> >> --- a/tools/firmware/vgabios/clext.c Fri Oct 26 10:33:12 2007 +0100
> >> +++ b/tools/firmware/vgabios/clext.c Fri Oct 26 10:41:07 2007 +0100
> >> @@ -1489,14 +1489,26 @@
> >> mov dx, #0x3ce
> >> out dx, ax
> >> push ax
> >> - mov cx, #0xa000
> >> - mov es, cx
> >> - xor di, di
> >> +
> >> +;; Windows Vista appears to be emulating this sequence as part of
> changing
> >> +;; screen resolution, but it generates 4096 writes per iteration.
> >> +;; Instead, use a magic register sequence to write the whole bank.
> >> +;;mov cx, #0xa000
> >> +;;mov es, cx
> >> +;;xor di, di
> >> +;;mov ax, si
> >> +;;mov cx, #8192
> >> +;;cld
> >> +;;rep
> >> +;; stosw
> >> mov ax, si
> >> - mov cx, #8192
> >> - cld
> >> - rep
> >> - stosw
> >> + shl ax, #8
> >> + mov al, #0xfe
> >> + out dx, ax ;; Low byte of value to be written to the bank
> >> + mov ax, si
> >> + mov al, #0xff
> >> + out dx, ax ;; High byte and trigger the write
> >> +
> >> pop ax
> >> inc ah
> >> cmp ah, bl
> >> diff -r 413107fa49a5 -r d31f63db5f1e tools/ioemu/hw/cirrus_vga.c
> >> --- a/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:33:12 2007 +0100
> >> +++ b/tools/ioemu/hw/cirrus_vga.c Fri Oct 26 10:41:07 2007 +0100
> >> @@ -294,6 +294,7 @@
> >>
> >> static void cirrus_bitblt_reset(CirrusVGAState *s);
> >> static void cirrus_update_memory_access(CirrusVGAState *s);
> >> +static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t
> addr, uint32_t val);
> >>
> >> /***************************************
> >> *
> >> @@ -1497,6 +1498,17 @@
> >> case 0x31: // BLT STATUS/START
> >> cirrus_write_bitblt(s, reg_value);
> >> break;
> >> +
> >> + // Extension to allow BIOS to clear 16K VRAM bank in one operation
> >> + case 0xFE:
> >> + s->gr[reg_index] = reg_value; // Lower byte of value to be written
> >> + break;
> >> + case 0xFF: {
> >> + target_phys_addr_t addr;
> >> + for (addr = 0xa0000; addr < 0xa4000; addr += 2)
> >> + cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
> >> + }
> >> + break;
> >> default:
> >> #ifdef DEBUG_CIRRUS
> >> printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,
> >>
> >> By replacing the vgabios-cirrus.bin, the windows XP guest screen updating is
> fast with upstream qemu.
> >>
> >> And I test the latest vgabios-0.7a come from
> >> http://www.nongnu.org/vgabios/#DOWNLOAD
> >> but the problem of blank screen remain.
> >>
>> Best Regards!
>> -Gonglei
>>
>>
>>> -----Original Message-----
>>> From: Gonglei (Arei)
>>> Sent: Friday, August 16, 2013 5:10 PM
>>> To: Gonglei (Arei); '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';
>>> Yanqiangjun; Yangxiaowei
>>> Subject: RE: [Xen-devel] [Qemu-devel] Cirrus VGA slow screen update, show
>>> blank screen last 13s or so for windows XP guest
>>>
>>> Hi, all
>>> I compared the traditional qemu-dm and upstream qemu,
>>> and I found the upstream qemu will create the expansion ROM at f3000000,
>>> but qemu-dm don't.
>>> the details as below (by "lspci -vnnn"):
>>>
>>> 1) traditional qemu-dm:
>>> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: XenSource, Inc. Device [5853:0001]
>>> Flags: bus master, fast devsel, latency 0, IRQ 11
>>> Memory at f0000000 (32-bit, prefetchable) [size=32M]
>>> Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>>> Kernel modules: cirrusfb
>>>
>>> 2) upstream qemu:
>>> 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: XenSource, Inc. Device [5853:0001]
>>> Physical Slot: 2
>>> Flags: bus master, fast devsel, latency 0, IRQ 11
>>> Memory at f0000000 (32-bit, prefetchable) [size=32M]
>>> Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
>>> Expansion ROM at f3000000 [disabled] [size=64K]
>>> Kernel modules: cirrusfb
>>>
>>> I tried to simply delete the expansion ROM at function pci_add_option_rom,
>>> such as
>>>
>>> //pci_register_bar(pdev, PCI_ROM_SLOT, 0, &pdev->rom);
>>>
>>> but the VNC viewer only can see black screen, but RDP works well.
>>> Any ideas about the cirrus's expansion ROM?
>>> Slow screen refresh has any relationship with cirrus's expansion ROM?
>>> Thank you in advance!
>>>
>>> BTW, I added some log in stdvga.c(xen-4.1.2/xen/arch/x86/hvm):
>>> static int stdvga_intercept_mmio(ioreq_t *p)
>>> {
>>> struct domain *d = current->domain;
>>> struct hvm_hw_stdvga *s = &d->arch.hvm_domain.stdvga;
>>> int buf = 0, rc;
>>> static int count_1 = 0;
>>> static int count_2 = 0;
>>>
>>> if ( p->size > 8 )
>>> {
>>> gdprintk(XENLOG_WARNING, "invalid mmio size %d\n", (int)p->size);
>>> return X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> spin_lock(&s->lock);
>>>
>>> if ( s->stdvga && s->cache )
>>> {
>>> switch ( p->type )
>>> {
>>> case IOREQ_TYPE_COPY:
>>> buf = mmio_move(s, p);
>>> count_1++;
>>> if (count_1 % 1000 == 0)
>>> gdprintk(XENLOG_WARNING, " =uvp= enter mmio_move,
>>> count_1=%d\n", count_1);
>>> if ( !buf )
>>> s->cache = 0;
>>> break;
>>> default:
>>> gdprintk(XENLOG_WARNING, "unsupported mmio request
>>> type:%d "
>>> "addr:0x%04x data:0x%04x size:%d count:%d
>>> state:%d "
>>> "isptr:%d dir:%d df:%d\n",
>>> p->type, (int)p->addr, (int)p->data, (int)p->size,
>>> (int)p->count, p->state,
>>> p->data_is_ptr, p->dir, p->df);
>>> s->cache = 0;
>>> }
>>> }
>>> else
>>> {
>>> buf = (p->dir == IOREQ_WRITE);
>>> count_2++;
>>> if (count_2 % 5000 == 0)
>>> gdprintk(XENLOG_WARNING, " >>> vga mmio count_2=%d\n",
>>> count_2);
>>> }
>>>
>>> rc = (buf && hvm_buffered_io_send(p));
>>>
>>> spin_unlock(&s->lock);
>>>
>>> return rc ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
>>> }
>>>
>>> and I got the below result with upstream qemu and tranditional qemu-dm:
>>>
>>> 1) traditional qemu-dm:
>>> (XEN) stdvga.c:152:d2 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=460000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=461000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=462000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=463000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=464000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=465000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=466000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=467000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=468000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=469000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=470000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=471000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=472000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=473000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=474000
>>> (XEN) stdvga.c:577:d2 =uvp= enter mmio_move, count_1=475000
>>> (XEN) stdvga.c:156:d2 leaving stdvga
>>>
>>> 2) upstream qemu:
>>> (XEN) stdvga.c:152:d1 entering stdvga and caching modes
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=233000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=234000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=235000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=236000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=237000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=238000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=239000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=240000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=241000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=242000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=243000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=244000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=245000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=246000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=247000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=248000
>>> (XEN) stdvga.c:577:d1 =uvp= enter mmio_move, count_1=249000
>>> (XEN) stdvga.c:156:d1 leaving stdvga
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8400000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8405000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8410000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=8415000
>>> ... ... //Omit some similar
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12570000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12575000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12580000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12585000
>>> (XEN) stdvga.c:596:d1 >>> vga mmio count_2=12590000
>>>
>>> Upstream qemu has lot's of MMIO access Memory region 0xa0000~0xc0000
>>> than traditional qemu-dm.
>>>
>>> Best Regards!
>>>
>>> -Gonglei
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
[-- Attachment #2: win2003.jpg --]
[-- Type: image/jpeg, Size: 143573 bytes --]
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2013-08-27 15:10 UTC | newest]
Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-25 13:13 [Qemu-devel] Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest Gonglei (Arei)
2013-07-25 13:54 ` Fabio Fantoni
2013-07-25 13:54 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
2013-07-25 14:21 ` Gonglei (Arei)
2013-07-25 14:21 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
2013-07-25 14:50 ` Fabio Fantoni
2013-07-25 14:50 ` Fabio Fantoni
2013-07-26 1:57 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
2013-07-26 8:10 ` Fabio Fantoni
2013-07-26 8:10 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
2013-07-26 1:57 ` Gonglei (Arei)
2013-07-26 2:09 ` [Qemu-devel] " Anthony Liguori
2013-07-26 3:08 ` Gonglei (Arei)
2013-07-26 3:08 ` Gonglei (Arei)
2013-07-26 3:20 ` Anthony Liguori
2013-07-26 6:41 ` Gonglei (Arei)
2013-07-26 6:41 ` Gonglei (Arei)
2013-07-26 10:02 ` Andreas Färber
2013-07-26 10:02 ` Andreas Färber
2013-07-26 10:19 ` Gerd Hoffmann
2013-07-26 10:27 ` Andreas Färber
2013-07-26 10:27 ` Andreas Färber
2013-07-27 11:06 ` Gonglei (Arei)
2013-07-27 11:06 ` Gonglei (Arei)
2013-07-27 11:51 ` Pasi Kärkkäinen
2013-07-27 11:51 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
2013-07-29 8:48 ` Gonglei (Arei)
2013-07-29 10:58 ` [Qemu-devel] " Pasi Kärkkäinen
2013-07-29 10:58 ` [Qemu-devel] [Xen-devel] " Pasi Kärkkäinen
2013-07-30 2:01 ` Gonglei (Arei)
2013-07-30 2:01 ` [Qemu-devel] " Gonglei (Arei)
2013-08-16 9:09 ` Gonglei (Arei)
2013-08-16 9:09 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
2013-08-17 9:04 ` Gonglei (Arei)
2013-08-20 19:45 ` [Qemu-devel] " Konrad Rzeszutek Wilk
2013-08-20 19:45 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2013-08-21 0:02 ` Ben Guthro
2013-08-21 0:02 ` [Qemu-devel] " Ben Guthro
2013-08-27 15:08 ` [Qemu-devel] [Xen-devel] " Gonglei (Arei)
2013-08-27 15:08 ` [Qemu-devel] " Gonglei (Arei)
2013-08-17 9:04 ` Gonglei (Arei)
2013-07-29 8:48 ` Gonglei (Arei)
2013-07-26 10:19 ` Gerd Hoffmann
2013-07-26 12:29 ` Fabio Fantoni
2013-07-26 12:29 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
2013-07-26 8:18 ` [Qemu-devel] " Gonglei (Arei)
2013-07-26 8:18 ` Gonglei (Arei)
2013-07-26 3:20 ` Anthony Liguori
2013-07-26 2:09 ` Anthony Liguori
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.