From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initialization Date: Tue, 16 Mar 2010 09:51:48 +0800 Message-ID: <201003160951.48973.sheng@linux.intel.com> References: <1268362647-5317-1-git-send-email-sheng@linux.intel.com> <4B9EBBEE.9020107@goop.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B9EBBEE.9020107@goop.org> Sender: linux-kernel-owner@vger.kernel.org To: Jeremy Fitzhardinge Cc: Stefano Stabellini , xen-devel , Ian Campbell , "Yaozu (Eddie) Dong" , "linux-kernel@vger.kernel.org" , Ian Pratt , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Tuesday 16 March 2010 06:59:58 Jeremy Fitzhardinge wrote: > On 03/15/2010 05:04 AM, Stefano Stabellini wrote: > >> But we should make sure Xen have ability to support such kind of > >> operation. The CPUID would show if Xen have such ability, and if it > >> does, the feature would be enabled unconditionally. Guest kernel always > >> enable all features it can do unconditionally, but Xen should offer the > >> support for them. > > > > In my opinion once the guest knows that is running on Xen HVM (that is > > from xen_cpuid_base() or xen_para_available()) it should assume > > that the pv clocksource is available, therefore XEN_HVM_PV_CLOCK_ENABLED > > should not be needed. > > In other words the mere presence of Xen should imply > > XEN_HVM_PV_CLOCK_ENABLED. > > The only reason why we wouldn't want to do this is if we want to > withdraw this feature at some point in the future. We're stuck with it > indefinitely for PV, but I don't know if that's necessarily going to be > the case for HVM. On the other hand, if other - better - mechanisms > become available, we can give them their own clocksource driver with a > higher priority than the Xen pvclock one, and users can still select > clocksources on the kernel command line. So you think about adding a new XENFEAT? > > > Do you mean write generic code now, then introduce the 64 bit > > limitation later? Or the other way around? > > I don't have a strong opinion here so I am OK with both approaches, but > > I would prefer to add the limitation later (maybe we'll be able to make > > it work on 32 bit too...). > > Seems like making it work for both 32 and 64-bit is the easiest thing to > do. If it is, it should be fine. But I had encountered some issues on 32 bits. -- regards Yang, Sheng