linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [kvmarm] [PATCH 09/29] arm64: KVM: system register handling
Date: Fri, 08 Mar 2013 04:29:48 +0100	[thread overview]
Message-ID: <6c8dff0e7f9f9dde4702017737f4c1b7@localhost> (raw)
In-Reply-To: <2CF940F9-4643-4C32-8A71-23DAD18EE9FA@suse.de>

On Thu, 7 Mar 2013 11:30:20 +0100, Alexander Graf <agraf@suse.de> wrote:
> On 05.03.2013, at 04:47, Marc Zyngier wrote:
> 
>> Provide 64bit system register handling, modeled after the cp15
>> handling for ARM.
>> 
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm64/include/asm/kvm_coproc.h |  51 ++
>> arch/arm64/include/uapi/asm/kvm.h   |  56 +++
>> arch/arm64/kvm/sys_regs.c           | 962
>> ++++++++++++++++++++++++++++++++++++
>> arch/arm64/kvm/sys_regs.h           | 141 ++++++
>> include/uapi/linux/kvm.h            |   1 +
>> 5 files changed, 1211 insertions(+)
>> create mode 100644 arch/arm64/include/asm/kvm_coproc.h
>> create mode 100644 arch/arm64/kvm/sys_regs.c
>> create mode 100644 arch/arm64/kvm/sys_regs.h
>> 

[..]

