From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VS5fF-0008K4-4H for qemu-devel@nongnu.org; Fri, 04 Oct 2013 09:43:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VS5f6-0004cd-UJ for qemu-devel@nongnu.org; Fri, 04 Oct 2013 09:43:29 -0400 Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:35896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VS5f6-0004cD-L1 for qemu-devel@nongnu.org; Fri, 04 Oct 2013 09:43:20 -0400 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 Oct 2013 14:43:17 +0100 Date: Fri, 4 Oct 2013 15:43:09 +0200 From: Greg Kurz Message-ID: <20131004154309.1e8aa8e1@bahia.local> In-Reply-To: <143D6A15-8585-4405-8E74-C3FFE8CDA7C1@suse.de> References: <20130925223118.GA2844@iris.ozlabs.ibm.com> <20130927135930.10288.86526.stgit@nimbus> <20130927164535.6dbeface@bahia.local> <20131003162952.4cbf482c@bahia.local> <143D6A15-8585-4405-8E74-C3FFE8CDA7C1@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 Developers" , kvm-ppc@vger.kernel.org, "open list:PReP" , Paul Mackerras , Laurent Dufour On Fri, 4 Oct 2013 13:43:38 +0200 Alexander Graf wrote: > CC'ing qemu-devel - please use qemu-ppc@ only as a tag, every mail > needs to go to qemu-devel as well. > Sure I will. > On 03.10.2013, at 16:29, Greg Kurz wrote: > [...] > > I have searched for an appropriate place to add the polling and I > > must admit I did not find any... I am no QEMU expert but I suspect > > we would need some kind of arch specific hook to be called from the > > virtio code to do this... :-\ I hope I am wrong, please correct me > > if so. > > Just put it into the normal register sync function and call > cpu_synchronize_state() on virtio reset. > Thanks, I will look into that. > > We have to decide which scheme to follow. There are 2 way we can / > should handle registers usually: > > a) owned by QEMU > b) owned by KVM > > If they're owned by QEMU, every hypercall needs to go into QEMU which > then propagates that change through an ioctl back into KVM. If > they're owned by KVM, QEMU needs to fetch them whenever it needs to > > As a general rule of thumb path b is easier to hack up, path a is > easier to maintain long term. Which is pretty much what you're seeing > here. > Agreed. > > I have a better feeling for (2) because: > > - 2-liner patch in KVM > > - no extra code change in QEMU > > - already *partially* tested > > I don't understand. QEMU would get triggered, then have to propagate > things back into KVM. We definitely do _not_ want KVM to do magic, > then tell QEMU to handle a hypercall again. > My idea was to have KVM and QEMU be like *co-owners* of the LPCR register... now I admit it was a bad idea ! :) > > Also, I understood Rusty is working on the next virtio specification > > which should address the endian issue: probably not worth to add too > > many temporary lines in the QEMU code... > > Does 3.13 support LE mode? Does 3.13 support the new and shiny virtio > spec? There's a good chance we'd have to deal with guest kernels that > can do LE, but not sane virtio. > I don't know any details about 3.13 but I guess you are right, it is unlikely the guests will have it. > > Of course, I probably lack some essential knowledge that would be > > more favorable to (1)... so please comment and argue ! :) > > I think a 100% QEMU implementation that just goes through all vcpus > and does a simple SET_ONE_REG for LPCR to set ILE would be the best. > Anton's patch isn't in Linus' tree yet, right? So all it takes is a > partial revert of that one to not handle the actual hypercall in KVM. > And some code in kvmppc_set_lpcr() to also set intr_msr (not changing > it is a bug today already). > > > Alex > > Thanks for your indications Alex. Cheers. -- Greg