From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 05AD145B44; Wed, 16 Oct 2024 01:04:51 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B75BE402B8; Wed, 16 Oct 2024 01:04:50 +0200 (CEST) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by mails.dpdk.org (Postfix) with ESMTP id 345414026F for ; Wed, 16 Oct 2024 01:04:49 +0200 (CEST) Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-7c3e1081804so3431983a12.3 for ; Tue, 15 Oct 2024 16:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1729033488; x=1729638288; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=stfAgveIMF1Ey4ePCx9xjxECNt2Om506E7cHEdvI6Vk=; b=Gs8+1EVnM4bAZ4PlnHFNOu8AWoED4LAPK4zHj8fg+4NDRtQwI5Tplqmlcufmf0vtvc xHKqWO7rhkpP8zogFGRvYGsoq94qqHcqued46NW/BUKO1c0VZ7upXAB4tv3GzWDXeuTT 27DHSFdDMmwtFXNNTiI1ubPYfBiiePhBJ3SbcQtqF9duin+8PD+0toNgLUGDchan/7cp drIMZ1LEFBa6W+qE6wen07wXcLThg64KYpwiFCqeZuoiqWWxhHMk3ym+wgXDnnHb6GYt XtrS2pQBDtq859kMXSbKjxXazVXR4rv34WvPkeehECKcKiJvgV7c2pOEF/9ikX0FeOmy abIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729033488; x=1729638288; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=stfAgveIMF1Ey4ePCx9xjxECNt2Om506E7cHEdvI6Vk=; b=jzSpR8MChYXGfa6NnbqQQQeHrDBMxWB8cRTUcCLmCpNCZqxeC8znOaSVnpgtGms1Z3 ye6dKrgxhVaCPfczyN2mcvUjlbRTwb9exFlech6R7CF4j8eYQxi+L9uK5kDWGV7n1X/S DqQR1yMtLLevij6wzN7HKKiTmtnfn6qLbioiBXpDs7u2QyS4mVKVqLrsxnobrAswDQwN GTmze6ghRfETJS2w2au91jCdhxsG7Yoc+F9S5TtKxpxK2x0Ns6qHqIzYcm2s7cC7533q w7JytOy4CoYhYzfeYV7oFvf3cNxc7poETiVkyjFXs+kZtrS7UqlO6H/04AQaxFbErEtz gFtQ== X-Gm-Message-State: AOJu0YwA/X43LBPxqOD/whe3WIUJDD3WUfFpwnLduyOvE4Gi6pogvPWo TQ55ZMvwHA6mNh7DEk0SBWUmUXC2MM35NN00lL2QTnajeHjJsenj45tHapWqYjA= X-Google-Smtp-Source: AGHT+IEvcrYeGZv3YvcS6BkWzXf8Z33rs/FNbhK7XXQkfsMp9tkE3+++T5gyJFxj5b3NkOTXX77PNQ== X-Received: by 2002:a05:6a21:1645:b0:1d9:911:af14 with SMTP id adf61e73a8af0-1d90911afa1mr2013629637.48.1729033488184; Tue, 15 Oct 2024 16:04:48 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7ea9c6c1948sm2007191a12.27.2024.10.15.16.04.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Oct 2024 16:04:48 -0700 (PDT) Date: Tue, 15 Oct 2024 16:04:46 -0700 From: Stephen Hemminger To: Ric Li Cc: dmitry.kozliuk@gmail.com, dev@dpdk.org, roretzla@linux.microsoft.com, Dmitry Kozlyuk Subject: Re: [PATCH v4] windows/virt2phys: fix block MDL not updated Message-ID: <20241015160446.1928c2df@hermes.local> In-Reply-To: <20231204103214.2504017-1-ming3.li@intel.com> References: <20231130071001.4c7931c8@sovereign> <20231204103214.2504017-1-ming3.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, 4 Dec 2023 18:32:14 +0800 Ric Li wrote: > The virt2phys_translate function previously scanned existing blocks, > returning the physical address from the stored MDL info if present. > This method was problematic when a virtual address pointed to a freed > and reallocated memory segment, potentially changing the physical > address mapping. Yet, virt2phys_translate would consistently return > the originally stored physical address, which could be invalid. > > This issue surfaced when allocating a memory region larger than 2MB > using rte_malloc. This action would allocate a new memory segment > and use virt2phy to set the IOVA. The driver would store the MDL > and lock the pages initially. When this region was freed, the memory > segment used as a whole page could be freed, invalidating the virtual > to physical mapping. Before this fix, the driver would only return the > initial physical address, leading to illegal IOVA for some pages when > allocating a new memory region larger than the hugepage size (2MB). > > To address this, a function to check block physical address has been > added. If a block with the same base address is detected in the > driver's context, the MDL's physical address is compared with the real > physical address. If they don't match, the block is removed and a new > one is created to store the correct mapping. To make the removal action > clear, the list to store MDL blocks is changed to a double linked list. > > Also fix the printing of PVOID type. > > Bugzilla ID: 1201 > Bugzilla ID: 1213 > > Signed-off-by: Ric Li This looks ok, but I know nothing about windows drivers. Could we get a review by Dmitry?