Emulated vgas problems with qemu upstream on Xen

Emulated vgas problems with qemu upstream on Xen

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 4191 bytes --]

Some times ago I have reported several times the problem with emulated 
vgas with qemu upstream on xen.
For example this was my last report about:
> WIth both cirrus and stdvga under qemu upstream with xen the 
> performance are poor even if I increase video memory, respect to 
> qemu-only and qemu-kvm (without xen).
> Qxl is definitely not working under xen and conversely is ok on 
> qemu-kvm and qemu-only.
>
> It seem that xen need change and/or fix to have full working emulated 
> vga on qemu upstream.
> At the moment all emulated vgas have problems with xen that aren't 
> present without xen.
>
> The performance differences are noticeable (in some case very big) 
> with xen and without xen using resolution > 1024x768.
>
> Probably the first link explain the change/fix necessary in xen about 
> vga (probably in hvmloader).
> I tried to do that more times failing but unfortunately I do not have 
> sufficient knowledge about this.
> Can someone help me please?
>
> I think this is important, years ago the minimal resolution used on 
> desktop was 1024x768, and no problem with actual vga setting but now 
> minimal resolution seems increased to up 1366x768 and many people are 
> using even higher resolutions.
> http://www.screenresolution.org/year-2013/

When I started testing qemu upstream at the end of 2011 there were 
critical bugs on videoram setting resolved with patches on qemu and xen.
I did recently libxl patch that correctly set videoram and add qxl 
support but it seems that on xen with qemu upstream all the emulated vga 
working only as standard vga.
What I mean is: even if I see the total amout of ram (i.e. 64 mb) on 
guest, the performances are poor in special mode when I increase the 
resolution even in real simple operations like screen updates.

I spent some days to find a solution, after comparative tests with 
qemu-kvm and qemu-only when using same build of qemu and seabios on both 
linux/windows domU/vm the problem seem of hvmloader.
I have tried to find what is exactly the culprit to no avail.
I don't have knownladge about bios parts.
I also tried to see the differences of seabios tables between xen and 
kvm or qemu-only with:

-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios

but Xen domU doesn't show the details (probably because seabios with xen 
uses the tables passed by hvmloader)

Today I also tested this patches probably related to solution:

[PATCH]xen/hvmloader: define a TOM register
[PATCH] qemu: define a TOM register to report the base of PCI

The problem persists, probably this is only partial solution about 
hvmloader changes needed for full support upstream qemu vgas.

This is an important problem to solve, not only for support bigger 
resolutions and good support of a opensource vdi solution but also 
because with stdvga is impossible to use some resolutions, for example 
the actually most used 1366x768.
(screenshots of examples with windows 7 on attachment)
Screenshots show list of resolutions supported by standard vga and qxl 
full working.

There is also a strange difference on bios info line of qxl between xen 
and kvm.
Someone tells that hvmloader do not cause problem with upstream qemu 
vgabioses, the difference is only caused by hvmloader generated tables 
or probably or is there another problem to found?

I also did some tests with ovmf after applied this patch:
http://lists.xen.org/archives/html/xen-devel/2013-02/msg01363.html
and using updated tianocore git, but it seems there are more work to do 
on hvmloader for complete integration.
I think like others that a hvmloader rewrite more minimal without 
including firmwares in hvmloader but linking them instead and using ovmf 
with seabios included (for support both eufi and bios) will be the best 
definitive solution for future of hvm domU.
Probably now the more important thing is fixes to hvmloader with seabios 
to have a full feature and stable qemu upstream on xen 4.3.

Is there someone that can help me to solve emulated vgas problem with 
upstream qemu?

Thanks for any reply and sorry for my bad english.


