From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] tools/hvmloader: move shared_info to reserved memory area Date: Fri, 26 Oct 2012 07:58:19 -0400 Message-ID: <20121026115817.GA27383@localhost.localdomain> References: <20121025114645.GA7218@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20121025114645.GA7218@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering Cc: Keir Fraser , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, Oct 25, 2012 at 01:46:45PM +0200, Olaf Hering wrote: > On Thu, Oct 25, Keir Fraser wrote: > > > To be honest, given that the XenPVHVM extensions to Linux won't have been > > tested on such old hypervisors, it wouldn't be a bad thing to bail on > > setting up the extensions when you detect running on a really old Xen > > version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing > > more harm than good? > > I could stick such a check into > arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the > code of xen_hvm_platform and init_hvm_pv_info. Konrad, what do you > think about that? Recent changes indicate that you did some testing on > 3.4 based hosts. Sure. It might make sense to streamline this a bit. Meaning after the version check, have an int (or function) called 'xen_old_hypervisor()' which your code and the XenBus code could call? That way on ARM that function can just become a nop while on X86 we do the cpuids (or if those had already been done - we just return true or false).