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 for Android: free password hash cracker in your pocket

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

Message-ID: <4B9FBBEA.2060508@goop.org>
Date:	Tue, 16 Mar 2010 10:12:10 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Sheng Yang <sheng@...ux.intel.com>
CC:	Stefano Stabellini <stefano.stabellini@...citrix.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 06:51 PM, Sheng Yang wrote:
> 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?
>    

I think that's a bit arbitrary.  If we need a new vcpuop to make it work 
properly anyway (set tsc offset), then the presence of that should be a 
good indicator.  In other words, make it depend on its actual fixed 
pre-reqs, rather than a specific flag for the feature.

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

What kinds of issues?

     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/