[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Emulated vgas problems with qemu upstream on Xen

[Frediano Ziglio]

> Some times ago I have reported several times the problem with emulated vgas with
> qemu upstream on xen.
> For example this was my last report about:
> > WIth both cirrus and stdvga under qemu upstream with xen the performance are
> > poor even if I increase video memory, respect to qemu-only and qemu-kvm
> > (without xen).
> > Qxl is definitely not working under xen and conversely is ok on qemu-kvm and
> > qemu-only.
> > 
> > It seem that xen need change and/or fix to have full working emulated vga on
> > qemu upstream.
> > At the moment all emulated vgas have problems with xen that aren't present
> > without xen.
> > 
> > The performance differences are noticeable (in some case very big) with xen
> > and without xen using resolution > 1024x768.
> > 
> > Probably the first link explain the change/fix necessary in xen about vga
> > (probably in hvmloader).

Which link refer this sentence ?

> > I tried to do that more times failing but unfortunately I do not have
> > sufficient knowledge about this.
> > Can someone help me please?
> > 
> > I think this is important, years ago the minimal resolution used on desktop
> > was 1024x768, and no problem with actual vga setting but now minimal
> > resolution seems increased to up 1366x768 and many people are using even
> > higher resolutions.
> > http://www.screenresolution.org/year-2013/
> 
> When I started testing qemu upstream at the end of 2011 there were critical bugs
> on videoram setting resolved with patches on qemu and xen.
> I did recently libxl patch that correctly set videoram and add qxl support but
> it seems that on xen with qemu upstream all the emulated vga working only as
> standard vga.
> What I mean is: even if I see the total amout of ram (i.e. 64 mb) on guest, the
> performances are poor in special mode when I increase the resolution even in
> real simple operations like screen updates.
> 
> I spent some days to find a solution, after comparative tests with qemu-kvm and
> qemu-only when using same build of qemu and seabios on both linux/windows
> domU/vm the problem seem of hvmloader.
> I have tried to find what is exactly the culprit to no avail.
> I don't have knownladge about bios parts.
> I also tried to see the differences of seabios tables between xen and kvm or
> qemu-only with:
> 
> -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
> 
> but Xen domU doesn't show the details (probably because seabios with xen uses
> the tables passed by hvmloader)
> 
> Today I also tested this patches probably related to solution:
> 
> [PATCH]xen/hvmloader: define a TOM register
> [PATCH] qemu: define a TOM register to report the base of PCI
> 
> The problem persists, probably this is only partial solution about hvmloader
> changes needed for full support upstream qemu vgas.
> 
> This is an important problem to solve, not only for support bigger resolutions
> and good support of a opensource vdi solution but also because with stdvga is
> impossible to use some resolutions, for example the actually most used 1366x768.
> (screenshots of examples with windows 7 on attachment)
> Screenshots show list of resolutions supported by standard vga and qxl full
> working.
> 
> There is also a strange difference on bios info line of qxl between xen and kvm.
> Someone tells that hvmloader do not cause problem with upstream qemu vgabioses,
> the difference is only caused by hvmloader generated tables or probably or is
> there another problem to found?
> 
> I also did some tests with ovmf after applied this patch:
> http://lists.xen.org/archives/html/xen-devel/2013-02/msg01363.html
> and using updated tianocore git, but it seems there are more work to do on
> hvmloader for complete integration.
> I think like others that a hvmloader rewrite more minimal without including
> firmwares in hvmloader but linking them instead and using ovmf with seabios
> included (for support both eufi and bios) will be the best definitive solution
> for future of hvm domU.
> Probably now the more important thing is fixes to hvmloader with seabios to have
> a full feature and stable qemu upstream on xen 4.3.
> 
> Is there someone that can help me to solve emulated vgas problem with upstream
> qemu?
> 
> Thanks for any reply and sorry for my bad english.
> 

Could you give more details. Are you measuring performance or just are
sensible slow? Did you try with qemu traditional and works better? Which
system are you using and which resolution are you trying to use? Do you
use vnc or other graphics output?

There could be problems in the video resolution informations. Other
issue could happen if OS have problems detecting linear frame pointer
and fall back to page switching. I had a similar problem with Qemu
traditional and Windows 8.

It's not hard to backport new resolutions.

Frediano

Re: Emulated vgas problems with qemu upstream on Xen

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 6811 bytes --]

Il 06/03/2013 11:38, Frediano Ziglio ha scritto:
>> Some times ago I have reported several times the problem with emulated vgas with
>> qemu upstream on xen.
>> For example this was my last report about:
>>> WIth both cirrus and stdvga under qemu upstream with xen the performance are
>>> poor even if I increase video memory, respect to qemu-only and qemu-kvm
>>> (without xen).
>>> Qxl is definitely not working under xen and conversely is ok on qemu-kvm and
>>> qemu-only.
>>>
>>> It seem that xen need change and/or fix to have full working emulated vga on
>>> qemu upstream.
>>> At the moment all emulated vgas have problems with xen that aren't present
>>> without xen.
>>>
>>> The performance differences are noticeable (in some case very big) with xen
>>> and without xen using resolution > 1024x768.
>>>
>>> Probably the first link explain the change/fix necessary in xen about vga
>>> (probably in hvmloader).
> Which link refer this sentence ?

