From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754787Ab3A2IgB (ORCPT ); Tue, 29 Jan 2013 03:36:01 -0500 Received: from nat28.tlf.novell.com ([130.57.49.28]:37232 "EHLO nat28.tlf.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753446Ab3A2If6 convert rfc822-to-8bit (ORCPT ); Tue, 29 Jan 2013 03:35:58 -0500 Message-Id: <510797FA02000078000BA4B8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.1 Date: Tue, 29 Jan 2013 08:35:54 +0000 From: "Jan Beulich" To: "Stefano Stabellini" , "KY Srinivasan" Cc: "Olaf Hering" , "Greg KH" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] x86: Hyper-V: register clocksource only if its advertised References: <1359121036-16309-1-git-send-email-olaf@aepfle.de> <761b736ff1854810bfe272961248e6d2@BLUPR03MB050.namprd03.prod.outlook.com> <20130125165443.GA15833@aepfle.de> <500ca90f5d3e4d4f80c7fb62c34d36f0@BLUPR03MB050.namprd03.prod.outlook.com> <20130125171923.GA19306@aepfle.de> <542f1d12e3ee46f48a85a143361c113d@SN2PR03MB061.namprd03.prod.outlook.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> On 28.01.13 at 18:44, Stefano Stabellini wrote: > I think that Olaf made his point very clear: a feature A should only be > enabled if the corresponding flag A is set. > In fact it seems to me that this patch is correct on its own merits, > regardless of Xen does or does not. > > The Xen tools might or might not know whether a guest is going to be > Linux, Windows, FreeBSD or whatever else people use nowadays. Setting > viridian=1 is the safe choice, given that it shouldn't create any > issues: after all guests are supposed to check for feature flags before > using them. > > If Xen is going to implement "Partition Reference Counter", it is also > going to set the corresponding flag, so the guest OS (Windows, Linux, > my pet OS) can check whether the feature is available and decide whether > it wants to use it. While I agree in general, the specific case of the callback vector seems a little more difficult: As KY says, there's no feature flag for this (or perhaps more precisely for it being deliverable across all CPUs), and hence there's both the problem of detection and the problem of disambiguation (as otherwise both the Hyper-V code and the Xen code in Linux could be trying to use the same vector). Jan