[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: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] [RFC] QEMU/KVM PowerPC: virtio and guest endianness |
Date: |
Fri, 4 Oct 2013 16:19:23 +0200 |
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 <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.
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