From patchwork Wed Jun 17 22:31:34 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 6628771 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 02B96C0020 for ; Wed, 17 Jun 2015 22:34:32 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0036B206A6 for ; Wed, 17 Jun 2015 22:34:31 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 042C22064E for ; Wed, 17 Jun 2015 22:34:30 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z5LsI-0006jm-DI; Wed, 17 Jun 2015 22:32:02 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z5LsD-0006iX-Q1 for linux-arm-kernel@lists.infradead.org; Wed, 17 Jun 2015 22:31:58 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 0BDF13663B0; Wed, 17 Jun 2015 22:31:36 +0000 (UTC) Received: from ul30vt.home (ovpn-113-72.phx2.redhat.com [10.3.113.72]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5HMVYR3031038; Wed, 17 Jun 2015 18:31:34 -0400 Message-ID: <1434580294.5628.135.camel@redhat.com> Subject: Re: [PATCH v4 0/4] VFIO platform reset From: Alex Williamson To: Eric Auger Date: Wed, 17 Jun 2015 16:31:34 -0600 In-Reply-To: <1434359385-19916-1-git-send-email-eric.auger@linaro.org> References: <1434359385-19916-1-git-send-email-eric.auger@linaro.org> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150617_153157_890788_D8EE8E3D X-CRM114-Status: GOOD ( 23.57 ) X-Spam-Score: -5.6 (-----) Cc: b.reynal@virtualopensystems.com, patches@linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, eric.auger@st.com, christoffer.dall@linaro.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 2015-06-15 at 11:09 +0200, Eric Auger wrote: > In situations where the userspace driver is stopped abnormally and the > VFIO platform device is released, the assigned HW device currently is > left running. As a consequence the HW device might continue issuing IRQs > and performing DMA accesses. > > On release, no physical IRQ handler is setup anymore. Also the DMA buffers > are unmapped leading to IOMMU aborts. So there is no serious consequence. > > However when assigning that HW device again to another userspace driver, > this latter might face some unexpected IRQs and DMA accesses, which are > the result of the previous assignment. > > In virtualization use-case, a VM newly granted with that HW device may be > impacted by the assignment of that device to a previous VM: > - IRQs may be injected very early when booting the new guest, even before > the guest driver has initialized leading to possible driver state > inconsistency. > - DMA accesses may hit the newly mapped VM address space at addresses that > may jeopardize the integrity of the newly installed VM. > > Obviously the criticity depends on the assigned HW device. > > As opposed to PCI, there is no standard mechanism to reset the platform > device. > > This series proposes to implement device specific reset functions in > separate in-kernel vfio reset modules. The vfio-platform driver holds > a whitelist of implemented triplets (compat string, module name, > reset function name). When the vfio-platform driver is probed it identifies > the fellow reset module/function matching the compat string of the > device, if any, and forces the load of this reset module. > > A first reset module is provided: the vfio-platform-calxedaxgmac > module which implements a basic reset for the Calxeda xgmac. > > The series can be found at > https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.1-rc8-reset-v4 > > History: > v3 -> v4: > - fix the commit message of "VFIO: platform: add reset struct and lookup table" Baptiste, Any comments? Should we also add something like this to MAINTAINERS before we go much further? I'm not sure what you want to be the primary list, maybe it's time to ask for a vfio list. Thanks, Alex > > v2 -> v3: > - remove void module_init/exit functions in calxeda reset module > - remove enum vfio_platform_reset_type > - for reset lookup, use ARRAY_SIZE > - in reset put use symbol_put_addr > > v1 -> v2: > - much simplified compared to v1 although principle of external modules is > kept: removed mechanism of dynamic registration of reset functions > - list is replaced by whitelist lookup table > - name of the reset function also stored in the lookup table > - autoload of reset modules > > RFC -> PATCH v1: > - solution now based on a lookup list instead of specialized driver > > > Eric Auger (4): > VFIO: platform: add reset struct and lookup table > VFIO: platform: add reset callback > VFIO: platform: populate the reset function on probe > VFIO: platform: Calxeda xgmac reset module > > drivers/vfio/platform/Kconfig | 2 + > drivers/vfio/platform/Makefile | 2 + > drivers/vfio/platform/reset/Kconfig | 7 ++ > drivers/vfio/platform/reset/Makefile | 5 ++ > .../platform/reset/vfio_platform_calxedaxgmac.c | 86 ++++++++++++++++++++++ > drivers/vfio/platform/vfio_platform_common.c | 60 ++++++++++++++- > drivers/vfio/platform/vfio_platform_private.h | 7 ++ > 7 files changed, 166 insertions(+), 3 deletions(-) > create mode 100644 drivers/vfio/platform/reset/Kconfig > create mode 100644 drivers/vfio/platform/reset/Makefile > create mode 100644 drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c > Acked-by: Baptiste Reynal Tested-by: Baptiste Reynal Reviewed-by: Baptiste Reynal diff --git a/MAINTAINERS b/MAINTAINERS index d8afd29..c6bf7f6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10545,6 +10545,12 @@ F: drivers/vfio/ F: include/linux/vfio.h F: include/uapi/linux/vfio.h +VFIO PLATFORM DRIVER +M: Baptiste Reynal +L: kvm@vger.kernel.org +S: Maintained +F: drivers/vfio/platform/ + VIDEOBUF2 FRAMEWORK M: Pawel Osciak M: Marek Szyprowski