On 11/29/2009 04:23 PM, Avi Kivity wrote:
On 11/29/2009 03:48 PM, Nix wrote:
On 29 Nov 2009, Avi Kivity uttered the following:
66 0f 7f 07 movdqa %xmm0,(%rdi)
which we don't emulate.
x86-64 glibc 2.10 memset(), perhaps? On SSE-capable platforms that does
a whole bunch of
L(SSE0QB): movdqa %xmm0,-0xb0(%rdi)
L(SSE0QA): movdqa %xmm0,-0xa0(%rdi)
L(SSE0Q9): movdqa %xmm0,-0x90(%rdi)
L(SSE0Q8): movdqa %xmm0,-0x80(%rdi)
L(SSE0Q7): movdqa %xmm0,-0x70(%rdi)
L(SSE0Q6): movdqa %xmm0,-0x60(%rdi)
L(SSE0Q5): movdqa %xmm0,-0x50(%rdi)
L(SSE0Q4): movdqa %xmm0,-0x40(%rdi)
L(SSE0Q3): movdqa %xmm0,-0x30(%rdi)
L(SSE0Q2): movdqa %xmm0,-0x20(%rdi)
L(SSE0Q1): movdqa %xmm0,-0x10(%rdi)
L(SSE0Q0): retq
(multiple blocks of this, catering for alignment, I guess)
and x86-64 is always SSE-capable.
Most likely, either this or something similar is called on a userspace
device driver. Can you check if this is triggered by starting X?
If so, we'll have to emulate this instruction, which will be a bitch.
Not just in the emulator, also in the userspace interface. We only
support up to 8 bytes mmio.
Our options in fixing this are:
- extend mmio support to 16 (32? more?) bytes, require new kernel and
new userspace
- use coalesced_mmio for this
- if the mmio happens for a non coalesced mmio region, we flush
immediately
- what if userspace doesn't support coalesced mmio? (unlikely these
days)
- doesn't work for reads (unlikely for 16 byte accesses?)
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
