From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13BC3192B84 for ; Fri, 3 Jan 2025 15:35:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735918529; cv=none; b=SJPPgCMt8WuGfyJo3Su0/m4xYiqatoPbVCnPLZl5ZyMDXH5kAj4e9MejshUP19H1V9yyUt7U4n0Hk/TZYCfVVd40PwjKrBZsyhy+qYXi2QBKEAAVF/9kxgn2O+HK0V+Z8sfPoTlcCsZVi8Xf+DuuUu+1/aRpSmS9n+h56bG9BMM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735918529; c=relaxed/simple; bh=vcCOxf9MjAm6R004BwmvpnBmn1ugdF3644CrfRERETA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lW6fNEy64f/MC8TEaHMm3Kd4yDJoBEDZXGj1UmLmUoksplSU+awVeqB2TOuNi0v29L0gtMobAE2qsDI+ew23GvHaif37b1LGT+xywzfZKJ4OI1TK1AKUQP27flZU/8UPZVQMl2ZGEuZIID2xhl5wY3UOrBpyIzG9IrPNtwZwg4A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=G7GKArw8; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="G7GKArw8" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-43621d2dd4cso57405e9.0 for ; Fri, 03 Jan 2025 07:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1735918525; x=1736523325; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=7TAFKlJ6U7QCklm7PSgnN2whltr6YSbd0ouHsKVqiJ0=; b=G7GKArw8QcUPTMutQcxlDjs1QY6r8HUOTuJD/sXSGd0wT/++jAfzHTCn+ToYB+T2B0 PVZxRafU+UJqAXstDQetOXs9IM3cJ1YbKrhCeBcEdwHKZMUacpZzHu/7BnjFWbMM1JV/ cY+YLJH3NqdGgNQdheo2b6b2h4A/hfsIQBE74cd/SQZ3tgInW6O2WuvlrhHxlUVREEvK ohyfsiDLgJ3cdXbYXSG/LF+JXSnz1eiPQIEiAsF/WrcYAHtfo6jMayRlXznT8pn+XwIG ZY/Hmq2etnifW9u+S7afN7XCqCTuakgSzbXWCbkDkSq3eGPTg4GSpah4MNkuSfQC9aK0 843Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735918525; x=1736523325; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7TAFKlJ6U7QCklm7PSgnN2whltr6YSbd0ouHsKVqiJ0=; b=KS/aWuXV51a7JTE5TETzPrkkM+P4tPamp9W/O8P0hSjh7XTj6FWdn6wtH/PkzgPLPu YHAuAQmO4oanDdGxduNwjJQhL1fkYj22DHmISxuziw0ZXD+1nebkb1vyu4UYuVfbucur Qqj3V+0kyI4uvouALpjwfshBypYEb9r+bTV4nHEhE60/9ldJQQeoW7+uQO5EcjOtjiUp 16FC3vBsj6I3fzvwRG57pakNaLauxdcuRUhy1Hqi8SGMY66fniuSMi6auuuRk0M7YzA2 N4LxuqLYIcMN4LOCDIqG9AQdTLkuTpS5tYtRuKpFPnNU5WN7EdcNSlrLfgmyQ55Anq3d P+pQ== X-Forwarded-Encrypted: i=1; AJvYcCWMjDWlgGbUnljHks75DfJHgXfimghjAgo/hDdEMV1E2VoGt+fiGt3Vg739d4HwWvcsmPYDH3CE+LQf0QU=@vger.kernel.org X-Gm-Message-State: AOJu0YxkqhzoLV59ROsXb0XOBUhR0XPfLqRWpw9BEWE6RD3gEhcg2wDX nu6FQcJPYN9c00sxHDGf8WtAZV24X1Z01Z3L8uKjA9NEAX5cYDDt/KzxtWMzlw== X-Gm-Gg: ASbGncs3roV1AHSTOz4Vynss7UrznuYGA5jb82IfiybOcPNrfdCAtk69w11RBkt+fzt xZWH+8aN+qzYPjd8ORbuaQRvxeS9I0tR02zJI5t6GmDJ0l+lTMxgOawTU++nM31mmIDT4C2JpNv MBEvyWbVqZHk3xC2VSMH8yrpiVXhorcB3LXOlpjUcT9fZWj5/jNJPb1yRLZ/zncX7PEJXryeMXK x6Qk8/cQH0ey+8oWxEQLKZ4hgjJMKtM+G9iE121WWGrtXuy9RuOx4Ap+fhJBT3/mPirii8qnX5R d/nBMwL99PZtC8L9Fyk= X-Google-Smtp-Source: AGHT+IFYpv295mC4BjSl9FSXlia/fjrHlkEb0FIGQ5Me85JthE8z4rdE+//UhwlzrKWnZRqRsAmKQA== X-Received: by 2002:a05:600c:5788:b0:434:9e1d:44ef with SMTP id 5b1f17b1804b1-436ccb413f2mr875415e9.7.1735918525147; Fri, 03 Jan 2025 07:35:25 -0800 (PST) Received: from google.com (216.131.76.34.bc.googleusercontent.com. [34.76.131.216]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c832b32sm40339218f8f.23.2025.01.03.07.35.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jan 2025 07:35:24 -0800 (PST) Date: Fri, 3 Jan 2025 15:35:20 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: Robin Murphy , iommu@lists.linux.dev, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, robdclark@gmail.com, joro@8bytes.org, jean-philippe@linaro.org, nicolinc@nvidia.com, vdonnefort@google.com, qperret@google.com, tabba@google.com, danielmentz@google.com, tzukui@google.com Subject: Re: [RFC PATCH v2 55/58] drivers/iommu: Add deferred map_sg operations Message-ID: References: <20241212180423.1578358-1-smostafa@google.com> <20241212180423.1578358-56-smostafa@google.com> <20250102201831.GB26854@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250102201831.GB26854@ziepe.ca> On Thu, Jan 02, 2025 at 04:18:31PM -0400, Jason Gunthorpe wrote: > On Thu, Dec 19, 2024 at 02:24:05PM +0000, Mostafa Saleh wrote: > > I had a quick look now at s390, and it seems a bit different as they only > > notify the hypervisor about the iova range being changed, and don’t need > > to provide iova->paddr mapping which pKVM does. > > Can you explain this statement some more. It seems strange to me, why > would the pkvm side, which has it's own page table, need to be be told > about the iova->paddr during range unmapping requests - and why would > the host/guest side have to unnecessarily store this information? No, it doesn’t need to be told about the paddr on unmapping. The problem is as follows; - With the current IOMMU API, an iommu_map_sg() function ends up looping on iommu_map() which is very slow as map is a hypercall and there is a lot of context switching. - So, we add a map_sg hypercall, instead of consuming the kernel scatterlist which duplicates logic and can be complicated to do. A new iommu operation is added add_deferred_map_sg(), where at iommu_map_sg() instead of calling iommu_map() it calls add_deferred_map_sg() to add mapping, and 2 other new ops also added to create and consume a sg request which comes from a single iommu_map_sg(). The drawback of this approach is that it adds 3 new iommu_ops with a bit of niche semantics, which for now only used by this driver. An alternative approach as Robin suggested, is to treat all iommu_map as sg map, and when the driver gets the iotlb_sync_map() call it can just issue the hypercall, however this call only provides the IOVA range, which requires extra work or locking as mentioned in the thread, and as Robin mentioned s390 doing something similar, I was highlighting that in their driver, this call only notifies the hypervisor about an IOVA and not an actual pv map as pKVM, so it much simpler in their case. Thanks, Mostafa > > Jason