From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH v2] KVM: nVMX: Improve I/O exit handling Date: Thu, 14 Feb 2013 16:44:39 +0200 Message-ID: <20130214144439.GP9817@redhat.com> References: <51180635.3060003@web.de> <20130211100721.GA11107@fermat.math.technion.ac.il> <5118C4F9.707@web.de> <5118D3B5.5010406@siemens.com> <20130214093257.GK9817@redhat.com> <511CC83E.1080208@siemens.com> <20130214121129.GM9817@redhat.com> <511CD6E9.7080509@siemens.com> <20130214125626.GO9817@redhat.com> <20130214135423.GA14179@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kiszka , Marcelo Tosatti , kvm , Orit Wasserman To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19227 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753973Ab3BNOot (ORCPT ); Thu, 14 Feb 2013 09:44:49 -0500 Content-Disposition: inline In-Reply-To: <20130214135423.GA14179@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Feb 14, 2013 at 03:54:23PM +0200, Nadav Har'El wrote: > On Thu, Feb 14, 2013, Gleb Natapov wrote about "Re: [PATCH v2] KVM: nVMX: Improve I/O exit handling": > > > >> Not sure how to map a failure on real HW behaviour. I guess it's best to > > > > Exit to L1 with nested_vmx_failValid() may be? > > > > > > To my understanding, nested_vmx_failValid/Invalid are related to errors > > > directly related to vm instruction execution. This one is triggered by > > > the guest later on. > > > > > You are right. We need some kind of error vmexit here, but nothing > > appropriate is defined by the spec, so lets just assume that exit to L1 > > is needed if we cannot read permission bitmaps. > > On real hardware, note that the MSR-bitmap address specified in the VMCS > is a physical address, so there can never be an error - if I understand > correctly, there is no such thing as a non-existant physical address - > reading from non-existant physical memory returns random garbage (please > correct me if I'm wrong here!). So if I'm correct, using a non-existent > address for an MSR-bitmap will give you an undefined behavior - not any > sort of entry error to special type of exit. > That's true for real HW. Reading from physical address outside of physical memory will either access some random device MMIO or nothing. Either way result is unpredictable and may hang the machine. I am fine with killing a guest that tries to do that. > The current code, using a random value on the stack, fits with the > "undefined behavior" definition, but you're right the more logical > behavior is to, indeed, always exit on the MSR access when the bitmap > cannot be read. This will make an unreadable bitmap equivalent to no > bitmap at all - which I think makes most sense. Current case leaks data from host kernel, not just exhibit random behaviour. > > You're also right that this case is identical in both MSR and I/O bitmap > cases, and should be fixed in both. > > > -- > Nadav Har'El | Thursday, Feb 14 2013, 4 Adar 5773 > nyh@math.technion.ac.il |----------------------------------------- > Phone +972-523-790466, ICQ 13349191 |A fanatic is one who can't change his > http://nadav.harel.org.il |mind and won't change the subject. -- Gleb.