From: Christoffer Dall <cdall@linaro.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org,
Marc Zyngier <marc.zyngier@arm.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v2 07/11] KVM: arm/arm64: Register iodevs when setting redist base and creating VCPUs
Date: Tue, 16 May 2017 22:31:46 +0200 [thread overview]
Message-ID: <20170516203146.GA24893@cbox> (raw)
In-Reply-To: <c6d828a8-e763-bdec-09fa-22d94a717acb@redhat.com>
On Tue, May 16, 2017 at 02:39:18PM +0200, Auger Eric wrote:
> Hi Jean, Christoffer,
>
> On 16/05/2017 13:23, Jean-Philippe Brucker wrote:
> > Hi,
> >
> > On 09/05/17 09:56, Christoffer Dall wrote:
> >> Instead of waiting with registering KVM iodevs until the first VCPU is
> >> run, we can actually create the iodevs when the redist base address is
> >> set. The only downside is that we must now also check if we need to do
> >> this for VCPUs which are created after creating the VGIC, because there
> >> is no enforced ordering between creating the VGIC (and setting its base
> >> addresses) and creating the VCPUs.
> >
> > This triggers a BUG(), when the order is VGIC init, then VCPU init (which
> > is what kvmtool does).
> >
> > Issuing KVM_CREATE_VCPU after VGIC intialization produces the following calls:
> >
> > kvm_vm_ioctl_create_vcpu
> > kvm_arch_vcpu_create
> > kvm_vcpu_init
> > kvm_arch_vcpu_init
> > kvm_vgic_vcpu_init
> > vgic_register_redist_iodev
> > kvm_vcpu_get_idx
> > ... no VCPU registered yet in kvm->vcpus :(
> > BUG();
>
> in QEMU use case, kvm_vgic_vcpu_init/vgic_register_redist_iodev does
> nothing since KVM_VGIC_V3_ADDR_TYPE_REDIST was not called yet and
> vgic->vgic_redist_base is undefined. Thus we postpone the redist_iodev
> registration until the redist base address is set.
>
> In QEMU case KVM_VGIC_V3_ADDR_TYPE_REDIST is called when all the CPUs
> are initialized and we were lucky.
> >
> > ... would later register vcpu:
> > kvm->vcpus[atomic_read(&kvm->online_vcpus)] = vcpu
> >
> > My quick fix is to move kvm_vgic_vcpu_init into kvm_arch_vcpu_postcreate,
> > but it discards the return value of kvm_vgic_vcpu_init, so I don't know
> > how to do it properly.
>
> changing the proto of kvm_arch_vcpu_postcreate and moving the
> kvm_vgic_vcpu_init there could be an alternative.
I think the whole point of postcreate is a hook that can be called where
it doesn't produce an error (rolling back the create at that point is
pretty horrid).
I'll have a closer look in the morning at what we can do - perhaps the
idx thing is just a ridiculous requirement and we can do something more
clever.
Thanks for the heads up, and sorry about breaking stuff.
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: cdall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 07/11] KVM: arm/arm64: Register iodevs when setting redist base and creating VCPUs
Date: Tue, 16 May 2017 22:31:46 +0200 [thread overview]
Message-ID: <20170516203146.GA24893@cbox> (raw)
In-Reply-To: <c6d828a8-e763-bdec-09fa-22d94a717acb@redhat.com>
On Tue, May 16, 2017 at 02:39:18PM +0200, Auger Eric wrote:
> Hi Jean, Christoffer,
>
> On 16/05/2017 13:23, Jean-Philippe Brucker wrote:
> > Hi,
> >
> > On 09/05/17 09:56, Christoffer Dall wrote:
> >> Instead of waiting with registering KVM iodevs until the first VCPU is
> >> run, we can actually create the iodevs when the redist base address is
> >> set. The only downside is that we must now also check if we need to do
> >> this for VCPUs which are created after creating the VGIC, because there
> >> is no enforced ordering between creating the VGIC (and setting its base
> >> addresses) and creating the VCPUs.
> >
> > This triggers a BUG(), when the order is VGIC init, then VCPU init (which
> > is what kvmtool does).
> >
> > Issuing KVM_CREATE_VCPU after VGIC intialization produces the following calls:
> >
> > kvm_vm_ioctl_create_vcpu
> > kvm_arch_vcpu_create
> > kvm_vcpu_init
> > kvm_arch_vcpu_init
> > kvm_vgic_vcpu_init
> > vgic_register_redist_iodev
> > kvm_vcpu_get_idx
> > ... no VCPU registered yet in kvm->vcpus :(
> > BUG();
>
> in QEMU use case, kvm_vgic_vcpu_init/vgic_register_redist_iodev does
> nothing since KVM_VGIC_V3_ADDR_TYPE_REDIST was not called yet and
> vgic->vgic_redist_base is undefined. Thus we postpone the redist_iodev
> registration until the redist base address is set.
>
> In QEMU case KVM_VGIC_V3_ADDR_TYPE_REDIST is called when all the CPUs
> are initialized and we were lucky.
> >
> > ... would later register vcpu:
> > kvm->vcpus[atomic_read(&kvm->online_vcpus)] = vcpu
> >
> > My quick fix is to move kvm_vgic_vcpu_init into kvm_arch_vcpu_postcreate,
> > but it discards the return value of kvm_vgic_vcpu_init, so I don't know
> > how to do it properly.
>
> changing the proto of kvm_arch_vcpu_postcreate and moving the
> kvm_vgic_vcpu_init there could be an alternative.
I think the whole point of postcreate is a hook that can be called where
it doesn't produce an error (rolling back the create at that point is
pretty horrid).
I'll have a closer look in the morning at what we can do - perhaps the
idx thing is just a ridiculous requirement and we can do something more
clever.
Thanks for the heads up, and sorry about breaking stuff.
-Christoffer
next prev parent reply other threads:[~2017-05-16 20:31 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 8:56 [PATCH v2 00/11] Fixes to v7 of the vITS save/restore series Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 8:56 ` [PATCH v2 01/11] KVM: arm/arm64: Clarification and relaxation to ITS save/restore ABI Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 8:56 ` [PATCH v2 02/11] KVM: arm/arm64: vgic: Rename kvm_vgic_vcpu_init to kvm_vgic_vcpu_enable Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 8:56 ` [PATCH v2 03/11] KVM: Add kvm_vcpu_get_idx to get vcpu index in kvm->vcpus Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 9:44 ` Auger Eric
2017-05-09 9:44 ` Auger Eric
2017-05-09 8:56 ` [PATCH v2 04/11] KVM: arm/arm64: Refactor vgic_register_redist_iodevs Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 9:44 ` Auger Eric
2017-05-09 9:44 ` Auger Eric
2017-05-09 8:56 ` [PATCH v2 05/11] KVM: arm/arm64: Make vgic_v3_check_base more broadly usable Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 9:45 ` Auger Eric
2017-05-09 9:45 ` Auger Eric
2017-05-09 8:56 ` [PATCH v2 06/11] KVM: arm/arm64: Slightly rework kvm_vgic_addr Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 8:56 ` [PATCH v2 07/11] KVM: arm/arm64: Register iodevs when setting redist base and creating VCPUs Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-16 11:23 ` Jean-Philippe Brucker
2017-05-16 11:23 ` Jean-Philippe Brucker
2017-05-16 12:39 ` Auger Eric
2017-05-16 12:39 ` Auger Eric
2017-05-16 20:31 ` Christoffer Dall [this message]
2017-05-16 20:31 ` Christoffer Dall
2017-05-17 11:18 ` Christoffer Dall
2017-05-17 11:18 ` Christoffer Dall
2017-05-17 12:28 ` Jean-Philippe Brucker
2017-05-17 12:28 ` Jean-Philippe Brucker
2017-05-17 13:19 ` Auger Eric
2017-05-17 13:19 ` Auger Eric
2017-05-09 8:56 ` [PATCH v2 08/11] KVM: arm/arm64: Get rid of its->initialized field Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 9:45 ` Auger Eric
2017-05-09 9:45 ` Auger Eric
2017-05-09 8:56 ` [PATCH v2 09/11] KVM: arm/arm64: Register ITS iodev when setting base address Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 9:53 ` Auger Eric
2017-05-09 9:53 ` Auger Eric
2017-05-09 8:56 ` [PATCH v2 10/11] KVM: arm/arm64: Don't call map_resources when restoring ITS tables Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 8:56 ` [PATCH v2 11/11] KVM: arm/arm64: vgic-its: Cleanup after failed ITT restore Christoffer Dall
2017-05-09 8:56 ` Christoffer Dall
2017-05-09 9:54 ` [PATCH v2 00/11] Fixes to v7 of the vITS save/restore series Auger Eric
2017-05-09 9:54 ` Auger Eric
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=20170516203146.GA24893@cbox \
--to=cdall@linaro.org \
--cc=eric.auger@redhat.com \
--cc=jean-philippe.brucker@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@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 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.