From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 581C53A9D9F for ; Tue, 18 Aug 2026 11:09:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787051358; cv=none; b=mVbirjlf+fGk8pCt3yAzgE2L8Wz47Q73Es0lKrbA6AD97FxyDT+FmtLGs01Q5Xhn6o27NN+Xlv+Q62tsqqMnLyZDvvFRQtbzgq0e/UNbImVNs2G9UxO5AsrJb1jNxeTFN9IvVEqj5RWY+jfxMJgAjT2Bheidepo6v8x9YtslcdU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787051358; c=relaxed/simple; bh=1p6nZ20jw4LUTgx/Y5mwhRhU4CxUnUa0MQ66rPqdx6M=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=deSCP6a9NarP87KGMnbPoqcFsBT+u4PQJGsU/uHtPgm4iO6+mJ5d4ACk6SIGDMLZmj3+Q20PdWTt/K8khDg2eR2mwF3mH6uevqJFaP/yhLoUm8RbVt/8RZjrteBgNZ3MWKqu+s+Z8A5FSXZT4sZLNkG7jXS3y0e6pI968k0/EyA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rtm5OsuU; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rtm5OsuU" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-490cf322ed0so43361955e9.1 for ; Tue, 18 Aug 2026 04:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787051355; x=1787656155; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=1p6nZ20jw4LUTgx/Y5mwhRhU4CxUnUa0MQ66rPqdx6M=; b=rtm5OsuU5Yz5il1gpxTqZl4bkbsLHlDSA2cZ7XGucWQLXuM6BEU+gFGzpAO9f2dqmt 4IlO1lOidhY0hUDDr2Srdji2EmZ2hmT32m+S+ei6N8iih64JDrGu9hj+7o3C4NOxItLH Z8NozMDslSfVclk3H4Bq0UBTCikrEDMc5HRqBu8MsdLYsIhAndzTVsyPjPFZbBifw7QY lgQ7E4AtO/znY6wCljlySQuHI57LFgctsARDbxBdyGU1OQD7VUUnDfc3kP+Lmq05SH5Z M6bA2+rY+3/PU8S8HRorx/NuTmk5Ya+3CC0HP1KTZeqTtthfVtD9hrXAcFs0TZmeyuCh yyLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787051355; x=1787656155; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1p6nZ20jw4LUTgx/Y5mwhRhU4CxUnUa0MQ66rPqdx6M=; b=kEWrYPQkxqz/ocdsdJQZMkDi+rcOfFHD3ilEZUl9+EX0zqL3rFZ2Y6Vfl0tVKHKjI0 xuMjPZHTmNEVvmE0PbG4IdPXc1gsxppyyV3X9iny+cmeaHwyeyM+02+SMsOqK1TbLrKj 07gHtdhZYSfwIXEGY5q4C7AZC6SdJ9rkyNeoVymBMhtPqZmbsr4Sv5JGFDEa628kkcve x1XmcEVI06WGdMX/mNG1QFwnXv/NY8aWd1gdH20REg66tl4d1DUiD70nvXEeCTNpjx5+ 4s552V9a9Pbdx9KNkE9h2skA/gqfokWL2sqlILhrj7Ew3/wnCo78EL0Vl3mZpz+NsFzU Tl1A== X-Forwarded-Encrypted: i=1; AHgh+RrEGhiVEsjpMgDaoTloz6hm4lvCN89FJBG/CdjQ0VOB58YoGdAxBhkz07Y3OjexR8SPExkpq9rRWBlNExQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyOWAnDsG0f4sphVgEwAIwAaJxRK5RRIXcEYUhOmE3qGhHj3k2p zShJUgai8/tA9o8JQzb6TQeZBVrSs3HtcngcME3OJEUCG3iKZBQ1rD0N X-Gm-Gg: AR+sD11tDLir22OrS0Khs0Xj8PqJEIryoiiwJmFunBinWzpmy8DLUCzulnqv8xYyNcs n+ojXmSQW7RaDy6YMS9O8qBSzypcK52FrQ5fp1Wf21Jq2UcYd9mmFIs2kYkiy2JPYSiIj/mYtc4 1DhZ0Qd5vFPJbSxMfZrcsUrXgCvOC3ibsyG/IkdcA2/5URS2hAdX43FotxgSpj+tfHHs1J+x03m lkbGYTQv+4v+4n6PQOM6+xjYVt1eZ/vpr9RQeiO9pOM9WDyWOtYFRh+je9IPI96aUrKks9sKB4A Xr7ruvQ7+9ymp+pAIeAaxItT3bmVYcoGpt27Eg15X73Du7xgGBRTF2LsBZasBEvAwyWWjugukgN eQJnjMmgZyAlQROOrPBPdd0SZMGPZT2oEJpdgx2PrensPqyENhZJFUS1EaaQ3uJ1l9nH1pL5TFi Le9CJn/bCZyWTZ6nWDTeqq/KSYRs8ZSX0PFAVb5S6rENtzToazz3OsMrBpTnchlH8= X-Received: by 2002:a05:600c:3b1d:b0:499:87b6:f3c0 with SMTP id 5b1f17b1804b1-4998807e4c9mr507923515e9.14.1787051355348; Tue, 18 Aug 2026 04:09:15 -0700 (PDT) Received: from [10.245.245.215] ([134.191.227.46]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49996109652sm301473815e9.4.2026.08.18.04.09.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 04:09:14 -0700 (PDT) Message-ID: <83968006d6ee498621978d81a02659bb6186a0b9.camel@gmail.com> Subject: Re: [PATCH v3 0/4] tdx-guest: Make Quote buffer size dynamic From: Artem Bityutskiy To: "Edgecombe, Rick P" , "seanjc@google.com" Cc: "hpa@zytor.com" , "bp@alien8.de" , "x86@kernel.org" , "kas@kernel.org" , "binbin.wu@linux.intel.com" , "Li, Xiaoyao" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "linux-kernel@vger.kernel.org" , "dave.hansen@linux.intel.com" , "tglx@kernel.org" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , "mingo@redhat.com" , "Fang, Peter" Date: Tue, 18 Aug 2026 14:09:11 +0300 In-Reply-To: <0b5a26492f367f793aab38e4a0d9d6f398340f51.camel@intel.com> References: <20260729122939.1340412-1-peter.fang@intel.com> <80b4ea89ebf17398c3bee21d157c7f97ea32aadf.camel@intel.com> <86d532f33816cd4fa3e29c40079a6003abf89324.camel@intel.com> <20260812223707.GD1013044@pedri> <6191a69559e58e04c8e3f1efa776e9639796af3d.camel@intel.com> <98dcc8a12f117745a1cb9981dc8f0f1548e9c96f.camel@gmail.com> <4ad451969522eecb445289ca74a88ee73d51336d.camel@intel.com> <8b432c8731167e97432b2e917d0b1c855fedf47c.camel@gmail.com> <21ffbb7b80c0c654c23a97cda55f43c73e49ba25.camel@intel.com> <498af8d6a5de3ee05e0216ea075c0eebf88c7072.camel@gmail.com> <0b5a26492f367f793aab38e4a0d9d6f398340f51.camel@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-08-17 at 17:26 +0000, Edgecombe, Rick P wrote: > > I am curious if today this is an attestation-only problem or a pattern. > > I mean this "many TDs compete for a shared TDX capability, VMM needs to > > be involved to handle fairness". > >=20 >=20 > Yea, I think it is a really good question. This is getting off topic now,= but... >=20 > There is an existing issue we have with the "host priority" (HP) bit. Thi= s is a > part of the TDX arch that is designed to help with guest host contention.= For > example a TDG call like ACCEPT can take an S-EPT lock that the host wants= to > also take with a TDH call. It is sort of important to have the host be in > ultimate control. So the way the HP bit works is, if the host meets conte= ntion, > it sets the HP bit. The bit means if the guest tries to take the lock aga= in, it > is blocked without letting the lock get taken. This gives the host a chan= ce to > retry and succeed. After the host succeeds in taking the lock, the HP bit= is > cleared. This is like a crude fairness thing. Thanks. Yes, sounds crude, and it does not look like it covers fairness across TDs. It only covers the "VMM has priority" part. > But it all depends on the host retrying. If the host never retries becaus= e > userspace intervenes, then the guest stays locked out. We actually hit th= is > condition in the tdx mmu stress selftest. So it is on the to-do list to f= ix in > TDX arch. I see, the VMM not making progress blocks TDs which could make progress=C2=A0otherwise. Thanks for the info. TDX specs describe the HP_LOCK_TIMEOUT per-TD property (set by the host via TDH.MNG.WR), which could be used to somewhat make the symptom somewhat controllable, may be make pain less painful, but it is not a cure for the illness. > Now how this connects to the 1-flow vs 2-flow design... As we have been > discussing this quote/report stuff, I wondered if we couldn't solve the H= P bit > problems with a similar 2-flow thing. For example a TDG.ACCEPT call could= exit > to the host without taking any locks and providing some kind of token, th= at a > paired TDH call could be used to complete the accept (and take the locks)= . TDH > calls should not be able to accept guest memory arbitrarily, so there nee= ds to > be some kind of security validation on the TDH call. But then the host co= uld > control all the scheduling/priority stuff. The overall solution would be = better > for having this locking balancing stuff done in a single place where ther= e are > no odd overlaps. But it means we also have extra host code for every TDG = call > that takes a problematic lock. Probably more TDX module complexity too. Yeah. We have TDG.VP.VMCALL as an "exit to the VMM and let it handle stuff" capability.=C2=A0 So essentially you are pointing out that one of the=C2=A0approaches is turning a problematic TDCALL[TDG.ABRA.CADABRA] into a TDCALL[TDG.VP.VMCALL]. I guess this approach could be used in few selected cases. Thanks!