The quote was only a part of a previous mail, the link refered is:
http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=blob_plain;f=docs/specs/standard-vga.txt;hb=HEAD


>>> I tried to do that more times failing but unfortunately I do not have
>>> sufficient knowledge about this.
>>> Can someone help me please?
>>>
>>> I think this is important, years ago the minimal resolution used on desktop
>>> was 1024x768, and no problem with actual vga setting but now minimal
>>> resolution seems increased to up 1366x768 and many people are using even
>>> higher resolutions.
>>> http://www.screenresolution.org/year-2013/
>> When I started testing qemu upstream at the end of 2011 there were critical bugs
>> on videoram setting resolved with patches on qemu and xen.
>> I did recently libxl patch that correctly set videoram and add qxl support but
>> it seems that on xen with qemu upstream all the emulated vga working only as
>> standard vga.
>> What I mean is: even if I see the total amout of ram (i.e. 64 mb) on guest, the
>> performances are poor in special mode when I increase the resolution even in
>> real simple operations like screen updates.
>>
>> I spent some days to find a solution, after comparative tests with qemu-kvm and
>> qemu-only when using same build of qemu and seabios on both linux/windows
>> domU/vm the problem seem of hvmloader.
>> I have tried to find what is exactly the culprit to no avail.
>> I don't have knownladge about bios parts.
>> I also tried to see the differences of seabios tables between xen and kvm or
>> qemu-only with:
>>
>> -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
>>
>> but Xen domU doesn't show the details (probably because seabios with xen uses
>> the tables passed by hvmloader)
>>
>> Today I also tested this patches probably related to solution:
>>
>> [PATCH]xen/hvmloader: define a TOM register
>> [PATCH] qemu: define a TOM register to report the base of PCI
>>
>> The problem persists, probably this is only partial solution about hvmloader
>> changes needed for full support upstream qemu vgas.
>>
>> This is an important problem to solve, not only for support bigger resolutions
>> and good support of a opensource vdi solution but also because with stdvga is
>> impossible to use some resolutions, for example the actually most used 1366x768.
>> (screenshots of examples with windows 7 on attachment)
>> Screenshots show list of resolutions supported by standard vga and qxl full
>> working.
>>
>> There is also a strange difference on bios info line of qxl between xen and kvm.
>> Someone tells that hvmloader do not cause problem with upstream qemu vgabioses,
>> the difference is only caused by hvmloader generated tables or probably or is
>> there another problem to found?
>>
>> I also did some tests with ovmf after applied this patch:
>> http://lists.xen.org/archives/html/xen-devel/2013-02/msg01363.html
>> and using updated tianocore git, but it seems there are more work to do on
>> hvmloader for complete integration.
>> I think like others that a hvmloader rewrite more minimal without including
>> firmwares in hvmloader but linking them instead and using ovmf with seabios
>> included (for support both eufi and bios) will be the best definitive solution
>> for future of hvm domU.
>> Probably now the more important thing is fixes to hvmloader with seabios to have
>> a full feature and stable qemu upstream on xen 4.3.
>>
>> Is there someone that can help me to solve emulated vgas problem with upstream
>> qemu?
>>
>> Thanks for any reply and sorry for my bad english.
>>
> Could you give more details. Are you measuring performance or just are
> sensible slow? Did you try with qemu traditional and works better? Which
> system are you using and which resolution are you trying to use? Do you
> use vnc or other graphics output?

