From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpRfw-0005dp-6H for qemu-devel@nongnu.org; Wed, 19 Jun 2013 19:20:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpRfv-0006jb-2W for qemu-devel@nongnu.org; Wed, 19 Jun 2013 19:20:28 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:41365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpRfu-0006jS-Se for qemu-devel@nongnu.org; Wed, 19 Jun 2013 19:20:27 -0400 Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 19 Jun 2013 17:20:26 -0600 From: Anthony Liguori In-Reply-To: <970EA7BC-E7EB-4971-8E36-CD303C872B53@suse.de> References: <1371674435-14973-1-git-send-email-aliguori@us.ibm.com> <1371674435-14973-10-git-send-email-aliguori@us.ibm.com> <87wqppg490.fsf@codemonkey.ws> <970EA7BC-E7EB-4971-8E36-CD303C872B53@suse.de> Date: Wed, 19 Jun 2013 18:20:17 -0500 Message-ID: <87k3lpelhq.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 09/12] spapr-vio: move special case handling for reg=0 to vio List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Alexey Kardashevskiy , qemu-devel qemu-devel , "qemu-ppc@nongnu.org list:PowerPC" , Paul Mackerras , Andreas Faerber Alexander Graf writes: > On 19.06.2013, at 23:49, Anthony Liguori wrote: > >> Alexander Graf writes: >> >>> On 19.06.2013, at 22:40, Anthony Liguori wrote: >>> >>>> The creatively named reg field is a hypervisor assigned global >>>> identifier for a virtual device. Despite the fact that no device >>>> is assigned a reg of 0, guests still use it to refer to early >>>> console. >>>> >>>> Instead of handling this in the VTY device, handle this in the VIO >>>> bus since this is ultimately about how devices are decoded. >>>> >>>> This does not produce a change in behavior since reg=0 hcalls to >>>> non-VTY devices will still fail as gloriously as they did before >>>> just for a different reason (invalid device instead of invalid reg). >>> >>> Ben, is it true that reg=0 is guaranteed to be free, regardless of the >>> target call? >> >> reg is exposed to the guest via device tree. My assumption is that the >> only reason this reg=0 silliness exists is for early boot code that >> hasn't gotten enough working yet to actually read the device tree to >> discover the proper reg value for the VTY. > > So QEMU decided the numbering scheme. Can we just use reg=0 for the > default VTY? Or is reg=0 considered invalid? We expose reg= on the command line too. I think we want to exclude 0 from that interface though. I suspect libvirt is going to want to allocate IDs to ensure a stable guest interface. Regardless of what the "first" VTY is assigned as it's reg, software is going to use reg=0 to access it. Regards, Anthony Liguori >>> Also, are there no other PAPR calls that could possibly refer to reg=0 >>> but mean something different from the VTY device? >> >> Note that if there is, it will still fail today exactly the same way as >> it does without this patch. >> >> We can still add work arounds to the reg lookup code to return something >> different for reg=0 if a different device type is being searched for. > > As mentioned in a later patch review, that's pretty much what I think would be the best way forward, yes. Unless we can just make the default VTY be reg=0. Then there's no hack needed at all ;). > >> >> So even if that's the case, I still think this move is the right way to >> handle things. > > Yes, but I want to grasp the scope of potential breakage. > > > Alex