From nobody Mon Apr 29 12:37:29 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1493909884171645.6599006449911; Thu, 4 May 2017 07:58:04 -0700 (PDT) Received: from localhost ([::1]:42422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d6ICd-0007MN-28 for importer@patchew.org; Thu, 04 May 2017 10:57:59 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d6IBs-0006vI-SV for qemu-devel@nongnu.org; Thu, 04 May 2017 10:57:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d6IBn-0003AG-Sa for qemu-devel@nongnu.org; Thu, 04 May 2017 10:57:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51308) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d6IBn-00037Z-Js for qemu-devel@nongnu.org; Thu, 04 May 2017 10:57:07 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C0B665876; Thu, 4 May 2017 14:57:06 +0000 (UTC) Received: from dhcp-17-113.lcy.redhat.com (unknown [10.42.17.113]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4B42577E2A; Thu, 4 May 2017 14:57:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1C0B665876 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=berrange@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1C0B665876 From: "Daniel P. Berrange" To: qemu-devel@nongnu.org Date: Thu, 4 May 2017 15:56:58 +0100 Message-Id: <20170504145658.5506-1-berrange@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 04 May 2017 14:57:06 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH RFC] i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , "Richard W.M. Jones" , Eduardo Habkost , Richard Henderson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Currently when running KVM, we expose "KVMKVMKVM\0\0\0" in the 0x40000000 CPUID leaf. Other hypervisors (VMWare, HyperV, Xen, BHyve) all do the same thing, which leaves TCG as the odd one out. The CPUID is used by software to detect when running in a virtual environment and change behaviour in certain ways. For example, systemd supports a ConditionVirtualization=3D setting in unit files. Currently they have to resort to custom hacks like looking for 'fw-cfg' entry in the /proc/device-tree file. The virt-what command has the same hacks & needs. This change thus proposes a signature TCGTCGTCGTCG to be reported when running under TCG. NB1, for reasons I don't undersatnd 'cpu_x86_cpuid' function clamps the requested CPUID leaf based on env->cpuid_level. The latter comes from the CPU model definitions, and is lower than 0x40000000, so the CPUID signature request just gets turned into a completely different request. eg when using '-cpu qemu64', the 0x40000000 request from the guest gets clamped to 0xD and thus returns totally bogus data. I just removed the clamping code, but someone who understands this might have a better suggestion. NB2, for KVM, we added a flag for '-cpu kvm=3Doff' to let you hide the KVMKVMKVM signature from guests. Presumably we should add a 'tcg=3Doff' flag for the same reason ? Signed-off-by: Daniel P. Berrange --- target/i386/cpu.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 13c0985..ac2776e 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -2626,6 +2626,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, = uint32_t count, X86CPU *cpu =3D x86_env_get_cpu(env); CPUState *cs =3D CPU(cpu); uint32_t pkg_offset; + uint32_t signature[3]; =20 /* test if maximum index reached */ if (index & 0x80000000) { @@ -2646,8 +2647,13 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,= uint32_t count, } } } else { - if (index > env->cpuid_level) + /* XXX this just breaks CPUID turning guest requests + * into something totally different, thus returning + * garbage data + */ + if (0 && index > env->cpuid_level) { index =3D env->cpuid_level; + } } =20 switch(index) { @@ -2872,6 +2878,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,= uint32_t count, } break; } + case 0x40000000: + /* XXX add flag to let us hide this */ + memcpy(signature, "TCGTCGTCGTCG", 12); + *eax =3D 0x40000001; + *ebx =3D signature[0]; + *ecx =3D signature[1]; + *edx =3D signature[2]; + break; case 0x80000000: *eax =3D env->cpuid_xlevel; *ebx =3D env->cpuid_vendor1; --=20 2.9.3