From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VS6De-0002Nz-CQ for qemu-devel@nongnu.org; Fri, 04 Oct 2013 10:19:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VS6DU-0008VR-9u for qemu-devel@nongnu.org; Fri, 04 Oct 2013 10:19:02 -0400 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:58014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VS6DU-0008UD-0A for qemu-devel@nongnu.org; Fri, 04 Oct 2013 10:18:52 -0400 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 Oct 2013 15:18:50 +0100 Date: Fri, 4 Oct 2013 16:08:06 +0200 From: Greg Kurz Message-ID: <20131004160806.42c1d53d@bahia.local> In-Reply-To: <46DFE136-500E-4192-BB38-06333A6A0901@suse.de> References: <20130925223118.GA2844@iris.ozlabs.ibm.com> <20130927135930.10288.86526.stgit@nimbus> <20130927164535.6dbeface@bahia.local> <20131003162952.4cbf482c@bahia.local> <20131004115302.GA26884@iris.ozlabs.ibm.com> <46DFE136-500E-4192-BB38-06333A6A0901@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC] QEMU/KVM PowerPC: virtio and guest endianness List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Michael Neuling , Rusty Russell , qemu-devel@nongnu.org, kvm-ppc@vger.kernel.org, qemu-ppc@nongnu.org, Paul Mackerras , Laurent Dufour Answering to both Paul and Alex. On Fri, 4 Oct 2013 13:54:25 +0200 Alexander Graf 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