[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [RFC] QEMU/KVM PowerPC: virtio and guest end
From: |
Greg Kurz |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] [RFC] QEMU/KVM PowerPC: virtio and guest endianness |
Date: |
Fri, 4 Oct 2013 15:43:09 +0200 |
On Fri, 4 Oct 2013 13:43:38 +0200
Alexander Graf <address@hidden> 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