From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 CA0721779AE for ; Mon, 27 Jan 2025 17:05:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737997503; cv=none; b=SA6dZq2OQSWlKhEXjGB0FTfyzlY93jGuiQ2PFedI92aX3r//2fRnNftIQvGWEcTPXFpHdvPLdRcSJ5vCDR6Ia9/ZPbdtj7O9YxOKTAUhCNVePwEUlbv7Cehc9zxZwftZNz/LCr6bA1zdoRkbYK0Hho9ImpA9mIdgLkptMpBVUqY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737997503; c=relaxed/simple; bh=wJmbWVGPNlBY1q9XcbEFIAtJU0FoZRe9yZqry0QkOsk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=CWRiNQefMZBFBO9dVebg0tjKVcV9Su5HwdAqnhhKCUj/sbbSBIBU/E0VlGEOwx68XXqvugyTGqMKQubSJOqy5qA4kj+/MSjUb7GJ+3OcN+MweQHqdbkYyLUd6NIinHxb7CsySaI9HvhUN4iBhSsI+NnqI4Yok/h22wBIW4fxyws= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=1RXoJyHp; arc=none smtp.client-ip=209.85.214.202 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=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="1RXoJyHp" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2164861e1feso89437855ad.1 for ; Mon, 27 Jan 2025 09:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737997501; x=1738602301; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=T+ETOTo5IfPgKyFMapOrCWmqlpkzTGZaFAV0TeQlMDE=; b=1RXoJyHpfkMiqH1bgm9VSF2mh9zxPja069TXsbu7lWbeUryTb1BnOyUB1r1/5Q3k9K diKM20jPcJkxROJubTde6IR/qg52IjuVF2PzmSnDN0ccU08zk6C3pcTAGjpvOdj/FPrT +3rS+jV3PiqkPFYurFPf1k79QagbRkgH2o+jXsZI+/V+4a0McS3oYcAQbb9n/KNA/o3V JGMdtSdpFeQl/NVYMuQXLpyPWVm5eH9vQZ9cOJrtmqkE+QW4HCHdMlpvDYJMKE80Yfp3 akGSVqPt8Xt0YMxHHe4dOn2BhCtvAwS5uUCnLZUGNK6Qh/yROijso1MeSzabdOiqhAIR DxkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737997501; x=1738602301; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=T+ETOTo5IfPgKyFMapOrCWmqlpkzTGZaFAV0TeQlMDE=; b=SRmNOUPXQWPkhSvDlM5u8F3uJh8HpsriIuFU6NIqUQzBbW9j6WpCzv3QHYoxgmpIiV Pd4GAyn4iq/q3MQsLG8QBENTyLxMXCOv302kdAsVGPQy2krELCHHrZad2O7LnonzsI/C 3NtZe0gbfTkmHyMd3u6cjhZpOo1VfXPmcWaymaALfaBHv93NNRzfay9lcvjj1VBVOlDv 4P9VMM31VaLRxXs5+qpbwEWywme4HllXRjwHUZuDWIDPb0I3BKEV0qClFp9yJ/nvKwsZ N2tAekbh1zVEvL7ggGY559D2nwQGHMUnwi+trrh5laQFRbaziWNwcYuNr5DPrnlR+PfM t7Nw== X-Forwarded-Encrypted: i=1; AJvYcCVD5ryXSm7885HKjrWdeGA7IG7S5idbW8df9pcJPL800dT4f0a8I2FGbYEO9GI2ujRwL/a4mAmUt0/8bw0=@vger.kernel.org X-Gm-Message-State: AOJu0YySs7unlk9jJnSclDQOs4jc63xBgInCdSuDMsnzGkPAF9WQXbyT rcqF5kpq9ZR9jS5T2R0VwAFLQ1n/l/Br9hBtCKeuN9CMiOA0/wZz4UWWd2nWNh6XNlFcqbcVwE4 Tmg== X-Google-Smtp-Source: AGHT+IFYQZC+7lIxW9G9BX1IIQ/awHF38+WG0ZYkvV34s8cor4Z8FTRasrIVcMKPRdWl8WX50bSEoI4+OsA= X-Received: from plblq13.prod.google.com ([2002:a17:903:144d:b0:216:248e:8fab]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:1c6:b0:215:65f3:27f2 with SMTP id d9443c01a7336-21c352c7915mr502501525ad.8.1737997500962; Mon, 27 Jan 2025 09:05:00 -0800 (PST) Date: Mon, 27 Jan 2025 09:04:59 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250113020925.18789-1-yan.y.zhao@intel.com> <20250113021218.18922-1-yan.y.zhao@intel.com> Message-ID: Subject: Re: [PATCH 3/7] KVM: TDX: Retry locally in TDX EPT violation handler on RET_PF_RETRY From: Sean Christopherson To: Yan Zhao Cc: pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, rick.p.edgecombe@intel.com, kai.huang@intel.com, adrian.hunter@intel.com, reinette.chatre@intel.com, xiaoyao.li@intel.com, tony.lindgren@intel.com, binbin.wu@linux.intel.com, dmatlack@google.com, isaku.yamahata@intel.com, isaku.yamahata@gmail.com Content-Type: text/plain; charset="us-ascii" On Mon, Jan 27, 2025, Yan Zhao wrote: > On Fri, Jan 24, 2025 at 05:23:36PM -0800, Sean Christopherson wrote: > My previous consideration is that > when there's a pending interrupt that can be recognized, given the current VM > Exit reason is EPT violation, the next VM Entry will not deliver the interrupt > since the condition to recognize and deliver interrupt is unchanged after the > EPT violation VM Exit. > So checking pending interrupt brings only false positive, which is unlike > checking PID that the vector in the PID could arrive after the EPT violation VM > Exit and PID would be cleared after VM Entry even if the interrupts are not > deliverable. So checking PID may lead to true positive and less false positive. > > But I understand your point now. As checking PID can also be false positive, it > would be no harm to introduce another source of false positive. Yep. FWIW, I agree that checking VMXIP is theoretically "worse", in the sense that it's much more likely to be a false positive. Off the top of my head, the only time VMXIP will be set with RFLAGS.IF=1 on an EPT Violation is if the EPT violation happens in an STI or MOV_SS/POP_SS shadow. > So using kvm_vcpu_has_events() looks like a kind of trade-off? > kvm_vcpu_has_events() can make TDX's code less special but might lead to the > local vCPU more vulnerable to the 0-step mitigation, especially when interrupts > are disabled in the guest. Ya. I think it's worth worth using kvm_vcpu_has_events() though. In practice, observing VMXIP=1 with RFLAGS=0 on an EPT Violation means the guest is accessing memory for the first time in atomic kernel context. That alone seems highly unlikely. Add in that triggering retry requires an uncommon race, and the overall probability becomes miniscule. > > That code needs a comment, because depending on the behavior of that field, it > > might not even be correct. > > > > > (2) kvm_vcpu_has_events() may lead to unnecessary breaks due to exception > > > pending. However, vt_inject_exception() is NULL for TDs. > > > > Wouldn't a pending exception be a KVM bug? > Hmm, yes, it should be. > Although kvm_vcpu_ioctl_x86_set_mce() can invoke kvm_queue_exception() to queue > an exception for TDs, I thought TDX didn't support synthetic #MCs? > this should not occur while VCPU_RUN is in progress. Not "should not", _cannot_, because they're mutually exclusive.