qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]