| 
  
  
     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@xxxxxxxxxxxxx>
                          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? 
      
      
          
          
            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 
     
     
  
 |