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




reply via email to

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