[RFC PATCH 0/3] Target CPU=Host implementation for KVM ARM/ARM64

[will.deacon@arm.com (Will Deacon)]

On Fri, Sep 06, 2013 at 11:51:07AM +0100, Anup Patel wrote:
> On Fri, Sep 6, 2013 at 4:19 PM, Will Deacon <will.deacon@arm.com> 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 <will.deacon@arm.com> 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