Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754382Ab0BBQYK (ORCPT ); Tue, 2 Feb 2010 11:24:10 -0500 Received: from smtp.citrix.com ([66.165.176.89]:64593 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347Ab0BBQYI (ORCPT ); Tue, 2 Feb 2010 11:24:08 -0500 X-IronPort-AV: E=Sophos;i="4.49,391,1262581200"; d="scan'208";a="7047353" Subject: Re: [Xen-devel] [PATCH 6/6] xen/hybrid: Enable grant table and xenbus From: Ian Campbell To: Sheng Yang CC: Jeremy Fitzhardinge , Keir Fraser , xen-devel , "linux-kernel@vger.kernel.org" In-Reply-To: <201002022124.41019.sheng@linux.intel.com> References: <1265098747-10117-1-git-send-email-sheng@linux.intel.com> <1265098747-10117-7-git-send-email-sheng@linux.intel.com> <1265110390.2965.22456.camel@zakaz.uk.xensource.com> <201002022124.41019.sheng@linux.intel.com> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Tue, 2 Feb 2010 16:24:04 +0000 Message-ID: <1265127844.24394.613.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1418 Lines: 34 On Tue, 2010-02-02 at 13:24 +0000, Sheng Yang wrote: > > I am not sure if I understand you right, but I think the issue is, > there is no PVonHVM drivers in Linux upstream. The drivers are > currently maintained by OSVs, and the one in Xen upstream code only > support 2.6.18. So I didn't take them into consideration at the time. True, but this is something which should be taken care of by the core Xen-aware code not something which should be pushed down into each driver. Someone who wants to add PVonHVM functionality shouldn't have to go and remove a bunch of conditionals from each driver (or worse add alternative clauses to each check!). > I think the "xen_evtchn_enable()" looks much better. Would replace > these ugly lines in the next version. I think it would be cleaner to encapsulate this in the evtchn code rather than leaking platform knowledge into each driver. IOW the evtchn functions should return failure if event channels are not enabled and the driver should cope with this gracefully. Or perhaps at the xenbus driver level we should be deciding whether or not we have enough paravirtualisation to be worth probing the drivers at all? Ian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/