From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/24] Nested VMX, v5 Date: Sun, 11 Jul 2010 18:45:23 +0300 Message-ID: <4C39E713.6040403@redhat.com> References: <1276431753-nyh@il.ibm.com> <1A42CE6F5F474C41B63392A5F80372B21F70B7B1@shsmsx501.ccr.corp.intel.com> <20100711082703.GA37@fermat.math.technion.ac.il> <1FEA66BE-8BFC-4158-A0F1-CDD8E595D0D7@suse.de> <20100711124937.GA11157@fermat.math.technion.ac.il> <4C39C32A.5000403@redhat.com> <20100711153951.GA15476@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , "Dong, Eddie" , "kvm@vger.kernel.org" To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33327 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999Ab0GKPpb (ORCPT ); Sun, 11 Jul 2010 11:45:31 -0400 In-Reply-To: <20100711153951.GA15476@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On 07/11/2010 06:39 PM, Nadav Har'El wrote: > On Sun, Jul 11, 2010, Avi Kivity wrote about "Re: [PATCH 0/24] Nested VMX, v5": > >>> nesting- >>> aware L1 guest hypervisors to actually use that internal structure to >>> modify >>> vmcs12 directly, without vmread/vmwrite and exits. >>> >>> >> No, they can't, since (for writes) L0 might cache the information and >> not read it again. For reads, L0 might choose to update vmcs12 on demand. >> > Well, in the current version of the nested code, all L0 does on a L1 vmwrite > is to update the in-memory vmcs12 structure. It doesn't not update vmcs02, > nor cache anything, nor remember what has changed and what hasn't. So replacing > it with a direct write to the memory structure should be fine... > Note you said "current version". What if this later changes? So, we cannot allow a guest to access vmcs12 directly. There has to be a protocol that allows the guest to know what it can touch and what it can't (or, tell the host what the guest touched and what it hasn't). Otherwise, we lose the ability to optimize. > Of course, this situation isn't optimal, and we *should* optimize the number of > unnecessary vmwrites L2 entry and exit (and we actually tried some of this > in our tech report), but it's not in the current patch set. When we do these > kind of optimizations, you're right that: > > >> A pvvmread/write needs to communicate with L0 about what fields are >> valid (likely using available and dirty bitmaps). >> It's right even before we do these optimizations, so a pv guest written before the optimizations can run on an optimized host. -- error compiling committee.c: too many arguments to function