From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40CDB1AAE34 for ; Thu, 20 Jun 2024 11:07:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718881627; cv=none; b=o+8O5w+nEaVLFqVBYyelokEoG1XAw97VlIXRtdqvOURZvbkhSM5oe+pGxyHCwKpzJK3NjV4bgM6mI3RMMsKm4xUPYUln5iE/7ZuzS4c3XlmoWmmneDkr9ldFCepFA2EuWU1eUW5kPMeKD8BKe75xmX4QIgcmbYjwVwlBYbahe3c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718881627; c=relaxed/simple; bh=pGP3EXENF/h16YOS7jUUe7kIh4Nxl//v/ksZfj/bzpk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: In-Reply-To:Content-Type:Content-Disposition; b=NstshgEUb2BUiHELkq4GLtDRL1sADJGYx6WmmQwsi1wEnY1E++wt4AcGDO+NyK+m84zI+UuYMYuftfD4gTBXMk/b9a8AKedXtrGLeHPwniRhvJGtyFkY1p36mfJTYSweURD5EEX1VNw8RTq39n47tVrgsVPRsQ//aBwmiihwlcM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Zvm6h9Eo; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Zvm6h9Eo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718881623; 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=asOuL0T8Du5hh5YbTvqvuUvFHIqZ4G+a72SoWSKyqQM=; b=Zvm6h9EoB/ZeDHJGPrrGNldmYZWP7xgUxZPJgfxStZqHMNiNJ4Z6Aoj0MorZxntfxqic/8 +dsbIW+Rr7Dg6cvFeTu6PXRiZaICZ4Bki2dY/UvzdI8jkrop1AJ79o+rAjupxVjQ08lOry ToLnxaayAq/UGkUHrn5xKAoQmgkbTas= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-131-paK34fKnOjqLyaCkmz0v8Q-1; Thu, 20 Jun 2024 07:07:02 -0400 X-MC-Unique: paK34fKnOjqLyaCkmz0v8Q-1 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-57d16b230ebso309552a12.1 for ; Thu, 20 Jun 2024 04:07:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718881621; x=1719486421; 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=asOuL0T8Du5hh5YbTvqvuUvFHIqZ4G+a72SoWSKyqQM=; b=HXe70kQuP/v2PmLDIBRq/I1r+j/5GJEc//JtyzVfmn7wfSxlM5E2QbjI1Szt/74Vrq KGrMgsFq3RTacncG6cc7eGOgQhVqa0ICfZ34unA53pCs7DzQt1WjCjIcJ7wFy0uZkfVs wrfG89zIl69v7ViMI29r2RYwqLrZqBw/RC4WfkIAMfromvaNzYcc98ZakuzbfWt1Npgi MHaHyBvrtJ+RwnvbqtlRexOTUaa9m90aGoIJR73ihTNUGIbsIHxODbXXWjktpmxXZYAF kOxbH/Zvj8x5CKFpkqmvM7VfpvXXTwetfCDNhsa2CWky4jn2MTRVqbGEKb/H6ZxdBtG7 pe7A== X-Gm-Message-State: AOJu0Yz2PjOA3uPbcA0xaWlnNmBS1yb+AScDytdC8IHfrGSYHu72RbNC b6VKPv4KPIuHSrVj5NuNSOpCy6yhiqCulv9gBBdG/PbkGtwASOZEn7yqIxCkdn8eGMu7uL0lx8S 9kIF0cET2HNKP6CEGl3olQSu0ZMxKp6jYIqXrrgiggYQMBim2J80DLaDMYeOMwX8v X-Received: by 2002:a50:f681:0:b0:572:1589:eb98 with SMTP id 4fb4d7f45d1cf-57d07e7ad48mr2720572a12.12.1718881620765; Thu, 20 Jun 2024 04:07:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF+O2pcBIB3xTxXGVaSg2RJcQJnlZbfDTdu2g3BCbKZScECK74GIw+9TE9o8AKC9KjzfkuaJw== X-Received: by 2002:a50:f681:0:b0:572:1589:eb98 with SMTP id 4fb4d7f45d1cf-57d07e7ad48mr2720537a12.12.1718881620258; Thu, 20 Jun 2024 04:07:00 -0700 (PDT) Received: from redhat.com ([2.52.146.100]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57d26a50cbbsm241731a12.63.2024.06.20.04.06.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jun 2024 04:06:59 -0700 (PDT) Date: Thu, 20 Jun 2024 07:06:53 -0400 From: "Michael S. Tsirkin" To: Xuan Zhuo Cc: virtualization@lists.linux.dev, Richard Weinberger , Anton Ivanov , Johannes Berg , Hans de Goede , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Vadim Pasternak , Bjorn Andersson , Mathieu Poirier , Cornelia Huck , Halil Pasic , Eric Farman , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , David Hildenbrand , 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 Subject: Re: [PATCH vhost v9 3/6] virtio: find_vqs: pass struct instead of multi parameters Message-ID: <20240620070354-mutt-send-email-mst@kernel.org> References: <20240424091533.86949-1-xuanzhuo@linux.alibaba.com> <20240424091533.86949-4-xuanzhuo@linux.alibaba.com> <20240620034823-mutt-send-email-mst@kernel.org> <1718874049.457552-1-xuanzhuo@linux.alibaba.com> <20240620050545-mutt-send-email-mst@kernel.org> <1718875249.1787696-3-xuanzhuo@linux.alibaba.com> <20240620061202-mutt-send-email-mst@kernel.org> <1718880210.0475078-2-xuanzhuo@linux.alibaba.com> Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <1718880210.0475078-2-xuanzhuo@linux.alibaba.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jun 20, 2024 at 06:43:30PM +0800, Xuan Zhuo wrote: > On Thu, 20 Jun 2024 06:15:08 -0400, "Michael S. Tsirkin" wrote: > > On Thu, Jun 20, 2024 at 05:20:49PM +0800, Xuan Zhuo wrote: > > > On Thu, 20 Jun 2024 05:14:24 -0400, "Michael S. Tsirkin" wrote: > > > > On Thu, Jun 20, 2024 at 05:00:49PM +0800, Xuan Zhuo wrote: > > > > > > > @@ -226,21 +248,37 @@ struct virtqueue *virtio_find_single_vq(struct virtio_device *vdev, > > > > > > > > > > > > > > static inline > > > > > > > int virtio_find_vqs(struct virtio_device *vdev, unsigned nvqs, > > > > > > > - struct virtqueue *vqs[], vq_callback_t *callbacks[], > > > > > > > - const char * const names[], > > > > > > > - struct irq_affinity *desc) > > > > > > > + struct virtqueue *vqs[], vq_callback_t *callbacks[], > > > > > > > + const char * const names[], > > > > > > > + struct irq_affinity *desc) > > > > > > > { > > > > > > > - return vdev->config->find_vqs(vdev, nvqs, vqs, callbacks, names, NULL, desc); > > > > > > > + struct virtio_vq_config cfg = {}; > > > > > > > + > > > > > > > + cfg.nvqs = nvqs; > > > > > > > + cfg.vqs = vqs; > > > > > > > + cfg.callbacks = callbacks; > > > > > > > + cfg.names = (const char **)names; > > > > > > > > > > > > > > > > > > Casting const away? Not safe. > > > > > > > > > > > > > > > > > > > > Because the vp_modern_create_avq() use the "const char *names[]", > > > > > and the virtio_uml.c changes the name in the subsequent commit, so > > > > > change the "names" inside the virtio_vq_config from "const char *const > > > > > *names" to "const char **names". > > > > > > > > I'm not sure I understand which commit you mean, > > > > and this kind of change needs to be documented, but it does not matter. > > > > Don't cast away const. > > > > > > > > > Do you mean change the virtio_find_vqs(), from > > > const char * const names[] to const char *names[]. > > > > > > And update the caller? > > > > > > If we do not cast the const, we need to update all the caller to remove the > > > const. > > > > > > Right? > > > > > > Thanks. > > > > > > Just do not split the patchset at a boundary that makes you do that. > > If you are passing in an array from a const section then it > > has to be const and attempts to change it are a bad idea. > > Without this patch set: > > static struct virtqueue *vu_setup_vq(struct virtio_device *vdev, > unsigned index, vq_callback_t *callback, > const char *name, bool ctx) > { > struct virtio_uml_device *vu_dev = to_virtio_uml_device(vdev); > struct platform_device *pdev = vu_dev->pdev; > struct virtio_uml_vq_info *info; > struct virtqueue *vq; > int num = MAX_SUPPORTED_QUEUE_SIZE; > int rc; > > info = kzalloc(sizeof(*info), GFP_KERNEL); > if (!info) { > rc = -ENOMEM; > goto error_kzalloc; > } > -> snprintf(info->name, sizeof(info->name), "%s.%d-%s", pdev->name, > pdev->id, name); > > vq = vring_create_virtqueue(index, num, PAGE_SIZE, vdev, true, true, > ctx, vu_notify, callback, info->name); > > > The name is changed by vu_setup_vq(). > If we want to pass names to > virtio ring, the names must not be "const char * const" > > And the admin queue of pci do the same thing. > > And I think you are right, we should not cast the const. > So we have to remove the "const" from the source. > And I checked the source code, if we remove the "const", I think > that makes sense. > > Thanks. /facepalm This is a different const. There should be no need to drop the annotation, core does not change these things and using const helps make sure that is the case. > > > > > > > > > > > > > > -- > > > > MST > > > > > >