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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EACADC3A59F for ; Thu, 29 Aug 2019 08:48:08 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BA49E20644 for ; Thu, 29 Aug 2019 08:48:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA49E20644 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3G6B-0006jT-Ra for qemu-devel@archiver.kernel.org; Thu, 29 Aug 2019 04:48:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59380) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3G54-0006E1-J1 for qemu-devel@nongnu.org; Thu, 29 Aug 2019 04:46:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i3G53-0000Pd-6u for qemu-devel@nongnu.org; Thu, 29 Aug 2019 04:46:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48768) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i3G52-0000PN-Un for qemu-devel@nongnu.org; Thu, 29 Aug 2019 04:46:57 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3BAF98B5FF0; Thu, 29 Aug 2019 08:46:56 +0000 (UTC) Received: from [10.36.116.105] (ovpn-116-105.ams2.redhat.com [10.36.116.105]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5844E5D6B2; Thu, 29 Aug 2019 08:46:44 +0000 (UTC) To: Peter Xu References: <20190812074531.28970-1-peterx@redhat.com> <319f1d6a-ef55-cc1b-98d6-f99b365bd88a@redhat.com> <20190829011850.GC8729@xz-x1> <20190829082153.GH8729@xz-x1> From: Auger Eric Message-ID: <85b87150-9414-00e6-86a3-cf92f1ca6f7c@redhat.com> Date: Thu, 29 Aug 2019 10:46:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190829082153.GH8729@xz-x1> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.69]); Thu, 29 Aug 2019 08:46:56 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH RFC 0/4] intel_iommu: Do sanity check of vfio-pci earlier X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , Eduardo Habkost , "Michael S. Tsirkin" , Bandan Das , Jason Wang , qemu-devel@nongnu.org, Alex Williamson , Paolo Bonzini , Igor Mammedov , Richard Henderson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi Peter, On 8/29/19 10:21 AM, Peter Xu wrote: > On Thu, Aug 29, 2019 at 10:05:27AM +0200, Auger Eric wrote: >> Hi Peter, > > Hi, Eric, > >> On 8/29/19 3:18 AM, Peter Xu wrote: >>> On Wed, Aug 28, 2019 at 02:59:45PM +0200, Auger Eric wrote: >>>> Hi Peter, >>> >>> Hi, Eric, >>> >>> [...] >>> >>>> In >>>> [PATCH v4 2/5] memory: Add IOMMU_ATTR_HW_NESTED_PAGING IOMMU memory >>>> region attribute (https://patchwork.kernel.org/patch/11109701/) >>> >>> [1] >>> >>>> >>>> [PATCH v4 3/5] hw/vfio/common: Fail on VFIO/HW nested paging detection >>>> (https://patchwork.kernel.org/patch/11109697/) >>>> >>>> I proposed to introduce a new IOMMU MR attribute to retrieve whether the >>>> vIOMMU uses HW nested paging to integrate with VFIO. I wonder whether >>>> this kind of solution would fit your need too. >>>> >>>> Assuming we would rename the attribute (whose name is challenged by >>>> Peter anyway) into something like IOMMU_ATTR_PHYS_MAP_MODE >>>> taking the possible values: NONE, CM, HW_NESTED_PAGING. SMMUv3 would >>>> return HW_NESTED_PAGING, Intel IOMMU would return CM if CM is enabled or >>>> NONE in the negative. Then we could implement the check directly in VFIO >>>> common.c. That way I don't think you would need the new notifiers and >>>> this would satisfy both requirements? >>> >>> IMHO it'll suffer from the similar issue we have now with >>> flag_changed, because at the very beginning of x86 system boots DMAR >>> is not yet enabled, the intel-iommu device is using the same mode as >>> its passthrough mode so there's no IOMMU memory region at all in the >>> DMA address spaces of the devices. >> >> Ah OK I did not get this initially. We don't have this issue with SMMUv3 >> as the IOMMU MR exists from the very beginning and does not depend on >> its enablement by the guest. Also it stays there. So the detection can >> be made immediatly. > > True. With that, I'm a bit curious on whether ARM should implement > something like PT mode of Intel's. For example, have you tried to run > a ARM guest with both a vSMMU and a vfio-pci inside, however keep DMAR > disabled? IIUC in that case there will be no mapping at all for the > assigned device, then would that work? Or is there any magic for ARM? If I understand correctly PT mode is a bypass mode. With the ARM SMMUv3 the IOMMU MR translate() function gets called but implements a direct mapping. I understand that on your side, you destroy the IOMMU MR, right? At the moment since SMMUv3/VFIO integration is not ready I plan to forbid any usage of VFIO along with SMMUv3, whatever the enable state. When HW nested paging gets ready, the stage1 bypass state will be propagated to the HW config structure. Hope I answer your question. Thanks Eric > > Regards, >