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 <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. 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 -- 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
