From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: Nested SVM and migration Date: Mon, 22 Feb 2010 07:24:02 -1000 Message-ID: <4B82BDB2.4050806@redhat.com> References: <4B80347E.7000003@redhat.com> <20100220201822.GG20833@8bytes.org> <4B806FB9.20009@redhat.com> <20100221121008.GI20833@8bytes.org> <4B8125E2.8050309@redhat.com> <4B82B411.7020907@redhat.com> <4B82B473.4010906@redhat.com> <4B82B81A.1020409@redhat.com> <4B82B8BA.4020308@redhat.com> <4B82B9DF.5010201@redhat.com> <4B82BAA4.2010709@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joerg Roedel , Joerg Roedel , kvm To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752192Ab0BVRYI (ORCPT ); Mon, 22 Feb 2010 12:24:08 -0500 In-Reply-To: <4B82BAA4.2010709@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/22/2010 07:11 AM, Avi Kivity wrote: > On 02/22/2010 07:07 PM, Zachary Amsden wrote: >> On 02/22/2010 07:02 AM, Avi Kivity wrote: >>> On 02/22/2010 07:00 PM, Zachary Amsden wrote: >>>>> The force vmexit would generate an INTR #vmexit even if the INTR >>>>> intercept was disabled and even if no INTR is pending. However >>>>> this was shot down since there was no equivalent vmx exit reason >>>>> that we can except the guest to reasonably handle. >>>> >>>> >>>> While true, my point is more precisely - how can this possibly work >>>> for guests which MUST never exit SVM? As in, the hypervisor is >>>> broken or deliberately disabled from taking exits, and in fact, may >>>> no longer even exist in memory? >>> >>> These guests will be broken. My assumption was that only malicious >>> guests will disable INTR intercepts (though I can imagine a >>> Luvalley-like system that disables INTR intercepts when running dom0). >> >> Not an SVM expert, but can't you pass through INTR in SVM and leave a >> fully functioning guest which technically runs under SVM but requires >> no hypervisor? > > You could, but without trapping INTR, you can't reliably multiplex > guests or have a hypervisor-controlled network interface. That means > you're likely a blue pill thing. Not necessarily; you could be a very subversive BIOS. You only intercept #UD instruction and emulate SSE3 instructions in software. Your control structure you mark unavailable as reserved BIOS memory and you pass on interrupts and all exceptions to the booted OS. You then implement nested VMRUN so as not to lock the OS out of the hardware SVM acceleration.. Quite reasonable actually, and not a blue pill. Not 100% secure and it doesn't need to be, but it is 100% correct for a guest which obeys the standard reasonable rules of not messing with BIOS reserved memory. > >> Is that what the Luvalley system does? > > Luvalley is vmx only at the moment, but it certainly could let its > dom0 handle interrupts (since the scheduler and all device drivers are > in dom0). Once it switches to a different guest, it needs to enable > INTR. I checked it out, interesting stuff. Zach