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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9D99C433F5 for ; Fri, 14 Jan 2022 01:10:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 38C0D49F17; Thu, 13 Jan 2022 20:10:12 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0Lbh9DkEvNB; Thu, 13 Jan 2022 20:10:11 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0AA8A49EF6; Thu, 13 Jan 2022 20:10:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B598249EED for ; Thu, 13 Jan 2022 20:10:09 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25VqRYw1ZNMD for ; Thu, 13 Jan 2022 20:10:08 -0500 (EST) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 8D1F349EE9 for ; Thu, 13 Jan 2022 20:10:08 -0500 (EST) Received: by mail-pj1-f54.google.com with SMTP id l10-20020a17090a384a00b001b22190e075so20502381pjf.3 for ; Thu, 13 Jan 2022 17:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=dfHTMu5yyfREc50x2Kq3TV4XK0N3u2/ilz/wJ1H6bEc=; b=Qp0L93h2Bp9PLGVaYi0WSJZdkp402RO5l/aQCpgeknH84r7jXsj7pSuEYA955i7rn1 W/p3e5Om59luBvf1WCuy9aMCOrdXM0d9zK5q9FPAIBUu+YPOluPJPYYDgGJHTgZdtQpc nUerIZBF1IuHj8vPAaqSwkIRpzapyybW2OQchtN+j/XvAyejjbCFcFTsNN3peB96A/cW U3rxmnuP7tXIc4sW/2zfK+HG8geZbnDbbhy93s2AOQI02kxI7/1FPXmzht3IuvE5V4jZ 2AaVVp/32HkacH3MCRJUeaGvlUbX2c5ey2lnicXWxn/xg22G9auoTekB9x32FSWgUC01 MK/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dfHTMu5yyfREc50x2Kq3TV4XK0N3u2/ilz/wJ1H6bEc=; b=DQvck7npnNGJADfZy48PaSFXsYRm0YGt124betsVZ+Sbb+/Dwa1HQsYMRGyiFNTcU+ YoILgixMEI1mE8LfnpbO8UGFBljI7+nvHeU21dM+ZMW6ndsRyIniJOT19m3o+hamDYWq yXbJG1NyvSus+GeN//mmtMzFKc0UMNDrpnz02vd++ok2Cqcu/cuoKT+h3ZL/3kG4c9/q XXQKHpuoMATDFb31Ugc3LR4E1UU6PRW5Xy96vmOmEFqhZDdmUGVjhfAlal8hrHIe4bmw pt98ka1sNL4msjvOTNMxLquLiq5KYXUeM2MasZuir9m+AuoUmfGH1S3XEzf7uaqKykL+ wTYw== X-Gm-Message-State: AOAM530LeWDMx6tDpRs7KNA7ZY9vzDopz0Sl0Mn9TpRJ0flIxFf8X5Rj VDoZ90co3tqKp/t7Mo32pbaCsg== X-Google-Smtp-Source: ABdhPJwJPF9HsoPu5KG5130tnrH/ZAmOSjZe/Jj2K4WwUe35vcCRE5fNeuBHwGHXHuwdjfoMvZZibA== X-Received: by 2002:a17:902:76c2:b0:149:7fa3:2ace with SMTP id j2-20020a17090276c200b001497fa32acemr7109949plt.64.1642122607394; Thu, 13 Jan 2022 17:10:07 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id y64sm3134915pgy.12.2022.01.13.17.10.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jan 2022 17:10:06 -0800 (PST) Date: Fri, 14 Jan 2022 01:10:03 +0000 From: Sean Christopherson To: Raghavendra Rao Ananta Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , linux-kernel@vger.kernel.org, Catalin Marinas , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, Linux ARM , Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, Jan 13, 2022, Raghavendra Rao Ananta wrote: > On Thu, Jan 13, 2022 at 9:21 AM Sean Christopherson wrote: > > If restricting updates in the arm64 is necessary to ensure KVM provides sane > > behavior, then it could be justified. But if it's purely a sanity check on > > behalf of the guest, then it's not justified. > Agreed that KVM doesn't really safeguard the guests, but just curious, > is there really a downside in adding this thin layer of safety check? It's more stuff that KVM has to maintain, creates an ABI that KVM must adhere to, potentially creates inconsistencies in KVM, and prevents using KVM to intentionally do stupid things to test scenarios that are "impossible". And we also try to avoid defining arbitrary CPU behavior in KVM (that may not be the case here). > On the bright side, the guests would be safe, and it could save the > developers some time in hunting down the bugs in this path, no? Yes, but that can be said for lots and lots of things. This is both a slippery slope argument and the inconsistency argument above, e.g. if KVM actively prevents userspace from doing X, why doesn't KVM prevent userspace from doing Y? Having a decently defined rule for these types of things, e.g. protect KVM/kernel and adhere to the architecture but otherwise let userspace do whatever, avoids spending too much time arguing over what KVM should/shouldn't allow, or wondering why on earth KVM does XYZ, at least in theory :-) There are certainly times where KVM could have saved userspace some pain, but overall I do think KVM is better off staying out of the way when possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 D7675C433EF for ; Fri, 14 Jan 2022 01:11:39 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EBf/PNFH05WZclDKH8/OvbLxkN/e/+NSx/IQpnSZZyk=; b=OdmKGI56l0V+4z zj2tkDlmy8NewrA19V/6dMXRlBJEhPcNoIkktW2yuZXNVMc4X9gxeNQvaNnSsgIe5jZtWonhUjkJ8 LYtBz6i2DO0SWTd0W2y/RMZrj8WhrkUsCIy9eByRDu6qC5kxYdp9YiCOf/LeEacOIpxwoGRU67SQC pf2lho5dX2jgTbaZBlqY0HXNWihgAj1JqCGSvwn1cChmnAaBtxAY9Crt/Fj3tb7sPOW0ciRJEtbZp nNTWg10hJFt04TsxyZ9xLWyjuoWQFs6wHkqN5lE9qCtqQ+HWuYkGy8iqDDK0VB0bQ9cymhzASvsJb bdm1lIXG/+vsJGk9YGKw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n8B6a-007OIa-SA; Fri, 14 Jan 2022 01:10:13 +0000 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n8B6X-007OHk-Hb for linux-arm-kernel@lists.infradead.org; Fri, 14 Jan 2022 01:10:10 +0000 Received: by mail-pl1-x635.google.com with SMTP id h1so11888511pls.11 for ; Thu, 13 Jan 2022 17:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=dfHTMu5yyfREc50x2Kq3TV4XK0N3u2/ilz/wJ1H6bEc=; b=Qp0L93h2Bp9PLGVaYi0WSJZdkp402RO5l/aQCpgeknH84r7jXsj7pSuEYA955i7rn1 W/p3e5Om59luBvf1WCuy9aMCOrdXM0d9zK5q9FPAIBUu+YPOluPJPYYDgGJHTgZdtQpc nUerIZBF1IuHj8vPAaqSwkIRpzapyybW2OQchtN+j/XvAyejjbCFcFTsNN3peB96A/cW U3rxmnuP7tXIc4sW/2zfK+HG8geZbnDbbhy93s2AOQI02kxI7/1FPXmzht3IuvE5V4jZ 2AaVVp/32HkacH3MCRJUeaGvlUbX2c5ey2lnicXWxn/xg22G9auoTekB9x32FSWgUC01 MK/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dfHTMu5yyfREc50x2Kq3TV4XK0N3u2/ilz/wJ1H6bEc=; b=1gJcGeT5sso/MNqd6MmJz4rH69YmVCvk881BpfRinmSiWomwn+xUAmfOCAKe++n58L toZdvYpuy6p7+z9BjGUMxrUmCtKJSTavgxpeffIrpHGqQPMEP2jczxLzTDwzjbyb6R+7 FEwxAXrbiB0VdcUi1Y1H27W3eWPO0N1kANHNTqK2PtBS7rsScru3Kh8xCBbSPf3TK7T7 WvAsruFiuQtb86Os/GhWvT3UG1doru+S0bK8XJXg+kwLonZ3U9KATJ28cojM+l8L36mk 5iFCoXwylmT9X+qNvH1XtJ5+44a7rgqXvB1TNud48ZX/Sc2Y8bN/99VPOh05UJkWeVns Hkxg== X-Gm-Message-State: AOAM532t6IIV9ZxpOlAyv/HZaOewJ+vmOOZzUwNlc2bNVN+YW6cc6N7U uO9XDuz0L12eNPjOUAaWcMqvoQ== X-Google-Smtp-Source: ABdhPJwJPF9HsoPu5KG5130tnrH/ZAmOSjZe/Jj2K4WwUe35vcCRE5fNeuBHwGHXHuwdjfoMvZZibA== X-Received: by 2002:a17:902:76c2:b0:149:7fa3:2ace with SMTP id j2-20020a17090276c200b001497fa32acemr7109949plt.64.1642122607394; Thu, 13 Jan 2022 17:10:07 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id y64sm3134915pgy.12.2022.01.13.17.10.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jan 2022 17:10:06 -0800 (PST) Date: Fri, 14 Jan 2022 01:10:03 +0000 From: Sean Christopherson To: Raghavendra Rao Ananta Cc: Jim Mattson , kvm@vger.kernel.org, Will Deacon , Marc Zyngier , Peter Shier , linux-kernel@vger.kernel.org, Catalin Marinas , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, Linux ARM Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220113_171009_618117_52B89F73 X-CRM114-Status: GOOD ( 17.98 ) 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 Thu, Jan 13, 2022, Raghavendra Rao Ananta wrote: > On Thu, Jan 13, 2022 at 9:21 AM Sean Christopherson wrote: > > If restricting updates in the arm64 is necessary to ensure KVM provides sane > > behavior, then it could be justified. But if it's purely a sanity check on > > behalf of the guest, then it's not justified. > Agreed that KVM doesn't really safeguard the guests, but just curious, > is there really a downside in adding this thin layer of safety check? It's more stuff that KVM has to maintain, creates an ABI that KVM must adhere to, potentially creates inconsistencies in KVM, and prevents using KVM to intentionally do stupid things to test scenarios that are "impossible". And we also try to avoid defining arbitrary CPU behavior in KVM (that may not be the case here). > On the bright side, the guests would be safe, and it could save the > developers some time in hunting down the bugs in this path, no? Yes, but that can be said for lots and lots of things. This is both a slippery slope argument and the inconsistency argument above, e.g. if KVM actively prevents userspace from doing X, why doesn't KVM prevent userspace from doing Y? Having a decently defined rule for these types of things, e.g. protect KVM/kernel and adhere to the architecture but otherwise let userspace do whatever, avoids spending too much time arguing over what KVM should/shouldn't allow, or wondering why on earth KVM does XYZ, at least in theory :-) There are certainly times where KVM could have saved userspace some pain, but overall I do think KVM is better off staying out of the way when possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 871B5C433EF for ; Fri, 14 Jan 2022 01:10:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235783AbiANBKI (ORCPT ); Thu, 13 Jan 2022 20:10:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229554AbiANBKI (ORCPT ); Thu, 13 Jan 2022 20:10:08 -0500 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 304B4C06161C for ; Thu, 13 Jan 2022 17:10:08 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id r16-20020a17090a0ad000b001b276aa3aabso20611481pje.0 for ; Thu, 13 Jan 2022 17:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=dfHTMu5yyfREc50x2Kq3TV4XK0N3u2/ilz/wJ1H6bEc=; b=Qp0L93h2Bp9PLGVaYi0WSJZdkp402RO5l/aQCpgeknH84r7jXsj7pSuEYA955i7rn1 W/p3e5Om59luBvf1WCuy9aMCOrdXM0d9zK5q9FPAIBUu+YPOluPJPYYDgGJHTgZdtQpc nUerIZBF1IuHj8vPAaqSwkIRpzapyybW2OQchtN+j/XvAyejjbCFcFTsNN3peB96A/cW U3rxmnuP7tXIc4sW/2zfK+HG8geZbnDbbhy93s2AOQI02kxI7/1FPXmzht3IuvE5V4jZ 2AaVVp/32HkacH3MCRJUeaGvlUbX2c5ey2lnicXWxn/xg22G9auoTekB9x32FSWgUC01 MK/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dfHTMu5yyfREc50x2Kq3TV4XK0N3u2/ilz/wJ1H6bEc=; b=qyhZJCtEdb4VzXHpu7Ng/sVCUJLFs6YWEeF7ZYDnMQP5u4fS+NoYBU7cJJfv4LoOsi R7BGugEMiHeAYbih+DuBns1G3PIwf8cwWTBcYoWYzaKEi1f4sfAbhrE/dXFoqy0oRXH+ GAgxuyrFpru7rQxLneDH23vAqJTcTB+Z2lW5rcIg+tXnXE1NWrbiIU6FCf/Y41V4f+hk LgizQErh4VTJHV0ZxlrhvJ/PPVjcXKvngIa4DUnAOXRvG1XVmXOsGmhKLS/64zFNlofZ VcMGyq/TCLqQJ7lbRc4odWiAyDekKiUxkMj/myGPI+cRyImfij7t3PXi4rKNV/4behCo P6Yw== X-Gm-Message-State: AOAM532/qOXAJ9GHKdI2zlZO7heXkKziR4iB4MKLpMrgJG49I6DZDnJP PBGIOaB53TkCUy3bwQ2E7q04aLPtTg0/Yg== X-Google-Smtp-Source: ABdhPJwJPF9HsoPu5KG5130tnrH/ZAmOSjZe/Jj2K4WwUe35vcCRE5fNeuBHwGHXHuwdjfoMvZZibA== X-Received: by 2002:a17:902:76c2:b0:149:7fa3:2ace with SMTP id j2-20020a17090276c200b001497fa32acemr7109949plt.64.1642122607394; Thu, 13 Jan 2022 17:10:07 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id y64sm3134915pgy.12.2022.01.13.17.10.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jan 2022 17:10:06 -0800 (PST) Date: Fri, 14 Jan 2022 01:10:03 +0000 From: Sean Christopherson To: Raghavendra Rao Ananta Cc: Jim Mattson , kvm@vger.kernel.org, Will Deacon , Marc Zyngier , Peter Shier , linux-kernel@vger.kernel.org, Catalin Marinas , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, Linux ARM Subject: Re: [RFC PATCH v3 01/11] KVM: Capture VM start Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Jan 13, 2022, Raghavendra Rao Ananta wrote: > On Thu, Jan 13, 2022 at 9:21 AM Sean Christopherson wrote: > > If restricting updates in the arm64 is necessary to ensure KVM provides sane > > behavior, then it could be justified. But if it's purely a sanity check on > > behalf of the guest, then it's not justified. > Agreed that KVM doesn't really safeguard the guests, but just curious, > is there really a downside in adding this thin layer of safety check? It's more stuff that KVM has to maintain, creates an ABI that KVM must adhere to, potentially creates inconsistencies in KVM, and prevents using KVM to intentionally do stupid things to test scenarios that are "impossible". And we also try to avoid defining arbitrary CPU behavior in KVM (that may not be the case here). > On the bright side, the guests would be safe, and it could save the > developers some time in hunting down the bugs in this path, no? Yes, but that can be said for lots and lots of things. This is both a slippery slope argument and the inconsistency argument above, e.g. if KVM actively prevents userspace from doing X, why doesn't KVM prevent userspace from doing Y? Having a decently defined rule for these types of things, e.g. protect KVM/kernel and adhere to the architecture but otherwise let userspace do whatever, avoids spending too much time arguing over what KVM should/shouldn't allow, or wondering why on earth KVM does XYZ, at least in theory :-) There are certainly times where KVM could have saved userspace some pain, but overall I do think KVM is better off staying out of the way when possible.