From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05D2436D; Thu, 6 Mar 2025 06:49:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741243787; cv=none; b=JjAsez+ZEfT62mXQeI4W9UnPdfvw/7it1QFaVmI978TKRWU4p/W2cQ/+duZhRaQy58ms3McI09zrbZFR0ANwncJxP///mCIDADD30r9McFTK/Uif1QZKP5Pp0N3ucAqhhPv0SJ7sxJRWAGF13+Xz45nxpU6XeSFiZXE9az+V5AU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741243787; c=relaxed/simple; bh=nihPbFWpYPqsBosZAhoIw4NpSVYZ7ujfvelE5cg2qlQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lSK/mmRjUfX+psHW+FPPQ9FW/ppqceTvMRA79uGjWAhiQOl4R2QawoWzztRkayvdk2xDCCszLFDw/zuA3T4JKSNMq+5TluIYgGpUXy9wUXgEsnpZS77oibaB9zEo1lutLEew56vub1lCpGj92ZcTDaCfishNqmEReebvloXSavE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=l8cJypSN; arc=none smtp.client-ip=192.198.163.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="l8cJypSN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741243786; x=1772779786; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=nihPbFWpYPqsBosZAhoIw4NpSVYZ7ujfvelE5cg2qlQ=; b=l8cJypSNKs+Tt3tSJtZPaE1YYYsmzOBytiKizccEkjQFmDJHR/rjR9SL 71G4THNnbki4NNOPFeHrJW5UAjNwbSC53xOhvIaHeTcKdhwgTbTHGHYnD JQs3IMrVqcDB4TVDr51aKKLSgdR8BeZ1vAbLKL3E1YXXlAmHIbcLTkHMN Z6aVq3pr/UpzhYnJsbieCcAuknUNmPARYLjCLVy9XAzHL24OrP0Re7OdJ 4u3b62gbTbqutW7A1r8O65HGaMZh47gUX16DaHSCK+x4QNuFvdMfzNYeS I09Piene9hR96XNdARYyTLqxcqubMici7vMo6r5HZ95NFa4asf6lUQ41E A==; X-CSE-ConnectionGUID: KIW218sMTvKSjAu0ddISzA== X-CSE-MsgGUID: V2/1ABVYROmL6vLM0X8sPA== X-IronPort-AV: E=McAfee;i="6700,10204,11363"; a="41488717" X-IronPort-AV: E=Sophos;i="6.14,225,1736841600"; d="scan'208";a="41488717" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2025 22:49:45 -0800 X-CSE-ConnectionGUID: 0YQ+ToHsQFqTfy8LYBXmaA== X-CSE-MsgGUID: eXWNYvDpQmebOFbpoNF84w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,225,1736841600"; d="scan'208";a="123948108" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.165]) by orviesa004.jf.intel.com with ESMTP; 05 Mar 2025 22:49:37 -0800 Date: Thu, 6 Mar 2025 14:47:23 +0800 From: Xu Yilun To: Jason Gunthorpe 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 , Michael Roth , 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 , "Aneesh Kumar K . V" Subject: Re: [RFC PATCH v2 14/22] iommufd: Add TIO calls Message-ID: References: <20250218111017.491719-1-aik@amd.com> <20250218111017.491719-15-aik@amd.com> <2fe6b3c6-3eed-424d-87f0-34c4e7e1c906@amd.com> <20250226131202.GH5011@ziepe.ca> <20250301003711.GR5011@ziepe.ca> <20250305192842.GE354403@ziepe.ca> Precedence: bulk X-Mailing-List: linux-coco@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: <20250305192842.GE354403@ziepe.ca> On Wed, Mar 05, 2025 at 03:28:42PM -0400, Jason Gunthorpe wrote: > On Mon, Mar 03, 2025 at 01:32:47PM +0800, Xu Yilun wrote: > > All these settings cannot really take function until guest verifies them > > and does TDISP start. Guest verification does not (should not) need host > > awareness. > > > > Our solution is, separate the secure DMA setting and secure device setting > > in different components, iommufd & vfio. > > > > Guest require bind: > > - ioctl(iommufd, IOMMU_VIOMMU_ALLOC, {.type = IOMMU_VIOMMU_TYPE_KVM_VALID, > > .kvm_fd = kvm_fd, > > .out_viommu_id = &viommu_id}); > > - ioctl(iommufd, IOMMU_HWPT_ALLOC, {.flag = IOMMU_HWPT_ALLOC_TRUSTED, > > .pt_id = viommu_id, > > .out_hwpt_id = &hwpt_id}); > > - ioctl(vfio_fd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, {.pt_id = hwpt_id}) > > - do secure DMA setting in Intel iommu driver. > > > > - ioctl(vfio_fd, VFIO_DEVICE_TSM_BIND, ...) > > - do bind in Intel TSM driver. > > Except what do command do you issue to the secure world for TSM_BIND > and what are it's argument? Again you can't include the vBDF or vIOMMU > ID here. Bind for TDX doesn't require vBDF or vIOMMU ID. The seamcall is like: u64 tdh_devif_create(u64 stream_id, // IDE stream ID, PF0 stuff u64 devif_id, // TDI ID, it is the host BDF u64 tdr_pa, // TDX VM core metadate page, TDX Connect uses it as CoCo-VM ID u64 devifcs_pa) // metadate page provide to firmware While for AMD: ... b.guest_device_id = guest_rid; //TDI ID, it is the vBDF b.gctx_paddr = gctx_paddr; //AMDs CoCo-VM ID ret = sev_tio_do_cmd(SEV_CMD_TIO_TDI_BIND, &b, ... Neither of them use vIOMMU ID or any IOMMU info, so the only concern is vBDF. Basically from host POV the two interfaces does the same thing, connect the CoCo-VM ID with the TDI ID, for which Intel uses host BDF while AMD uses vBDF. But AMD firmware cannot know anything meaningful about the vBDF, it is just a magic number to index TDI metadata. So I don't think we have to introduce vBDF concept in kernel. AMD uses QEMU created vBDF as TDI ID, that's fine, QEMU should ensure the validity of the vBDF. > > vfio also can't validate that the hwpt is in the right state when it > executes this function. Not sure if VFIO has to validate, or is there a requirement that secure DMA should be in right state before bind. TDX doesn't require this, and I didn't see the requirement in SEV-TIO spec. I.e. the bind firmware calls don't check DMA state. In my opinion, TDI bind means put device in LOCKED state and related metadate management in firmware. After bind the DMA cannot work. It is the guest's resposibility to validate everything (including DMA) is in the right state, then issues RUN, then DMA works. I.e. guest tsm calls check DMA state. That's why I think Secure DMA configuration on host could be in a separated flow from bind. > > You could also issue the TSM bind against the idev on the iommufd > side.. But I cannot figure out how idev could ensure no mmap on VFIO, and how idev could call dma_buf_move_notify. Thanks, Yilun > > Part of my problem here is I don't see anyone who seems to have read > all three specs and is trying to mush them together. Everyone is > focused on their own spec. I know there are subtle differences :\ > > Jason