From: Jan Kiszka <firstname.lastname@example.org>
To: Gleb Natapov <email@example.com>
Cc: "Borislav Petkov" <firstname.lastname@example.org>,
"Paolo Bonzini" <email@example.com>,
"Peter Zijlstra" <firstname.lastname@example.org>,
"Steven Rostedt" <email@example.com>, x86-ml <firstname.lastname@example.org>,
email@example.com, "Jörg Rödel" <firstname.lastname@example.org>
Subject: Re: __schedule #DF splat
Date: Sun, 29 Jun 2014 12:59:30 +0200 [thread overview]
Message-ID: <53AFF192.email@example.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]
On 2014-06-29 12:53, Gleb Natapov wrote:
> On Sun, Jun 29, 2014 at 12:31:50PM +0200, Jan Kiszka wrote:
>> On 2014-06-29 12:24, Gleb Natapov wrote:
>>> On Sun, Jun 29, 2014 at 11:56:03AM +0200, Jan Kiszka wrote:
>>>> On 2014-06-29 08:46, Gleb Natapov wrote:
>>>>> On Sat, Jun 28, 2014 at 01:44:31PM +0200, Borislav Petkov wrote:
>>>>>> qemu-system-x86-20240  ...1 9406.484134: kvm_page_fault: address 7fffb62ba318 error_code 2
>>>>>> qemu-system-x86-20240  ...1 9406.484136: kvm_inj_exception: #PF (0x2)a
>>>>>> kvm injects the #PF into the guest.
>>>>>> qemu-system-x86-20240  d..2 9406.484136: kvm_entry: vcpu 1
>>>>>> qemu-system-x86-20240  d..2 9406.484137: kvm_exit: reason PF excp rip 0xffffffff8161130f info 2 7fffb62ba318
>>>>>> qemu-system-x86-20240  ...1 9406.484138: kvm_page_fault: address 7fffb62ba318 error_code 2
>>>>>> qemu-system-x86-20240  ...1 9406.484141: kvm_inj_exception: #DF (0x0)
>>>>>> Second #PF at the same address and kvm injects the #DF.
>>>>>> BUT(!), why?
>>>>>> I probably am missing something but WTH are we pagefaulting at a
>>>>>> user address in context_switch() while doing a lockdep call, i.e.
>>>>>> spin_release? We're not touching any userspace gunk there AFAICT.
>>>>>> Is this an async pagefault or so which kvm is doing so that the guest
>>>>>> rip is actually pointing at the wrong place?
>>>>> There is nothing in the trace that point to async pagefault as far as I see.
>>>>>> Or something else I'm missing, most probably...
>>>>> Strange indeed. Can you also enable kvmmmu tracing? You can also instrument
>>>>> kvm_multiple_exception() to see which two exception are combined into #DF.
>>>> FWIW, I'm seeing the same issue here (likely) on an E-450 APU. It
>>>> disappears with older KVM (didn't bisect yet, some 3.11 is fine) and
>>>> when patch-disabling the vmport in QEMU.
>>>> Let me know if I can help with the analysis.
>>> Bisection would be great of course. Once thing that is special about
>>> vmport that comes to mind is that it reads vcpu registers to userspace and
>>> write them back. IIRC "info registers" does the same. Can you see if the
>>> problem is reproducible with disabled vmport, but doing "info registers"
>>> in qemu console? Although trace does not should any exists to userspace
>>> near the failure...
>> Yes, info registers crashes the guest after a while as well (with
>> different backtrace due to different context).
> Oh crap. Bisection would be most helpful. Just to be absolutely sure
> that this is not QEMU problem: does exactly same QEMU version work with
> older kernels?
Yes, that was the case last time I tried (I'm on today's git head with
QEMU right now).
Will see what I can do regarding bisecting. That host is a bit slow
(netbook), so it may take a while. Boris will probably beat me in this.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2014-06-29 11:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 15:32 __schedule #DF splat Borislav Petkov
2014-06-25 20:26 ` Borislav Petkov
2014-06-27 10:18 ` Borislav Petkov
2014-06-27 11:41 ` Paolo Bonzini
2014-06-27 11:55 ` Borislav Petkov
2014-06-27 12:01 ` Paolo Bonzini
2014-06-27 12:10 ` Borislav Petkov
2014-06-28 11:44 ` Borislav Petkov
2014-06-29 6:46 ` Gleb Natapov
2014-06-29 9:56 ` Jan Kiszka
2014-06-29 10:24 ` Gleb Natapov
2014-06-29 10:31 ` Jan Kiszka
2014-06-29 10:53 ` Gleb Natapov
2014-06-29 10:59 ` Jan Kiszka [this message]
2014-06-29 11:51 ` Borislav Petkov
2014-06-29 12:22 ` Jan Kiszka
2014-06-29 13:14 ` Borislav Petkov
2014-06-29 13:42 ` Gleb Natapov
2014-06-29 14:01 ` Borislav Petkov
2014-06-29 14:27 ` Gleb Natapov
2014-06-29 14:32 ` Jan Kiszka
2014-06-29 14:51 ` Jan Kiszka
2014-06-29 15:12 ` [PATCH] KVM: SVM: Fix CPL export via SS.DPL Jan Kiszka
2014-06-29 18:00 ` Borislav Petkov
2014-06-30 15:01 ` Paolo Bonzini
2014-06-30 15:03 ` Jan Kiszka
2014-06-30 15:15 ` Borislav Petkov
2014-06-30 15:25 ` Gleb Natapov
2014-06-30 15:26 ` Paolo Bonzini
2014-06-29 13:46 ` __schedule #DF splat Borislav Petkov
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.