From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [RFC] Re-introduce VCPUOP_register_vcpu_info back for PVHVM guests. (v1) Date: Wed, 17 Apr 2013 17:24:46 +0100 Message-ID: <516ECCCE.9080904@eu.citrix.com> References: <1366146586-20377-1-git-send-email-konrad.wilk@oracle.com> <516EE8AB02000078000CE4B2@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <516EE8AB02000078000CE4B2@nat28.tlf.novell.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: Jan Beulich Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 17/04/13 17:23, Jan Beulich wrote: >>>> On 17.04.13 at 17:31, George Dunlap wrote: >> On Tue, Apr 16, 2013 at 10:09 PM, Konrad Rzeszutek Wilk >> wrote: >>> Hey Jan, >>> >>> While I've been digging around CPU hotplug for PVHVM I noticed an oddity >>> when running with different versions of hypervisor. I found out that the >>> big change you did in Xen 4.2 of splitting the PV and HVM arch structure >>> introduce the regression wherein VCPUOP_register_vcpu_info will not >>> work for PVHVM guests. >>> >>> Interestingly enough if I introduce this back to the hypervisor the >>> CPU hotplug path gets even more broken for PVHVM :-).. But that is a Linux >>> problem. >> Except that we really don't want to be trashing people's existing, >> working versions of Linux, especially if they're distro-provided >> kernels. I haven't tested a distro kernel yet, but for my own >> locally-built 2.6.37 kernel, this c/s breaks it running in PVHVM mode. > Hmm - that's minimally a reason to not backport it to 4.2, but > perhaps even a reason to revert it from staging. Hold off on reverting it -- I thought I had clearly shown it to be the c/s that breaks things, but now it's not so clear... really frustrating dealing w/ the build system right now... -George