From: Christoffer Dall <cdall@linaro.org>
To: Andrew Jones <drjones@redhat.com>
Cc: marc.zyngier@arm.com, qemu-arm@nongnu.org, wu.wubin@huawei.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH RFC 6/7] ARM64: KVM: Support heterogeneous system
Date: Wed, 15 Mar 2017 14:36:45 +0100 [thread overview]
Message-ID: <20170315133645.GQ1277@cbox> (raw)
In-Reply-To: <20170315125113.erfl2gk6fwmbccsn@kamzik.brq.redhat.com>
On Wed, Mar 15, 2017 at 01:51:13PM +0100, Andrew Jones wrote:
> On Wed, Mar 15, 2017 at 12:50:44PM +0100, Christoffer Dall wrote:
> > Hi Drew,
> >
> > [Replying here to try to capture the discussion about this patch we had
> > at connect].
> >
> > On Sat, Jan 28, 2017 at 03:55:51PM +0100, Andrew Jones wrote:
> > > On Mon, Jan 16, 2017 at 05:33:33PM +0800, Shannon Zhao wrote:
> > > > From: Shannon Zhao <shannon.zhao@linaro.org>
> > > >
> > > > When initializing KVM, check whether physical hardware is a
> > > > heterogeneous system through the MIDR values. If so, force userspace to
> > > > set the KVM_ARM_VCPU_CROSS feature bit. Otherwise, it should fail to
> > > > initialize VCPUs.
> > > >
> > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > > > ---
> > > > arch/arm/kvm/arm.c | 26 ++++++++++++++++++++++++++
> > > > include/uapi/linux/kvm.h | 1 +
> > > > 2 files changed, 27 insertions(+)
> > > >
> > > > diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> > > > index bdceb19..21ec070 100644
> > > > --- a/arch/arm/kvm/arm.c
> > > > +++ b/arch/arm/kvm/arm.c
> > > > @@ -46,6 +46,7 @@
> > > > #include <asm/kvm_coproc.h>
> > > > #include <asm/kvm_psci.h>
> > > > #include <asm/sections.h>
> > > > +#include <asm/cputype.h>
> > > >
> > > > #ifdef REQUIRES_VIRT
> > > > __asm__(".arch_extension virt");
> > > > @@ -65,6 +66,7 @@ static unsigned int kvm_vmid_bits __read_mostly;
> > > > static DEFINE_SPINLOCK(kvm_vmid_lock);
> > > >
> > > > static bool vgic_present;
> > > > +static bool heterogeneous_system;
> > > >
> > > > static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
> > > >
> > > > @@ -210,6 +212,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > > case KVM_CAP_ARM_CROSS_VCPU:
> > > > r = 1;
> > > > break;
> > > > + case KVM_CAP_ARM_HETEROGENEOUS:
> > > > + r = heterogeneous_system;
> > > > + break;
> > >
> > > What's this for? When/why would usespace check it?
> > >
> >
> > Without a capability, how can userspace tell the difference between "I
> > got -EINVAL because I'm on an old kernel" or "I asked for something that
> > any kernel cannot emulate"?
> >
> > Do we need to distinguish between these cases?
>
> Yup, I'm in full agreement that we need a capability for the
> cross-vcpu support. Above this heterogeneous one there's the
> CROSS_VCPU one though. Do we need both?
Probably not.
> If QEMU wants to know
> whether or not the host it's running on is heterogeneous, then
> it can just query sysfs, rather than ask KVM.
>
Can it? Is this information available in a reliable way from userspace?
> >
> > > > case KVM_CAP_COALESCED_MMIO:
> > > > r = KVM_COALESCED_MMIO_PAGE_OFFSET;
> > > > break;
> > > > @@ -812,6 +817,12 @@ static int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
> > > > int phys_target = kvm_target_cpu();
> > > > bool cross_vcpu = kvm_vcpu_has_feature_cross_cpu(init);
> > > >
> > > > + if (heterogeneous_system && !cross_vcpu) {
> > > > + kvm_err("%s:Host is a heterogeneous system, set KVM_ARM_VCPU_CROSS bit\n",
> > > > + __func__);
> > > > + return -EINVAL;
> > > > + }
> > >
> > > Instead of forcing userspace to set a bit, why not just confirm the
> > > target selected will work? E.g. if only generic works on a heterogeneous
> > > system then just
> > >
> > > if (heterogeneous_system && init->target != GENERIC)
> > > return -EINVAL
> > >
> > > should work
> > >
> >
> > Yes, I think we concluded that if we advertise if we can do the
> > cross type emulation or not, then if we can do the emulation we should
> > just do it when possible, for maximum user experience.
>
> Your agreement here implies to me that we only need the one capability.
>
Yes.
> >
> > I'm sure I missed some aspect of this discussion though.
>
> Me too. As we discussed, it's probably time to try and hash out a fresh
> design doc. It'd be good to get a clear design agreed upon before
> returning to the patches.
>
Yes, it's on my list.
Thanks,
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: Christoffer Dall <cdall@linaro.org>
To: Andrew Jones <drjones@redhat.com>
Cc: marc.zyngier@arm.com, qemu-arm@nongnu.org, wu.wubin@huawei.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH RFC 6/7] ARM64: KVM: Support heterogeneous system
Date: Wed, 15 Mar 2017 14:36:45 +0100 [thread overview]
Message-ID: <20170315133645.GQ1277@cbox> (raw)
In-Reply-To: <20170315125113.erfl2gk6fwmbccsn@kamzik.brq.redhat.com>
On Wed, Mar 15, 2017 at 01:51:13PM +0100, Andrew Jones wrote:
> On Wed, Mar 15, 2017 at 12:50:44PM +0100, Christoffer Dall wrote:
> > Hi Drew,
> >
> > [Replying here to try to capture the discussion about this patch we had
> > at connect].
> >
> > On Sat, Jan 28, 2017 at 03:55:51PM +0100, Andrew Jones wrote:
> > > On Mon, Jan 16, 2017 at 05:33:33PM +0800, Shannon Zhao wrote:
> > > > From: Shannon Zhao <shannon.zhao@linaro.org>
> > > >
> > > > When initializing KVM, check whether physical hardware is a
> > > > heterogeneous system through the MIDR values. If so, force userspace to
> > > > set the KVM_ARM_VCPU_CROSS feature bit. Otherwise, it should fail to
> > > > initialize VCPUs.
> > > >
> > > > Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
> > > > ---
> > > > arch/arm/kvm/arm.c | 26 ++++++++++++++++++++++++++
> > > > include/uapi/linux/kvm.h | 1 +
> > > > 2 files changed, 27 insertions(+)
> > > >
> > > > diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> > > > index bdceb19..21ec070 100644
> > > > --- a/arch/arm/kvm/arm.c
> > > > +++ b/arch/arm/kvm/arm.c
> > > > @@ -46,6 +46,7 @@
> > > > #include <asm/kvm_coproc.h>
> > > > #include <asm/kvm_psci.h>
> > > > #include <asm/sections.h>
> > > > +#include <asm/cputype.h>
> > > >
> > > > #ifdef REQUIRES_VIRT
> > > > __asm__(".arch_extension virt");
> > > > @@ -65,6 +66,7 @@ static unsigned int kvm_vmid_bits __read_mostly;
> > > > static DEFINE_SPINLOCK(kvm_vmid_lock);
> > > >
> > > > static bool vgic_present;
> > > > +static bool heterogeneous_system;
> > > >
> > > > static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
> > > >
> > > > @@ -210,6 +212,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > > case KVM_CAP_ARM_CROSS_VCPU:
> > > > r = 1;
> > > > break;
> > > > + case KVM_CAP_ARM_HETEROGENEOUS:
> > > > + r = heterogeneous_system;
> > > > + break;
> > >
> > > What's this for? When/why would usespace check it?
> > >
> >
> > Without a capability, how can userspace tell the difference between "I
> > got -EINVAL because I'm on an old kernel" or "I asked for something that
> > any kernel cannot emulate"?
> >
> > Do we need to distinguish between these cases?
>
> Yup, I'm in full agreement that we need a capability for the
> cross-vcpu support. Above this heterogeneous one there's the
> CROSS_VCPU one though. Do we need both?
Probably not.
> If QEMU wants to know
> whether or not the host it's running on is heterogeneous, then
> it can just query sysfs, rather than ask KVM.
>
Can it? Is this information available in a reliable way from userspace?
> >
> > > > case KVM_CAP_COALESCED_MMIO:
> > > > r = KVM_COALESCED_MMIO_PAGE_OFFSET;
> > > > break;
> > > > @@ -812,6 +817,12 @@ static int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
> > > > int phys_target = kvm_target_cpu();
> > > > bool cross_vcpu = kvm_vcpu_has_feature_cross_cpu(init);
> > > >
> > > > + if (heterogeneous_system && !cross_vcpu) {
> > > > + kvm_err("%s:Host is a heterogeneous system, set KVM_ARM_VCPU_CROSS bit\n",
> > > > + __func__);
> > > > + return -EINVAL;
> > > > + }
> > >
> > > Instead of forcing userspace to set a bit, why not just confirm the
> > > target selected will work? E.g. if only generic works on a heterogeneous
> > > system then just
> > >
> > > if (heterogeneous_system && init->target != GENERIC)
> > > return -EINVAL
> > >
> > > should work
> > >
> >
> > Yes, I think we concluded that if we advertise if we can do the
> > cross type emulation or not, then if we can do the emulation we should
> > just do it when possible, for maximum user experience.
>
> Your agreement here implies to me that we only need the one capability.
>
Yes.
> >
> > I'm sure I missed some aspect of this discussion though.
>
> Me too. As we discussed, it's probably time to try and hash out a fresh
> design doc. It'd be good to get a clear design agreed upon before
> returning to the patches.
>
Yes, it's on my list.
Thanks,
-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2017-03-15 13:35 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 9:33 [PATCH RFC 0/7] ARM64: KVM: Cross type vCPU support Shannon Zhao
2017-01-16 9:33 ` Shannon Zhao
2017-01-16 9:33 ` [PATCH RFC 1/7] ARM64: KVM: Add the definition of ID registers Shannon Zhao
2017-01-16 9:33 ` Shannon Zhao
2017-01-28 12:07 ` Andrew Jones
2017-01-28 12:07 ` Andrew Jones
2017-01-16 9:33 ` [PATCH RFC 2/7] ARM64: KVM: Add reset handlers for all " Shannon Zhao
2017-01-16 9:33 ` Shannon Zhao
2017-01-28 12:36 ` Andrew Jones
2017-01-28 12:36 ` Andrew Jones
2017-03-09 10:19 ` Christoffer Dall
2017-03-09 10:19 ` Christoffer Dall
2017-01-16 9:33 ` [PATCH RFC 3/7] ARM64: KVM: Reset ID registers when creating the VCPUs Shannon Zhao
2017-01-16 9:33 ` Shannon Zhao
2017-01-28 13:32 ` Andrew Jones
2017-01-28 13:32 ` Andrew Jones
2017-01-16 9:33 ` [PATCH RFC 4/7] ARM64: KVM: emulate accessing ID registers Shannon Zhao
2017-01-16 9:33 ` Shannon Zhao
2017-01-28 13:49 ` Andrew Jones
2017-01-28 13:49 ` [Qemu-arm] " Andrew Jones
2017-03-09 10:28 ` Christoffer Dall
2017-03-09 10:28 ` Christoffer Dall
2017-01-16 9:33 ` [PATCH RFC 5/7] ARM64: KVM: Support cross type vCPU Shannon Zhao
2017-01-16 9:33 ` Shannon Zhao
2017-01-28 14:47 ` Andrew Jones
2017-01-28 14:47 ` Andrew Jones
2017-03-09 10:56 ` Christoffer Dall
2017-03-09 10:56 ` Christoffer Dall
2017-01-16 9:33 ` [PATCH RFC 6/7] ARM64: KVM: Support heterogeneous system Shannon Zhao
2017-01-16 9:33 ` Shannon Zhao
2017-01-28 14:55 ` Andrew Jones
2017-01-28 14:55 ` Andrew Jones
2017-03-09 15:21 ` Suzuki K Poulose
2017-03-09 15:21 ` Suzuki K Poulose
2017-03-15 11:50 ` Christoffer Dall
2017-03-15 11:50 ` Christoffer Dall
2017-03-15 12:51 ` Andrew Jones
2017-03-15 12:51 ` Andrew Jones
2017-03-15 13:36 ` Christoffer Dall [this message]
2017-03-15 13:36 ` Christoffer Dall
2017-03-15 14:06 ` Andrew Jones
2017-03-15 14:06 ` Andrew Jones
2017-03-15 14:21 ` Peter Maydell
2017-03-15 14:21 ` [Qemu-arm] " Peter Maydell
2017-03-15 14:42 ` Andrew Jones
2017-03-15 14:42 ` Andrew Jones
2017-03-15 14:49 ` Mark Rutland
2017-03-15 14:49 ` Mark Rutland
2017-03-15 15:22 ` Christoffer Dall
2017-03-15 15:22 ` Christoffer Dall
2017-03-15 15:32 ` Andrew Jones
2017-03-15 15:32 ` Andrew Jones
2017-01-16 9:33 ` [PATCH RFC 7/7] ARM64: KVM: Add user set handler for id_aa64mmfr0_el1 Shannon Zhao
2017-01-16 9:33 ` Shannon Zhao
2017-01-28 15:22 ` Andrew Jones
2017-01-28 15:22 ` Andrew Jones
2017-03-09 12:52 ` Christoffer Dall
2017-03-09 12:52 ` Christoffer Dall
2017-03-09 15:03 ` Mark Rutland
2017-03-09 15:03 ` Mark Rutland
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=20170315133645.GQ1277@cbox \
--to=cdall@linaro.org \
--cc=drjones@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=marc.zyngier@arm.com \
--cc=qemu-arm@nongnu.org \
--cc=wu.wubin@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.