From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 476711E7C03 for ; Tue, 3 Feb 2026 07:03:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770102210; cv=none; b=sD8kB9BYWtgfauK2mKHCh74hmxCbnhTDU7yRgLwqbabf++8MmC+yeEplv06Hb8ZYHdTycROXVW7Kn136lg1x7QvnIaC52kht0gZUW88Zb0Ga0extAL+VLq13/HGtovufLLFWvayAFHJtzhK7bwze93z7nzl3kbsOdo66TR9VBF4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770102210; c=relaxed/simple; bh=kczN3zFVSzrE7bKpYSzAUPB9J3iO/g+9SFCRSp4oF4s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=l76Rr14+JS3OYSHw4zbNqbbsq49TnvfYrLwXbhIlpl6pvoi542zoLW+qeyMkoe8+8jrZC+fohL56HQbpz6+5agnz8FZ/4lBTTL81d1+nd2BwQgHotF/oUlIsukhHw/sMQUtQVrqLEp3u7O5E4ppL/4TYbpb1PlNDWauwOCyX5Xk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=iPlhIMsr; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="iPlhIMsr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770102208; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JNV9xtlwyBIDkoyTjXrtJhXtllvrWI0sq7+WcuGQXaw=; b=iPlhIMsrW9c+r6rvRaYaS7Yfns0tqbZpqb9tTXWErv2qRnQS4O97fc2dXt36UHU1ZCSBRP 5cy3jyfVLvvABguVwiTr8+OaoiuYtAbm784hSBpg4TdXF8FW/shVHku2PRm2YOvPpC9hqP BeRdAZHcsFH8V6c5l0taeXCGZTStAXQ= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-490-mZlohMmuOFaSj-MBD9DLKw-1; Tue, 03 Feb 2026 02:03:23 -0500 X-MC-Unique: mZlohMmuOFaSj-MBD9DLKw-1 X-Mimecast-MFC-AGG-ID: mZlohMmuOFaSj-MBD9DLKw_1770102201 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 74E371800447; Tue, 3 Feb 2026 07:03:21 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.45.242.22]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 44BFB1956053; Tue, 3 Feb 2026 07:03:20 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id DBA7021E692D; Tue, 03 Feb 2026 08:03:17 +0100 (CET) From: Markus Armbruster To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: Daniel P. =?utf-8?Q?Berrang=C3=A9?= , qemu-devel@nongnu.org, Eric Blake , Paolo Bonzini , Marcelo Tosatti , "open list:X86 KVM CPUs" , Eduardo Habkost , Marcel Apfelbaum , =?utf-8?Q?Philippe_Mathieu-Daud=C3=A9?= , Yanan Wang , Zhao Liu Subject: Re: [PATCH] Add query-tdx-capabilities In-Reply-To: (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Mon, 26 Jan 2026 19:20:29 +0400") References: <20260106183620.2144309-1-marcandre.lureau@redhat.com> <87qzrzku9z.fsf@pond.sub.org> <87jyxrksug.fsf@pond.sub.org> <87cy3jkrj8.fsf@pond.sub.org> <871pjzkm4y.fsf@pond.sub.org> Date: Tue, 03 Feb 2026 08:03:17 +0100 Message-ID: <87343i71hm.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 Cc: machine core maintainers for an opinion on query-machines. Marc-Andr=C3=A9 Lureau writes: > Hi > > On Fri, Jan 9, 2026 at 4:27=E2=80=AFPM Markus Armbruster wrote: >> >> Daniel P. Berrang=C3=A9 writes: >> >> > On Fri, Jan 09, 2026 at 11:29:47AM +0100, Markus Armbruster wrote: >> >> Daniel P. Berrang=C3=A9 writes: >> >> >> >> > On Fri, Jan 09, 2026 at 11:01:27AM +0100, Markus Armbruster wrote: >> >> >> Daniel P. Berrang=C3=A9 writes: >> >> >> >> >> >> > On Fri, Jan 09, 2026 at 10:30:32AM +0100, Markus Armbruster wrot= e: >> >> >> >> Daniel P. Berrang=C3=A9 writes: >> >> >> >> >> >> >> >> > On Tue, Jan 06, 2026 at 10:36:20PM +0400, marcandre.lureau@re= dhat.com wrote: >> >> >> >> >> From: Marc-Andr=C3=A9 Lureau >> >> >> >> >> >> >> >> >> >> Return an empty TdxCapability struct, for extensibility and = matching >> >> >> >> >> query-sev-capabilities return type. >> >> >> >> >> >> >> >> >> >> Fixes: https://issues.redhat.com/browse/RHEL-129674 >> >> >> >> >> Signed-off-by: Marc-Andr=C3=A9 Lureau [...] >> >> >> Do management applications need to know more than "this combinatio= n of >> >> >> host + KVM + QEMU can do SEV, yes / no? >> >> >> >> >> >> If yes, what do they need? "No" split up into serval "No, because= X"? >> >> > >> >> > When libvirt runs query-sev-capabilities it does not care about the >> >> > reason for it being unsupported. Any "GenericError" is considered >> >> > to mark the lack of host support, and no fine grained checks are >> >> > performed on the err msg. >> >> > >> >> > If query-sev-capabilities succeeds (indicating SEV is supported), t= hen >> >> > all the returned info is exposed to mgmt apps in the libvirt domain >> >> > capabilities XML document. >> >> >> >> So query-sev-capabilities is good enough as is? >> > >> > IIUC, essentially all QEMU errors that could possibly be seen with >> > query-sev-capabilities are "GenericError" these days, except for >> > the small possibility of "CommandNotFound". >> > >> > The two scenarios with lack of SEV support are covered by GenericError >> > but I'm concerned that other things that should be considered fatal >> > will also fall under GenericError. >> > >> > eg take a look at qmp_dispatch() and see countless places where we can >> > return GenericError which ought to be treated as fatal by callers. >> > >> > IMHO "SEV not supported" is not conceptually an error, it is an >> > expected informational result of query-sev-capabilities, and thus >> > shouldn't be using the QMP error object, it should have been a >> > boolean result field. >> >> I agree that errors should be used only for "abnormal" outcomes, not for >> the "no" answer to a simple question like "is SEV available, and if yes, >> what are its capabilities?" >> >> I further agree that encoding "no" as GenericError runs the risk of >> conflating "no" with other errors. Since query-sev itself can fail just >> one way, these can only come from the QMP core. For the core's syntax >> and type errors, the risk is only theoretical: just don't do that. >> Errors triggered by state, like the one in qmp_command_available(), are >> a bit more worrying. I think they're easy enough to avoid if you're >> aware, but "if you're aware" is admittedly rittle. >> >> Anyway, that's what we have. Badly designed, but it seems to be >> workable. >> >> Is the bad enough to justify revising the interface? I can't see how to >> do that compatibly. >> >> Is it bad enough to justify new interfaces for similar things to be >> dissimilar? >> > > Maybe query-{sev,tdx,*}-capabilities should only be called when the > host is actually capable, thus throwing an Error is fine. > > What about a new "query-confidential-guest-supports" command that > checks the host capability and returns ["sev", "tdx", "pef"...] then ? Some similarity to query-accelerators. Feels reasonable. > Or maybe this should be provided at the MachineInfo level instead > (query-machines). Also reasonable, I think. Machine core maintainers, got an opinion?