Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp410602pxu; Tue, 1 Dec 2020 14:35:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJyYUCOEj3fyCJFS6EUTfhJazL/YqjvHe6l3kZg0LssTw97X02Zu5RgKVw9LUx/Ts1E8Scel X-Received: by 2002:a05:6402:b8a:: with SMTP id cf10mr5416292edb.130.1606862130787; Tue, 01 Dec 2020 14:35:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606862130; cv=none; d=google.com; s=arc-20160816; b=RBTLue/lTY9UsvAdC6op5ettCjecDdBCMlxFQd5WkBJSo3pOitX2KEgpO0M3Y93V7t trkkwrluc2Buqv9r9sZ5+fbLF+morcpwD4HlJMiuFFEX0tBueDblYH5Smv74zXyylc7h FAIIqL3U+8LYffJ2aWbzHmASremrWdi1U1R5MnFIIgvQCKdFp4UZ7ywiPvh4VWrIeHMn KXnrgnzetNU7ucWAOMwtlR8rzUYCOLSEGclRcPxvW3qXll2F7jMkeOi5kl6t72vIYXPn D+X5nqrb5JTLrXCaVluHY3H8Iu/CBqiC26IlmdAeq8hyvFYguU8sgJTvGNuKiP9Wpuiu TaLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=myXYBD46UvClc6/JcJZBliDe+/db79psyDbz7J+w+P0=; b=GH3/oKumpHNfeNv06i6VZJ00fzMTw4rLf0h2tLAeKw/wCTVF1me7arcu3RrEUWYJJd TaunusIV4cppqlheJfNZldeVW/P1HTgAHGJxdahNdsVFz6sicnzbfU4MS8ni1lHhgXMj +JOrSIOIw/Hc5d7kWDeox+SqeHC02G/LsfD03LwM1TNmY/A0y/EIP5qMJtWEKGEM0byi QyQfXPZkh1I47ZiNtZ161YaYVNLKFE7uXi/2crEVedIKONttArrxPdh6ptj8R0orfIoY p/hRty0aV2E9n+VkeV4eJ848SRwWkrM0E7HsX3XzNZ6fBWVIHQNh8IUn8cHCqoxYhucI f40g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=adfk0FFg; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r5si791753edo.330.2020.12.01.14.35.08; Tue, 01 Dec 2020 14:35:30 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=adfk0FFg; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730237AbgLAKye (ORCPT + 99 others); Tue, 1 Dec 2020 05:54:34 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:28051 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727330AbgLAKye (ORCPT ); Tue, 1 Dec 2020 05:54:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606819987; 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=myXYBD46UvClc6/JcJZBliDe+/db79psyDbz7J+w+P0=; b=adfk0FFgK/2tF46CPU65qvuu/j4aY3xf5czxT+JgO8MjymTQEBhb5nlRz2lYe0K46cZPJT gDqXGZJ27nAibxtfRgITZoIQSfyzDKyL1rcpEAgsZHjpG5Tp98inuqrefmihaM/3jdYVvI 815YqfHxIqMVVXMPtYEvg6fikaeeb30= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-348-cITHzwIhN9mI081tXNE-BA-1; Tue, 01 Dec 2020 05:53:05 -0500 X-MC-Unique: cITHzwIhN9mI081tXNE-BA-1 Received: by mail-wm1-f72.google.com with SMTP id g198so544218wme.7 for ; Tue, 01 Dec 2020 02:53:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=myXYBD46UvClc6/JcJZBliDe+/db79psyDbz7J+w+P0=; b=rxGXEAE2/5U/O5qwqeO4Une9vaIjmSq/dzyV4ukke8KAre+iZgI6GH6DiI7YNzu1QF s2xyExhbXdP7vJEtot709X+Na9t4DvTfmIrybAtOzLsWie/h6MEVdfq2zB72aQSrp30Q m6KdFcpzN3mOeiTLytPcrrhPg8mm4hJMtcuIIHEeWlwbfskHYd64OpPOb7ZMnd1VOJbT UFUMPsrshyBIKStmwXU+XBdPDhlNzJeJm2UnqouYncnud1vnW+Nn26Lj20s70kezu80h ecxHdLlAA+Mqaa38mB4FGPfdC0Ipk0/YNg2/2doGkioMPIsZ7liptFsosvCm+CJUR8TV LFTA== X-Gm-Message-State: AOAM532iaYph0mKwGHqnm8OL79mzEhw56nnILXPHbMH09h8yaVAHyNKU pMaGVFnLrcRUVQTss0UHgYpUBzrwRJ00x4nPDrot2ZtuU6S3HK8hiTpP1TEXU4fnCjMKz8F51FW 1U4D97XIV5EgNY30trlZOHhOm X-Received: by 2002:a5d:630b:: with SMTP id i11mr3180902wru.404.1606819982891; Tue, 01 Dec 2020 02:53:02 -0800 (PST) X-Received: by 2002:a5d:630b:: with SMTP id i11mr3180319wru.404.1606819975700; Tue, 01 Dec 2020 02:52:55 -0800 (PST) Received: from steredhat (host-79-17-248-175.retail.telecomitalia.it. [79.17.248.175]) by smtp.gmail.com with ESMTPSA id q16sm2490957wrn.13.2020.12.01.02.52.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Dec 2020 02:52:53 -0800 (PST) Date: Tue, 1 Dec 2020 11:52:50 +0100 From: Stefano Garzarella To: Jason Wang Cc: virtualization@lists.linux-foundation.org, Stefan Hajnoczi , linux-kernel@vger.kernel.org, Laurent Vivier , Max Gurtovoy , "Michael S. Tsirkin" , Eli Cohen Subject: Re: [PATCH v2 12/17] vdpa_sim: add get_config callback in vdpasim_dev_attr Message-ID: <20201201105250.a72yxsxmyalio6c3@steredhat> References: <20201126144950.92850-1-sgarzare@redhat.com> <20201126144950.92850-13-sgarzare@redhat.com> <20201130141453.jobe76loyfy4qrdw@steredhat> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 01, 2020 at 11:44:19AM +0800, Jason Wang wrote: > >On 2020/11/30 下午10:14, Stefano Garzarella wrote: >>On Mon, Nov 30, 2020 at 11:25:31AM +0800, Jason Wang wrote: >>> >>>On 2020/11/26 下午10:49, Stefano Garzarella wrote: >>>>The get_config callback can be used by the device to fill the >>>>config structure. >>>>The callback will be invoked in vdpasim_get_config() before copying >>>>bytes into caller buffer. >>>> >>>>Move vDPA-net config updates from vdpasim_set_features() in the >>>>new vdpasim_net_get_config() callback. >>>> >>>>Signed-off-by: Stefano Garzarella >>>>--- >>>> drivers/vdpa/vdpa_sim/vdpa_sim.c | 33 +++++++++++++++++++------------- >>>> 1 file changed, 20 insertions(+), 13 deletions(-) >>>> >>>>diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c >>>>b/drivers/vdpa/vdpa_sim/vdpa_sim.c >>>>index c07ddf6af720..8b87ce0485b6 100644 >>>>--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c >>>>+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c >>>>@@ -58,6 +58,8 @@ struct vdpasim_virtqueue { >>>> #define VDPASIM_NET_FEATURES    (VDPASIM_FEATURES | \ >>>>                  (1ULL << VIRTIO_NET_F_MAC)) >>>>+struct vdpasim; >>>>+ >>>> struct vdpasim_dev_attr { >>>>     u64 supported_features; >>>>     size_t config_size; >>>>@@ -65,6 +67,7 @@ struct vdpasim_dev_attr { >>>>     u32 id; >>>>     work_func_t work_fn; >>>>+    void (*get_config)(struct vdpasim *vdpasim, void *config); >>>> }; >>>> /* State of each vdpasim device */ >>>>@@ -520,8 +523,6 @@ static u64 vdpasim_get_features(struct >>>>vdpa_device *vdpa) >>>> static int vdpasim_set_features(struct vdpa_device *vdpa, u64 >>>>features) >>>> { >>>>     struct vdpasim *vdpasim = vdpa_to_sim(vdpa); >>>>-    struct virtio_net_config *config = >>>>-        (struct virtio_net_config *)vdpasim->config; >>>>     /* DMA mapping must be done by driver */ >>>>     if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM))) >>>>@@ -529,15 +530,6 @@ static int vdpasim_set_features(struct >>>>vdpa_device *vdpa, u64 features) >>>>     vdpasim->features = features & >>>>vdpasim->dev_attr.supported_features; >>>>-    /* We generally only know whether guest is using the legacy >>>>interface >>>>-     * here, so generally that's the earliest we can set config >>>>fields. >>>>-     * Note: We actually require VIRTIO_F_ACCESS_PLATFORM above which >>>>-     * implies VIRTIO_F_VERSION_1, but let's not try to be >>>>clever here. >>>>-     */ >>>>- >>>>-    config->mtu = cpu_to_vdpasim16(vdpasim, 1500); >>>>-    config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP); >>>>-    memcpy(config->mac, macaddr_buf, ETH_ALEN); >>>>     return 0; >>>> } >>>>@@ -593,8 +585,12 @@ static void vdpasim_get_config(struct >>>>vdpa_device *vdpa, unsigned int offset, >>>> { >>>>     struct vdpasim *vdpasim = vdpa_to_sim(vdpa); >>>>-    if (offset + len < vdpasim->dev_attr.config_size) >>>>-        memcpy(buf, vdpasim->config + offset, len); >>>>+    if (offset + len > vdpasim->dev_attr.config_size) >>>>+        return; >>>>+ >>>>+    vdpasim->dev_attr.get_config(vdpasim, vdpasim->config); >>>>+ >>>>+    memcpy(buf, vdpasim->config + offset, len); >>>> } >>> >>> >>>I wonder how much value we can get from vdpasim->config consider >>>we've already had get_config() method. >>> >>>Is it possible to copy to the buffer directly here? >> >>I had thought of eliminating it too, but then I wanted to do something >>similar to what we do in QEMU (hw/virtio/virtio.c), leaving in the >>simulator core the buffer, the memory copy (handling offset and len), >>and the boundary checks. >> >>In this way each device should simply fill the entire configuration >>and we can avoid code duplication. >> >>Storing the configuration in the core may also be useful if some >>device needs to support config writes. > > >I think in that way we need should provide config_write(). Yes, I'll add set_config() callback. > > >> >>Do you think it makes sense, or is it better to move everything in the >>device? > > >I prefer to do that in the device but it's also fine keep what the >patch has done. Okay, for now I'll keep it and add the set_config() callback, but I'm open to move it in the device. Thanks, Stefano