From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [PATCH 1/3] KVM: x86 emulator: Fix task switch privilege checks Date: Fri, 27 Jan 2012 16:02:30 +0100 Message-ID: <4F22BC86.6090302@redhat.com> References: <1327335048-31925-2-git-send-email-kwolf@redhat.com> <20120124140316.GD19255@amd.com> <4F1EBCF1.9050808@redhat.com> <20120124141630.GD9571@redhat.com> <4F1EBF32.6020904@redhat.com> <20120124162350.GD538@redhat.com> <20120125160058.GG19255@amd.com> <4F229F7E.5030905@redhat.com> <20120127133456.GN19255@amd.com> <4F22ACC0.7020506@redhat.com> <20120127141702.GO19255@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm@vger.kernel.org, yoshikawa.takuya@oss.ntt.co.jp, avi@redhat.com, mtosatti@redhat.com To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14308 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755071Ab2A0O7J (ORCPT ); Fri, 27 Jan 2012 09:59:09 -0500 In-Reply-To: <20120127141702.GO19255@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 27.01.2012 15:17, schrieb Joerg Roedel: > On Fri, Jan 27, 2012 at 02:55:12PM +0100, Kevin Wolf wrote: >> Am 27.01.2012 14:34, schrieb Joerg Roedel: >>> On Fri, Jan 27, 2012 at 01:58:38PM +0100, Kevin Wolf wrote: >>>> Am 25.01.2012 17:00, schrieb Joerg Roedel: >>> >>>> I just retried. I use kvm-kmod and kvm.git with HEAD at ff92e9b5 plus >>>> the tree patches of this series plus a printk to output exit_int_info in >>>> task_switch_intercept(). I ran taskswitch2 from kvm-unittests and got >>>> two failures and my VM86 unit test which hung when trying to return from >>>> VM86. I also ran the kernel that made me aware of the issue initially. >>>> All debug messages show exit_int_info = 0. >>> >>> Okay, you are testing on a K8 which has exactly this bug. As I just >>> found out it is documented as erratum 701. The good news is that this >>> only happens on K8 and Fam11h, any later AMD processor doesn't have this >>> bug. >> >> Meh. Unless you give me a newer processor, this doesn't really help >> me... Doesn't look like there's any way to get a workaround, is there? I >> guess I'll have to hack it locally and possibly break other guests with >> the hacked module. > > No, unfortunatly there is no workaround for this problem. How do you > plan to hack around it? I know that my guest only uses iret and exceptions for task switches, so I think in my case I can assume that any TASK_SWITCH_CALL is really a TASK_SWITCH_GATE and I don't have to skip an instruction. Not quite upstreamable, obviously. Kevin