Re: Xen 4.3 development update RC2 imminent

[George Dunlap <george.dunlap@eu.citrix.com>]

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

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

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

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

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