From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D962E2405F9 for ; Thu, 3 Apr 2025 07:31:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743665495; cv=none; b=UEMA6+Sli+41JjaBAFDZRq1dIHutGP/Ko3Sg4N8gI73UmE7BhpaGMqiErZx+ATnvtVpKrZadZ0rLmFCj7Vt1NGW3VBCeTT38U+eSWSavdRVGeBCpiuHJC8Uaj6mrA471OAx7PrjRSGGCiXYjchn0TyD67Y3aytwwKSK8LDNmI6U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743665495; c=relaxed/simple; bh=gadWXU6eh61A4qPirA1UOUEnFFW8TKcydrcWHCVIMo4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: In-Reply-To:Content-Type:Content-Disposition; b=pF4qgaJday/ad6KTSDa1HJ7ugdOf2iT9qFx0Oc4g9GeAzVYPH6ZtztPWHZN8SmDsIJ63tb7l9UyKQSBIrkCIPJk+IZyZlr9Dcc03wjzPQ6miizlTSZveYufwWH9KKzLI5RMEuZLzUFH/cX9ORfeUjOTix8UTSNCiirJzd4yy6y8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IVeDKWEl; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IVeDKWEl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743665492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cqLi9hga+rUbDTsLYNtIpJzcY52jbaY8MlNYMQISxiY=; b=IVeDKWElhD9tc9P0WQxulYZlNQLGKzSpsgVYtkYBfR0KFE5z6sjl9ey+22s/u9C+sMuT+1 yY6so4+abXXm0DdbnhaTkLCGJLPzNIW1vVO7UJ37XdbkUOjzlGwFWYUtpq4IMUJ6yodvrT gdS8O2LP+5QBr+kxSPH2Nlp3pJXlI2A= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-451-JtRGKS4RNiO_MrU51jWL-Q-1; Thu, 03 Apr 2025 03:31:31 -0400 X-MC-Unique: JtRGKS4RNiO_MrU51jWL-Q-1 X-Mimecast-MFC-AGG-ID: JtRGKS4RNiO_MrU51jWL-Q_1743665491 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4394c489babso2609985e9.1 for ; Thu, 03 Apr 2025 00:31:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743665490; x=1744270290; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cqLi9hga+rUbDTsLYNtIpJzcY52jbaY8MlNYMQISxiY=; b=mFceJiwgtcec6k3gknbqI5YIgvc3kAP7b7N1HTKu7yEs048EIiGYq03lAPimuY7F4R LNKiFinBDRNSLNME/ZGZiUd/MCfxspPb3vkIwbX//9GdUlfI3JVz8OXgp3nR2ZeZm4Ro yTj9c9lWT7/1cNEV3yasVcTfqTpM7ovQLfWIXGP38EVLkwndLLqHj1niXwLuewN1IDQe KpaD02Zok71L8pX7fKXS1iAbUjllpWUtKVH4M/itxkxd82sBo7S4mcotZ9hO2bi9q1ST sIl5Gsx9kKLvrKcs6IbiHY0SJhDIy/qNUC+mNbyKsWvUoD47FJUfUSzwze6P0M/JOlU4 WeiA== X-Gm-Message-State: AOJu0YwIECgwKlxC/O3DsB436/Ys5yCcJOqj1Vkf2cnh5vbtr3+HhA33 ARTzF2p/ot1Z8HAYCw+mbrqmRYD9N/uxdGN+pHLgY0H78h0PutN0ywFFWp7ENnd98CHXSca2NCV gDxRP2KRQCdoy0XZewgJnLb1Os0AEF2R4w+/3XX7K8/sNilz2BIlsOjXAstpvGu2vgXq8BnI3 X-Gm-Gg: ASbGncsFrVkM3ZRsRrIVxL1NjdGkGIq0QqjBx4t73zeK2ZmpgyKaWxp28WiqHWzc6Ko UYPsZrVmPFz5gkiACDasBU9UfiE4ZNZXySGX5dhC5DxWsLcZuHsU2plUseMKyZIeUHwByI2HByw fPYfpug0HSV2GPaerjLvn4nIZAfQsf8RYsjsjU4SE/y+JVCq2QttJ9mK2eGQlGSyddajTjEeIdt 9ev28ql6WCMeJqT0tajLkc33prKQhQrRLP5sR1Eq2zmo0+nCV0z1wSySZIpBMPlkl4445VJ/wkU t+eqKcgMOA== X-Received: by 2002:a05:6000:144b:b0:38f:3c01:fb1f with SMTP id ffacd0b85a97d-39c2f8e1d9amr1220403f8f.30.1743665489987; Thu, 03 Apr 2025 00:31:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEwqYSQyMdV+bfQoHlJPQ9wPekLQ2x6Zs1CTechQHAMxVRhfrKQdBBHEB0GmCYDni6sWlkBDQ== X-Received: by 2002:a05:6000:144b:b0:38f:3c01:fb1f with SMTP id ffacd0b85a97d-39c2f8e1d9amr1220371f8f.30.1743665489627; Thu, 03 Apr 2025 00:31:29 -0700 (PDT) Received: from redhat.com ([2a0d:6fc0:1517:1000:ea83:8e5f:3302:3575]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-39c30096923sm1021344f8f.17.2025.04.03.00.31.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Apr 2025 00:31:28 -0700 (PDT) Date: Thu, 3 Apr 2025 03:31:26 -0400 From: "Michael S. Tsirkin" To: David Woodhouse Cc: virtio-comment@lists.linux.dev, hch@infradead.org, Claire Chang , linux-devicetree , Rob Herring , =?iso-8859-1?Q?J=F6rg?= Roedel , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, graf@amazon.de Subject: Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use of SWIOTLB bounce buffers Message-ID: <20250403032729-mutt-send-email-mst@kernel.org> References: <20250402112410.2086892-1-dwmw2@infradead.org> <20250402112410.2086892-2-dwmw2@infradead.org> <20250402105137-mutt-send-email-mst@kernel.org> <19ba662feeb93157bc8a03fb0b11cb5f2eca5e40.camel@infradead.org> <20250402111901-mutt-send-email-mst@kernel.org> <6b3b047f1650d91abe5e523dd7f862c6f7ee6611.camel@infradead.org> <20250402114757-mutt-send-email-mst@kernel.org> <965ccf2f972c5d5f1f4edacb227f03171f20e887.camel@infradead.org> <20250402124131-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: virtio-comment@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: IXw56hcCDz8-dX8e6nnmKHzPw1CkOlYBeIb9dCO3AsU_1743665491 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 02, 2025 at 06:10:53PM +0100, David Woodhouse wrote: > On Wed, 2025-04-02 at 12:43 -0400, Michael S. Tsirkin wrote: > > > > yes. > > > > I know a bit more about PCI, and for PCI I prefer just not saying > > anything. The platform already defines whether it is behind an iommu > > or not, and duplication is not good. > > Not a hill for me to die on I suppose, but I would personally prefer to > spell it out in words of one syllable or fewer, to make *sure* that > device and driver authors get it right even though it's "obvious". > > After all, if we could trust them to do their thinking, we would never > have had the awful situation that led to VIRTIO_F_ACCESS_PLATFORM > existing in the first place; the legacy behaviour we get when that bit > *isn't* set would never have happened. Oh, you are wrong here. It's not implementer's fault. virtio just was not designed with real DMA in mind, and micro-optimizing by bypassing the DMA API was very much intentional. > > For mmio it is my understanding that the "restricted" does the same > > already? or is it required in the spec for some reason? > > No, it's exactly the same. But I still don't trust driver authors to > realise the obvious, or VMM implementations either for that matter. > > I'm not sure I see the *harm* in spelling out explicitly for the hard- > of-thinking. I don't want people to make assumptions, like crashing if device is behind an iommu or whatnot. We can go with something informative. "It is expected that for most implementations, when using this feature, the behaviour with and without ACCESS_PLATFORM is the same" -- MST