From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wx2RC-00047u-76 for qemu-devel@nongnu.org; Tue, 17 Jun 2014 19:05:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wx2R6-00081P-5f for qemu-devel@nongnu.org; Tue, 17 Jun 2014 19:05:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42141 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wx2R5-000805-Vm for qemu-devel@nongnu.org; Tue, 17 Jun 2014 19:05:04 -0400 Message-ID: <53A0C99E.4020101@suse.de> Date: Wed, 18 Jun 2014 01:05:02 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1402974463.7661.102.camel@pasglop> <1403001900.1614.10.camel@nilsson.home.kraxel.org> <1403003721.7661.148.camel@pasglop> <1403006267.1614.14.camel@nilsson.home.kraxel.org> <1403040734.7661.173.camel@pasglop> <1403045714.7661.179.camel@pasglop> In-Reply-To: <1403045714.7661.179.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt , Peter Maydell Cc: Alexey Kardashevskiy , Paolo Bonzini , Gerd Hoffmann , "qemu-devel@nongnu.org" On 18.06.14 00:55, Benjamin Herrenschmidt wrote: > On Tue, 2014-06-17 at 23:12 +0100, Peter Maydell wrote: >> On 17 June 2014 22:32, Benjamin Herrenschmidt wrote: >>> Additionally, I wouldn't mind of we did a quick "trick" equivalent (but >>> cleaner) to what I did in my patch which is when the pseries guest calls >>> the hypervisor call to change the interrupt endian mode, we notify VGA >>> and switch its endian mode, so we work "by default" with kernels not >>> updated to know about that register. But this is open for debate. It's >>> somewhat "acceptable" in the context of our hypercall being a >>> "paravirtualized" interface, so it can be argued that the hypercall >>> poking at the VGA chip is equivalent to some FW doing so :-) >> I'm definitely against this. Have your guest change the behaviour >> of the VGA device by explicitly prodding the VGA device, not by >> back-door side-effects of something else that it happens to do >> on one particular guest for one particular architecture, please. > But that means modifying guests ... obviously you live in a world where > you don't have to live with existing enterprise distros backward > compatibility :-) > > I understand the reluctance against backdoor side effects in general, > but as I said, this is a hypervisor call that basically says "change > system endianness". It does make some amount of sense to have in that > case the hypervisor (which here is qemu) go adjust the endianness > setting in some devices as well as the cores. Semantically the H_SET_MODE(LE) hypercall is on the same level as PSCI. Some code somewhere (Trustzone in the guest on ARM or QEMU) runs some code to "do magic". So for the sake of the discussion imagine this code would live inside of guest context. It can't for us, as hypercalls always trap into KVM or QEMU, but semantically the code shouldn't be able to do too much more than anything coming from the guest should be able to do. Imagine the code that runs here loops through all PCI devices, looks for BOCHS VGA adapters and pokes that endian register. This is essentially the interface that Ben is suggesting here. Given that, the prerequisite to that interface is to have a guest exposed register to flip the endianness in the first place. I think it makes most sense to settle on that register first, then talk about potential backwards compat hacks that we could do on hypercalls with that register. Of course, the side effect that H_SET_MODE(LE) flips the VGA endianness needs to be documented in sPAPR as well if we want to go down that path. sPAPR is the hypercall specification we implement with -M pseries. Alex