Re: [Qemu-devel] [Qemu-ppc] [RFC] QEMU/KVM PowerPC: virtio and guest endianness
On Fri, 4 Oct 2013 13:43:38 +0200 Alexander Graf ag...@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
Re: [Qemu-devel] [Qemu-ppc] [RFC] QEMU/KVM PowerPC: virtio and guest endianness
Answering to both Paul and Alex. On Fri, 4 Oct 2013 13:54:25 +0200 Alexander Graf ag...@suse.de wrote: On 04.10.2013, at 13:53, Paul Mackerras wrote: I don't mind particularly whether H_SET_MODE for the endianness setting gets handled in the kernel or in QEMU, but I don't think it should be handled in both. If you want QEMU to know about the endianness setting immediately, make the kernel version do nothing and get QEMU to handle it -- which if KVM is enabled will mean iterating over all vcpus and getting them all to send the new LPCR setting to the kernel via the SET_ONE_REG ioctl. However, I want the setting of breakpoint registers (CIABR and DAWR/X) via H_SET_MODE to happen in the kernel, preferably in real mode, since that can happen on context switch and thus needs to be quick. Paul, As far as virtio is concerned, QEMU only needs to know about the guest endiannes if a virtio device shows up. The virtio reset flow is a good candiadate for that. I don't want to see a single hypercall be split across the QEMU/KVM barrier. So if there's a reasonable incentive to handle H_SET_MODE in KVM, we should handle all of it in KVM. Alex, The appropriate solution would be then to let KVM implement the whole H_SET_MODE hcall and own LPCR. QEMU will poll it with cpu_synchronize_state(). It seems to preserve all the requirements. Alex -- Thanks for your guidance. Cheers. -- Greg
Re: [Qemu-devel] [Qemu-ppc] [RFC] QEMU/KVM PowerPC: virtio and guest endianness
On 04.10.2013, at 16:08, Greg Kurz wrote: Answering to both Paul and Alex. On Fri, 4 Oct 2013 13:54:25 +0200 Alexander Graf ag...@suse.de wrote: On 04.10.2013, at 13:53, Paul Mackerras wrote: I don't mind particularly whether H_SET_MODE for the endianness setting gets handled in the kernel or in QEMU, but I don't think it should be handled in both. If you want QEMU to know about the endianness setting immediately, make the kernel version do nothing and get QEMU to handle it -- which if KVM is enabled will mean iterating over all vcpus and getting them all to send the new LPCR setting to the kernel via the SET_ONE_REG ioctl. However, I want the setting of breakpoint registers (CIABR and DAWR/X) via H_SET_MODE to happen in the kernel, preferably in real mode, since that can happen on context switch and thus needs to be quick. Paul, As far as virtio is concerned, QEMU only needs to know about the guest endiannes if a virtio device shows up. The virtio reset flow is a good candiadate for that. I don't want to see a single hypercall be split across the QEMU/KVM barrier. So if there's a reasonable incentive to handle H_SET_MODE in KVM, we should handle all of it in KVM. Alex, The appropriate solution would be then to let KVM implement the whole H_SET_MODE hcall and own LPCR. QEMU will poll it with cpu_synchronize_state(). It seems to preserve all the requirements. Yes. Since breakpoint registers are part of H_SET_MODE, we want to have it owned by KVM rather than QEMU. I still don't know what those PAPR people think they're doing, shoving completely unrelated things into the same hypercall though :). Alex
