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;
Subject: Re: [PATCH net-next V2 6/8] vhost: packed ring support
To:     "Michael S. Tsirkin" <mst@redhat.com>
Cc:     Tiwei Bie <tiwei.bie@intel.com>, kvm@vger.kernel.org,
        virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, wexu@redhat.com,
        jfreimann@redhat.com, maxime.coquelin@redhat.com
References: <1531711691-6769-1-git-send-email-jasowang@redhat.com>
 <1531711691-6769-7-git-send-email-jasowang@redhat.com>
 <20181012143244.GA28400@debian>
 <20181012131812-mutt-send-email-mst@kernel.org>
 <447f47fa-32dd-a408-dd81-13a9839e0748@redhat.com>
 <20181014224208-mutt-send-email-mst@kernel.org>
 <ee3785be-b309-c4ae-e959-737018c21464@redhat.com>
 <20181015062241-mutt-send-email-mst@kernel.org>
From:   Jason Wang <jasowang@redhat.com>
Message-ID: <f37dbff8-321e-7b6c-6f40-49c71d167ab6@redhat.com>
Date:   Thu, 18 Oct 2018 10:44:36 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20181015062241-mutt-send-email-mst@kernel.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2018/10/15 下午6:25, Michael S. Tsirkin wrote:
> On Mon, Oct 15, 2018 at 10:51:06AM +0800, Jason Wang wrote:
>> On 2018年10月15日 10:43, Michael S. Tsirkin wrote:
>>> On Mon, Oct 15, 2018 at 10:22:33AM +0800, Jason Wang wrote:
>>>> On 2018年10月13日 01:23, Michael S. Tsirkin wrote:
>>>>> On Fri, Oct 12, 2018 at 10:32:44PM +0800, Tiwei Bie wrote:
>>>>>> On Mon, Jul 16, 2018 at 11:28:09AM +0800, Jason Wang wrote:
>>>>>> [...]
>>>>>>> @@ -1367,10 +1397,48 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *arg
>>>>>>>     		vq->last_avail_idx = s.num;
>>>>>>>     		/* Forget the cached index value. */
>>>>>>>     		vq->avail_idx = vq->last_avail_idx;
>>>>>>> +		if (vhost_has_feature(vq, VIRTIO_F_RING_PACKED)) {
>>>>>>> +			vq->last_avail_wrap_counter = wrap_counter;
>>>>>>> +			vq->avail_wrap_counter = vq->last_avail_wrap_counter;
>>>>>>> +		}
>>>>>>>     		break;
>>>>>>>     	case VHOST_GET_VRING_BASE:
>>>>>>>     		s.index = idx;
>>>>>>>     		s.num = vq->last_avail_idx;
>>>>>>> +		if (vhost_has_feature(vq, VIRTIO_F_RING_PACKED))
>>>>>>> +			s.num |= vq->last_avail_wrap_counter << 31;
>>>>>>> +		if (copy_to_user(argp, &s, sizeof(s)))
>>>>>>> +			r = -EFAULT;
>>>>>>> +		break;
>>>>>>> +	case VHOST_SET_VRING_USED_BASE:
>>>>>>> +		/* Moving base with an active backend?
>>>>>>> +		 * You don't want to do that.
>>>>>>> +		 */
>>>>>>> +		if (vq->private_data) {
>>>>>>> +			r = -EBUSY;
>>>>>>> +			break;
>>>>>>> +		}
>>>>>>> +		if (copy_from_user(&s, argp, sizeof(s))) {
>>>>>>> +			r = -EFAULT;
>>>>>>> +			break;
>>>>>>> +		}
>>>>>>> +		if (vhost_has_feature(vq, VIRTIO_F_RING_PACKED)) {
>>>>>>> +			wrap_counter = s.num >> 31;
>>>>>>> +			s.num &= ~(1 << 31);
>>>>>>> +		}
>>>>>>> +		if (s.num > 0xffff) {
>>>>>>> +			r = -EINVAL;
>>>>>>> +			break;
>>>>>>> +		}
>>>>>> Do we want to put wrap_counter at bit 15?
>>>>> I think I second that - seems to be consistent with
>>>>> e.g. event suppression structure and the proposed
>>>>> extension to driver notifications.
>>>> Ok, I assumes packed virtqueue support 64K but looks not. I can change it to
>>>> bit 15 and GET_VRING_BASE need to be changed as well.
>>>>
>>>>>> If put wrap_counter at bit 31, the check (s.num > 0xffff)
>>>>>> won't be able to catch the illegal index 0x8000~0xffff for
>>>>>> packed ring.
>>>>>>
>>>> Do we need to clarify this in the spec?
>>> Isn't this all internal vhost stuff?
>> I meant the illegal index 0x8000-0xffff.
> It does say packed virtqueues support up to 2 15 entries each.
>
> But yes we can add a requirement that devices do not expose
> larger rings. Split does not support 2**16 either, right?
> With 2**16 enties avail index becomes 0 and ring looks empty.
>

Yes, so it's better to clarify this in the spec.

Thanks