From: Fabio Fantoni <fantonifabio@tiscali.it>
To: xen-devel <xen-devel@lists.xensource.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
"Keir (Xen.org)" <keir@xen.org>,
xudong.hao@intel.com, frediano.ziglio@citrix.com
Subject: Emulated vgas problems with qemu upstream on Xen
Date: Fri, 22 Feb 2013 17:36:06 +0100 [thread overview]
Message-ID: <51279E76.8050703@tiscali.it> (raw)
[-- 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
next reply other threads:[~2013-02-22 16:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 16:36 Fabio Fantoni [this message]
[not found] <alpine.DEB.2.02.1302251612410.5360@kaball.uk.xensource.com>
2013-03-06 10:38 ` Emulated vgas problems with qemu upstream on Xen Frediano Ziglio
2013-03-07 14:02 ` Fabio Fantoni
2013-03-08 16:48 ` Frediano Ziglio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51279E76.8050703@tiscali.it \
--to=fantonifabio@tiscali.it \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=frediano.ziglio@citrix.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
--cc=xudong.hao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.