From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: qemu-kvm-1.1.0 crashing with kernel 3.5.0-rc6 Date: Wed, 01 Aug 2012 16:11:49 +0300 Message-ID: <50192B15.3050508@redhat.com> References: <5011D123.4060101@googlemail.com> <5012719A.5080208@googlemail.com> <5012E659.7060304@googlemail.com> <50152FC8.20905@redhat.com> <50154294.9040705@googlemail.com> <50154632.7010304@redhat.com> <50155AF4.9050500@redhat.com> <5015662A.2000006@redhat.com> <501577D1.7030205@googlemail.com> <20120729175453.GA32360@redhat.com> <50158A97.3050909@googlemail.com> <50169389.1020607@googlemail.com> <50169421.6060406@redhat.com> <50169515.7050900@googlemail.com> <5016B8C3.7040103@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Eric Northup , kvm@vger.kernel.org, Jan Kiszka , Marcelo Tosatti To: Chris Clayton Return-path: Received: from mx1.redhat.com ([209.132.183.28]:5177 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751356Ab2HANLz (ORCPT ); Wed, 1 Aug 2012 09:11:55 -0400 In-Reply-To: <5016B8C3.7040103@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/30/2012 07:39 PM, Avi Kivity wrote: > On 07/30/2012 05:07 PM, Chris Clayton wrote: >>> >>>>> With kernel 3.5.0 with b2da15ac26a0c00 reverted, I have just had 15 >>>>> clean invocations of vanilla qemu-kvm-1.1.1. So that commit would seem >>>>> to be the problem. >>>> >>>> Just to be sure, I've run some more tests today. No crashes occurred in >>>> 20 runs of vanilla qemu-kvm-1.1.1 on kernel 3.5.0 with b2da15ac26a0c00 >>>> reverted. >>> >>> Ok. I'm trying to reproduce it here on a nested-virt setup, since the >>> code looks correct. >>> >>> What's your preemption settings? >>> >>> >> [chris:~/kernel/linux-3.5.0]$ grep PREEMPT .config >> CONFIG_TREE_PREEMPT_RCU=y >> CONFIG_PREEMPT_RCU=y >> CONFIG_PREEMPT_NOTIFIERS=y >> # CONFIG_PREEMPT_NONE is not set >> # CONFIG_PREEMPT_VOLUNTARY is not set >> CONFIG_PREEMPT=y >> CONFIG_PREEMPT_COUNT=y > > Here's what I think that is happening > > vcpu_load > ... > vmx_save_host_state > vmx_vcpu_run > (ds.cpl, es.cpl cleared by hardware) > > interrupt > push ds, es # pushes bad ds, es > schedule > vmx_vcpu_put > vmx_load_host_state > reload ds, es > pop ds, es # of other thread's stack > iret > # other thread runs > interrupt > schedule # back in vcpu thread > interrupt return: pop ds, es # <-- problem In fact, those are fine. > iret But IRET-to-outer-privilege-level clears segment registers with the wrong RPL. Think how secure OSes would be if they used the hardware fully. Credit to Gleb for pinpointing this. > > ... > vcpu_put > > # bad ds, es, but !vmx->host_state.loaded > -- error compiling committee.c: too many arguments to function