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

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

[Gonglei (Arei)]

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

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

[Fabio Fantoni]

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.

Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest

[Fabio Fantoni]

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.

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

[Gonglei (Arei)]

> -----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

Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest

[Gonglei (Arei)]

> -----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

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

[Fabio Fantoni]

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.

Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest

[Fabio Fantoni]

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.

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

[Gonglei (Arei)]

> >> 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

Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest

[Gonglei (Arei)]

> >> 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

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

[Anthony Liguori]

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

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

[Anthony Liguori]

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

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

[Gonglei (Arei)]

> -----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

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

[Gonglei (Arei)]

> -----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

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

[Anthony Liguori]

 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
>

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

[Anthony Liguori]

 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
>

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

[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:
> >> -----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
> >

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

[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:
> >> -----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
> >

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

[Fabio Fantoni]

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
>

Re: Cirrus VGA slow screen update, show blank screen last 13s or so for windows XP guest

[Fabio Fantoni]

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
>

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

[Gonglei (Arei)]

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
> > >

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

[Gonglei (Arei)]

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
> > >

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

[Andreas Färber]

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

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

[Andreas Färber]

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

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

[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 ;)

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

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

[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 ;)

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

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

[Andreas Färber]

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

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

[Andreas Färber]

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

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

[Fabio Fantoni]

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

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

[Fabio Fantoni]

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

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

[Gonglei (Arei)]

> -----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

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

[Gonglei (Arei)]

> -----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

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

[Pasi Kärkkäinen]

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

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

[Pasi Kärkkäinen]

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

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

[Gonglei (Arei)]

> -----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

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

[Gonglei (Arei)]

> -----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

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

[Pasi Kärkkäinen]

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
> 

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

[Pasi Kärkkäinen]

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
> 

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

[Gonglei (Arei)]

> 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
> >

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

[Gonglei (Arei)]

> 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

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

[Gonglei (Arei)]

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?
> 

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

[Gonglei (Arei)]

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

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

[Gonglei (Arei)]

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
> 

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

[Gonglei (Arei)]

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

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

[Konrad Rzeszutek Wilk]

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

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

[Konrad Rzeszutek Wilk]

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

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

[Ben Guthro]

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

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

[Ben Guthro]

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

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

[Gonglei (Arei)]

[-- 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 --]

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

[Gonglei (Arei)]

[-- 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