Re: Xen 4.3 development update RC2 imminent

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

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

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?

>>
>>> According to the results it seems that the only blocking task for 
>>> qxl is full sse support. I think also that full sse support can 
>>> improve general domU perfomances.
>>
>> Just to be clear, normally SSE is provded by the processor; the vast 
>> majority of the time SSE instructions will work just fine. The 
>> particular problem here is that instructions talking to qemu need to 
>> be emulated by Xen.  Xen will emulate SSE2 instructions, but not if 
>> the amount of data transferred is over 8 bytes.
>>
>> Getting that particular instruction to work is definitely going to be 
>> a work item for 4.4; but it's too late in the release process to do 
>> anything for 4.3 at this point.
> I understand. Is it a lot of work? Can we start making an experimental 
> patch?
> Can you give me some advice to try making it myself or is it not worth 
> it with my low experience?

I'm afraid the code is terribly complicated.  If I could have hacked 
together a quick patch I would have already done so.  :-)

  -George

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

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

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