Answering to both Paul and Alex. On Fri, 4 Oct 2013 13:54:25 +0200 Alexander Graf <agraf@xxxxxxx> 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 -- 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
