Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3043713imm; Mon, 28 May 2018 23:14:35 -0700 (PDT) X-Google-Smtp-Source: AB8JxZroi6sXkKfNz75xFHAUKEtYOzt7F/QhrUdy02RXE0garq0BgQFZ+tonWbyW++IM2Od3CN2w X-Received: by 2002:a17:902:a5c7:: with SMTP id t7-v6mr16456187plq.360.1527574475729; Mon, 28 May 2018 23:14:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527574475; cv=none; d=google.com; s=arc-20160816; b=IIaOmwJdhUvUeNV2pGCYKif+1V5iSy7t2fZO1RuFH5W3ROTYyCqANL7TalkgdWvaJ/ 6ibjRrVZ7+VJmgM0i8WDFcLC3ARNq4ZFhtJgzex2u9oSDiMYPMV4JD3Mu4vtAzlmiFGX pRaHIS41PrT+4O7Ohv92harqoWLJvlXkw4g03H8BooLp3mtq8jtnTE1cyzFEylb+0RPq 52vwPqg7ysDNmPypIS3dldsxQ1fiFZ4tqqD8md5sTVw2f2qtapeFQHbzvW8DGRSB0pqr SB+cInlE5KO8cMg7A3w4PSRtsCyAbDIIYMPUy9J9brzSbD4LIjaul765wyV2+738AuR/ cwTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=BgeKXOMScu0jkfv2CZsA+IfO7k83K4azidOWPJJLRC4=; b=cU3bHtMVBuHt14c8Y6DFCbSIKpWSXcGl+zolwo8LIMG8PGG/PfPRtLzzNRnDLO6Vt+ Js52BCcaBvekjcQtUWAnpk3Hk3C35oenI1wBuDEjeprBFeWC89c3jAsCQOAuFxMww6Ys onfzXLV4cGW+hEqopq7d06eB23Wah7QR49JSvrnXXu0uBIq6vNS6CwXet8VwvEKp6xIc RART9TrErkiU4dviDLR7VLDlD7Mye3C9UK1jpT6xtVHXJEGEgi+uUHKMwyP2ZAwK68xS Vfn988Foc9Vvn0cslweXJa6FeB6AaeHjIepmJNChGT6VM7kGATAEO4WuGAmdb9nCX0gD zwkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z18-v6si31490152pfd.357.2018.05.28.23.14.21; Mon, 28 May 2018 23:14:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754576AbeE2GNm (ORCPT + 99 others); Tue, 29 May 2018 02:13:42 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:41178 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751800AbeE2GNk (ORCPT ); Tue, 29 May 2018 02:13:40 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 73563BB41D; Tue, 29 May 2018 06:13:39 +0000 (UTC) Received: from [10.72.12.86] (ovpn-12-86.pek2.redhat.com [10.72.12.86]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0F46E1116708; Tue, 29 May 2018 06:13:30 +0000 (UTC) Subject: Re: [RFC v5 2/5] virtio_ring: support creating packed ring To: Tiwei Bie Cc: mst@redhat.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, wexu@redhat.com, jfreimann@redhat.com, Cornelia Huck References: <20180522081648.14768-1-tiwei.bie@intel.com> <20180522081648.14768-3-tiwei.bie@intel.com> <654feee2-3414-e304-0aec-2bb19a7e0c87@redhat.com> <20180529052418.GB2976@debian> From: Jason Wang Message-ID: Date: Tue, 29 May 2018 14:13:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180529052418.GB2976@debian> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 29 May 2018 06:13:39 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 29 May 2018 06:13:39 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jasowang@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018年05月29日 13:24, Tiwei Bie wrote: > On Tue, May 29, 2018 at 10:49:11AM +0800, Jason Wang wrote: >> On 2018年05月22日 16:16, Tiwei Bie wrote: >>> This commit introduces the support for creating packed ring. >>> All split ring specific functions are added _split suffix. >>> Some necessary stubs for packed ring are also added. >>> >>> Signed-off-by: Tiwei Bie >>> --- >>> drivers/virtio/virtio_ring.c | 801 +++++++++++++++++++++++------------ >>> include/linux/virtio_ring.h | 8 +- >>> 2 files changed, 546 insertions(+), 263 deletions(-) >>> >>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c >>> index 71458f493cf8..f5ef5f42a7cf 100644 >>> --- a/drivers/virtio/virtio_ring.c >>> +++ b/drivers/virtio/virtio_ring.c >>> @@ -61,11 +61,15 @@ struct vring_desc_state { >>> struct vring_desc *indir_desc; /* Indirect descriptor, if any. */ >>> }; >>> +struct vring_desc_state_packed { >>> + int next; /* The next desc state. */ >>> +}; >>> + >>> struct vring_virtqueue { >>> struct virtqueue vq; >>> - /* Actual memory layout for this queue */ >>> - struct vring vring; >>> + /* Is this a packed ring? */ >>> + bool packed; >>> /* Can we use weak barriers? */ >>> bool weak_barriers; >>> @@ -87,11 +91,39 @@ struct vring_virtqueue { >>> /* Last used index we've seen. */ >>> u16 last_used_idx; >>> - /* Last written value to avail->flags */ >>> - u16 avail_flags_shadow; >>> + union { >>> + /* Available for split ring */ >>> + struct { >>> + /* Actual memory layout for this queue. */ >>> + struct vring vring; >>> - /* Last written value to avail->idx in guest byte order */ >>> - u16 avail_idx_shadow; >>> + /* Last written value to avail->flags */ >>> + u16 avail_flags_shadow; >>> + >>> + /* Last written value to avail->idx in >>> + * guest byte order. */ >>> + u16 avail_idx_shadow; >>> + }; >>> + >>> + /* Available for packed ring */ >>> + struct { >>> + /* Actual memory layout for this queue. */ >>> + struct vring_packed vring_packed; >>> + >>> + /* Driver ring wrap counter. */ >>> + u8 avail_wrap_counter; >>> + >>> + /* Device ring wrap counter. */ >>> + u8 used_wrap_counter; >> How about just use boolean? > I can change it to bool if you want. Yes, please. > > [...] >>> -static int vring_mapping_error(const struct vring_virtqueue *vq, >>> - dma_addr_t addr) >>> -{ >>> - if (!vring_use_dma_api(vq->vq.vdev)) >>> - return 0; >>> - >>> - return dma_mapping_error(vring_dma_dev(vq), addr); >>> -} >> It looks to me if you keep vring_mapping_error behind >> vring_unmap_one_split(), lots of changes were unncessary. >> > [...] >>> + } >>> + /* That should have freed everything. */ >>> + BUG_ON(vq->vq.num_free != vq->vring.num); >>> + >>> + END_USE(vq); >>> + return NULL; >>> +} >> I think the those copy-and-paste hunks could be avoided and the diff should >> only contains renaming of the function. If yes, it would be very welcomed >> since it requires to compare the changes verbatim otherwise. > Michael suggested to lay out the code as: > > XXX_split > > XXX_packed > > XXX wrappers > > https://lkml.org/lkml/2018/4/13/410 > > That's why I moved some code. I see, then no need to change but it still looks unnecessary. > >>> + >>> +/* >>> + * The layout for the packed ring is a continuous chunk of memory >>> + * which looks like this. >>> + * >>> + * struct vring_packed { >>> + * // The actual descriptors (16 bytes each) >>> + * struct vring_packed_desc desc[num]; >>> + * >>> + * // Padding to the next align boundary. >>> + * char pad[]; >>> + * >>> + * // Driver Event Suppression >>> + * struct vring_packed_desc_event driver; >>> + * >>> + * // Device Event Suppression >>> + * struct vring_packed_desc_event device; >>> + * }; >>> + */ >>> +static inline void vring_init_packed(struct vring_packed *vr, unsigned int num, >>> + void *p, unsigned long align) >>> +{ >>> + vr->num = num; >>> + vr->desc = p; >>> + vr->driver = (void *)(((uintptr_t)p + sizeof(struct vring_packed_desc) >>> + * num + align - 1) & ~(align - 1)); >> If we choose not to go uapi, maybe we can use ALIGN() macro here? > Okay. > >>> + vr->device = vr->driver + 1; >>> +} > [...] >>> +/* Only available for split ring */ >>> const struct vring *virtqueue_get_vring(struct virtqueue *vq) >>> { >> A possible issue with this is: >> >> After commit d4674240f31f8c4289abba07d64291c6ddce51bc ("KVM: s390: >> virtio-ccw revision 1 SET_VQ"). CCW tries to use >> virtqueue_get_avail()/virtqueue_get_used(). Looks like a bug either here or >> ccw code. > Do we still need to support: > > include/linux/virtio.h > /* > * Legacy accessors -- in almost all cases, these are the wrong functions > * to use. > */ > static inline void *virtqueue_get_desc(struct virtqueue *vq) > { > return virtqueue_get_vring(vq)->desc; > } > static inline void *virtqueue_get_avail(struct virtqueue *vq) > { > return virtqueue_get_vring(vq)->avail; > } > static inline void *virtqueue_get_used(struct virtqueue *vq) > { > return virtqueue_get_vring(vq)->used; > } > > in packed ring? I think it was probably a bug in ccw, they should use e.g virtqueue_get_desc_addr() instead. Thanks > > If so, I think maybe it's better to expose them as > symbols and implement them in virtio_ring.c. > > Best regards, > Tiwei Bie