From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: Nested SVM and migration Date: Mon, 22 Feb 2010 06:54:23 -1000 Message-ID: <4B82B6BF.5090800@redhat.com> References: <4B80347E.7000003@redhat.com> <20100220201822.GG20833@8bytes.org> <4B806FB9.20009@redhat.com> <20100221121008.GI20833@8bytes.org> <4B8125E2.8050309@redhat.com> <20100221124141.GA26465@8bytes.org> <4B812CE9.2070107@redhat.com> <20100221130915.GB26465@8bytes.org> <4B8131A5.5060600@redhat.com> <4B8137E7.4030001@redhat.com> <20100221144352.GC26465@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Joerg Roedel , kvm To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:21322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751746Ab0BVQy3 (ORCPT ); Mon, 22 Feb 2010 11:54:29 -0500 In-Reply-To: <20100221144352.GC26465@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 02/21/2010 04:43 AM, Joerg Roedel wrote: > On Sun, Feb 21, 2010 at 03:40:55PM +0200, Avi Kivity wrote: > >> On 02/21/2010 03:14 PM, Avi Kivity wrote: >> >>> (Either synthetic msrs, or an new state ioctl). The state would >>> contain a bit that says whether the guest is in guest or host mode. >>> >>> However, since we're breaking the architecture one way or another, >>> let's just go with the synthetic INTR intercept. >>> >>> >> On the other hand, there is no equivalent intercept in vmx. The >> "external interrupt" exit can be configured to run an INTACK cycle and >> capture the vector in a vmcs field, and there's no vector we can insert >> there (Xen for example uses this). >> > Difficult. We could use an instruction intercept which has no side > effect on guest state (invlpg for example). But thats a lot more > dangerous than an INTR intercept. What about PENDING_INTERRUPT? Are > there hypervisors that may get confused getting this intercept without > asking for it? > Yes, hypervisors which never mean to handle exits will break. There are many possible reasons you might design such a hypervisor; security, non-trivial software lock-out of SVM, special hardware concern, research project, or perhaps just a shell hypervisor which has one module capable of handling exits, and one module which doesn't require it, used for high performance but still maintaining binary compatibility with the underlying OS. Perhaps it is just a guest bug, but any design which disallows this is visibly and fundamentally architecturally broken. On the other hand, architectural effects of a new state ioctl or MSR update which is properly implemented are completely invisible to the guest. I don't have a strong preference which way that is done, but I do have a very strong preference not to break the architecture. Zach