Re: Xen 4.3 development update RC2 imminent

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

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

On 24/05/13 15:53, Fabio Fantoni wrote:
> 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.

All I can tell you are that the two options I was going to explore were:
* Increase the size of the "data" element of ioreq_t in 
xen.git/xen/include/public/hvm/ioreq.h
* When you detect size > sizeof(long), switch to data_is_ptr mode.

In the first case you'll need to be sure to re-compile qemu.

I'm afraid I won't be able to give you any more help than that at the 
moment.

  -George


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

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

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