Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1197654pxb; Mon, 11 Oct 2021 00:03:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxpdspaT/i2deXzTROm5rwNQUtmtfptUBgfTdY2WX9igtPlJ+uQPaliRr8X/sgOsprFSXCH X-Received: by 2002:a17:906:713:: with SMTP id y19mr24224920ejb.506.1633935819893; Mon, 11 Oct 2021 00:03:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633935819; cv=none; d=google.com; s=arc-20160816; b=arebJ2+7TRH8Um8ERu78av6TVDcGxGjVJrQAqccgvNeFjGQ/4feWm33aISN/oCN8wD bKi2JDwBHRI0F8T4n5NQTWg1YCXz4a5d9OB08Ufizn4/0hJ+rdPeJiyBVY1oiasmaUny tdSwSJPmhl2jHjONXDW+gKbMB8CHMc6Bm9YAfq0VVwqc+1P+UUs5ZxT0HCjWdOZ4TlWH r3nue5Rc7Z5ZoeZGUgy3ULwRrNYKNKPqzBUs64dsTAfRSTzPElUE9/lLwEUFIXAmLl9m se5wXpRKNdmJw+rRy7Ptxyikyo/V5PjPUkUdwSm0/M+VmTy8dCiwhq1wlFfyECHYW3x5 4fqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=4HW4pQ25GO1K6URUKRqS+7ujDcAMEDeHj0XORmuOSA8=; b=Ox0YonCmz81uElAKikD+XngXpk7RkZA3e61iw2iTZQpu1jfaRmVy0QoJtd7W6X4f1a i1d/tGWZzBRC4Sc2xG8T9JDAN2HzkuiUwqXvPZNCzcFlI00TT+DNh+7ldmmD7O43LRvu i8PR22TL22JtNUg0YOjML0Ztk1BA52pYKjoS/sTlwt/QYzIisjb2uHQkVOw/rOs+wu0e 00kVMI7hEqqS2dYefnn1aaFmbVcNNK/uLT53cGpYtckp73OGlz3nAGOKjS7zUSfx7MQw IRqv7hz5QNXXL9AAWU+TvBZlE0NISMedwaxRBxbG4urfQdh8t2qYhBPnuXjD2u9tkmlc nlYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=Fr4eXMe4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sb7si16325822ejc.415.2021.10.11.00.03.16; Mon, 11 Oct 2021 00:03:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=Fr4eXMe4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234002AbhJKFlm (ORCPT + 99 others); Mon, 11 Oct 2021 01:41:42 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52194 "EHLO mx0b-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234011AbhJKFll (ORCPT ); Mon, 11 Oct 2021 01:41:41 -0400 Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19B4482n036941; Mon, 11 Oct 2021 01:39:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding; s=pp1; bh=4HW4pQ25GO1K6URUKRqS+7ujDcAMEDeHj0XORmuOSA8=; b=Fr4eXMe4OkDkyiQmqrBL1+8IzDGUg+4XlH/GOfVLDc05Wz+GqSmqX4QCgQgoN2InZsqQ 9al/6cazEusi2dieO+HhlZuuf94GIhONYgfFzw5/5SMHmBlarli8aWimkPx89jIVeGzp ORvIT7fpybLJ9ukJmQg6goAyXjRgxa85YzgQUapdX9TEfLXzAaTpFlSlHsYQwaH4EMSg zrCOfr22XNXArC6wQiTrcN+Cb7nEF5aWwvfW7BFqUHghCYQ2YMPoYRIHNKdqk+oH94b1 GrBXyX5RKK/jG3gxcA8lMO6fcssgShwVAfL090RY1H7sL140D6AeZ8s0iguk/wV4DDYq qQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bm25mugj6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 01:39:32 -0400 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 19B5K9pm038567; Mon, 11 Oct 2021 01:39:32 -0400 Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bm25mughk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 01:39:32 -0400 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 19B5VlGF019479; Mon, 11 Oct 2021 05:39:30 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma06ams.nl.ibm.com with ESMTP id 3bk2bht3y9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 05:39:30 +0000 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19B5dQCl5440160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Oct 2021 05:39:27 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D9F3442045; Mon, 11 Oct 2021 05:39:26 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 445CB42041; Mon, 11 Oct 2021 05:39:26 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 11 Oct 2021 05:39:26 +0000 (GMT) From: Halil Pasic To: "Michael S. Tsirkin" , Jason Wang , Xie Yongji , virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org Cc: Halil Pasic , stable@vger.kernel.org, markver@us.ibm.com, Cornelia Huck , Christian Borntraeger , linux-s390@vger.kernel.org, stefanha@redhat.com, Raphael Norwitz , qemu-devel@nongnu.org Subject: [PATCH v3 1/1] virtio: write back F_VERSION_1 before validate Date: Mon, 11 Oct 2021 07:39:21 +0200 Message-Id: <20211011053921.1198936-1-pasic@linux.ibm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: MkvVeVrmStp-ePltWRF4RTURcd9rcOLa X-Proofpoint-GUID: nhX1dJtH4R_VgKXe83_52DJi-xKWhRzH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-10_07,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0 clxscore=1015 spamscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 adultscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110110032 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The virtio specification virtio-v1.1-cs01 states: "Transitional devices MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not been acknowledged by the driver." This is exactly what QEMU as of 6.1 has done relying solely on VIRTIO_F_VERSION_1 for detecting that. However, the specification also says: "... the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device ..." before setting FEATURES_OK. In that case, any transitional device relying solely on VIRTIO_F_VERSION_1 for detecting legacy drivers will return data in legacy format. In particular, this implies that it is in big endian format for big endian guests. This naturally confuses the driver which expects little endian in the modern mode. It is probably a good idea to amend the spec to clarify that VIRTIO_F_VERSION_1 can only be relied on after the feature negotiation is complete. Before validate callback existed, config space was only read after FEATURES_OK. However, we already have two regressions, so let's address this here as well. The regressions affect the VIRTIO_NET_F_MTU feature of virtio-net and the VIRTIO_BLK_F_BLK_SIZE feature of virtio-blk for BE guests when virtio 1.0 is used on both sides. The latter renders virtio-blk unusable with DASD backing, because things simply don't work with the default. See Fixes tags for relevant commits. For QEMU, we can work around the issue by writing out the feature bits with VIRTIO_F_VERSION_1 bit set. We (ab)use the finalize_features config op for this. This isn't enough to address all vhost devices since these do not get the features until FEATURES_OK, however it looks like the affected devices actually never handled the endianness for legacy mode correctly, so at least that's not a regression. No devices except virtio net and virtio blk seem to be affected. Long term the right thing to do is to fix the hypervisors. Cc: #v4.11 Signed-off-by: Halil Pasic Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space") Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range") Reported-by: markver@us.ibm.com Reviewed-by: Cornelia Huck --- @Connie: I made some more commit message changes to accommodate Michael's requests. I just assumed these will work or you as well and kept your r-b. Please shout at me if it needs to be dropped :) --- drivers/virtio/virtio.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c index 0a5b54034d4b..236081afe9a2 100644 --- a/drivers/virtio/virtio.c +++ b/drivers/virtio/virtio.c @@ -239,6 +239,17 @@ static int virtio_dev_probe(struct device *_d) driver_features_legacy = driver_features; } + /* + * Some devices detect legacy solely via F_VERSION_1. Write + * F_VERSION_1 to force LE config space accesses before FEATURES_OK for + * these when needed. + */ + if (drv->validate && !virtio_legacy_is_little_endian() + && device_features & BIT_ULL(VIRTIO_F_VERSION_1)) { + dev->features = BIT_ULL(VIRTIO_F_VERSION_1); + dev->config->finalize_features(dev); + } + if (device_features & (1ULL << VIRTIO_F_VERSION_1)) dev->features = driver_features & device_features; else base-commit: 60a9483534ed0d99090a2ee1d4bb0b8179195f51 -- 2.25.1