linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: kvmarm@lists.cs.columbia.edu
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Okamoto Takayuki" <tokamoto@jp.fujitsu.com>,
	"Christoffer Dall" <cdall@kernel.org>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Marc Zyngier" <marc.zyngier@arm.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will.deacon@arm.com>,
	"Julien Grall" <Julien.Grall@arm.com>,
	"Andre Przywara" <andre.przywara@arm.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 09/12] arm64: [HACK] Show extra info about SVE with --show-reg-list
Date: Fri, 18 Jan 2019 16:14:18 +0000	[thread overview]
Message-ID: <1547828061-20462-10-git-send-email-Dave.Martin@arm.com> (raw)
In-Reply-To: <1547828061-20462-1-git-send-email-Dave.Martin@arm.com>

This patch prints out some information about the SVE configuration
when --show-reg=list is passed.

This is development hack only (as well as being an abuse of the
purpose of that option).

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arm/kvm-cpu.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 110 insertions(+), 1 deletion(-)

diff --git a/arm/kvm-cpu.c b/arm/kvm-cpu.c
index 38a071b..80e7b79 100644
--- a/arm/kvm-cpu.c
+++ b/arm/kvm-cpu.c
@@ -1,3 +1,4 @@
+#include <assert.h>
 #include <errno.h>
 #include <stddef.h>
 #include <stdio.h>
@@ -48,6 +49,112 @@ error:
 	return ret;
 }
 
+static int kvm_show_sve_info(struct kvm_cpu const *vcpu)
+{
+	int ret = 0;
+	u64 val;
+	struct kvm_one_reg r;
+	int have_sve;
+	u64 vls[9];
+	unsigned int i;
+
+	r.addr = (u64)&val;
+
+	r.id = ARM64_SYS_REG(3, 0, 0, 4, 0); /* ID_AA64PFR0_EL1 */
+	assert((r.id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U64);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &r)) {
+		perror("KVM_GET_ONE_REG(ID_AA64PFR0_EL1)");
+		goto error;
+	}
+
+	printf("ID_AA64PFR0_EL1:\t0x%lx\n", (unsigned long)val);
+
+	have_sve = !!((val >> 32) & 0xf);
+
+	r.id = ARM64_SYS_REG(3, 0, 0, 4, 4);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &r)) {
+		if (errno != ENOENT || have_sve) {
+			perror("KVM_GET_ONE_REG(ID_AA64ZFR0_EL1)");
+			ret = -1;
+		}
+	} else {
+		if (!have_sve) {
+			puts("ID_AA64ZFR0_EL1 unexpectedly present");
+			ret = -1;
+		}
+
+		printf("ID_AA64ZFR0_EL1:\t0x%lx\n", (unsigned long)val);
+	}
+
+	r.id = ARM64_SYS_REG(3, 0, 1, 2, 0);
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &r)) {
+		if (errno != ENOENT || have_sve) {
+			perror("KVM_GET_ONE_REG(ZCR_EL1)");
+			ret = -1;
+		}
+	} else {
+		if (!have_sve) {
+			puts("ZCR_EL1 unexpectedly present");
+			ret = -1;
+		}
+
+		printf("ZCR_EL1:\t0x%lx\n", (unsigned long)val);
+	}
+
+	r.addr = (u64)&vls;
+	r.id = KVM_REG_ARM64_SVE_VLS;
+	assert(8 * (sizeof(vls) - sizeof(*vls)) == 512 &&
+	       (r.id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U512);
+
+	/*
+	 * Write some canary data so we can see that the kernel writes
+	 * the expected amount:
+	 */
+	for (i = 0; i < sizeof(vls) / sizeof(*vls); ++i)
+		vls[i] = -7;
+
+	if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, &r)) {
+		if (errno != ENOENT || have_sve) {
+			perror("KVM_GET_ONE_REG(KVM_REG_ARM64_SVE_VLS)");
+			ret = -1;
+		}
+	} else {
+		char const *prefix = "";
+
+		if (!have_sve) {
+			puts("KVM_REG_ARM64_SVE_VLS unexpectedly present");
+			ret = -1;
+		}
+
+		if (vls[7] == (u64)-7) {
+			puts("KVM_REG_ARM64_SVE_VLS short read?");
+			ret = -1;
+		}
+
+		if (vls[8] != (u64)-7) {
+			puts("KVM_REG_ARM64_SVE_VLS overrun?");
+			ret = -1;
+		}
+
+		fputs("SVE VQs: ", stdout);
+
+		for (i = 0; i < 512; ++i)
+			if ((vls[i / 64] >> (i % 64)) & 1) {
+				printf("%s%lu", prefix, (unsigned long)i + 1);
+				prefix = ",";
+			}
+
+		putchar('\n');
+	}
+
+	fflush(stdout);
+
+	return ret;
+
+error:
+	return -1;
+}
+
 static int debug_fd;
 
 void kvm_cpu__set_debug_fd(int fd)
