On Fri, 4 Oct 2013 13:43:38 +0200 Alexander Graf <agraf@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
