Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni <fabio.fantoni@m2r.biz>]

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

Il 24/05/2013 15:59, George Dunlap ha scritto:
> On 24/05/13 14:56, Fabio Fantoni wrote:
>> Il 23/05/2013 18:07, George Dunlap ha scritto:
>>> On 23/05/13 15:58, Fabio Fantoni wrote:
>>>> Il 23/05/2013 16:26, George Dunlap ha scritto:
>>>>> On 23/05/13 15:17, Fabio Fantoni wrote:
>>>>>> Il 23/05/2013 12:54, George Dunlap ha scritto:
>>>>>>> On 23/05/13 11:39, Andrew Cooper wrote:
>>>>>>>> On 23/05/13 11:36, Fabio Fantoni wrote:
>>>>>>>>> Il 23/05/2013 09:39, Jan Beulich ha scritto:
>>>>>>>>>>>>> On 22.05.13 at 18:54, George Dunlap 
>>>>>>>>>>>>> <george.dunlap@eu.citrix.com> wrote:
>>>>>>>>>>> On 22/05/13 17:30, Pasi Kärkkäinen wrote:
>>>>>>>>>>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote:
>>>>>>>>>>>> Hmm, for testing, can we use cpuid to mask out SSE,
>>>>>>>>>>>> and then try qxl ?
>>>>>>>>>>> That had occurred to me -- Andrew / Jan, do you know which 
>>>>>>>>>>> flag might
>>>>>>>>>>> disable this particular instruction?
>>>>>>>>>>>
>>>>>>>>>>> I guess we could try just disabling all the SSE instructions.
>>>>>>>>>> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX
>>>>>>>>>> output to EAX=1 input.
>>>>>>>>> Can you explain better please?
>>>>>>>>> Should I add this to test it?
>>>>>>>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1"
>>>>>>>> It will likely not work.  SSE2 is an architectural requirement 
>>>>>>>> for 64bit.
>>>>>>>>
>>>>>>>> It means that 64bit code may assume the presence of SSE2.  Xen 
>>>>>>>> amongst
>>>>>>>> other software does make this assumption.
>>>>>>>
>>>>>>> It might work if he's using 32-bit.
>>>>>>>
>>>>>>> Fabio, as I said in my initial e-mail, you need to:
>>>>>>>
>>>>>>> 1. Run "cat /proc/cpuinfo" on your dom0
>>>>>>> 2. Look at the line that says "features:"
>>>>>>> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c)
>>>>>>> 4. Set them to 0 in the "cpuid" field like above.
>>>>>>>
>>>>>>> Every processor will be a bit different -- you can't just copy 
>>>>>>> mine and expect it to work.
>>>>>>>
>>>>>>> Don't include "eax=1" -- Jan is thinking of a different interface.
>>>>>>>
>>>>>>>  -George
>>>>>> Tried with Raring (ubuntu 13.04) 32bit...
>>>>>> in cfg:
>>>>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0"
>>>>>>
>>>>>> # xl create /etc/xen/RARING.cfg
>>>>>> Parsing config from /etc/xen/RARING.cfg
>>>>>> while parsing CPUID flag: "sse4_1=0":
>>>>>>   error #2: unknown CPUID flag name
>>>>>> while parsing CPUID flag: "sse4_2=0":
>>>>>>   error #2: unknown CPUID flag name
>>>>>
>>>>> Right -- in that case this is a minor bug in libxl. (Actually I 
>>>>> got the same result, I just didn't notice the error messages -- 
>>>>> sorry about that.)
>>>>>
>>>>>>
>>>>>> In domU:
>>>>>> # cat /proc/cpuinfo | grep sse
>>>>>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep 
>>>>>> mtrr pge mca cmov
>>>>>>  pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 
>>>>>> *sse4_1 sse4_2* x2apic popcnt tsc_deadline_timer hypervisor lahf_lm
>>>>>>
>>>>>> What should I do to have sse4 disabled?
>>>>>>
>>>>>> For now with sse, sse2 and sse3 disabled the performance is very 
>>>>>> very low (even without qxl), while performances are acceptables 
>>>>>> with SSE.
>>>>>> I got the same results with qxl card and qxl driver loaded, but 
>>>>>> now at least X and qemu didn't crash.
>>>>>
>>>>> Sorry, same result as what?  Does the X driver work or not?
>>>> X qxl driver works with sse disabled (tried also with the correct 
>>>> sse4.1 and sse4.2 on cpuid) but performance are too bad, even 
>>>> without qxl, therefore it seems that the performance problem is 
>>>> only due to sse being disabled.
>>>
>>> Well that's good news anyway -- it means that qxl as a feature is 
>>> actually within reach. :-)
>>>
>>> Can you try it just with sse2 disabled?
>> Tried with only sse2 disabled: Raring domU did not complete the O.S. 
>> loading and qemu did not crash.
>> Qemu log without error and unable to connect with xl console.
>> Same result with only sse (1) enabled.
>> What should I do for debugging in this case with nothing on logs?
>> Should I recompile qemu with "--enable-debug" and/or should I do 
>> other things?
>
> I don't think these can really be classified as bugs -- it's perfectly 
> reasonable for software to expect to be running on an actual processor 
> that someone made; so if you end up setting a CPUID that doesn't match 
> any real-life processor, and that breaks some assumptions, I think 
> there's nothing we can really do about that.
>
> It was always a long-shot that this "disable sse instructions" thing 
> would work -- I'm surprised in fact that disabling *all* sse 
> instructions actually ran, and not at all surprised that the result 
> was incredibly slow.  But since it's easy to try, there's no harm in 
> giving it a shot.  Too bad it didn't work out.
>
>  -George
Thanks for all your help.
Are there other test I can do or only wait for a patch?
About patch I'm thinking to do fast test by increasing size variable 
(and connected things) of hvmemul_do_io() function in 
...x86/hvm/emulate.c, but if you tell that the patch is very complex 
probably my idea is only very stupid.
I also not understand why check if size > of long while size is defined 
int in that function ( hvmemul_do_io() ), probably is another stupid 
question.

[-- Attachment #1.2: Type: text/html, Size: 9379 bytes --]

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

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