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?

> 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.

  -George