Re: [Qemu-devel] [Qemu-ppc] [RFC] QEMU/KVM PowerPC: virtio and guest endianness

[Greg Kurz <gkurz@linux.vnet.ibm.com>]

On Fri, 4 Oct 2013 13:43:38 +0200
Alexander Graf <agraf@suse.de> wrote:

> CC'ing qemu-devel - please use qemu-ppc@ only as a tag, every mail
> needs to go to qemu-devel as well.
> 

Sure I will.

> On 03.10.2013, at 16:29, Greg Kurz wrote:
> [...]
> > I have searched for an appropriate place to add the polling and I
> > must admit I did not find any... I am no QEMU expert but I suspect
> > we would need some kind of arch specific hook to be called from the
> > virtio code to do this... :-\ I hope I am wrong, please correct me
> > if so.
> 
> Just put it into the normal register sync function and call
> cpu_synchronize_state() on virtio reset.
> 

Thanks, I will look into that.

> 
> We have to decide which scheme to follow. There are 2 way we can /
> should handle registers usually:
> 
>   a) owned by QEMU
>   b) owned by KVM
> 
> If they're owned by QEMU, every hypercall needs to go into QEMU which
> then propagates that change through an ioctl back into KVM. If
> they're owned by KVM, QEMU needs to fetch them whenever it needs to
> 
> As a general rule of thumb path b is easier to hack up, path a is
> easier to maintain long term. Which is pretty much what you're seeing
> here.
> 

Agreed.

> > I have a better feeling for (2) because:
> > - 2-liner patch in KVM
> > - no extra code change in QEMU
> > - already *partially* tested
> 
> I don't understand. QEMU would get triggered, then have to propagate
> things back into KVM. We definitely do _not_ want KVM to do magic,
> then tell QEMU to handle a hypercall again.
> 

My idea was to have KVM and QEMU be like *co-owners* of the LPCR
register... now I admit it was a bad idea ! :)

> > Also, I understood Rusty is working on the next virtio specification
> > which should address the endian issue: probably not worth to add too
> > many temporary lines in the QEMU code...
> 
> Does 3.13 support LE mode? Does 3.13 support the new and shiny virtio
> spec? There's a good chance we'd have to deal with guest kernels that
> can do LE, but not sane virtio.
> 

I don't know any details about 3.13 but I guess you are right, it is
unlikely the guests will have it.

> > Of course, I probably lack some essential knowledge that would be
> > more favorable to (1)... so please comment and argue ! :)
> 
> I think a 100% QEMU implementation that just goes through all vcpus
> and does a simple SET_ONE_REG for LPCR to set ILE would be the best.
> Anton's patch isn't in Linus' tree yet, right? So all it takes is a
> partial revert of that one to not handle the actual hypercall in KVM.
> And some code in kvmppc_set_lpcr() to also set intr_msr (not changing
> it is a bug today already).
> 
> 
> Alex
> 
> 

Thanks for your indications Alex.

Cheers.

--
Greg