We are using qemu upstream since over one year, all performances except 
video are much better than traditional one, so we would prefer 
testing/support it instead of traditional.
Dom0 is Wheezy with kernel from package, xen-unstable from source and 
both qemu from experimental package recompiled and qemu-xen from xen source.
DomU target is mainly Windows 7 pro 64 bit, tested also some linux hvm 
domU (Wheezy, Precise and Quantal).
We use Linux PV domU only with server without DE.
Mainly used resolution and problematic are 1366x768, 1920x1080, 1600x900.
Our customers need to access Windows domU with rdp sessions for now.
Windows 7 had cirrus driver dropped, so forced as to use standard vga in 
our domUs until qxl will be full working on xen (spice with qxl is our 
final goal).
Standard vga is missing some resoution with vnc or spice, for example 
the more used 1366x768.
The performance problem is probably due to a lack of use of effective 
videoram size.
For example: on cirrus it seems to work because if videoram passed is 
minor of qemu parameter, vga.vram_size_mb gives a correct "xen out of 
memory error" on qemu-dm log.
With stdvga we cannot replicate the above error, so I think that real 
videoram used was forced to something hardcoded (probably in hvmloader 
and/or vgabios).
We  got the error only if we set <16mb videoram (default value of stdvga 
is 16 mb with qemu 1.4).
Performance is poorer increasing resolutions over 1024x768 (even simple 
screen refresh operation).


>
> There could be problems in the video resolution informations. Other
> issue could happen if OS have problems detecting linear frame pointer
> and fall back to page switching. I had a similar problem with Qemu
> traditional and Windows 8.

Where I can check this kind of problems?

> It's not hard to backport new resolutions.
>
> Frediano
>




