From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 2DE8E14B949; Fri, 30 Aug 2024 16:59:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725037186; cv=none; b=E/gtiysytRjYVvLfOgo0Qe1iR7vrU07mjf/1GxQl6WrRk/u85dHv1+6TxYxjf174GSQmtL8Z9IqHfSeg0EjDMTsGBDmBzlIDcSwGtgLr6d3JOetKTVz3JEMswOO8rdysD1plwOsnQ4daam2275ug4anzHa8PHmZ8mLnhJMKXdGg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725037186; c=relaxed/simple; bh=g+CDz/qgnDvPGrRMnmHjXJO8gZVIdvkxBnTYdMpl1Eo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qj/3u2q6jxDUWf91mXh82mDEmSW907lp1LF+Q2glhNygtVafZaruSuVGOrpnEGrnEpgsJl1n9MnXF50N5LD6n0foLZtik3CUKofJhMdyv39daAjUz6EG3UI4Iw+zWzAF8brpzhZLnBlx6mAshKHQtXAUSy8++Tf44cQi52m84bU= 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=i4ib93TQ; arc=none smtp.client-ip=192.198.163.15 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="i4ib93TQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725037183; x=1756573183; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=g+CDz/qgnDvPGrRMnmHjXJO8gZVIdvkxBnTYdMpl1Eo=; b=i4ib93TQs4gLyG8nEDEVLi1RRLCsqU03GLbmmJnjF+GrVabuc4T8i3QX pLMpX2scEmzWO7bs3p4QRnnVntyWVFtph28EccT7aR9K+Gws+pow7WYVk Ej0tr93SsGAlpebRkPw9oTk0J7BPqx3SG0qJPm5EzOlA81qhi1Rm2rKye ILd68NTQ5r8QmzDD4iA/NWOXoPa4eGHVWwmGXA+PK52XyWO/dWtv6XjzJ 70o5Y6/Lv+82/bwApqfyHuAoMvKIq+5hvlztvnbILbzSsHqLa89f+0OE3 z8sBRhbTs5hQh9Mi1qo6eQU5SXVg8aZanpAbU8TQ64aCxZ9GSilBclgaB g==; X-CSE-ConnectionGUID: 8gjQMlfbRzekDk71M2y+qg== X-CSE-MsgGUID: k+KSlKSmTWeS7Wp80eigoQ== X-IronPort-AV: E=McAfee;i="6700,10204,11180"; a="23850880" X-IronPort-AV: E=Sophos;i="6.10,189,1719903600"; d="scan'208";a="23850880" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2024 09:59:42 -0700 X-CSE-ConnectionGUID: 8WJvFrZ1S4S5x2a3h0WlzA== X-CSE-MsgGUID: 5ROgX7cgTDCCRTrQKpm91w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,189,1719903600"; d="scan'208";a="68842950" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.165]) by orviesa004.jf.intel.com with ESMTP; 30 Aug 2024 09:59:38 -0700 Date: Sat, 31 Aug 2024 00:57:10 +0800 From: Xu Yilun To: Alexey Kardashevskiy Cc: kvm@vger.kernel.org, iommu@lists.linux.dev, linux-coco@lists.linux.dev, linux-pci@vger.kernel.org, Suravee Suthikulpanit , Alex Williamson , Dan Williams , pratikrajesh.sampat@amd.com, michael.day@amd.com, david.kaplan@amd.com, dhaval.giani@amd.com, Santosh Shukla , Tom Lendacky , Michael Roth , Alexander Graf , Nikunj A Dadhania , Vasant Hegde , Lukas Wunner Subject: Re: [RFC PATCH 13/21] KVM: X86: Handle private MMIO as shared Message-ID: References: <20240823132137.336874-1-aik@amd.com> <20240823132137.336874-14-aik@amd.com> 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: <20240823132137.336874-14-aik@amd.com> On Fri, Aug 23, 2024 at 11:21:27PM +1000, Alexey Kardashevskiy wrote: > Currently private MMIO nested page faults are not expected so when such > fault occurs, KVM tries moving the faulted page from private to shared > which is not going to work as private MMIO is not backed by memfd. > > Handle private MMIO as shared: skip page state change and memfd This means host keeps the mapping for private MMIO, which is different from private memory. Not sure if it is expected, and I want to get some directions here. >From HW perspective, private MMIO is not intended to be accessed by host, but the consequence may varies. According to TDISP spec 11.2, my understanding is private device (known as TDI) should reject the TLP and transition to TDISP ERROR state. But no further error reporting or logging is mandated. So the impact to the host system is specific to each device. In my test environment, an AER NonFatalErr is reported and nothing more, much better than host accessing private memory. On SW side, my concern is how to deal with mmu_notifier. In theory, if we get pfn from hva we should follow the userspace mapping change. But that makes no sense. Especially for TDX TEE-IO, private MMIO mapping in SEPT cannot be changed or invalidated as long as TDI is running. Another concern may be specific for TDX TEE-IO. Allowing both userspace mapping and SEPT mapping may be safe for private MMIO, but on KVM_SET_USER_MEMORY_REGION2, KVM cannot actually tell if a userspace addr is really for private MMIO. I.e. user could provide shared memory addr to KVM but declare it is for private MMIO. The shared memory then could be mapped in SEPT and cause problem. So personally I prefer no host mapping for private MMIO. Thanks, Yilun > page state tracking. > > The MMIO KVM memory slot is still marked as shared as the guest can > access it as private or shared so marking the MMIO slot as private > is not going to help. > > Signed-off-by: Alexey Kardashevskiy > --- > arch/x86/kvm/mmu/mmu.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 928cf84778b0..e74f5c3d0821 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -4366,7 +4366,11 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > { > bool async; > > - if (fault->is_private) > + if (fault->slot && fault->is_private && !kvm_slot_can_be_private(fault->slot) && > + (vcpu->kvm->arch.vm_type == KVM_X86_SNP_VM)) > + pr_warn("%s: private SEV TIO MMIO fault for fault->gfn=%llx\n", > + __func__, fault->gfn); > + else if (fault->is_private) > return kvm_faultin_pfn_private(vcpu, fault); > > async = false; > -- > 2.45.2 > >