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 84BB7C54E58 for ; Mon, 25 Mar 2024 09:47:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc: To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BdmZcxTxaezoD4ADz7mbOH050D8bZAskNFuCnh+xicc=; b=Ac8TuB8YGqqbFUIJRHGbfg4s14 yYL3iDpBCf1oF9qO7J+AJF515gY2TeHrIYLj9cpZDBs/6jlQXgKNJXkNW4wA5OTNZu7un12k7T4dK ucMLPKlDPvN6VpnFI4uRQH7nClal9NBbtk6f/3Mw3SBTLckcdo/Owrva0sFA5YS3ssi+IA8D1Fk2e Q7CH7qiXf8LEkHqxE1TAKwkDaJ4soQbjI9U/ko+kRcu30lp9c+gaZe9IIO3JncdU8k1mpiVScw/W/ Ve2BAASOJszwPv44PIvFQi++k1imBQv927Se9xJAFJ9OS0FZANyMYnp23/JamyTw0mKYyuoMrbkuL iGGRU92w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rogv4-0000000GXJj-1XWu; Mon, 25 Mar 2024 09:47:06 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rogv0-0000000GXIH-46oI for linux-um@lists.infradead.org; Mon, 25 Mar 2024 09:47:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711360021; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BdmZcxTxaezoD4ADz7mbOH050D8bZAskNFuCnh+xicc=; b=drYu53ww23Ev3WL0X3Di+rkuGXjDuUKD9nOdF8v3Op1Fjf4TEi15zNwL58u8aniqYglnKE jxhNneilcnG474NGbYWS8hScQ9BxXqXhrGK0LyPNvv9df1X5zzmVcq0x8F7RVMEUCvT2qS wQB/qhweu0CgDlVKA9rSMyZKtjyiKD4= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-625-4bwf4HvHONWvCeWH0UPaXQ-1; Mon, 25 Mar 2024 05:44:51 -0400 X-MC-Unique: 4bwf4HvHONWvCeWH0UPaXQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 488B628B6AA2; Mon, 25 Mar 2024 09:44:50 +0000 (UTC) Received: from localhost (dhcp-192-239.str.redhat.com [10.33.192.239]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9FD631C060A4; Mon, 25 Mar 2024 09:44:48 +0000 (UTC) From: Cornelia Huck To: Xuan Zhuo , David Hildenbrand Cc: virtualization@lists.linux.dev, Richard Weinberger , Anton Ivanov , Johannes Berg , Hans de Goede , Ilpo =?utf-8?Q?J=C3=A4rvinen?= , Vadim Pasternak , Bjorn Andersson , Mathieu Poirier , Halil Pasic , Eric Farman , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "Michael S. Tsirkin" , Jason Wang , linux-um@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, Daniel Verkamp Subject: Re: [PATCH vhost v4 1/6] virtio_balloon: remove the dependence where names[] is null In-Reply-To: <1711346901.0977402-2-xuanzhuo@linux.alibaba.com> Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross" References: <20240321101532.59272-1-xuanzhuo@linux.alibaba.com> <20240321101532.59272-2-xuanzhuo@linux.alibaba.com> <1711346901.0977402-2-xuanzhuo@linux.alibaba.com> User-Agent: Notmuch/0.37 (https://notmuchmail.org) Date: Mon, 25 Mar 2024 10:44:47 +0100 Message-ID: <87zfum7ii8.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240325_024703_213750_21C6DDC8 X-CRM114-Status: GOOD ( 35.74 ) X-BeenThere: linux-um@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-um" Errors-To: linux-um-bounces+linux-um=archiver.kernel.org@lists.infradead.org On Mon, Mar 25 2024, Xuan Zhuo wrote: > On Fri, 22 Mar 2024 22:02:27 +0100, David Hildenbrand = wrote: >> On 22.03.24 20:16, Daniel Verkamp wrote: >> > On Thu, Mar 21, 2024 at 3:16=E2=80=AFAM Xuan Zhuo wrote: >> >> >> >> Currently, the init_vqs function within the virtio_balloon driver rel= ies >> >> on the condition that certain names array entries are null in order to >> >> skip the initialization of some virtual queues (vqs). This behavior is >> >> unique to this part of the codebase. In an upcoming commit, we plan to >> >> eliminate this dependency by removing the function entirely. Therefor= e, >> >> with this change, we are ensuring that the virtio_balloon no longer >> >> depends on the aforementioned function. >> > >> > This is a behavior change, and I believe means that the driver no >> > longer follows the spec [1]. >> > >> > For example, the spec says that virtqueue 4 is reporting_vq, and >> > reporting_vq only exists if VIRTIO_BALLOON_F_PAGE_REPORTING is set, >> > but there is no mention of its virtqueue number changing if other >> > features are not set. If a device/driver combination negotiates >> > VIRTIO_BALLOON_F_PAGE_REPORTING but not VIRTIO_BALLOON_F_STATS_VQ or >> > VIRTIO_BALLOON_F_FREE_PAGE_HINT, my reading of the specification is >> > that reporting_vq should still be vq number 4, and vq 2 and 3 should >> > be unused. This patch would make the reporting_vq use vq 2 instead in >> > this case. >> > >> > If the new behavior is truly intended, then the spec does not match >> > reality, and it would need to be changed first (IMO); however, >> > changing the spec would mean that any devices implemented correctly >> > per the previous spec would now be wrong, so some kind of mechanism >> > for detecting the new behavior would be warranted, e.g. a new >> > non-device-specific virtio feature flag. >> > >> > I have brought this up previously on the virtio-comment list [2], but >> > it did not receive any satisfying answers at that time. I had missed it back then, but now that I read it, I realize that we really have a bit of a mess here :/ >> >> Rings a bell, but staring at this patch, I thought that there would be >> no behavioral change. Maybe I missed it :/ >> >> I stared at virtio_ccw_find_vqs(), and it contains: >> >> for (i =3D 0; i < nvqs; ++i) { >> if (!names[i]) { >> vqs[i] =3D NULL; >> continue; >> } >> >> vqs[i] =3D virtio_ccw_setup_vq(vdev, queue_idx++, callbacks[i], >> names[i], ctx ? ctx[i] : false, >> ccw); >> if (IS_ERR(vqs[i])) { >> ret =3D PTR_ERR(vqs[i]); >> vqs[i] =3D NULL; >> goto out; >> } >> } >> >> We increment queue_idx only if an entry was not NULL. SO I thought no >> behavioral change? (at least on s390x :) ) The code for pci behaves in the same way. >> >> It's late here in Germany, so maybe I'm missing something. > > I think we've encountered a tricky issue. Currently, all transports handl= e queue > id by incrementing them in order, without skipping any queue id. So, I'm = quite > surprised that my changes would affect the spec. The fact that the > 'names' value is null is just a small trick in the Linux kernel implement= ation > and should not have an impact on the queue id. > > I believe that my recent modification will not affect the spec. So, let's > consider the issues with this patch set separately for now. Regarding the= Memory > Balloon Device, it has been operational for many years, and perhaps we sh= ould > add to the spec that if a certain vq does not exist, then subsequent vqs = will > take over its id. The changes here do not really seem to affect the spec issue that Daniel had noted, unless I'm reading the code wrong. However, we should try to address the spec mess, where we have at least some of the most popular/important implementations behaving differently than the spec describes... I would suggest to discuss that on the virtio lists -- but they are still dead, and at this point I'm just hoping they'll come back eventually :/