[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4510 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Emulated vgas problems with qemu upstream on Xen

[Frediano Ziglio]

On Thu, 2013-03-07 at 15:02 +0100, Fabio Fantoni wrote:
> Il 06/03/2013 11:38, Frediano Ziglio ha scritto:
> >> Some times ago I have reported several times the problem with emulated vgas with
> >> qemu upstream on xen.
> >> For example this was my last report about:
> >>> WIth both cirrus and stdvga under qemu upstream with xen the performance are
> >>> poor even if I increase video memory, respect to qemu-only and qemu-kvm
> >>> (without xen).
> >>> Qxl is definitely not working under xen and conversely is ok on qemu-kvm and
> >>> qemu-only.
> >>>
> >>> It seem that xen need change and/or fix to have full working emulated vga on
> >>> qemu upstream.
> >>> At the moment all emulated vgas have problems with xen that aren't present
> >>> without xen.
> >>>
> >>> The performance differences are noticeable (in some case very big) with xen
> >>> and without xen using resolution > 1024x768.
> >>>
> >>> Probably the first link explain the change/fix necessary in xen about vga
> >>> (probably in hvmloader).
> > Which link refer this sentence ?
> 
> The quote was only a part of a previous mail, the link refered is:
> http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=blob_plain;f=docs/specs/standard-vga.txt;hb=HEAD
> 
> 
> >>> I tried to do that more times failing but unfortunately I do not have
> >>> sufficient knowledge about this.
> >>> Can someone help me please?
> >>>
> >>> I think this is important, years ago the minimal resolution used on desktop
> >>> was 1024x768, and no problem with actual vga setting but now minimal
> >>> resolution seems increased to up 1366x768 and many people are using even
> >>> higher resolutions.
> >>> http://www.screenresolution.org/year-2013/
> >> When I started testing qemu upstream at the end of 2011 there were critical bugs
> >> on videoram setting resolved with patches on qemu and xen.
> >> I did recently libxl patch that correctly set videoram and add qxl support but
> >> it seems that on xen with qemu upstream all the emulated vga working only as
> >> standard vga.
> >> What I mean is: even if I see the total amout of ram (i.e. 64 mb) on guest, the
> >> performances are poor in special mode when I increase the resolution even in
> >> real simple operations like screen updates.
> >>
> >> I spent some days to find a solution, after comparative tests with qemu-kvm and
> >> qemu-only when using same build of qemu and seabios on both linux/windows
> >> domU/vm the problem seem of hvmloader.
> >> I have tried to find what is exactly the culprit to no avail.
> >> I don't have knownladge about bios parts.
> >> I also tried to see the differences of seabios tables between xen and kvm or
> >> qemu-only with:
> >>
> >> -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
> >>
> >> but Xen domU doesn't show the details (probably because seabios with xen uses
> >> the tables passed by hvmloader)
> >>
> >> Today I also tested this patches probably related to solution:
> >>
> >> [PATCH]xen/hvmloader: define a TOM register
> >> [PATCH] qemu: define a TOM register to report the base of PCI
> >>
> >> The problem persists, probably this is only partial solution about hvmloader
> >> changes needed for full support upstream qemu vgas.
> >>
> >> This is an important problem to solve, not only for support bigger resolutions
> >> and good support of a opensource vdi solution but also because with stdvga is
> >> impossible to use some resolutions, for example the actually most used 1366x768.
> >> (screenshots of examples with windows 7 on attachment)
> >> Screenshots show list of resolutions supported by standard vga and qxl full
> >> working.
> >>
> >> There is also a strange difference on bios info line of qxl between xen and kvm.
> >> Someone tells that hvmloader do not cause problem with upstream qemu vgabioses,
> >> the difference is only caused by hvmloader generated tables or probably or is
> >> there another problem to found?
> >>
> >> I also did some tests with ovmf after applied this patch:
> >> http://lists.xen.org/archives/html/xen-devel/2013-02/msg01363.html
> >> and using updated tianocore git, but it seems there are more work to do on
> >> hvmloader for complete integration.
> >> I think like others that a hvmloader rewrite more minimal without including
> >> firmwares in hvmloader but linking them instead and using ovmf with seabios
> >> included (for support both eufi and bios) will be the best definitive solution
> >> for future of hvm domU.
> >> Probably now the more important thing is fixes to hvmloader with seabios to have
> >> a full feature and stable qemu upstream on xen 4.3.
> >>
> >> Is there someone that can help me to solve emulated vgas problem with upstream
> >> qemu?
> >>
> >> Thanks for any reply and sorry for my bad english.
> >>
> > Could you give more details. Are you measuring performance or just are
> > sensible slow? Did you try with qemu traditional and works better? Which
> > system are you using and which resolution are you trying to use? Do you
> > use vnc or other graphics output?
> 
> We are using qemu upstream since over one year, all performances except 
> video are much better than traditional one, so we would prefer 
> testing/support it instead of traditional.
> Dom0 is Wheezy with kernel from package, xen-unstable from source and 
> both qemu from experimental package recompiled and qemu-xen from xen source.
> DomU target is mainly Windows 7 pro 64 bit, tested also some linux hvm 
> domU (Wheezy, Precise and Quantal).
> We use Linux PV domU only with server without DE.
> Mainly used resolution and problematic are 1366x768, 1920x1080, 1600x900.
> Our customers need to access Windows domU with rdp sessions for now.
> Windows 7 had cirrus driver dropped, so forced as to use standard vga in 
> our domUs until qxl will be full working on xen (spice with qxl is our 
> final goal).
> Standard vga is missing some resoution with vnc or spice, for example 
> the more used 1366x768.
> The performance problem is probably due to a lack of use of effective 
> videoram size.
> For example: on cirrus it seems to work because if videoram passed is 
> minor of qemu parameter, vga.vram_size_mb gives a correct "xen out of 
> memory error" on qemu-dm log.
> With stdvga we cannot replicate the above error, so I think that real 
> videoram used was forced to something hardcoded (probably in hvmloader 
> and/or vgabios).
> We  got the error only if we set <16mb videoram (default value of stdvga 
> is 16 mb with qemu 1.4).
> Performance is poorer increasing resolutions over 1024x768 (even simple 
> screen refresh operation).
> 
> 
> >
> > There could be problems in the video resolution informations. Other
> > issue could happen if OS have problems detecting linear frame pointer
> > and fall back to page switching. I had a similar problem with Qemu
> > traditional and Windows 8.
> 
> Where I can check this kind of problems?
> 

I wrote some patches in the past for Xen firmware vgabios. Mainly there
are some information in vga modes that make drivers work with flat frame
buffer. The problem was that if planes was not 1 Windows 8 thinks it has
to switch banks and this slow down a lot updates. From VM point you have
to be able map all frame buffer in a single linear memory. I checked
with lspci and it seems that using SeaBIOS you have 32 mb from graphics
card.

I remember I wrote a small program to grab that info (you need to use
int 10 calls to the BIOS). I'm trying to find these programs, if I don't
find I'll wrote something new (was actually really small). I remember I
post patches to vgabios.

Another issue however could be the vnc code (which is very different
between traditional and upstream).

I noted that after launching the machine first boot screens seems
painted pixel by pixel while after changing resolution seems much faster
which seems to indicate that problem in this case is not VNC.

> > It's not hard to backport new resolutions.
> >

Frediano