linux-kernel - Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initialization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Mar 2010 15:59:58 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Stefano Stabellini <stefano.stabellini@...citrix.com>
CC:	Sheng Yang <sheng@...ux.intel.com>,
	xen-devel <xen-devel@...ts.xensource.com>,
	Ian Campbell <Ian.Campbell@...citrix.com>,
	"Yaozu (Eddie) Dong" <eddie.dong@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ian Pratt <Ian.Pratt@...citrix.com>,
	Keir Fraser <Keir.Fraser@...citrix.com>
Subject: Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM
 initialization

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.

> 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.

     J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/