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