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 53E3D3B52ED for ; Thu, 15 Jan 2026 16:55:02 +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=1768496105; cv=none; b=i2sb6wOeerPdHHa/E7FBr9NwgKb11VUgr1IsZLftbWfghTiG6FeyLw/VbEZWLXdOOVW03mRhGlH1C5P9JuCwpENMi2PrAVOUKjkZ41AJSSo5Qe/+6AH+pBtMchyNqCa9aQux85zn20/TJ96TqZLl6xdiXv2+aZH1Joz0eayOHQg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768496105; c=relaxed/simple; bh=vHJzNvUgrWMaqSEXYwJjvXoh/vXYEQ7TR+f/TbNG3c8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=e0qgxvDjNmRwMbUjQrpa/+z7jAE0wxSDgOsY5f3Y4kPhxXZlclgqOsFlAHIUUkCHaZfM6bm9Hs0vXBGM1ivKWXIc1ED20IxAjD02t8P2kd0tWloGYd+b6y0/3ga4AsHEHKHFyAxjltKvw9bR0B8NvLah1uD8msXL8Hbi2ZjzodU= 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=o98zpagQ; 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="o98zpagQ" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-29f13989cd3so22043825ad.1 for ; Thu, 15 Jan 2026 08:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1768496101; x=1769100901; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=eL+E7/4JmScKJihcx95KMzbVjQVIxgRJYXFYqhlTPBQ=; b=o98zpagQZjnhW8aF+YmJ7PiI4uOky8u79nmPt6eTgm4xg8KLMQeNy6b49S/nVpUFTb 9Pa+rUL+3CnPhz8losVkTk9mCWiWXrbwvRE7DxN7JTBajczZG2hGpEkRGO4oEM0q0X9/ x+QQUJD4BlQo2QeInkSrzGJKhLcH9zts+sckdwP9AqltIXlwQQXpGY7/NzLUDdg5sSYi Dga/dc0hs1niaW8fJVSm2TP/F6AS9iQJwYV37upkvCQxbgXzkGGVDY31bFWpqZlEit/k TbpQNppaVlqzf8F7v+rFVIdZp5sI685Bv2dyyYtQpC04lZvFeO7pC/T3EgXBy20Qw7NC 6HOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768496101; x=1769100901; h=content-transfer-encoding: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=eL+E7/4JmScKJihcx95KMzbVjQVIxgRJYXFYqhlTPBQ=; b=dZZ2zAOlOdTDVb2VQwgeXBr40yE180ltILKjOMROodV8RP37YsMepx0YMIaWeh/1im ObqIMkT0e2ldrjvXtT/+EzxDrx+38PKjDZHoeVjdelMzyKMHNr5CpZKUSLkQiVKIHIUU 5BA2+uhHSKiQyRyuzJqqf3WJaZL0ZD1vKF3VO28k5jTtP9Wwz98rBSkYgqs3eKxaq7aZ RWCxtoOX+kv5PovSuTAyI5LtMZJFb8oOpCse1AOO4KlKX5Bf4sArcH7gWdp/6bT/FKS1 ZPGffiyEsobU+V6qC/FW4Jas5LfGoL9RHlM6olJQwJu9Cpk/5HKUoN/B6fbYj4IP2lPL Cdug== X-Forwarded-Encrypted: i=1; AJvYcCXVnFiMc9OH9WJWNlPAroUWbCCfcnAWnjHh156FV3VyCw1qhtmun8jGJa43zakqvktE3gGJUvQGEQShqHI=@vger.kernel.org X-Gm-Message-State: AOJu0YwVzaDYjFifVttRNLX9mKmatIEd2VYmduI+sGrOzHk9Zw47/qQL A6ob0xw4ROQN3hz3qJ7ZjthBPed1Qsk6Y9A7/29eWHmwbrel6G+OMp/ogRcUCygIwHLwQw/CVi3 HPuylSQ== X-Received: from plog2.prod.google.com ([2002:a17:902:8682:b0:2a0:ad08:d949]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:f685:b0:295:96bc:8699 with SMTP id d9443c01a7336-2a7175408damr1410685ad.20.1768496101557; Thu, 15 Jan 2026 08:55:01 -0800 (PST) Date: Thu, 15 Jan 2026 08:54: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: <20260114003015.1386066-1-sagis@google.com> <43a0558a-4cca-4d9c-97dc-ffd085186fd9@intel.com> Message-ID: Subject: Re: [PATCH] KVM: TDX: Allow userspace to return errors to guest for MAPGPA From: Sean Christopherson To: Xiaoyao Li Cc: Sagi Shahar , Paolo Bonzini , Dave Hansen , Kiryl Shutsemau , Rick Edgecombe , Thomas Gleixner , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, Vishal Annapurve Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2026, Xiaoyao Li wrote: > On 1/15/2026 9:21 AM, Sagi Shahar wrote: > > On Wed, Jan 14, 2026 at 9:57=E2=80=AFAM Sean Christopherson wrote: > > > On Wed, Jan 14, 2026, Xiaoyao Li wrote: > > > > The -EINVAL will eventually be returned to userspace for the VCPU_R= UN > > > > ioctl. It certainly breaks userspace. > > >=20 > > > It _might_ break userspace. It certainly changes KVM's ABI, but if n= o userspace > > > actually utilizes the existing ABI, then userspace hasn't been broken= . > > >=20 > > > And unless I'm missing something, QEMU _still_ doesn't set hypercall.= ret. E.g. > > > see this code in __tdx_map_gpa(). > > >=20 > > > /* > > > * In principle this should have been -KVM_ENOSYS, but users= pace (QEMU <=3D9.2) > > > * assumed that vcpu->run->hypercall.ret is never changed by= KVM and thus that > > > * it was always zero on KVM_EXIT_HYPERCALL. Since KVM is n= ow overwriting > > > * vcpu->run->hypercall.ret, ensuring that it is zero to not= break QEMU. > > > */ > > > tdx->vcpu.run->hypercall.ret =3D 0; > > >=20 > > > AFAICT, QEMU kills the VM if anything goes wrong. > > >=20 > > > So while I initially had the exact same reaction of "this is a breaki= ng change > > > and needs to be opt-in", we might actually be able to get away with j= ust making > > > the change (assuming no other VMMs care, or are willing to change the= mselves). > >=20 > > Is there a better source of truth for whether QEMU uses hypercall.ret > > or just point to this comment in the commit message. >=20 > No version of QEMU touches hypercall.ret, from the source code. >=20 > I suggest not mentioning the comment, because it only tells QEMU expects > vcpu->run->hypercall.ret to be 0 on KVM_EXIT_HYPERCALL. What matters is Q= EMU > never sets vcpu->run->hypercall.ret to a non-zero value after handling > KVM_EXIT_HYPERCALL. I think you can just describe the fact that QEMU neve= r > set vcpu->run->hypercall.ret to a non-zero value in the commit message. +1. We can't _guarantee_ changing the behavior won't break userspace, e.g.= in theory, someone could be running a fork of QEMU in production that explicit= ly sets hypercall.ret to some weird value. Or someone could be running a VMM = we don't even know about. I.e. there is no single source of truth, all we can= do is explain why we have high confidence that the ABI change won't break anyt= hing.