>> +/*
>> + * Architected system registers.
>> + * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
>> + */
>> +static const struct sys_reg_desc sys_reg_descs[] = {
>> +	/* DC ISW */
>> +	{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b0110), Op2(0b010),
>> +	  access_dcsw },
>> +	/* DC CSW */
>> +	{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1010), Op2(0b010),
>> +	  access_dcsw },
>> +	/* DC CISW */
>> +	{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1110), Op2(0b010),
>> +	  access_dcsw },
>> +
>> +	/* TTBR0_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b000),
>> +	  NULL, reset_unknown, TTBR0_EL1 },
>> +	/* TTBR1_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b001),
>> +	  NULL, reset_unknown, TTBR1_EL1 },
>> +	/* TCR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b010),
>> +	  NULL, reset_val, TCR_EL1, 0 },
>> +
>> +	/* AFSR0_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b000),
>> +	  NULL, reset_unknown, AFSR0_EL1 },
>> +	/* AFSR1_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b001),
>> +	  NULL, reset_unknown, AFSR1_EL1 },
>> +	/* ESR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0010), Op2(0b000),
>> +	  NULL, reset_unknown, ESR_EL1 },
>> +	/* FAR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b0110), CRm(0b0000), Op2(0b000),
>> +	  NULL, reset_unknown, FAR_EL1 },
>> +
>> +	/* PMINTENSET_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
>> +	  pm_fake },
>> +	/* PMINTENCLR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
>> +	  pm_fake },
>> +
>> +	/* MAIR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
>> +	  NULL, reset_unknown, MAIR_EL1 },
>> +	/* AMAIR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0011), Op2(0b000),
>> +	  NULL, reset_amair_el1, AMAIR_EL1 },
>> +
>> +	/* VBAR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b1100), CRm(0b0000), Op2(0b000),
>> +	  NULL, reset_val, VBAR_EL1, 0 },
>> +	/* CONTEXTIDR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b001),
>> +	  NULL, reset_val, CONTEXTIDR_EL1, 0 },
>> +	/* TPIDR_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b100),
>> +	  NULL, reset_unknown, TPIDR_EL1 },
>> +
>> +	/* CNTKCTL_EL1 */
>> +	{ Op0(0b11), Op1(0b000), CRn(0b1110), CRm(0b0001), Op2(0b000),
>> +	  NULL, reset_val, CNTKCTL_EL1, 0},
>> +
>> +	/* CSSELR_EL1 */
>> +	{ Op0(0b11), Op1(0b010), CRn(0b0000), CRm(0b0000), Op2(0b000),
>> +	  NULL, reset_unknown, CSSELR_EL1 },
>> +
>> +	/* PMCR_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
>> +	  pm_fake },
>> +	/* PMCNTENSET_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
>> +	  pm_fake },
>> +	/* PMCNTENCLR_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
>> +	  pm_fake },
>> +	/* PMOVSCLR_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
>> +	  pm_fake },
>> +	/* PMSWINC_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
>> +	  pm_fake },
>> +	/* PMSELR_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
>> +	  pm_fake },
>> +	/* PMCEID0_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
>> +	  pm_fake },
>> +	/* PMCEID1_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
>> +	  pm_fake },
>> +	/* PMCCNTR_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
>> +	  pm_fake },
>> +	/* PMXEVTYPER_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
>> +	  pm_fake },
>> +	/* PMXEVCNTR_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
>> +	  pm_fake },
>> +	/* PMUSERENR_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
>> +	  pm_fake },
>> +	/* PMOVSSET_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
>> +	  pm_fake },
>> +
>> +	/* TPIDR_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
>> +	  NULL, reset_unknown, TPIDR_EL0 },
>> +	/* TPIDRRO_EL0 */
>> +	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
>> +	  NULL, reset_unknown, TPIDRRO_EL0 },
>> +};
>> +
>> +/* Target specific emulation tables */
>> +static struct kvm_sys_reg_target_table
>> *target_tables[KVM_ARM_NUM_TARGETS];
>> +
>> +void kvm_register_target_sys_reg_table(struct kvm_sys_reg_target_table
>> *table)
>> +{
>> +	target_tables[table->target] = table;
>> +}
>> +
>> +/* Get specific register table for this target. */
>> +static const struct sys_reg_desc *get_target_table(unsigned target,
>> size_t *num)
>> +{
>> +	struct kvm_sys_reg_target_table *table;
>> +
>> +	table = target_tables[target];
>> +	*num = table->table64.num;
>> +	return table->table64.table;
>> +}
>> +
>> +static const struct sys_reg_desc *find_reg(const struct sys_reg_params
>> *params,
>> +					 const struct sys_reg_desc table[],
>> +					 unsigned int num)
>> +{
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < num; i++) {
>> +		const struct sys_reg_desc *r = &table[i];
>> +
>> +		if (params->Op0 != r->Op0)
>> +			continue;
>> +		if (params->Op1 != r->Op1)
>> +			continue;
>> +		if (params->CRn != r->CRn)
>> +			continue;
>> +		if (params->CRm != r->CRm)
>> +			continue;
>> +		if (params->Op2 != r->Op2)
>> +			continue;
>> +
>> +		return r;
>> +	}
>> +	return NULL;
>> +}
>> +
>> +static int emulate_sys_reg(struct kvm_vcpu *vcpu,
>> +			   const struct sys_reg_params *params)
>> +{
>> +	size_t num;
>> +	const struct sys_reg_desc *table, *r;
>> +
>> +	table = get_target_table(vcpu->arch.target, &num);
>> +
>> +	/* Search target-specific then generic table. */
>> +	r = find_reg(params, table, num);
>> +	if (!r)
>> +		r = find_reg(params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
> 
> Searching through the whole list sounds quite slow. Especially since the
> TLS register is at the very bottom of it.

Slow, yes. Though not as bad as it sounds as only the first entries are
used on a trap path at the moment. For all the other entries, this is only
used when userspace tries to read/write a VM system register.

But overall I agree, this is not very efficient.

> Can't you make this a simple switch() statement through a bit of #define
> and maybe #include magic? After all, the sysreg target encoding is all
part
> of the opcode. And from my experience in the PPC instruction emulator,
> switch()es are _a lot_ faster than any other way of lookup I've tried.

There is definitely something like this to be done, and for the 32bit part
as well.

I'll have a look.

Thanks,

        M.
-- 
Fast, cheap, reliable. Pick two.

  reply	other threads:[~2013-03-08  3:29 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05  3:47 [PATCH 00/29] Port of KVM to arm64 Marc Zyngier
2013-03-05  3:47 ` [PATCH 01/29] arm64: KVM: define HYP and Stage-2 translation page flags Marc Zyngier
2013-03-05  3:47 ` [PATCH 02/29] arm64: KVM: HYP mode idmap support Marc Zyngier
2013-03-05  3:47 ` [PATCH 03/29] arm64: KVM: EL2 register definitions Marc Zyngier
2013-03-05  3:47 ` [PATCH 04/29] arm64: KVM: system register definitions for 64bit guests Marc Zyngier
2013-03-07 10:33   ` [kvmarm] " Alexander Graf
2013-03-08  3:23     ` Marc Zyngier
2013-03-12 13:20   ` Christopher Covington
2013-03-12 13:41     ` Christopher Covington
2013-03-12 13:50     ` Marc Zyngier
2013-03-05  3:47 ` [PATCH 05/29] arm64: KVM: Basic ESR_EL2 helpers and vcpu register access Marc Zyngier
2013-03-16  0:55   ` Geoff Levand
2013-03-05  3:47 ` [PATCH 06/29] arm64: KVM: fault injection into a guest Marc Zyngier
2013-03-12 13:20   ` Christopher Covington
2013-03-12 14:25     ` Marc Zyngier
2013-03-16  1:03   ` Geoff Levand
2013-03-05  3:47 ` [PATCH 07/29] arm64: KVM: architecture specific MMU backend Marc Zyngier
2013-03-05  3:47 ` [PATCH 08/29] arm64: KVM: user space interface Marc Zyngier
2013-03-07  8:09   ` Michael S. Tsirkin
2013-03-08  3:46     ` [kvmarm] " Marc Zyngier
2013-03-10  9:23       ` Michael S. Tsirkin
2013-03-05  3:47 ` [PATCH 09/29] arm64: KVM: system register handling Marc Zyngier
2013-03-07 10:30   ` [kvmarm] " Alexander Graf
2013-03-08  3:29     ` Marc Zyngier [this message]
2013-03-25  8:19     ` Marc Zyngier
2013-04-23 23:07       ` Christoffer Dall
2013-03-05  3:47 ` [PATCH 10/29] arm64: KVM: Cortex-A57 specific system registers handling Marc Zyngier
2013-03-13 18:30   ` Christopher Covington
2013-03-14 10:26     ` Marc Zyngier
2013-03-05  3:47 ` [PATCH 11/29] arm64: KVM: virtual CPU reset Marc Zyngier
2013-03-05  3:47 ` [PATCH 12/29] arm64: KVM: kvm_arch and kvm_vcpu_arch definitions Marc Zyngier
2013-03-12 17:30   ` Christopher Covington
2013-03-05  3:47 ` [PATCH 13/29] arm64: KVM: MMIO access backend Marc Zyngier
2013-03-05  3:47 ` [PATCH 14/29] arm64: KVM: guest one-reg interface Marc Zyngier
2013-03-12 17:31   ` Christopher Covington
2013-03-12 18:05     ` Marc Zyngier
2013-03-12 22:07       ` Christopher Covington
2013-03-13  7:48         ` Marc Zyngier
2013-03-13 20:34           ` Christopher Covington
2013-03-14  8:57             ` [kvmarm] " Peter Maydell
2013-03-20 20:06               ` Christopher Covington
2013-03-05  3:47 ` [PATCH 15/29] arm64: KVM: hypervisor initialization code Marc Zyngier
2013-03-05  3:47 ` [PATCH 16/29] arm64: KVM: HYP mode world switch implementation Marc Zyngier
2013-03-13 19:59   ` Christopher Covington
2013-03-20 20:04     ` Christopher Covington
2013-03-21 11:54       ` Marc Zyngier
2013-03-05  3:47 ` [PATCH 17/29] arm64: KVM: Exit handling Marc Zyngier
2013-03-05  3:47 ` [PATCH 18/29] arm64: KVM: Plug the VGIC Marc Zyngier
2013-03-05  3:47 ` [PATCH 19/29] arm64: KVM: Plug the arch timer Marc Zyngier
2013-03-05  3:47 ` [PATCH 20/29] arm64: KVM: PSCI implementation Marc Zyngier
2013-03-05  3:47 ` [PATCH 21/29] arm64: KVM: Build system integration Marc Zyngier
2013-03-05  3:47 ` [PATCH 22/29] arm64: KVM: define 32bit specific registers Marc Zyngier
2013-03-18 17:03   ` Christopher Covington
2013-03-05  3:47 ` [PATCH 23/29] arm64: KVM: 32bit GP register access Marc Zyngier
2013-03-16  0:24   ` Geoff Levand
2013-03-05  3:47 ` [PATCH 24/29] arm64: KVM: 32bit conditional execution emulation Marc Zyngier
2013-03-18 17:04   ` Christopher Covington
2013-03-05  3:47 ` [PATCH 25/29] arm64: KVM: 32bit handling of coprocessor traps Marc Zyngier
2013-03-05  3:47 ` [PATCH 26/29] arm64: KVM: 32bit coprocessor access for Cortex-A57 Marc Zyngier
2013-03-05  3:47 ` [PATCH 27/29] arm64: KVM: 32bit specific register world switch Marc Zyngier
2013-03-05  3:47 ` [PATCH 28/29] arm64: KVM: 32bit guest fault injection Marc Zyngier
2013-03-18 18:45   ` Christopher Covington
2013-03-05  3:47 ` [PATCH 29/29] arm64: KVM: enable initialization of a 32bit vcpu Marc Zyngier
2013-03-18 18:56   ` Christopher Covington

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=6c8dff0e7f9f9dde4702017737f4c1b7@localhost \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).