From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Status of Nested Virt in 4.4 (Was: Re: Xen 4.4 development update) Date: Fri, 24 Jan 2014 16:04:11 +0000 Message-ID: <52E28EFB.3020008@eu.citrix.com> References: <1389186984.4883.67.camel@kazak.uk.xensource.com> <1389865519.5190.9.camel@kazak.uk.xensource.com> <52D7BC9E02000078001142D4@nat28.tlf.novell.com> <1389951634.6697.43.camel@kazak.uk.xensource.com> <52E27CEF.2010009@eu.citrix.com> <20140124145641.GA83765@deinos.phlegethon.org> <1390575746.2124.91.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1W6jFD-0008Qr-Ay for xen-devel@lists.xenproject.org; Fri, 24 Jan 2014 16:04:35 +0000 In-Reply-To: <1390575746.2124.91.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Tim Deegan Cc: "Zhang, Yang Z" , xen-devel , Jan Beulich , Andrew Cooper List-Id: xen-devel@lists.xenproject.org On 01/24/2014 03:02 PM, Ian Campbell wrote: > On Fri, 2014-01-24 at 15:56 +0100, Tim Deegan wrote: >> B11;rgb:0000/0000/0000At 14:47 +0000 on 24 Jan (1390571231), George Dunlap wrote: >>> On 01/17/2014 09:40 AM, Ian Campbell wrote: >>>> On Fri, 2014-01-17 at 02:16 +0000, Zhang, Yang Z wrote: >>>>> As Andrew said, nested still in experimental stage, because there are >>>>> still lots of scenarios I am not covered in my testing. So it may not >>>>> accurate to say it is good supported. But I hope people know that the >>>>> nested is ready to use now. And encourage them to try it and report >>>>> bug to us to push nested move forward. >>>> Perhaps we could say it is "tech preview" rather than "experimental"? >>> If { {xp,win7,win8,rhel6}x{x86,x64} } x { Xen, KVM, VMWare } and Win7 XP >>> compatibility mode are tested regularly, and only HyperV, L2 shadow, and >>> paging / PoD don't work, I think we should be able to call this a "1.0" >>> release for nested virt. Then we can add in "now works with HyperV", >>> "Now works with shadow", "Now works with paging" as those become mature. >> That depends on what the failure modes are for the other cases -- >> esp. given that the L1 guest's choice of hypervisor, shadow vs HAP &c, >> are not under the control of the L0 admin. I thikn that has to be >> clearly understood before we encourage people to turn this on. > Especially in the light of the previous two bugs here which let the > guest admin crash the host, in at least one of the two cases even if the > host admin had disabled nested virt for that guest (and I think it was > actually in both cases...) Right -- well I think then we need to help try to define some criteria that VMX nested virt would need to meet for portions of it to stop being considered "experimental" or "tech preview". Just a couple of angles: * L1 / L2 guests tested. What do people think of the mix of L1 / L2 guests there? They look like a pretty good combination to me. * L2 workloads tested Other than booting, what kinds of workloads are run in the L2 guests? Do the L2 guests ever get into heavy swapping scenarios, for instance? * Minimum subset of functionality I think it makes sense to explicitly say that we support only certain hypervisors, and to not support some advanced features in L2 guests. Saying only L1 HAP L2 HAP is reasonable, I think. No HyperV, no L2 shadow, no PoD are reasonable restrictions; it should be fine for us to say that the L1 admin enables that, and badness ensues, he has only himself to blame. * Security That said, I think we must assume that some of our users will have L0 admin != L1 admin. This means that L1 admin must not be able to do anything to crash L0. In the PoD case above, for example, if L1 enables PoD or paging, it might cause locking issue in L0; that's not acceptable. Anything else? -George