[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 16:08:06 +0200 |
Answering to both Paul and Alex.
On Fri, 4 Oct 2013 13:54:25 +0200
Alexander Graf <address@hidden> 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,
Greg Kurz <=