From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [RFC PATCH 5/16]: PVH xen: supporting changes. Date: Fri, 25 Jan 2013 09:26:26 +0000 Message-ID: <20130125092626.GA31562@ocelot.phlegethon.org> References: <20130111174851.20bac3cb@mantra.us.oracle.com> <20130124152221.GE20551@ocelot.phlegethon.org> <20130124174441.74362af0@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20130124174441.74362af0@mantra.us.oracle.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: Mukesh Rathor Cc: "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org At 17:44 -0800 on 24 Jan (1359049481), Mukesh Rathor wrote: > On Thu, 24 Jan 2013 15:22:21 +0000 > Tim Deegan wrote: > > > At 17:48 -0800 on 11 Jan (1357926531), Mukesh Rathor wrote: > > > In this patch, we make pv_cpuid() and emulate_forced_invalid_op() > > > public to be used by PVH. Also put vmx functions like vmr(), > > > get_instruction_length(), inlined in header file to be used by PVH. > > > No real code change. > > > > Please don't export vmr(). It silently suppresses errors, which is OK > > for its current use (as a helper function in the state dump) but not > > for actual guest state manipulations. > > Ok, done. Thanks. > I'll assueme it's ok to export get_instruction_length(). Yes, that's fine as long as the warnings about when it's safe to use are preserved! And, as Jan suggested, it should be renamed to vmx_get_instruction_length(). Cheers, Tim.