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 lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) (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 A41A4CD8C9D for ; Thu, 11 Jun 2026 18:37:35 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wXkHI-0001gT-BU; Thu, 11 Jun 2026 14:37:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wXkHH-0001g5-FJ for qemu-arm@nongnu.org; Thu, 11 Jun 2026 14:37:19 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wXkHF-0004UY-Mj for qemu-arm@nongnu.org; Thu, 11 Jun 2026 14:37:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781203037; 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=XWumlH0m/QeWCWPNQY8VE2vifcIr8d96emDw33IrnMw=; b=btPu22nv6WdeK5WIWi/Yu1tSd85kGoL7c9uB5T0dyS6LM1xdoXN+6kPrGKgbEAfINVo/ct DBuGAiXi+0KJXQB7diRHu/Ye4G7SPcCtqZNDP673Kenzm1GgiZvAddViIWbI8Q0pDm0VqN GcbtsIMmMEAkBMJ6ktBOktl4SaOBanI= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-630-3jKerzVePHW_72ExFR3c9g-1; Thu, 11 Jun 2026 14:37:12 -0400 X-MC-Unique: 3jKerzVePHW_72ExFR3c9g-1 X-Mimecast-MFC-AGG-ID: 3jKerzVePHW_72ExFR3c9g_1781203031 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 150B81956069; Thu, 11 Jun 2026 18:37:11 +0000 (UTC) Received: from localhost (unknown [10.2.16.171]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4F749180049F; Thu, 11 Jun 2026 18:37:09 +0000 (UTC) Date: Thu, 11 Jun 2026 14:37:08 -0400 From: Stefan Hajnoczi To: "Michael S. Tsirkin" Cc: Peter Maydell , Gavin Shan , qemu-devel@nongnu.org, qemu-arm@nongnu.org, jugraham@redhat.com, shan.gavin@gmail.com, qemu-block@nongnu.org Subject: Re: [PATCH RFCv1] virtio: Inherit max bounce buffer size from bus parent if possible Message-ID: <20260611183708.GA222320@fedora> References: <20260608001821.850921-1-gshan@redhat.com> <20260610041036-mutt-send-email-mst@kernel.org> <20260610183046.GB121666@fedora> <20260610165710-mutt-send-email-mst@kernel.org> <20260611142022.GA202155@fedora> <20260611103513-mutt-send-email-mst@kernel.org> <20260611110543-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nYquIO6tCyfJvJvM" Content-Disposition: inline In-Reply-To: <20260611110543-mutt-send-email-mst@kernel.org> X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Received-SPF: pass client-ip=170.10.133.124; envelope-from=stefanha@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: 8 X-Spam_score: 0.8 X-Spam_bar: / X-Spam_report: (0.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.445, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-arm@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-arm-bounces+qemu-arm=archiver.kernel.org@nongnu.org Sender: qemu-arm-bounces+qemu-arm=archiver.kernel.org@nongnu.org --nYquIO6tCyfJvJvM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 11, 2026 at 11:09:35AM -0400, Michael S. Tsirkin wrote: > On Thu, Jun 11, 2026 at 04:04:20PM +0100, Peter Maydell wrote: > > On Thu, 11 Jun 2026 at 15:46, Michael S. Tsirkin wrote: > > > > > > On Thu, Jun 11, 2026 at 10:20:22AM -0400, Stefan Hajnoczi wrote: > > > > Gavin posted the lspci output: > > > > > > > > Region 0: Memory at 661ffd000000 (64-bit, prefetchable) [size=3D1= 6M] > > > > Region 2: Memory at 662000000000 (64-bit, prefetchable) [size=3D1= 28G] > > > > Region 4: Memory at 661ffe000000 (64-bit, prefetchable) [size=3D3= 2M] > > > > > > > > These are prefetchable memory BARs, so I would expect them to be > > > > mmappable. Why does QEMU have no way of knowing upfront whether the= y can > > > > be mmapped? > > > > > > > > > They can be mmapped. The issue is just that after mmap flatview uses > > > memcpy/memmove on them, and that might not match what guest driver is > > > expecting specifically for 1/2/4/8 byte accesses. > >=20 > > Huh? The guest driver has nothing to do with it, surely. >=20 > My answer is I don't know. >=20 > But the commit that introduced the regression says: >=20 > The assumption here is that accesses initiated by the VM are > driven by a device specific driver, which knows the device > capabilities.=20 >=20 > > The > > problem is that for some PCI devices (like the network card > > mentioned in 4a2e242bbb30's commit message) the BAR is *not* > > safe for arbitrary access (because the actual real host hardware > > inside it is not RAM). >=20 > But we don't do arbitrary access. Why would we? >=20 > > That commit disabled direct access > > for all vfio MRs, which is safe but overcautious. Would > > "direct access is OK if this is a prefetchable memory BAR" be OK? > > Or do some prefetchable memory BARs still have restrictions > > beyond those of real RAM? I wonder the same thing. > >=20 > > > Removing mmap is one solution, this is what vfio does now. > > > Fixing flatview is another. > >=20 > > No, you can't fix this in flatview. If a BAR is not safe for > > direct access then it is not safe for direct access. > >=20 > > -- PMM >=20 > There's no such thing as "not safe for direct access" in PCI. > All operations are memory operations. > What can be unsafe is accesses of specific width and length. >=20 > So we should not use variable length memcpy/memmove which > do that. Fixes length memcpy/memmove exactly mimic what > guest does, so they are safe. The bounce buffer approach doesn't seem like a solution to me: if the device has alignment and size restrictions on accesses, then the bounce buffer won't get them right because it doesn't know where the registers live within the BAR. Also, the guest initiated I/O to a VIRTIO device pointing to a buffer in another PCI device's BAR. In this case any failure to handle BAR accesses would be the guest's problem. It cannot assume that the VIRTIO device follows a specific DMA transfer pattern with respect to alignment/size. Stefan --nYquIO6tCyfJvJvM Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmorAFQACgkQnKSrs4Gr c8jE1wgAnCRsE7bI9F2KOJEvWOgqT1UaTjvRg53aQ++FBV5/9JMj+sRlpDA/bNU5 8SUbg5ocU2ImqJdKTrv5gQ/TT+6gvdUWZ+G6cvSWvgRZFv5f3OP6w84KL5Y5FD2a hfLe6nuXnqtzzQNHvN7DM/6dews1joXISw0WyqEDmCah3euRZ5EameRSZbTqJv8P WEcz6m7HPpoNOR4P1fQL3m7LU0Ikzf9c6z/Q06Ov2Gf68Q3mJzeVqcFpj/zA2a98 5hMCHQYIYAetQRQPajG2dgxGcF25/pVVgce68v6QHvocwFrFSTUS6gsxnez7ysV6 JTwQiXcxDpooIonCjwN2vMJhCFfW+g== =fjbp -----END PGP SIGNATURE----- --nYquIO6tCyfJvJvM--