From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH] tools/hvmloader: move shared_info to reserved memory area Date: Fri, 26 Oct 2012 16:08:20 +0200 Message-ID: <20121026140820.GA11453@aepfle.de> References: <20121025114645.GA7218@aepfle.de> <20121026115817.GA27383@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20121026115817.GA27383@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Keir Fraser , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, Oct 26, Konrad Rzeszutek Wilk wrote: > 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? Oh, my take would be to return false in xen_hvm_platform if the hypervisor is 3.3 or older, so that the guest does not use the PVonHVM extensions. Olaf