From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qing He Subject: Re: [PATCH 10/17] vmx: nest: VMExit handler in L2 Date: Fri, 21 May 2010 00:06:06 +0800 Message-ID: <20100520160606.GD21538@qhe2-db> References: <1271929289-18572-1-git-send-email-qing.he@intel.com> <1271929289-18572-11-git-send-email-qing.he@intel.com> <20100520114414.GQ4164@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20100520114414.GQ4164@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, 2010-05-20 at 19:44 +0800, Tim Deegan wrote: > At 10:41 +0100 on 22 Apr (1271932882), Qing He wrote: > > + > > + case VMX_EXIT_REASONS_FAILED_VMENTRY: > > + case EXIT_REASON_TRIPLE_FAULT: > > + case EXIT_REASON_TASK_SWITCH: > > + case EXIT_REASON_IO_INSTRUCTION: > > + case EXIT_REASON_CPUID: > > + case EXIT_REASON_MSR_READ: > > + case EXIT_REASON_MSR_WRITE: > > Aren't these gated on a control bitmap in the L1 VMCS? > cpuid is unconditional io and msr are controlled through bitmaps, but they are turned off in the capability reporting > > + case EXIT_REASON_HLT: > > + case EXIT_REASON_RDTSC: > > + case EXIT_REASON_RDPMC: > > + case EXIT_REASON_MWAIT_INSTRUCTION: > > + case EXIT_REASON_PAUSE_INSTRUCTION: > > + case EXIT_REASON_MONITOR_INSTRUCTION: > > + case EXIT_REASON_DR_ACCESS: > > + case EXIT_REASON_INVLPG: > > + { > > + int i; > > + > > + /* exit according to guest exec_control */ > > + ctrl = __get_vvmcs(nest->vvmcs, CPU_BASED_VM_EXEC_CONTROL); > > + > > + for ( i = 0; i < ARRAY_SIZE(control_bit_for_reason); i++ ) > > + if ( control_bit_for_reason[i].reason == exit_reason ) > > + break; > > You've already got a switch statement - why not gate these individually > rather than bundling them together and scanning an array? > Well, they are the `regular' part of exit handling, a bit in the control bitmap corresponds to their behavior > > + if ( nest->vmexit_pending ) > > + bypass_l0 = 1; > > This variable doesn't seem to do anything useful. This is a preparation for those doesn't generate virtual vmexit but need to bypass normal L0 exit handler > > > + return bypass_l0; > > +} > > Cheers, > > Tim. > > -- > Tim Deegan > Principal Software Engineer, XenServer Engineering > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)