Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp491072ybl; Fri, 30 Aug 2019 02:53:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqytIUKgEJ80qrhQe9qxs6zisr7LAFC07/Yys5mTQkbC8e3BdR4un0rtYOsdCoCPl+xU0eNX X-Received: by 2002:a17:902:2f05:: with SMTP id s5mr14882864plb.170.1567158798138; Fri, 30 Aug 2019 02:53:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567158798; cv=none; d=google.com; s=arc-20160816; b=M/XggyF1kyr8Y0AEJ1B2pYScDEhk4iag3iBQZ0dTGSVMzaJ4tK8uBna+6y4vatbv6L EygMrXUUZxyZZ1oepWnGaJinFW3he6WDvnRWDx8q14nfunZx0ESzDJfXZMltyfa+DT7d 85gf0Tr+8YCygJ4His+aYvk1yycI11TDVx/N78VQp6mkNWuGA73slK+YDpbl0EVz+kEv T3wjgt8Dx2WxKj2Usa/pCwQKnBkuHoD8Fi1A45nPb5bJoo+td8FelkXUhD5GQYxK3jSm Bgg5s3e8H8hCDIZiFxo2W0EfXqgNFPlGdbQ5vySBl4JqJWT1VWDCX6rBi+5Himfr2Y6/ wGSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Q92AZ33GMgNsLPQlvf84AmUlGlzcTTx58bN8qOBFkF0=; b=ZGb8hUllmHUxV0D7ekyugbt+g7SLBZ2MQGG2UpCAzDIqCq+Xw3TVUQxHXV0eSRntVH EBJgiJAkM3eBx3PHb8/lIgVMJh8F+uD6hNIglhKWcE/3HjzAaq0PNFfA9yB4R5wkBnui uD+xZjAh/cOs/xQCxbjeHrTDo+HMXviqBgpF/GrkTIlM8ARd9CobJbgNHiPMKHwi9xWt abn1CGOjms6iomM/GohoqiBK6O/L6por2zW1tN+UvtwHrAkI7EBi3/crDbQyostRGANp /MYaXTRsqzMvwWawxQOjFWmfdF8UgDNtiHuBmoZM2UK9KADeBl73AcWiTm+TKIgXAKLb eq9w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k25si5165866pfi.265.2019.08.30.02.53.02; Fri, 30 Aug 2019 02:53:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727756AbfH3JwK (ORCPT + 99 others); Fri, 30 Aug 2019 05:52:10 -0400 Received: from foss.arm.com ([217.140.110.172]:57630 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727242AbfH3JwJ (ORCPT ); Fri, 30 Aug 2019 05:52:09 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C85E8344; Fri, 30 Aug 2019 02:52:08 -0700 (PDT) Received: from [10.1.196.133] (e112269-lin.cambridge.arm.com [10.1.196.133]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 23C263F718; Fri, 30 Aug 2019 02:52:07 -0700 (PDT) Subject: Re: [PATCH v4 05/10] KVM: arm64: Support stolen time reporting via shared structure To: Christoffer Dall Cc: kvm@vger.kernel.org, linux-doc@vger.kernel.org, Marc Zyngier , linux-kernel@vger.kernel.org, Russell King , Catalin Marinas , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org References: <20190830084255.55113-1-steven.price@arm.com> <20190830084255.55113-6-steven.price@arm.com> <20190830094245.GB5307@e113682-lin.lund.arm.com> From: Steven Price Message-ID: Date: Fri, 30 Aug 2019 10:52:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190830094245.GB5307@e113682-lin.lund.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/08/2019 10:42, Christoffer Dall wrote: > On Fri, Aug 30, 2019 at 09:42:50AM +0100, Steven Price wrote: >> Implement the service call for configuring a shared structure between a >> VCPU and the hypervisor in which the hypervisor can write the time >> stolen from the VCPU's execution time by other tasks on the host. >> >> The hypervisor allocates memory which is placed at an IPA chosen by user >> space. The hypervisor then updates the shared structure using >> kvm_put_guest() to ensure single copy atomicity of the 64-bit value >> reporting the stolen time in nanoseconds. >> >> Whenever stolen time is enabled by the guest, the stolen time counter is >> reset. >> >> The stolen time itself is retrieved from the sched_info structure >> maintained by the Linux scheduler code. We enable SCHEDSTATS when >> selecting KVM Kconfig to ensure this value is meaningful. >> >> Signed-off-by: Steven Price [...] >> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init) >> +{ >> + struct kvm *kvm = vcpu->kvm; >> + u64 steal; >> + u64 steal_le; >> + u64 offset; >> + int idx; >> + u64 base = vcpu->arch.steal.base; >> + >> + if (base == GPA_INVALID) >> + return -ENOTSUPP; >> + >> + /* Let's do the local bookkeeping */ >> + steal = vcpu->arch.steal.steal; >> + steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal; >> + vcpu->arch.steal.last_steal = current->sched_info.run_delay; >> + vcpu->arch.steal.steal = steal; >> + >> + steal_le = cpu_to_le64(steal); >> + idx = srcu_read_lock(&kvm->srcu); >> + if (init) { >> + struct pvclock_vcpu_stolen_time init_values = { >> + .revision = 0, >> + .attributes = 0 >> + }; >> + kvm_write_guest(kvm, base, &init_values, >> + sizeof(init_values)); >> + } >> + offset = offsetof(struct pvclock_vcpu_stolen_time, stolen_time); >> + kvm_put_guest(kvm, base + offset, steal_le, u64); > > Let's hope we don't have thousands of memslots through which we have to > do a linear scan on every vcpu load after this. If that were the case, > I think the memslot search path would have to be updated anyhow. Yes I'm not sure with the current memslot implementation it is actually beneficial to split up the stolen time structures into separate memslots. But there's nothing requiring the use of so many memslots. If this is really a problem it would be possible to implement a memslot-caching kvm_put_guest(), but I'd want to wait until someone shows there's actually a problem first. > Otherwise looks reasonable to me. Great, thanks for the review. Steve