From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755175Ab3EHLsW (ORCPT ); Wed, 8 May 2013 07:48:22 -0400 Received: from wolverine02.qualcomm.com ([199.106.114.251]:26636 "EHLO wolverine02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753729Ab3EHLsU (ORCPT ); Wed, 8 May 2013 07:48:20 -0400 X-IronPort-AV: E=Sophos;i="4.87,634,1363158000"; d="scan'208";a="45318400" Message-ID: <518A3B81.3080308@codeaurora.org> Date: Wed, 08 May 2013 07:48:17 -0400 From: Christopher Covington User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Stefano Stabellini CC: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "linux@arm.linux.org.uk" , Ian Campbell , "marc.zyngier@arm.com" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , "john.stultz@linaro.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [Xen-devel] [PATCH 1/3] arm_arch_timer: introduce arch_timer_stolen_ticks References: <1367436460-10183-1-git-send-email-stefano.stabellini@eu.citrix.com> <51817CBE.4050003@codeaurora.org> <1367482772.21869.26.camel@zakaz.uk.xensource.com> <5182DBA9.9080609@codeaurora.org> <20130506143533.GF15278@phenom.dumpdata.com> <51892933.7090405@codeaurora.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/08/2013 07:19 AM, Stefano Stabellini wrote: > On Tue, 7 May 2013, Christopher Covington wrote: >> Hi Konrad, >> >> On 05/06/2013 10:35 AM, Konrad Rzeszutek Wilk wrote: >>>>> e.g. if a VCPU sets a timer for NOW+5, but 3 are stolen in the middle it >>>>> would not make sense (from the guests PoV) for NOW'==NOW+2 at the point >>>>> where the timer goes off. Nor does it make sense to require that the >>>>> guest actually be running for 5 before injecting the timer because that >>>>> would mean real time elapsed time for the timer would be 5+3 in the case >>>>> where 3 are stolen. >>>> >>>> This is a bit of an aside, but I think that hiding time spent at higher >>>> privilege levels can be a quite sensible approach to timekeeping in a >>>> virtualized environment, but I understand that it's not the approach taken >>>> with Xen, and as you pointed out above, adjusting the Virtual Offset Register >>>> by itself isn't enough to implement that approach. >>> >>> This is the approach taken by Xen and KVM. Look in CONFIG_PARAVIRT_CLOCK for >>> implementation. In the user-space, the entry in 'top' of "stolen" (%st) >>> is for this exact value. >> >> I may have been unclear with my terms, sorry. When I refer to time being >> "hidden", I mean that kernel level software (supervisor mode, EL1) cannot >> detect the passage of that time at all. I don't know whether this would really >> work, but I imagine one might be able to get close with the current >> virtualization facilities for ARM. >> >> Am I correct in interpreting that what you're referring to is the deployment >> of paravirtualization code that ensures (observable) "stolen" time is factored >> into kernel decision-making? > > Although it might be possible to hide the real time flow from the VM, it > is inadvisable: what would happen when the VM needs to deal with a real > hardware device? Or just send packets over the network? This is why it > is much safer and more reliable to expose the stolen ticks to the VM. One would probably have to emulate all the hardware. I don't mean to imply that I think this is useful for everyday virtualization, but I speculate that such an approach might enable the analysis of kernels infected with VM-detecting malware or other niche use-cases. Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation.