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 5E608A04A4; Mon, 4 Nov 2019 09:45:06 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D91DB37B7; Mon, 4 Nov 2019 09:45:04 +0100 (CET) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 16EDE37B4 for ; Mon, 4 Nov 2019 09:45:04 +0100 (CET) Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (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 0622559449 for ; Mon, 4 Nov 2019 08:45:03 +0000 (UTC) Received: by mail-wr1-f71.google.com with SMTP id u2so4005510wrm.7 for ; Mon, 04 Nov 2019 00:45:02 -0800 (PST) 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=Q9b3X1FQqowmejlu73aNnpRMBB3epBLkhl6ZJ7WDu9M=; b=Of2KfmtSQUUXp9+VbVQhmqb3R0Za6D0h4TDXIGvKRqBURlWFAr6lIdu1wOfd1nQF7k GMBbRfWg75O3LSMuGlrh9C7R5X/7rK/Up+/eReUEmxifokNRAlu8uZBQsaWNUyQJCCfR JnUy0KH7Pl9co5k4d+xtSGIZKjxThUsxbhAEhhaAmtMGwgEe4zTB//elMTICwmaZwgzn nIbNsnbQ+hbHK6A7WDupVA1M2jtJKy93/7GmFolJrifHHggCCaBMk+G3aw49T7vOhToW FzNGlxpzq/i47oA5jzXa4nKtPUkhiwggSElA9tUCkeEf5UJNIzHMLGG7k1cRd+VI4y90 KhjQ== X-Gm-Message-State: APjAAAWjlU+ff9FRQR/Vn/KMHEUHKgHUA2rKNp0OMO3jKhItVKmHiAsn O+hlh4RrccMdoCwxmJlVhUsm95glMeUW+9atVZK3zNNi2vVn97TYhAcJerzFGhUCR9xljcmftVd 8KZ8= X-Received: by 2002:a1c:2dd0:: with SMTP id t199mr20820227wmt.58.1572857101030; Mon, 04 Nov 2019 00:45:01 -0800 (PST) X-Google-Smtp-Source: APXvYqxiGplgtBWjkYf8QkmSIEZLxFgE49JMJlk99MoyTwQ1VQbjPaAQtMAjBCIwqyDRFZeLZSQ+og== X-Received: by 2002:a1c:2dd0:: with SMTP id t199mr20820205wmt.58.1572857100797; Mon, 04 Nov 2019 00:45:00 -0800 (PST) Received: from amorenoz.users.ipa.redhat.com ([81.0.4.169]) by smtp.gmail.com with ESMTPSA id y16sm6762465wro.25.2019.11.04.00.44.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Nov 2019 00:45:00 -0800 (PST) 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> <86228AFD5BCD8E4EBFD2B90117B5E81E633EE800@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: <8816ec84-59e6-83dd-52c2-ab22fa848963@redhat.com> Date: Mon, 4 Nov 2019 09:44:59 +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: <86228AFD5BCD8E4EBFD2B90117B5E81E633EE800@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" On 11/1/19 8:16 AM, Liu, Yong wrote: > > >> -----Original Message----- >> From: Adrian Moreno [mailto:amorenoz@redhat.com] >> Sent: Friday, November 01, 2019 1:48 AM >> To: Liu, Yong ; Bie, Tiwei >> Cc: maxime.coquelin@redhat.com; Wang, Zhihong ; >> dev@dpdk.org >> Subject: Re: [PATCH v3] vhost: fix vhost user virtqueue not accessible >> >> 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. > > That's fine, Adrian. This issue only occurred when using dpdk virtio user device. > Since address logging is disabled in virtio user, simple flag check fix it. > What I meant is that we would be changing the behavior for the vhost-user case in which qemu sends a valid log address even when logging is still not enabled. In that case we would be effectively postponing the translation. In any case, I've run a quick test and that case still works fine. Thanks, Adrian >> >>>> `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. >> > You are right, I misunderstood tiwei's comment. The ring address is useful for > checking numa id, numa reallocation should be after address translation. > > Regards, > Marvin > >> 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 >>>>> >