From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 91F23A00D7; Thu, 31 Oct 2019 18:49:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EA59B1C2E1; Thu, 31 Oct 2019 18:49:34 +0100 (CET) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 2D7301C2DD for ; Thu, 31 Oct 2019 18:49:33 +0100 (CET) Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3E5D687634 for ; Thu, 31 Oct 2019 17:49:32 +0000 (UTC) Received: by mail-wr1-f72.google.com with SMTP id 7so3860542wrl.2 for ; Thu, 31 Oct 2019 10:49:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/OFiX39/uTBD1CR6mFYMSxw/DbdnnMhhczLztL6gmHg=; b=ejpvCtA6H4lbxKHwQZQRsHitPA15rsa9pKw6zZrUJIcXMCBH0lICwLCfWjy9zRCRS2 FBlBnBTcO+nOdHXGZSMH6QeswJxG2bb9qSqUVpN1F4Ga1TnFFd9FG2OfM6YO7RsyuqsT 0mOehMx4b7PRpFtvypCpNoKL5ZkJ7p4GNksHPjbKBFs5nIbvabMToUgpyAiBonXYdXgF /dVGH/0TzyC6RNhiPeme6IPZ5Wkx1t8V9YK4WvZ7rtGTPZQGm/BP4i5d0OA9/QEMjpP3 WL6r0eqvvCb3PsAyr3qRx3xgYbfo6e+tO8Hj3VKH/XUBFiE9BaorcbpPEw9XSgsg2ox3 YB6A== X-Gm-Message-State: APjAAAXep3QWgHOfhtaQXqoqzGx8wuljk+sKLfDGktV9CNfyuXz653N6 ol1DvbEydvXHJrwiTh/iNSfnbuAIsRQZvfFEFGWbR1qnjW7woh000CLrCsOdQJm+umUwq85IZXw Vr9Q= X-Received: by 2002:a05:600c:210b:: with SMTP id u11mr4517526wml.170.1572544170415; Thu, 31 Oct 2019 10:49:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqz1djGm+8MO1vRqpBrQShSPEGOMKl5Ve3VCZPUv+5QXhGrqHJKkMHSwAAMlboXlkt0TyWH/YA== X-Received: by 2002:a05:600c:210b:: with SMTP id u11mr4517505wml.170.1572544170192; Thu, 31 Oct 2019 10:49:30 -0700 (PDT) Received: from amorenoz.users.ipa.redhat.com ([46.222.48.191]) by smtp.gmail.com with ESMTPSA id s21sm5807326wrb.31.2019.10.31.10.48.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Oct 2019 10:49:29 -0700 (PDT) To: "Liu, Yong" , "Bie, Tiwei" Cc: "maxime.coquelin@redhat.com" , "Wang, Zhihong" , "dev@dpdk.org" References: <20191030110723.20195-1-yong.liu@intel.com> <20191030145602.1948-1-yong.liu@intel.com> <20191031104220.GA22299@___> <86228AFD5BCD8E4EBFD2B90117B5E81E633EE261@SHSMSX103.ccr.corp.intel.com> From: Adrian Moreno Autocrypt: addr=amorenoz@redhat.com; prefer-encrypt=mutual; keydata= mQENBF1syNUBCADQ9dk3fDMxOZ/+OQpmbanpodYxEv8IRtDz8PXw8YX7UyGfozOpLjQ8Fftj ZxuubYNbt2QVbSgviFilFdNWu2eTnN/JaGtfhmTOLPVoakkPHZF8lbgImMoch7L0fH8wN2IM KPxQyPNlX+K9FD5brHsV1lfe1TwAxmhcvLW8yNrVq+9eDIDykxc7tH4exIqXgZroahGxMHKy c8Ti2kJka/t6pDfRaY0J+6J7I1nrn6GXXSMNA45EH8+0N/QlcXhP3rfftnoPeVmpjswzvJqY FNjf/Q5VPLx7RX0Qx+y8mMB2JcChV5Bl7D7x5EUbItj6+Sy7QfOgCtPegk9HSrBCNYaLABEB AAG0I0FkcmlhbiBNb3Jlbm8gPGFtb3Jlbm96QHJlZGhhdC5jb20+iQFUBBMBCAA+FiEEogUD gihhmbOPHy26d5C5fbYeFsUFAl1syNUCGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQd5C5fbYeFsX7qwgArGHSkX+ILNcujkVzjTG4OtkpJMPFlkn/1PxSEKD0jLuzx14B COzpg/Mqj3Re/QBuOas+ci9bsUA0/2nORtmmEBvzDOJpR5FH1jaGCx8USlY4WM6QqEDNZgTw hsy9KhjFzFjMk+oo3HyItXA+Uq9yrRBTjNBGTXxezMRcMuUZ4MIAfY0IRBglL2BufiuL43jD BvTENNFLoQ/wFV7qkFWSkv+8IjTsxr7M6XUo1QLd29Hn0dvwssN579HL1+BP46i2REpzeBEG L75iVChi+YnIQQNMJ9NYarVabZx4Y1Gn8+7B/1SNArDV+IDgnYgt7E58otoV2Ap310dmtuvE VbxGpbkBDQRdbMjVAQgAqyp9oA7WDu7/Y9T4Ommt69iZx8os7shUIfdgPEy5xrcPn6qGwN1/ HQ4j8nWfBG9uuX1X0RXUZIUEtYTxtED4yaCQMTqDUf9cBAwAA2mYxBfoiNYx8YqxM+sT0/J4 2qmDd+y+20UR4yzHE8AmIbspTzDFIJDAi+jKSR8F355z0sfW7CIMDC4ZWrPsskjEy1YN/U10 r6tRRH1kNyrCSbTG0d9MtcQO58h7DLXuzUhErB+BtG52A04t5cweIJTJC+koV5XPeilzlHnm RFoj0ncruGa9Odns21BNt3cy9wLfK+aUnWuAB1uc6bJGQPiAwjkilz7g7MBRUuIQ2Zt7HGLc SwARAQABiQE8BBgBCAAmFiEEogUDgihhmbOPHy26d5C5fbYeFsUFAl1syNUCGwwFCQHhM4AA CgkQd5C5fbYeFsUlSwf8CH+u/IXaE7WeWxwFkMaORfW8cM4q0xrL3M6yRGuQNW+kMjnrvK9U J9G+L1/5uTRbDQ/4LdoKqize8LjehA+iF6ba4t9Npikh8fLKWgaJfQ/hPhH4C3O5gWPOLTW6 ylGxiuER4CdFwQIoAMMslhFA7G+teeOKBq36E+1+zrybI6Xy1UBSlpDK9j4CtTnMQejjuSQb Qhle+l8VroaUHq869wjAhRHHhqmtJKggI+OvzgQpDIwfHIDypb1BuKydi2W6cVYEALUYyCLS dTBDhzj8zR5tPCsga8J7+TclQzkWOiI2C6ZtiWrMsL/Uym3uXk5nsoc7lSj7yLd/MrBRhYfP JQ== Message-ID: Date: Thu, 31 Oct 2019 18:47:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <86228AFD5BCD8E4EBFD2B90117B5E81E633EE261@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3] vhost: fix vhost user virtqueue not accessible X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Marvin, On 10/31/19 3:54 PM, Liu, Yong wrote: > > >> -----Original Message----- >> From: Bie, Tiwei >> Sent: Thursday, October 31, 2019 6:42 PM >> To: Liu, Yong >> Cc: maxime.coquelin@redhat.com; Wang, Zhihong ; >> amorenoz@redhat.com; dev@dpdk.org >> Subject: Re: [PATCH v3] vhost: fix vhost user virtqueue not accessible >> >> On Wed, Oct 30, 2019 at 10:56:02PM +0800, Marvin Liu wrote: >>> Log feature is disabled in vhost user, so that log address was invalid >>> when checking. Check whether log address is valid can workaround it. >>> Also log address should be translated in packed ring virtqueue. >>> >>> Fixes: 04cfc7fdbfca ("vhost: translate incoming log address to gpa") >>> >>> Signed-off-by: Marvin Liu >>> --- >>> lib/librte_vhost/vhost_user.c | 30 +++++++++++++----------------- >>> 1 file changed, 13 insertions(+), 17 deletions(-) >>> >>> diff --git a/lib/librte_vhost/vhost_user.c >> b/lib/librte_vhost/vhost_user.c >>> index 61ef699ac..7754d2467 100644 >>> --- a/lib/librte_vhost/vhost_user.c >>> +++ b/lib/librte_vhost/vhost_user.c >>> @@ -641,11 +641,23 @@ translate_ring_addresses(struct virtio_net *dev, >> int vq_index) >>> struct vhost_vring_addr *addr = &vq->ring_addrs; >>> uint64_t len, expected_len; >>> >>> + dev = numa_realloc(dev, vq_index); >> >> We need to update `vq->desc` first before doing numa_realloc. >> https://github.com/DPDK/dpdk/blob/19397c7bf2545e6adab41b657a1f1da3c7344e7b/ >> lib/librte_vhost/vhost_user.c#L445 >> >>> + vq = dev->virtqueue[vq_index]; >>> + if (addr->flags & (1 << VHOST_VRING_F_LOG)) { >> I fear the possible consequences of this change. Before 04cfc7fdbfca the approach was "best-effort". The log address would be assigned without further checks: vq->log_guest_addr = addr->log_guest_addr; Then, the behavior changed and an error was generated if the log address was invalid, which I guess is the problem you have hit: vq->log_guest_addr = translate_log_addr(dev, vq, addr->log_guest_addr); if (vq->log_guest_addr == 0) { RTE_LOG(DEBUG, VHOST_CONFIG, "(%d) failed to map log_guest_addr .\n", dev->vid); return dev; } In the tests I ran I always saw valid log addresses being sent at ring initialization phase, but if, as you claim, it's possible that invalid addresses are given at initialization phase, maybe we should go back to "best-effort" (i.e: remove the return statement) But it's unlikely that qemu has enabled logging at ring initialization so this would effectively disable the translation at the initialization phase. I cannot forecast the consequences of this change without deeper analysis. >> `vq` can be reallocated by numa_realloc. >> We need to update the `addr` pointer before using it. >> > > Hi Tiwei, > Numa_realloc function will copy data from original vq structure to new vq when reallocating. > The content of vhost_ring_addr will be the same in new and old vqs, it may not be necessary to update pointer. That's true but 'addr' still holds a pointer to the old structure, assigned at line 641. Also, note Tiwei's comment regarding updating 'vq->desc'. The idea behind numa_realloc is to reallocate the vhost_virtqueue structure to the same numa node as the descriptor ring. This function is updating the descriptor rings, so I think the idea is to update the ring addresses and then reallocate the virtqueue structure if needed. Thanks, Adrian > Regards, > Marvin > >> Thanks, >> Tiwei >> >> >>> + vq->log_guest_addr = >>> + translate_log_addr(dev, vq, addr->log_guest_addr); >>> + if (vq->log_guest_addr == 0) { >>> + RTE_LOG(DEBUG, VHOST_CONFIG, >>> + "(%d) failed to map log_guest_addr.\n", >>> + dev->vid); >>> + return dev; >>> + } >>> + } >>> + >>> if (vq_is_packed(dev)) { >>> len = sizeof(struct vring_packed_desc) * vq->size; >>> vq->desc_packed = (struct vring_packed_desc *)(uintptr_t) >>> ring_addr_to_vva(dev, vq, addr->desc_user_addr, &len); >>> - vq->log_guest_addr = 0; >>> if (vq->desc_packed == NULL || >>> len != sizeof(struct vring_packed_desc) * >>> vq->size) { >>> @@ -655,10 +667,6 @@ translate_ring_addresses(struct virtio_net *dev, int >> vq_index) >>> return dev; >>> } >>> >>> - dev = numa_realloc(dev, vq_index); >>> - vq = dev->virtqueue[vq_index]; >>> - addr = &vq->ring_addrs; >>> - >>> len = sizeof(struct vring_packed_desc_event); >>> vq->driver_event = (struct vring_packed_desc_event *) >>> (uintptr_t)ring_addr_to_vva(dev, >>> @@ -701,10 +709,6 @@ translate_ring_addresses(struct virtio_net *dev, int >> vq_index) >>> return dev; >>> } >>> >>> - dev = numa_realloc(dev, vq_index); >>> - vq = dev->virtqueue[vq_index]; >>> - addr = &vq->ring_addrs; >>> - >>> len = sizeof(struct vring_avail) + sizeof(uint16_t) * vq->size; >>> if (dev->features & (1ULL << VIRTIO_RING_F_EVENT_IDX)) >>> len += sizeof(uint16_t); >>> @@ -741,14 +745,6 @@ translate_ring_addresses(struct virtio_net *dev, int >> vq_index) >>> vq->last_avail_idx = vq->used->idx; >>> } >>> >>> - vq->log_guest_addr = >>> - translate_log_addr(dev, vq, addr->log_guest_addr); >>> - if (vq->log_guest_addr == 0) { >>> - RTE_LOG(DEBUG, VHOST_CONFIG, >>> - "(%d) failed to map log_guest_addr .\n", >>> - dev->vid); >>> - return dev; >>> - } >>> vq->access_ok = 1; >>> >>> VHOST_LOG_DEBUG(VHOST_CONFIG, "(%d) mapped address desc: %p\n", >>> -- >>> 2.17.1 >>>