From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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 899C423CF0B for ; Wed, 19 Feb 2025 20:37:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739997433; cv=none; b=qf41Os+Q9Qatjqt60SKeQTn5lKoHG7cJpQQ/mheUhN/KJYaC+JTPkHICSgtuBXaxS1nlLuv9DPtyy0HfbBFTZCRbtcgJjrwjAOwDRUjiJalAJXl4VK63oEvLJtGFaNQNlwKmVhw8/uv/pc6auFC+gF8z58ULjl/k5BccVR9z9UQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739997433; c=relaxed/simple; bh=yKjrUDxi3dkFLFUc55Tgy0oxRUHV39lyNPsgf4nGVB4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TpZb+92PMiwPPlc7cWXAQnMcSN3ESBBu9lgzYPV0cCIF0TvqiyG45k5pxKqmF03oAyWj48x81zD7T82A+E1cQ72loWfr0OC0Mc4mpgJviA3k4XTt5n4NJYcv1ILd36SqKryPuqhbPtJcvNuBCyIBX8mALvTupePctnkE9rwYuEk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=pW6S5ABF; arc=none smtp.client-ip=209.85.160.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="pW6S5ABF" Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-471f7261f65so2978381cf.0 for ; Wed, 19 Feb 2025 12:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1739997430; x=1740602230; darn=lists.linux.dev; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=dy6Nbly0xz+HIc0W3Ixx9GKeMksXztaJI1bUpLuF4hY=; b=pW6S5ABFTnR8jg12dpBsEJdRkdWdoexnmIrOGzJW6/ZxzJ5gILNwh07/GEF/cI2nX+ fmi2Roz6Sg1MZku3Guks7qnZOnzxubp4sFhEZJTGo6jeBKMfTZTNGdEdpsatvN9huWFj 2Vo5Hqj9q19yFdlcCtAqdCVS+ZYR+WgyZYnIrbzza8/lC2S+pgcKsHwMZ7eaODT5DoBB gDnkhlbeJVHSALWPhYQMzppuPA7czOuqCV28y3XEYi+wpHBoAGeTCFamqTxWGkGNtpDo A/F74lcRlgo4oVp6BD4PlJfV+ikMqmRJkb/NjG1eQpkUT/AfyHXl37VUcVeO+iJ+IOlw nKxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739997430; x=1740602230; h=in-reply-to: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=dy6Nbly0xz+HIc0W3Ixx9GKeMksXztaJI1bUpLuF4hY=; b=MHQASP5cfYMaF+trWFiqT9COv4b4aU2G6r0cOkzvkMRLF4pM2DTJREqMQdv0CBGw7C EEVDPNOpfNLgIFdtDgnF38OrSu5ZRJFCha84MeaSD8TgHaw2hwp0Ojxxw45gu7SFOI8O m3W+s4WMJQr5ReifZoBQ9LVa5m1FbD6/UdiRRDWgnqaAP289FXNWl2Rq+7khiKPtx77H c5TRShKtohL3Mu7Erd3XCP9HqtuAmv6agJGKDpGpMqCr3cY5LiKPXMHV8VP78TIxXti+ d1vOoMBj1eM6Id61qdZoLscOMvBXlqd0eN4FPZ0DsT4+4PRkZWMdrXcAs2D0RQfwnQhS yRnw== X-Forwarded-Encrypted: i=1; AJvYcCX0OLxvNBaLc2p1SyCWd7YHvIUUfgBVbuu1mqI4EYqaU81WB+Dzjxst9frW5nXP3YY/+/k4jg==@lists.linux.dev X-Gm-Message-State: AOJu0Ywo15nvOOk+Tr6l8+BOKtSc5Vee4Cjih0rbGGg7UsWhdhO0Z2JJ 0xES5QS2ZZaDoKJjb1myZR79NXUH0fMOxJG/AwO97h6ZOz3a0JrEd7liZldX6rQ= X-Gm-Gg: ASbGncv6nJ4RnCunPMwGT+60XqkuVZtR7tyo41hnmUAtuYXOa1fH6NpdYqDsB+bZs4j QuWroWw3p1DzcIhHARNms/MSXhgWqlrSJtZy3iEvIoPBSJtIT/10N8bL9Y/OW/T2BGyiy/oEpFx iRhexf505gkuCfq/dFbE9kuHWWpWUQpDaROjg7w/AuVwQzmwtE1FDkWdIIovYE6Py7vUxpyFr3N HE1de2Ygsv7Fqu4z+LzOgXPfMhkaoXAeLkf0I+JfG2w5F1eOOEWH+CZ5CCmVBxZmLU80MVJF3SO QrUy7rSBs77VRpYcEuCWph4rIuUq1mBdTmE5QkCH7UuHqFoPWTot5EnlLn4Du7aw X-Google-Smtp-Source: AGHT+IGaUTz7ZR5mTsPN8ZqZQSlW5yPd5NDczzm4gie81ewyfyxQiY2YHx+YPUrCb2CsYgW0NA6WJA== X-Received: by 2002:ac8:5fc1:0:b0:471:fa1c:3cbb with SMTP id d75a77b69052e-47215123e44mr12524791cf.22.1739997430338; Wed, 19 Feb 2025 12:37:10 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-128-5.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.128.5]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-471feb82ecesm25021711cf.63.2025.02.19.12.37.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Feb 2025 12:37:09 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1tkqoe-00000000BJo-3Lm8; Wed, 19 Feb 2025 16:37:08 -0400 Date: Wed, 19 Feb 2025 16:37:08 -0400 From: Jason Gunthorpe To: Michael Roth Cc: Alexey Kardashevskiy , x86@kernel.org, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-pci@vger.kernel.org, linux-arch@vger.kernel.org, Sean Christopherson , Paolo Bonzini , Tom Lendacky , Ashish Kalra , Joerg Roedel , Suravee Suthikulpanit , Robin Murphy , Kevin Tian , Bjorn Helgaas , Dan Williams , Christoph Hellwig , Nikunj A Dadhania , Vasant Hegde , Joao Martins , Nicolin Chen , Lu Baolu , Steve Sistare , Lukas Wunner , Jonathan Cameron , Suzuki K Poulose , Dionna Glaze , Yi Liu , iommu@lists.linux.dev, linux-coco@lists.linux.dev, Zhi Wang , AXu Yilun , "Aneesh Kumar K . V" Subject: Re: [RFC PATCH v2 12/22] iommufd: Allow mapping from guest_memfd Message-ID: <20250219203708.GO3696814@ziepe.ca> References: <20250218111017.491719-1-aik@amd.com> <20250218111017.491719-13-aik@amd.com> <20250218141634.GI3696814@ziepe.ca> <340d8dba-1b09-4875-8604-cd9f66ca1407@amd.com> <20250218235105.GK3696814@ziepe.ca> <06b850ab-5321-4134-9b24-a83aaab704bf@amd.com> <20250219133516.GL3696814@ziepe.ca> <20250219202324.uq2kq27kmpmptbwx@amd.com> Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250219202324.uq2kq27kmpmptbwx@amd.com> On Wed, Feb 19, 2025 at 02:23:24PM -0600, Michael Roth wrote: > Just for clarity: at least for normal/nested page table (but I'm > assuming the same applies to IOMMU mappings), 1G mappings are > handled similarly as 2MB mappings as far as RMP table checks are > concerned: each 2MB range is checked individually as if it were > a separate 2MB mapping: Well, IIRC we are dealing with the AMDv1 IO page table here which supports more sizes than 1G and we likely start to see things like 4M mappings and the like. So maybe there is some issue if the above special case really only applies to 1G and only 1G. > But the point still stands for 4K RMP entries and 2MB mappings: a 2MB > mapping either requires private page RMP entries to be 2MB, or in the > case of 2MB mapping of shared pages, every page in the range must be > shared according to the corresponding RMP entries. Is 4k RMP what people are running? > I think, for the non-SEV-TIO use-case, it had more to do with inability > to unmap a 4K range once a particular 4K page has been converted Yes, we don't support unmap or resize. The entire theory of operation has the IOPTEs cover the guest memory and remain static at VM boot time. The RMP alone controls access and handles the static/private. Assuming the host used 2M pages the IOPTEs in an AMDv1 table will be sized around 2M,4M,8M just based around random luck. So it sounds like you can get to a situation with a >=2M mapping in the IOPTE but the guest has split it into private/shared at lower granularity and the HW cannot handle this? > from shared to private if it was originally installed via a 2MB IOPTE, > since the guest could actively be DMA'ing to other shared pages in > the 2M range (but we can be assured it is not DMA'ing to a particular 4K > page it has converted to private), and the IOMMU doesn't (AFAIK) have > a way to atomically split an existing 2MB IOPTE to avoid this. The iommu can split it (with SW help), I'm working on that infrastructure right now.. So you will get a notification that the guest has made a private/public split and the iommu page table can be atomically restructured to put an IOPTE boundary at the split. Then the HW will not see IOPTEs that exceed the shared/private granularity of the VM. Jason