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 ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (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 E1B9BC77B7F for ; Tue, 16 May 2023 21:23:17 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 318E6153865 for ; Tue, 16 May 2023 21:23:17 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 196649865A6 for ; Tue, 16 May 2023 21:23:17 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 03A319862F6; Tue, 16 May 2023 21:23:17 +0000 (UTC) Mailing-List: contact virtio-comment-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id DF8D89862F8 for ; Tue, 16 May 2023 21:23:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-MC-Unique: spIALfYiN0qM4k6IR0kTKA-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684272194; x=1686864194; 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=xiwE6I6eZPfqmqsfjNSEzVfhR2MKhiJ8+DKTUlNd5yM=; b=eJG1hj+QCtY3lUnSWgLMZx+/6YG4MCswSfGSZ7iJ7YxFMAJsEgZK/fMKdBkwWqtdkv 7Xk49VLEWpim5Q66/1S6FMwz0Jfhzf1bD7XgIUSV1d4w2ddrZUFideJj9FwkZDGthkks EYbFCAE/tpYYSAjmwC4pzuF3lUFIn/jcr6VgRAZk7gygUPDxUyOTCAT+8p+t2HugSU+o rGS89q3MJrnDaFNHin/BSQHg7msHCi5w0hGFN5ZxUFEqgaTDF6VdIiGSBxcaAm4tNlc6 Zwv5fu3mT1YKyxQX9fhGtippFlxqoaOw4IWJPRKyvEuCdFLjX1ZYYNrKBaJbgsOILKmE q1mQ== X-Gm-Message-State: AC+VfDyIMkGLSmsFL3QdeKA+Nmfu396IyXFfdYQC3oe5bH6ZdnDJLJ+G p19w01vxZvVg2NKOgTNY+n8sd6HwmnmK4dmgBjMk7Or+Wp1u2q5yc3AAD9wIvLck165G8go8tu1 jD4Mr8FeHeK9J9e3BDfdVKVwNgo+dc/lvSQ== X-Received: by 2002:a5d:570c:0:b0:307:cdfb:b7af with SMTP id a12-20020a5d570c000000b00307cdfbb7afmr56710wrv.19.1684272193876; Tue, 16 May 2023 14:23:13 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5K+NHCHa96iKv7Ma42avRHlF3XMTJ+yp54uNQ4vztog43ryXWY9UMXWwhy1rVRztt+/GfDyA== X-Received: by 2002:a5d:570c:0:b0:307:cdfb:b7af with SMTP id a12-20020a5d570c000000b00307cdfbb7afmr56698wrv.19.1684272193585; Tue, 16 May 2023 14:23:13 -0700 (PDT) Date: Tue, 16 May 2023 17:23:09 -0400 From: "Michael S. Tsirkin" To: Parav Pandit Cc: Jason Wang , "virtio-dev@lists.oasis-open.org" , "cohuck@redhat.com" , "david.edmondson@oracle.com" , "sburla@marvell.com" , Yishai Hadas , Maor Gottlieb , "virtio-comment@lists.oasis-open.org" , Shahaf Shuler Message-ID: <20230516171940-mutt-send-email-mst@kernel.org> References: <20230510033812-mutt-send-email-mst@kernel.org> <20230511085205-mutt-send-email-mst@kernel.org> <0f75a142-71e9-676a-11ae-a54e6dbb472d@redhat.com> <20230516021401-mutt-send-email-mst@kernel.org> <20230516165509-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [virtio-comment] Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ On Tue, May 16, 2023 at 09:19:02PM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin > > Sent: Tuesday, May 16, 2023 4:58 PM > > > > > Let me give you an example. I feel that device specific config > > > > should allow arbitrary length accesses so that e.g. > > > > mac can be read and written atomically. > > > > > > > > On the other hand, this is not the case for common config. > > > > > > > Why is this not the case with common config? > > > Spec snippet: "When using the legacy interface the driver MAY access > > > the device-specific configuration region using any width accesses" > > > > I mean, what you said above exactly? > > device-specific configuration excludes common config. > > > > > So, what prevents the device to fail AQ command with the error code when alignment/width/size is not right? Nothing but you then need to specify what is and what isn't right. > > > > I feel we do not need to allow e.g. access to both common config and > > > > device specific one in a single operation, that is just messy. > > > It is just an offset and value. > > > What part bothers you? > > > > E.g. that it can cross the coundary between common and device config. > > > This is the legacy transport. > > > Look we didn't build modern because we wanted to make work, we did because > > legacy is broken. So either let legacy die already or let's build a sane interface > > to emulate it please. > Almost everyone building virtio device would prefer for legacy to die. > I am still trying to understand that why bisecting register definition of legacy makes it sane. Because legacy common config is very evil, do not copy it. Legacy device config is only bad in minor tolerable ways. > Device behaves based on the register offset, is fine for the legacy transport, guest driver will make the register accesses anyway it prefers. This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/ 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 ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (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 D4EBEC77B7F for ; Tue, 16 May 2023 21:23:22 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 201F615B665 for ; Tue, 16 May 2023 21:23:22 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 1B22F9865B5 for ; Tue, 16 May 2023 21:23:22 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 0F8569862F6; Tue, 16 May 2023 21:23:22 +0000 (UTC) Mailing-List: contact virtio-dev-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id ED6489862F7 for ; Tue, 16 May 2023 21:23:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-MC-Unique: B9Fa8YExNw2ZfgfAdG_DbQ-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684272194; x=1686864194; 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=xiwE6I6eZPfqmqsfjNSEzVfhR2MKhiJ8+DKTUlNd5yM=; b=K8oLjISIqzN+8Y5PvEnmeKTOmkW1OUAHHaXVQiCNamPiJ8McLlheIzv4Ia3LyLr9gR F1VB9eYfZLjrMTQHngNzyAsXHoMC7jLhVbEUjw9EF7jrOKV8zgQ32DZnIa8tm1XzMc5e cOsLiasjX1DUuCYOxU2inwRE2KS30qp9984ah/ZMeozi3YdlWtP1QPhOGdksaCrLRXtx 9L/UVt74LY/iIT76fCqrymwHMRWqfXERhzqLT0s2BvspnLhIaU7LB9hn/c4ZXlZ1drRp JdPtn4hlEKP3gA3w4PdLgqReSOZR595UsWfYpjwFxEV4dfol1asmzJnPTJ5G8x8CgEpa erlA== X-Gm-Message-State: AC+VfDw0qOaUJeOX+KBwcyPhr2xB1f8j1oUUKIEP/EEjkme+bRqhXHbm VYvA6NfeoTjs73rBqfHWH+pMw0JZ81/sMedXrLTWfHmyy1yMLYacZOS7MAsjLzMvfutp2go8/uO Mgb39XKQxKXf0Yd1XUVObe4wgOqeO X-Received: by 2002:a5d:570c:0:b0:307:cdfb:b7af with SMTP id a12-20020a5d570c000000b00307cdfbb7afmr56711wrv.19.1684272193876; Tue, 16 May 2023 14:23:13 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5K+NHCHa96iKv7Ma42avRHlF3XMTJ+yp54uNQ4vztog43ryXWY9UMXWwhy1rVRztt+/GfDyA== X-Received: by 2002:a5d:570c:0:b0:307:cdfb:b7af with SMTP id a12-20020a5d570c000000b00307cdfbb7afmr56698wrv.19.1684272193585; Tue, 16 May 2023 14:23:13 -0700 (PDT) Date: Tue, 16 May 2023 17:23:09 -0400 From: "Michael S. Tsirkin" To: Parav Pandit Cc: Jason Wang , "virtio-dev@lists.oasis-open.org" , "cohuck@redhat.com" , "david.edmondson@oracle.com" , "sburla@marvell.com" , Yishai Hadas , Maor Gottlieb , "virtio-comment@lists.oasis-open.org" , Shahaf Shuler Message-ID: <20230516171940-mutt-send-email-mst@kernel.org> References: <20230510033812-mutt-send-email-mst@kernel.org> <20230511085205-mutt-send-email-mst@kernel.org> <0f75a142-71e9-676a-11ae-a54e6dbb472d@redhat.com> <20230516021401-mutt-send-email-mst@kernel.org> <20230516165509-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [virtio-dev] Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ On Tue, May 16, 2023 at 09:19:02PM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin > > Sent: Tuesday, May 16, 2023 4:58 PM > > > > > Let me give you an example. I feel that device specific config > > > > should allow arbitrary length accesses so that e.g. > > > > mac can be read and written atomically. > > > > > > > > On the other hand, this is not the case for common config. > > > > > > > Why is this not the case with common config? > > > Spec snippet: "When using the legacy interface the driver MAY access > > > the device-specific configuration region using any width accesses" > > > > I mean, what you said above exactly? > > device-specific configuration excludes common config. > > > > > So, what prevents the device to fail AQ command with the error code when alignment/width/size is not right? Nothing but you then need to specify what is and what isn't right. > > > > I feel we do not need to allow e.g. access to both common config and > > > > device specific one in a single operation, that is just messy. > > > It is just an offset and value. > > > What part bothers you? > > > > E.g. that it can cross the coundary between common and device config. > > > This is the legacy transport. > > > Look we didn't build modern because we wanted to make work, we did because > > legacy is broken. So either let legacy die already or let's build a sane interface > > to emulate it please. > Almost everyone building virtio device would prefer for legacy to die. > I am still trying to understand that why bisecting register definition of legacy makes it sane. Because legacy common config is very evil, do not copy it. Legacy device config is only bad in minor tolerable ways. > Device behaves based on the register offset, is fine for the legacy transport, guest driver will make the register accesses anyway it prefers. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org