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:37 UTC|newest]
Thread overview: 30+ 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 ` [PATCH RFC 1/7] ARM64: KVM: Add the definition of ID registers Shannon Zhao
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-28 12:36 ` Andrew Jones
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-28 13:32 ` Andrew Jones
2017-01-16 9:33 ` [PATCH RFC 4/7] ARM64: KVM: emulate accessing ID registers Shannon Zhao
2017-01-28 13:49 ` [Qemu-arm] " Andrew Jones
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-28 14:47 ` Andrew Jones
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-28 14:55 ` Andrew Jones
2017-03-09 15:21 ` Suzuki K Poulose
2017-03-15 11:50 ` Christoffer Dall
2017-03-15 12:51 ` Andrew Jones
2017-03-15 13:36 ` Christoffer Dall [this message]
2017-03-15 14:06 ` Andrew Jones
2017-03-15 14:21 ` [Qemu-arm] " Peter Maydell
2017-03-15 14:42 ` Andrew Jones
2017-03-15 14:49 ` Mark Rutland
2017-03-15 15:22 ` Christoffer Dall
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-28 15:22 ` Andrew Jones
2017-03-09 12:52 ` Christoffer Dall
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 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).