From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9240153E13 for ; Mon, 11 Dec 2023 22:57:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Cwi9buOC" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-5de8c2081d1so42034207b3.1 for ; Mon, 11 Dec 2023 14:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702335422; x=1702940222; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=XLiTtRRqM+qNBV6tYcuiNPBMTUo4FdzTRXinHk4XXSY=; b=Cwi9buOCGKlpuG1lHoACs47f26uonCRt8VjufKI2DI8HsOdcx3VkjmGszbKcwTUdbQ jb7lNDb+SZPhrWrX1LJKJq1F/fIS5ES86A6NnpWmDdCOxgMCCYgVjr5f278G82IM/PPI CUsV1ajOR6wvVDcB2K0Lrxu6+sotdlTcC4bp/uh5Z94jF9H70gF5yhOXkWfVYzZ/E7nV fIqFOLTFI30YsV1G93mNMj9RYQPHtiK3tFa7TvGDY3/gkul35wbkRlP3S9Zu7ImDB6jY uq7WepA+SNGczm57YfdQl1AOVSngKt3DkCCxwq+C4nc+sx/V5JtLz4YpuulCwyCs6+jO mylw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702335422; x=1702940222; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XLiTtRRqM+qNBV6tYcuiNPBMTUo4FdzTRXinHk4XXSY=; b=NLCORjxjTFeyejmqIQZr67u7ra8Bm8TI0k/VHTQ/KV5/1M1HQVAzKxRYqmIqc8wrbj DowTMA/fllVnbRZ2oPT1epzhWN22QqI1qomB14q7EMmM5/cdQGdeM8vHE6duBro6acMf LNDKqA9kqY5dVu6YiOzXWQ2yQDSEpIQyN3KuRrqN9dDYuLRhZEy37BDYzRNsEtTHp7sL lhyHI3IL+l8r1nVYcrgwPys1i1IuLCzj+naczCxajs5kOuld/kXndVpqsB+pPiAI/obZ YkkxOqMaL7qfB0LDhsJ52tGOVz/n+6LYla22G8xlEkPnk8hSufPFibgYC5qgVltVgidT 9YIw== X-Gm-Message-State: AOJu0YxyWg1lRLFZO/PsNL8fXSFebeNfxxu4XqdeYo6WPdo4WxEJKHlz f0lPlOWHyX5wICmOVCBCpdqWFt4kjnk= X-Google-Smtp-Source: AGHT+IEhhypj7D/PwqeFaL95W7v5NUceMg/HzzkyowCvBZn3QIeqdswnpmg0GcBg4W9bI7RZryt2AT+W5iM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:c01:b0:5d1:104a:acb5 with SMTP id cl1-20020a05690c0c0100b005d1104aacb5mr53522ywb.2.1702335422457; Mon, 11 Dec 2023 14:57:02 -0800 (PST) Date: Mon, 11 Dec 2023 14:57:00 -0800 In-Reply-To: <865y16b6cf.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <865y16b6cf.wl-maz@kernel.org> Message-ID: Subject: Re: [PATCH v3 1/5] KVM: Add arch specific interfaces for sampling guest callchains From: Sean Christopherson To: Marc Zyngier Cc: Tianyi Liu , pbonzini@redhat.com, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org, mark.rutland@arm.com, mlevitsk@redhat.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, namhyung@kernel.org, irogers@google.com, adrian.hunter@intel.com Content-Type: text/plain; charset="us-ascii" On Sun, Dec 10, 2023, Marc Zyngier wrote: > On Sun, 10 Dec 2023 08:12:18 +0000, Tianyi Liu wrote: > > +bool kvm_arch_vcpu_read_virt(struct kvm_vcpu *vcpu, gva_t addr, void *dest, unsigned int length) > > +{ > > + /* TODO: implement */ > > + return false; > > +} > > I don't do it very often, but the only thing I can say about this is > *NAK*. > > You have decided to ignore the previous review comments, which is your > prerogative. However, I absolutely refuse to add half baked and > *dangerous* stuff to the arm64's version of KVM. > > If you can convince the x86 folks that they absolutely want this, fine > by me. But this need to be a buy-in interface, not something that is > required for each and every architecture to have stubs, wrongly > suggesting that extra work is needed. > > For arm64, the way to go is to have this in userspace. Which is both > easy to implement and safe. And until we have such a userspace > implementation as a baseline, I will not consider a kernel > version. I too want more justification of why this needs to be handled in the kernel[*]. The usefulness of this is dubious for many modern setups/workloads, and outright undesirable for some, e.g. many (most?) cloud providers want to make it all but impossible to access customer data. [*] https://lore.kernel.org/all/ZSlNsn-f1j2bB8pW@FVFF77S0Q05N.cambridge.arm.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 45C5BC4167B for ; Mon, 11 Dec 2023 22:57:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=4ynJ9qmqM5q9YxXMIgoyaNyJ4OkD9kYiqrmP4VjmGIk=; b=GyKbsP/dy84NQy2y9rZyWjUe/g bF4CghTcThsHKOTHoHg2HaZCKTGSY2pxm9qjMgFJUtgMR0Oz8oUXqauJpDzX5m72YJWZH9P11Ks8V GE3z182xaBbm048uYwVxTtXjXEYAoj5TiMVZcupDApc9pW2Wy/+6Kzd5gbrj7odlTxDiaipbFPUJO EOGBZ9ZfLs42vG61nS1vQ0DnoSEuw+KMwp6poTNpgqyXAbtSGv7GcjSvb5Ppu39+LMar/TvUdGm/L cZ3R3V8/KBw/fOo0C7tlqTd9Fc3D1CraZSUWDgW+CNGxh8uIOyXX/3w9x27Wbas/jSMV8gVaVULd8 P2Yzr4Rw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rCpD2-009Q1J-2E; Mon, 11 Dec 2023 22:57:08 +0000 Received: from mail-yw1-x1149.google.com ([2607:f8b0:4864:20::1149]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rCpCy-009Pwp-2u for linux-arm-kernel@lists.infradead.org; Mon, 11 Dec 2023 22:57:06 +0000 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5e1b9b10dc0so4055797b3.2 for ; Mon, 11 Dec 2023 14:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702335422; x=1702940222; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=XLiTtRRqM+qNBV6tYcuiNPBMTUo4FdzTRXinHk4XXSY=; b=buX9plBf74USn2M8OMHZrKJQbd3AWD1EYpKmA18v1AfWk97R5orXKCvMUBrO6nrzwJ 8lCevqm7/j4wfuL7f94WyjneiY3dVRb1u51Q45y030Qqiqc0Fv8Izu7+do4Ex22Unqfx BIScbpSKRQDf6XRdm+u6izwGH/rgcB0J4gs6ecjoDk9lrpOArSk2K4byZxMCXjOzORBc +VmxvhLCU9LBvz+1LzS9I0Z4RAMZfOqHmDr5naZJSP3HiP56InOPIrXfox64GDTz1gVE 0EmB7YZQNevbCL/aUOIvpcMROYguaJsOKV8tEjzzdwxaISGFVOcT7w3OGlfvkKXuC3mf 98UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702335422; x=1702940222; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XLiTtRRqM+qNBV6tYcuiNPBMTUo4FdzTRXinHk4XXSY=; b=dW2oD4sLkUUri4rqEFziPIMGjOLaII3dOB1cwX1ifHzKBHEM/lsnV/58VGXgkNckNw IffGwfNYR9S0v1ZopHuhZs3PgtnfEBftdgC+M3UtdEe3Jg4AC05bQkjksBWc3FsPx4eR awQK5PfjtA7xYv7AwWhosgce7zSxvq88Vr5Q2CAPayDS6PGDiLIeKzSXSFeuo8YANnp6 /MJI3n1kbLePJ5/EqC9vWwZa8WhU2A98FCIS9qdIBYhgZW5E0DYKGs6KRzCFo8ISZH0T RNby9japA7aUpQgsAdVQqJJfAXrA8ZoB+jOn49MOs9MX2VlTPnAWFUzoTQwRl7Jh05YI vFsA== X-Gm-Message-State: AOJu0YzAnWZZwNvhfN821uQTMtsrA053jQ92tka2OBHaLUW6Gqf3GLbc OR/Y8LNtd7b1tuc66qGwybpAueJukXc= X-Google-Smtp-Source: AGHT+IEhhypj7D/PwqeFaL95W7v5NUceMg/HzzkyowCvBZn3QIeqdswnpmg0GcBg4W9bI7RZryt2AT+W5iM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:c01:b0:5d1:104a:acb5 with SMTP id cl1-20020a05690c0c0100b005d1104aacb5mr53522ywb.2.1702335422457; Mon, 11 Dec 2023 14:57:02 -0800 (PST) Date: Mon, 11 Dec 2023 14:57:00 -0800 In-Reply-To: <865y16b6cf.wl-maz@kernel.org> Mime-Version: 1.0 References: <865y16b6cf.wl-maz@kernel.org> Message-ID: Subject: Re: [PATCH v3 1/5] KVM: Add arch specific interfaces for sampling guest callchains From: Sean Christopherson To: Marc Zyngier Cc: Tianyi Liu , pbonzini@redhat.com, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org, mark.rutland@arm.com, mlevitsk@redhat.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, namhyung@kernel.org, irogers@google.com, adrian.hunter@intel.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231211_145704_959377_79399CFA X-CRM114-Status: GOOD ( 17.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Dec 10, 2023, Marc Zyngier wrote: > On Sun, 10 Dec 2023 08:12:18 +0000, Tianyi Liu wrote: > > +bool kvm_arch_vcpu_read_virt(struct kvm_vcpu *vcpu, gva_t addr, void *dest, unsigned int length) > > +{ > > + /* TODO: implement */ > > + return false; > > +} > > I don't do it very often, but the only thing I can say about this is > *NAK*. > > You have decided to ignore the previous review comments, which is your > prerogative. However, I absolutely refuse to add half baked and > *dangerous* stuff to the arm64's version of KVM. > > If you can convince the x86 folks that they absolutely want this, fine > by me. But this need to be a buy-in interface, not something that is > required for each and every architecture to have stubs, wrongly > suggesting that extra work is needed. > > For arm64, the way to go is to have this in userspace. Which is both > easy to implement and safe. And until we have such a userspace > implementation as a baseline, I will not consider a kernel > version. I too want more justification of why this needs to be handled in the kernel[*]. The usefulness of this is dubious for many modern setups/workloads, and outright undesirable for some, e.g. many (most?) cloud providers want to make it all but impossible to access customer data. [*] https://lore.kernel.org/all/ZSlNsn-f1j2bB8pW@FVFF77S0Q05N.cambridge.arm.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel