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. 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. 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@xxxxxxxxxxxxxxxxxxx |----------------------------------------- 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
