From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Fri, 6 Sep 2013 11:52:40 +0100 Subject: [RFC PATCH 0/3] Target CPU=Host implementation for KVM ARM/ARM64 In-Reply-To: References: <1378392362-6773-1-git-send-email-anup.patel@linaro.org> <20130906090623.GA30450@mudshark.cambridge.arm.com> <20130906104931.GC30450@mudshark.cambridge.arm.com> Message-ID: <20130906105240.GD30450@mudshark.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Sep 06, 2013 at 11:51:07AM +0100, Anup Patel wrote: > On Fri, Sep 6, 2013 at 4:19 PM, Will Deacon wrote: > > On Fri, Sep 06, 2013 at 11:09:09AM +0100, Anup Patel wrote: > >> On Fri, Sep 6, 2013 at 2:36 PM, Will Deacon wrote: > >> > On Fri, Sep 06, 2013 at 09:54:23AM +0100, Alexander Graf wrote: > >> >> On 06.09.2013, at 09:44, Anup Patel wrote: > >> >> > it hard to come up with a use case where having a separate ioctl for > >> >> > "get best CPU for this host" would be better for user space. > >> >> > >> >> It can store it and migrate it as part of its migration protocol (probably hard for QEMU's current work flow, but that's QEMU's issue). > >> > > >> > It's also better from the point of view of devicetree generation. For > >> > example, kvmtool needs to generate the correct architected timer interrupt > >> > numbers for the target CPU, so munging this into KVM_ARM_VCPU_INIT means we > >> > have to go off and figure out the host CPU separately anyway. > >> > >> Please look at the patch carefully we are returning VCPU > >> target type back to user space so, you can generate correct > >> architected timer interrupt numbers for the target CPU. > > > > I did look at the patch, but I also looked at the overriding consensus in > > the feedback saying that you can't change the direction of the ioctl, so > > that would require what I said above. > > > > Will > > Instead of arguing more, I'll save everyone's time and revise this > patch as needed by everyone. Cheers :) Will