From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 06/11] arm/arm64: vgic: Implement VGICv3 CPU interface access
Date: Tue, 29 Nov 2016 11:51:03 +0100 [thread overview]
Message-ID: <20161129105103.GB15346@cbox> (raw)
In-Reply-To: <CALicx6uK9kQ5fuW=SGnny7oerPbhGbVDw=MMi0Tna_B4XdJqeg@mail.gmail.com>
On Tue, Nov 29, 2016 at 03:31:44PM +0530, Vijay Kilari wrote:
> On Tue, Nov 29, 2016 at 2:07 PM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Tue, Nov 29, 2016 at 01:08:26PM +0530, Vijay Kilari wrote:
> >> On Tue, Nov 29, 2016 at 1:09 AM, Christoffer Dall
> >> <christoffer.dall@linaro.org> wrote:
> >> > On Wed, Nov 23, 2016 at 06:31:53PM +0530, vijay.kilari at gmail.com wrote:
> >> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> >>
> >> >> VGICv3 CPU interface registers are accessed using
> >> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
> >> >> as 64-bit. The cpu MPIDR value is passed along with register id.
> >> >> is used to identify the cpu for registers access.
> >> >>
> >> >> The VM that supports SEIs expect it on destination machine to handle
> >> >> guest aborts and hence checked for ICC_CTLR_EL1.SEIS compatibility.
> >> >> Similarly, VM that supports Affinity Level 3 that is required for AArch64
> >> >> mode, is required to be supported on destination machine. Hence checked
> >> >> for ICC_CTLR_EL1.A3V compatibility.
> >> >>
> >> >> The CPU system register handling is spitted into two files
> >> >
> >> > spitted? Did you mean 'split into' ?
> >> >
> >> >> vgic-sys-reg-common.c and vgic-sys-reg-v3.c.
> >> >> The vgic-sys-reg-common.c handles read and write of VGIC CPU registers
> >> >
> >> > So this is weird because everything in virt/kvm/arm/ is exactly supposed
> >> > to be common between arm and arm64 already.
> >> >
> >> > I would rather that you had a copy of vgic-sys-reg-v3.c in arch/arm/kvm/
> >> > and in arch/arm64/kvm/ each taking care of its own architecture.
> >> >
> >> > But note that I didn't actually require that you implemented support for
> >> > GICv3 migration on AArch32 hosts for these patches, I just didn't want
> >> > thigns to silently break.
> >> >
> >> > If we cannot test the AArch32 implementation, we should potentially just
> >> > make sure that is not supported yet, return a proper error to userspace
> >> > and get the AArch64 host implementation correct.
> >> >
> >> > I suggest you move your:
> >> > virt/kvm/arm/vgic/vgic-sys-reg-v3.c to
> >> > arch/arm64/kvm/vgic-sys-reg-v3.c
> >> >
> >> > and rename
> >> > virt/kvm/arm/vgic/vgic-sys-reg-common.c to
> >> > virt/kvm/arm/vgic/vgic-sys-reg-v3.c
> >> >
> >> > And then wait with the AArch32 host side for now, but just make sure it
> >> > compiles and returns an error as opposed to crashing the system if
> >> > someone tries to excercise this interface on an AArch32 host.
> >>
> >> I will add arch/arm/kvm/vgic-coproc-v3.c (pls check if file name is ok or not?)
> >
> > I would call it vgic-v3-coproc.c
> >
> >> and return -ENXIO as shown below and update document accordingly.
> >>
> >> int vgic_v3_has_cpu_sysregs_attr(struct kvm_vcpu *vcpu, bool is_write, u64 id,
> >> u64 *reg)
> >> {
> >> /*
> >> * TODO: Implement for AArch32
> >> */
> >> return -ENXIO;
> >> }
> >>
> >> int vgic_v3_cpu_sysregs_uaccess(struct kvm_vcpu *vcpu, bool is_write, u64 id,
> >> u64 *reg)
> >> {
> >> /*
> >> * TODO: Implement for AArch32
> >> */
> >> return -ENXIO;
> >> }
> >
> >
> >>
> >> >
> >> >> for both AArch64 and AArch32 mode. The vgic-sys-reg-v3.c handles AArch64
> >> >> mode and is compiled only for AArch64 mode.
> >> >>
> >> >> Updated arch/arm/include/uapi/asm/kvm.h with new definitions
> >> >> required to compile for AArch32.
> >> >>
> >> >> The version of VGIC v3 specification is define here
> >> >> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >> >>
> >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
> >> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> >> ---
> >> [...]
> >> >> +static bool access_gic_aprn(struct kvm_vcpu *vcpu, bool is_write, u8 apr,
> >> >> + u8 idx, unsigned long *reg)
> >> >> +{
> >> >> + struct vgic_cpu *vgic_v3_cpu = &vcpu->arch.vgic_cpu;
> >> >> +
> >> >> + /* num_pri_bits are initialized with HW supported values.
> >> >> + * We can rely safely on num_pri_bits even if VM has not
> >> >> + * restored ICC_CTLR_EL1 before restoring APnR registers.
> >> >> + */
> >> >
> >> > nit: commenting style
> >> ok
> >> >
> >> >> + switch (vgic_v3_cpu->num_pri_bits) {
> >> >> + case 7:
> >> >> + vgic_v3_access_apr_reg(vcpu, is_write, apr, idx, reg);
> >> >> + break;
> >> >> + case 6:
> >> >> + if (idx > 1)
> >> >> + goto err;
> >> >> + vgic_v3_access_apr_reg(vcpu, is_write, apr, idx, reg);
> >> >> + break;
> >> >> + default:
> >> >> + if (idx > 0)
> >> >> + goto err;
> >> >> + vgic_v3_access_apr_reg(vcpu, is_write, apr, idx, reg);
> >> >> + }
> >> >
> >> > It looks to me like userspace can then program active priorities with
> >> > higher numbers than what it will program num_pri_bits to later. Is that
> >> > not weird, or am I missing something?
> >>
> >> As long as it is within HW supported priorities it is safe.
> >
> > I know that it is safe on the hardware, but it is weird to define a VM
> > with some max priority and still be able to set a higher active priority
> > is it not?
>
> In that case, we need to cache the highest active priorities updated
> by a VM in a variable
> when APnR is restored and later check against num_pri_bits when
> ICC_CTLR_EL1 is updated.
> If the value cached is greater than num_pri_bits restored then reject
> ICC_CTLR_EL1 restore.
>
> This variable should be initialized with value 5 ( min priority)
>
> >
> > On the other hand, if we cannot enforce this at runtime, it may not
> > matter?
>
> At VM runtime irrespective of VM's num_pri_bits all the APnR registers that
> HW supports are saved and restored.
>
Yes, never mind my comment. Since we cannot enforce this constraint
once the VM runs, I don't think there's any concern here.
> >> >
> >> >> +
> >> >> + return true;
> >> >> +err:
> >> >> + if (!is_write)
> >> >> + *reg = 0;
> >> >> +
> >> >> + return false;
> >> >> +}
> >> >> +
> >> >> +bool access_gic_ap0r_reg(struct kvm_vcpu *vcpu, bool is_write, u8 idx,
> >> >> + unsigned long *reg)
> >> >> +{
> >> >> + return access_gic_aprn(vcpu, is_write, 0, idx, reg);
> >> >> +}
> >> >> +
> >> >> +bool access_gic_ap1r_reg(struct kvm_vcpu *vcpu, bool is_write, u8 idx,
> >> >> + unsigned long *reg)
> >> >> +{
> >> >> + return access_gic_aprn(vcpu, is_write, 1, idx, reg);
> >> >> +}
> >> >> +
> >> >> +bool access_gic_sre_reg(struct kvm_vcpu *vcpu, bool is_write,
> >> >> + unsigned long *reg)
> >> >> +{
> >> >> + struct vgic_v3_cpu_if *vgicv3 = &vcpu->arch.vgic_cpu.vgic_v3;
> >> >> +
> >> >> + /* Validate SRE bit */
> >> >> + if (is_write) {
> >> >> + if (!(*reg & ICC_SRE_EL1_SRE))
> >> >> + return false;
> >> >> + } else {
> >> >> + *reg = vgicv3->vgic_sre;
> >> >> + }
> >> >> +
> >> >> + return true;
> >> >> +}
> >> >> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
> >> >> new file mode 100644
> >> >> index 0000000..82c2f02
> >> >> --- /dev/null
> >> >> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
> >> >> @@ -0,0 +1,142 @@
> >> >> +/*
> >> >> + * VGIC system registers handling functions
> >> >> + *
> >> >> + * This program is free software; you can redistribute it and/or modify
> >> >> + * it under the terms of the GNU General Public License version 2 as
> >> >> + * published by the Free Software Foundation.
> >> >> + *
> >> >> + * This program is distributed in the hope that it will be useful,
> >> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> >> + * GNU General Public License for more details.
> >> >> + */
> >> >> +
> >> >> +#include <linux/kvm.h>
> >> >> +#include <linux/kvm_host.h>
> >> >> +#include <asm/kvm_emulate.h>
> >> >> +#include "vgic.h"
> >> >> +#include "sys_regs.h"
> >> >> +
> >> >> +#define ACCESS_SYS_REG(REG) \
> >> >> +static bool access_gic_##REG##_sys_reg(struct kvm_vcpu *vcpu, \
> >> >> + struct sys_reg_params *p, \
> >> >> + const struct sys_reg_desc *r) \
> >> >> +{ \
> >> >> + unsigned long tmp; \
> >> >> + bool ret; \
> >> >> + \
> >> >> + if (p->is_write) \
> >> >> + tmp = p->regval; \
> >> >> + ret = access_gic_##REG##_reg(vcpu, p->is_write, &tmp); \
> >> >> + if (!p->is_write) \
> >> >> + p->regval = tmp; \
> >> >> + \
> >> >> + return ret; \
> >> >> +}
> >> >> +
> >> >> +ACCESS_SYS_REG(ctlr)
> >> >> +ACCESS_SYS_REG(pmr)
> >> >> +ACCESS_SYS_REG(bpr0)
> >> >> +ACCESS_SYS_REG(bpr1)
> >> >> +ACCESS_SYS_REG(sre)
> >> >> +ACCESS_SYS_REG(grpen0)
> >> >> +ACCESS_SYS_REG(grpen1)
> >> >> +
> >> >> +#define ACCESS_APNR_SYS_REG(REG) \
> >> >> +static bool access_gic_##REG##_sys_reg(struct kvm_vcpu *vcpu, \
> >> >> + struct sys_reg_params *p, \
> >> >> + const struct sys_reg_desc *r) \
> >> >> +{ \
> >> >> + unsigned long tmp; \
> >> >> + u8 idx = p->Op2 & 3; \
> >> >> + bool ret; \
> >> >> + \
> >> >> + if (p->is_write) \
> >> >> + tmp = p->regval; \
> >> >> + ret = access_gic_##REG##_reg(vcpu, p->is_write, idx, &tmp); \
> >> >> + if (!p->is_write) \
> >> >> + p->regval = tmp; \
> >> >> + \
> >> >> + return ret; \
> >> >> +}
> >> >> +
> >> >> +ACCESS_APNR_SYS_REG(ap0r)
> >> >> +ACCESS_APNR_SYS_REG(ap1r)
> >> >
> >> > I don't get these indirections. Why can't you call the functions
> >> > directly?
> >>
> >> The code is same for accessing the registers hence added this indirection.
> >>
> >
> > That's not answering my question.
> >
> > What is the benefit of adding this indirection as opposed to having the
> > functions called directly?
>
> In sys_reg_desc the access function is of type
>
> bool (*access)(struct kvm_vcpu *,
> struct sys_reg_params *,
> const struct sys_reg_desc *);
>
> Where as the each register access function is of type below to support
> access to AArch32(later if not now).
>
> bool access_gic_xxx(struct kvm_vcpu *vcpu, bool is_write, unsigned long *reg);
>
> I can drop this macro and make function calls for each reg access.
>
Please don't worry about the 32-bit side until we actually implement
that. And once we do, we can move things around in patches to support
the 32-bit side so that it makes sense to the reader.
So, for now, just have this one file, moved to arch/arm64/kvm/ where all
the access functions are static in this file and called directly from
the single dispatch function.
Thanks,
-Christoffer
next prev parent reply other threads:[~2016-11-29 10:51 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-23 13:01 [PATCH v9 0/11] arm/arm64: vgic: Implement API for vGICv3 live migration vijay.kilari at gmail.com
2016-11-23 13:01 ` [PATCH v9 01/11] arm/arm64: vgic: Implement support for userspace access vijay.kilari at gmail.com
2016-11-28 13:05 ` Christoffer Dall
2016-12-06 11:42 ` Auger Eric
2016-12-06 14:30 ` Christoffer Dall
2016-12-15 7:36 ` Vijay Kilari
2016-12-16 12:40 ` Auger Eric
2016-11-23 13:01 ` [PATCH v9 02/11] arm/arm64: vgic: Add distributor and redistributor access vijay.kilari at gmail.com
2016-11-28 13:08 ` Christoffer Dall
2016-12-06 13:18 ` Auger Eric
2016-11-23 13:01 ` [PATCH v9 03/11] arm/arm64: vgic: Introduce find_reg_by_id() vijay.kilari at gmail.com
2016-12-06 13:27 ` Auger Eric
2016-11-23 13:01 ` [PATCH v9 04/11] irqchip/gic-v3: Add missing system register definitions vijay.kilari at gmail.com
2016-12-06 13:53 ` Auger Eric
2017-01-23 10:55 ` Vijay Kilari
2016-11-23 13:01 ` [PATCH v9 05/11] arm/arm64: vgic: Introduce VENG0 and VENG1 fields to vmcr struct vijay.kilari at gmail.com
2016-11-28 14:28 ` Christoffer Dall
2016-12-08 11:52 ` Auger Eric
2016-12-08 12:21 ` Christoffer Dall
2016-12-08 12:50 ` Auger Eric
2016-12-11 16:38 ` Christoffer Dall
2016-11-23 13:01 ` [PATCH v9 06/11] arm/arm64: vgic: Implement VGICv3 CPU interface access vijay.kilari at gmail.com
2016-11-28 19:39 ` Christoffer Dall
2016-11-29 7:38 ` Vijay Kilari
2016-11-29 8:37 ` Christoffer Dall
2016-11-29 10:01 ` Vijay Kilari
2016-11-29 10:51 ` Christoffer Dall [this message]
2016-11-23 13:01 ` [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl vijay.kilari at gmail.com
2016-11-28 19:50 ` Christoffer Dall
2016-11-29 16:36 ` Vijay Kilari
2016-11-29 21:09 ` Christoffer Dall
2016-11-30 7:10 ` Peter Maydell
2016-11-30 8:24 ` Christoffer Dall
2016-11-30 8:29 ` Peter Maydell
2016-11-23 13:01 ` [PATCH v9 08/11] arm/arm64: Documentation: Update arm-vgic-v3.txt vijay.kilari at gmail.com
2016-11-23 13:01 ` [PATCH v9 09/11] arm: coproc: Drop const from coproc reg access function vijay.kilari at gmail.com
2016-11-23 13:01 ` [PATCH v9 10/11] arm: coproc: Introduce find_coproc_reg_by_id() vijay.kilari at gmail.com
2016-11-23 13:01 ` [PATCH v9 11/11] arm: vgic: Save and restore GICv3 CPU interface regs for AArch32 vijay.kilari at gmail.com
2016-11-28 19:51 ` [PATCH v9 0/11] arm/arm64: vgic: Implement API for vGICv3 live migration Christoffer Dall
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=20161129105103.GB15346@cbox \
--to=christoffer.dall@linaro.org \
--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).