Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6630166ybi; Wed, 31 Jul 2019 18:20:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqxkyPe9KwarDlAbIgSHC6bAatCTxsjSe14/7nN7ZBoI7Is/hQupKvfDx7I5rWSocND44+4Y X-Received: by 2002:a17:902:724c:: with SMTP id c12mr120923677pll.219.1564622403883; Wed, 31 Jul 2019 18:20:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564622403; cv=none; d=google.com; s=arc-20160816; b=CXvg5vGw74qmB9vuNTOxCjKydHzWJuAABXKjRbq08ayXmcPi1KuUck/D4tWfVNquiA sDjYpgTVAiM7EknPEdHLMQV1LgoROZ0mrKFLyb3bNzZ8z+5lCVaMl6pGqjQGGxPtg+mU MhFOBeQH/6XT8Zv++lET66cQtdcGlflazJcmFe9JCkMRa8ZYZ+U/LSwYFXiRYqTetjGE GIf+O86Syypq+79bAwyhy8apFXLvAKouOdvHb7+t2g0k0L8NUVi73vdn5MMlBxiQTXGW MmMF38/LwygYTdo+6K5wI9ynWnVZggs+lnQYlYbqwSUuk4ILzRdcEl6Ls4Nuxd7K5rjL q8Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=X0n3MlpBw6ypLmARyUijLoTSFviMQgQMGryI80gkqOc=; b=NRtBbsfmQruzsZe4ILmX80ulYmzqlEtbNqB3BvwtvG8SrncrjzUL+wzT1keWEyNJbv rcKjpbBuri/Se6T2svj0Ul8wDZHFdbNXKddaCvdRFCKO7BaSf9Duya+T3WbmppVc5fTz i/G3mON9MKWHVTSHCtjjpIIrvAICSgkN48O7XugLj3AmOx0asgEfpumCJ83vINlxE5rc dM1zhjo0yg/D4q+xc/ZSSthXHytMAwYnuwrtkEpTh0taPhjXg9znU5KxfgtlQU/E6KbK GGzQe6xdWcqKNwUzD9WQBdFutE4PEyUFvlWm0DPtqqJK7TW1OmOw8ryPmedBlu8s2iEx AqUw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a32si2660676pje.7.2019.07.31.18.19.48; Wed, 31 Jul 2019 18:20:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730903AbfGaXhd (ORCPT + 99 others); Wed, 31 Jul 2019 19:37:33 -0400 Received: from mga07.intel.com ([134.134.136.100]:54398 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729275AbfGaXhd (ORCPT ); Wed, 31 Jul 2019 19:37:33 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2019 16:37:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,332,1559545200"; d="scan'208";a="256368246" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.41]) by orsmga001.jf.intel.com with ESMTP; 31 Jul 2019 16:37:31 -0700 Date: Wed, 31 Jul 2019 16:37:31 -0700 From: Sean Christopherson To: Jim Mattson Cc: Paolo Bonzini , Vitaly Kuznetsov , kvm list , LKML , Radim =?utf-8?B?S3LEjW3DocWZ?= , Joerg Roedel Subject: Re: [PATCH RFC 3/5] x86: KVM: svm: clear interrupt shadow on all paths in skip_emulated_instruction() Message-ID: <20190731233731.GA2845@linux.intel.com> References: <20190620110240.25799-1-vkuznets@redhat.com> <20190620110240.25799-4-vkuznets@redhat.com> <87ftmm71p3.fsf@vitty.brq.redhat.com> <36a9f411-f90c-3ffa-9ee3-6ebee13a763f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 31, 2019 at 01:27:53PM -0700, Jim Mattson wrote: > On Wed, Jul 31, 2019 at 9:37 AM Paolo Bonzini wrote: > > > > On 31/07/19 15:50, Vitaly Kuznetsov wrote: > > > Jim Mattson writes: > > > > > >> On Thu, Jun 20, 2019 at 4:02 AM Vitaly Kuznetsov wrote: > > >>> > > >>> Regardless of the way how we skip instruction, interrupt shadow needs to be > > >>> cleared. > > >> > > >> This change is definitely an improvement, but the existing code seems > > >> to assume that we never call skip_emulated_instruction on a > > >> POP-SS/MOV-to-SS/STI. Is that enforced anywhere? > > > > > > (before I send v1 of the series) I looked at the current code and I > > > don't think it is enforced, however, VMX version does the same and > > > honestly I can't think of a situation when we would be doing 'skip' for > > > such an instruction.... and there's nothing we can easily enforce from > > > skip_emulated_instruction() as we have no idea what the instruction > > > is... > > Can't we still coerce kvm into emulating any instruction by leveraging > a stale ITLB entry? The 'emulator' kvm-unit-test did this before the > KVM forced emulation prefix was introduced, but I haven't checked to > see if the original (admittedly fragile) approach still works. Also, > for POP-SS, you could always force emulation by mapping the %rsp > address beyond guest physical memory. The hypervisor would then have > to emulate the instruction to provide bus-error semantics. > > > I agree, I think a comment is worthwhile but we can live with the > > limitation. > > I think we can live with the limitation, but I'd really prefer to see > a KVM exit with KVM_INTERNAL_ERROR_EMULATION for an instruction that > kvm doesn't emulate properly. That seems better than just a comment > that the virtual CPU doesn't behave as architected. (I realize that I > am probably in the minority here.) At a glance, the full emulator models behavior correctly, e.g. see toggle_interruptibility() and setters of ctxt->interruptibility. I'm pretty sure that leaves the EPT misconfig MMIO and APIC access EOI fast paths as the only (VMX) path that would incorrectly handle a MOV/POP SS. Reading the guest's instruction stream to detect MOV/POP SS would defeat the whole "fast path" thing, not to mention both paths aren't exactly architecturally compliant in the first place.