From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Fantoni Subject: Re: Emulated vgas problems with qemu upstream on Xen Date: Thu, 07 Mar 2013 15:02:07 +0100 Message-ID: <51389DDF.8060401@tiscali.it> References: <7CE799CC0E4DE04B88D5FDF226E18AC20105C1F797A0@LONPMAILBOX01.citrite.net> Reply-To: fantonifabio@tiscali.it Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6252716230743198416==" Return-path: In-Reply-To: <7CE799CC0E4DE04B88D5FDF226E18AC20105C1F797A0@LONPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Frediano Ziglio Cc: "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , Ian Campbell , Stefano Stabellini , "xudong.hao@intel.com" , Ian Jackson List-Id: xen-devel@lists.xenproject.org Questo è un messaggio firmato digitalmente in formato MIME. --===============6252716230743198416== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030707070309070809050905" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms030707070309070809050905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 performa= nce are >>> poor even if I increase video memory, respect to qemu-only and qemu-k= vm >>> (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 pr= esent >>> without xen. >>> >>> The performance differences are noticeable (in some case very big) wi= th 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=3Dstaging/qemu-upstream-unstable.git;a=3D= blob_plain;f=3Ddocs/specs/standard-vga.txt;hb=3DHEAD >>> 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 d= esktop >>> was 1024x768, and no problem with actual vga setting but now minimal >>> resolution seems increased to up 1366x768 and many people are using e= ven >>> higher resolutions. >>> http://www.screenresolution.org/year-2013/ >> When I started testing qemu upstream at the end of 2011 there were cri= tical bugs >> on videoram setting resolved with patches on qemu and xen. >> I did recently libxl patch that correctly set videoram and add qxl sup= port but >> it seems that on xen with qemu upstream all the emulated vga working o= nly as >> standard vga. >> What I mean is: even if I see the total amout of ram (i.e. 64 mb) on g= uest, the >> performances are poor in special mode when I increase the resolution e= ven in >> real simple operations like screen updates. >> >> I spent some days to find a solution, after comparative tests with qem= u-kvm and >> qemu-only when using same build of qemu and seabios on both linux/wind= ows >> 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=3Dseabios -device isa-debugcon,iobase=3D0x402,charde= v=3Dseabios >> >> but Xen domU doesn't show the details (probably because seabios with x= en 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 hvm= loader >> changes needed for full support upstream qemu vgas. >> >> This is an important problem to solve, not only for support bigger res= olutions >> and good support of a opensource vdi solution but also because with st= dvga 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 xe= n and kvm. >> Someone tells that hvmloader do not cause problem with upstream qemu v= gabioses, >> the difference is only caused by hvmloader generated tables or probabl= y 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 d= o on >> hvmloader for complete integration. >> I think like others that a hvmloader rewrite more minimal without incl= uding >> firmwares in hvmloader but linking them instead and using ovmf with se= abios >> 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 seabi= os 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? Whic= h > 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=20 video are much better than traditional one, so we would prefer=20 testing/support it instead of traditional. Dom0 is Wheezy with kernel from package, xen-unstable from source and=20 both qemu from experimental package recompiled and qemu-xen from xen sour= ce. DomU target is mainly Windows 7 pro 64 bit, tested also some linux hvm=20 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=20 final goal). Standard vga is missing some resoution with vnc or spice, for example=20 the more used 1366x768. The performance problem is probably due to a lack of use of effective=20 videoram size. For example: on cirrus it seems to work because if videoram passed is=20 minor of qemu parameter, vga.vram_size_mb gives a correct "xen out of=20 memory error" on qemu-dm log. With stdvga we cannot replicate the above error, so I think that real=20 videoram used was forced to something hardcoded (probably in hvmloader=20 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=20 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 > --------------ms030707070309070809050905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDMwNzE0MDIwN1owIwYJKoZIhvcNAQkEMRYEFNgY2Grkad97+aNzxhoLeTgz vMc8MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAIBG3mVCzmztllKE1OA3WHD0A gdbUKkePML1HHmtwFkWzcEO94PtsI+rlDl1zMiMlVseGY3mtX4+HqUWbwngNT7GG36+McuIY DWtbanQmHlbnz6uNrNnAKmUWuZW99L18YjcVOALZedkO++eTqGt7GojwwwNZA+ExSNi79C1J J+GCbLp4rmYMZKVfqPu8X/5upi0krSkSKq/T18kI3GSlvYtZnIiNVg1eqOHqA2msDha7GH4W Y7NmdkMfZjfmidkzoSrSPAX6rLA6xpt9XGiIen2bMvUYIYMLEP7ga7iS5hJ8Ecdsv3Kt6ZBK aXTPYljAOuemDJxoEGknuBPHnox5WwAAAAAAAA== --------------ms030707070309070809050905-- --===============6252716230743198416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6252716230743198416==--