@@ -156,8 +263,10 @@ struct kvm_cpu *kvm_cpu__arch_init(struct kvm *kvm, unsigned long cpu_id)
 	if (err || target->init(vcpu))
 		die("Unable to initialise vcpu");
 
-	if (kvm->cfg.arch.show_reg_list)
+	if (kvm->cfg.arch.show_reg_list) {
+		kvm_show_sve_info(vcpu);
 		kvm_show_reg_list(vcpu);
+	}
 
 	coalesced_offset = ioctl(kvm->sys_fd, KVM_CHECK_EXTENSION,
 				 KVM_CAP_COALESCED_MMIO);
-- 
2.1.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-01-18 16:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 16:14 [RFC PATCH 00/12] arm64: SVE guest support test hacks Dave Martin
2019-01-18 16:14 ` [RFC PATCH 01/12] guest: Add generated file guest/guest_init.c to .gitignore Dave Martin
2019-01-18 16:14 ` [RFC PATCH 02/12] update_headers: Sync kvm UAPI headers with linux v5.0-rc2 Dave Martin
2019-01-18 16:14 ` [RFC PATCH 03/12] Makefile: [HACK] Work around GCC 8 warnings :( Dave Martin
2019-01-18 16:14 ` [RFC PATCH 04/12] Makefile: [HACK] Pass relevant flags when checking for libfdt Dave Martin
2019-01-18 16:14 ` [RFC PATCH 05/12] arm64: Correct ARM64_CORE_REG() size encodings for all core registers Dave Martin
2019-01-18 16:14 ` [RFC PATCH 06/12] arm64: [HACK] Pull in kvm UAPI header updates from SVE development branch Dave Martin
2019-01-18 16:14 ` [RFC PATCH 07/12] arm64: [HACK] Add option to show the kernel's KVM register ID list Dave Martin
2019-01-18 16:14 ` [RFC PATCH 08/12] arm64: [HACK] Basic SVE support Dave Martin
2019-01-18 16:14 ` Dave Martin [this message]
2019-01-18 16:14 ` [RFC PATCH 10/12] arm64: [HACK] Allow configuration of the guest's set of SVE vector lengths Dave Martin
2019-01-18 16:14 ` [RFC PATCH 11/12] arm64: [HACK] FPSIMD/SVE register dumping for lkvm debug Dave Martin
2019-01-18 16:14 ` [RFC PATCH 12/12] arm64: [HACK] Check that out-of-range SVE register IDs can't be dumped Dave Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1547828061-20462-10-git-send-email-Dave.Martin@arm.com \
    --to=dave.martin@arm.com \
    --cc=Julien.Grall@arm.com \
    --cc=alex.bennee@linaro.org \
    --cc=andre.przywara@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=cdall@kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=peter.maydell@linaro.org \
    --cc=tokamoto@jp.fujitsu.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).