linux-kernel - Re: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4B166ABC.9040004@redhat.com>
Date:	Wed, 02 Dec 2009 15:25:16 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Nix <nix@...eri.org.uk>
CC:	kvm@...r.kernel.org,
	Linux-Kernel-Mailing-List <linux-kernel@...r.kernel.org>,
	Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b
 66 0f 7f 07'

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/