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 8508DCDB474 for ; Fri, 20 Oct 2023 11:22:31 +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=v+MhOOXzU1z/uVJe34GBx4h06bUl6+h8OL/6YHuXZfo=; b=xU6QuqmBtP7SLG dF2oa3g5a0U9qzm4zZ4ywb1yHyu7DNemAqVBvns/XxQnWk6WURAsanXXUeRLZjMDtu11OMzaHGz1s 9KbGaCtszL2VZYinhRSTsOznDBM+OhNBGNlIRYkSK3dSyUb284gY/c6ovnzRrDXoljhlvfK6rXeN1 5xpZkChd+i1q3nAqF9rF63a3MGJzKU0OOSgE7A7ZGK5OgFdbxq0/OMcowS5V6mOvopUwxzI/7Ehvx RHhQhTK+M8KvsrfzrwXP8Th3YqgYEts+5tWHpDfQj43wIj7ADg/jWHN9m8DRrOkd5IlGIu1lVNFdl UQIqGhPVqQugdqmDDniQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qtnZp-00283P-2b; Fri, 20 Oct 2023 11:22:01 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qtnZn-00282e-1F for linux-arm-kernel@lists.infradead.org; Fri, 20 Oct 2023 11:22:00 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 0EE56CE3730; Fri, 20 Oct 2023 11:21:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B91DC433C8; Fri, 20 Oct 2023 11:21:53 +0000 (UTC) Date: Fri, 20 Oct 2023 12:21:50 +0100 From: Catalin Marinas To: Jason Gunthorpe Cc: Will Deacon , Lorenzo Pieralisi , ankita@nvidia.com, maz@kernel.org, oliver.upton@linux.dev, aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com, targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com, apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 2/2] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory Message-ID: References: <20231012123541.GB11824@willie-the-truck> <20231012144807.GA12374@willie-the-truck> <20231013092934.GA13524@willie-the-truck> <20231013134541.GP3952@nvidia.com> <20231019115142.GQ3952@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231019115142.GQ3952@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231020_042159_599090_C88EF175 X-CRM114-Status: GOOD ( 20.42 ) 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, Oct 19, 2023 at 08:51:42AM -0300, Jason Gunthorpe wrote: > On Thu, Oct 19, 2023 at 12:07:42PM +0100, Catalin Marinas wrote: > > Talking to Will earlier, I think we can deem the PCIe scenario > > (somewhat) safe but not as a generic mechanism for other non-PCIe > > devices (e.g. platform). With this concern, can we make this Stage 2 > > relaxation in KVM only for vfio-pci mappings? I don't have an example of > > non-PCIe device assignment to figure out how this should work though. > > It is not a KVM problem. As I implied above it is VFIO's > responsibility to reliably reset the device, not KVMs. If for some > reason VFIO cannot do that on some SOC then VFIO devices should not > exist. > > It is not KVM's job to double guess VFIO's own security properties. I'd argue that since KVM is the one relaxing the memory attributes beyond what the VFIO driver allows the VMM to use, it is KVM's job to consider the security implications. This is fine for vfio-pci and Normal_NC but I'm not sure we can generalise. > Specifically about platform the generic VFIO platform driver is the > ACPI based one. If the FW provides an ACPI method for device reset > that is not properly serializing, that is a FW bug. We can quirk it in > VFIO and block using those devices if they actually exist. > > I expect the non-generic VFIO platform drivers to take care of this > issue internally with, barriers, read from devices, whatver is > required to make their SOCs order properly. Just as I would expect a > normal Linux platform driver to directly manage whatever > implementation specific ordering quirks the SOC may have. This would be a new requirement if an existing VFIO platform driver relied on all mappings being Device. But maybe that's just theoretical at the moment, are there any concrete examples outside vfio-pci? If not, we can document it as per Lorenzo's suggestion to summarise this discussion under Documentation/. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel