From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Zmf-0006jg-Cy for qemu-devel@nongnu.org; Thu, 18 Jun 2015 09:23:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5ZmZ-00005M-Ht for qemu-devel@nongnu.org; Thu, 18 Jun 2015 09:23:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5ZmZ-000055-AO for qemu-devel@nongnu.org; Thu, 18 Jun 2015 09:23:03 -0400 Message-ID: <5582C633.2000205@redhat.com> Date: Thu, 18 Jun 2015 15:22:59 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <20150617155237-mutt-send-email-mst@redhat.com> <20150617141820.GA11337@morn.localdomain> <55818819.3010107@redhat.com> <20150617150544.GA26500@redhat.com> <5581B97E.8020707@redhat.com> <20150617204828-mutt-send-email-mst@redhat.com> <5581C74C.5070405@redhat.com> <20150617192843.GB27117@morn.localdomain> <20150617213011-mutt-send-email-mst@redhat.com> <5581CE07.20302@redhat.com> <20150617235009-mutt-send-email-mst@redhat.com> In-Reply-To: <20150617235009-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 7/7] hw/pci-bridge: format SeaBIOS-compliant OFW device node for PXB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Marcel Apfelbaum , Kevin O'Connor , qemu-devel@nongnu.org, Markus Armbruster On 06/17/15 23:50, Michael S. Tsirkin wrote: > On Wed, Jun 17, 2015 at 09:44:07PM +0200, Laszlo Ersek wrote: >> On 06/17/15 21:32, Michael S. Tsirkin wrote: >>> On Wed, Jun 17, 2015 at 03:28:44PM -0400, Kevin O'Connor wrote: >>>> On Wed, Jun 17, 2015 at 09:15:24PM +0200, Laszlo Ersek wrote: >>>>> On 06/17/15 20:54, Michael S. Tsirkin wrote: >>>>>> Right. But what I was discussing is a different issue. The point is >>>>>> that it does not make sense to have /pci@i0cf8 under two hierarchies: >>>>>> it's the same register. What happens is that you access /pci@i0cf8 and >>>>>> then *through that* you access another pci root. Not the other way >>>>>> around. The proposal thus is to switch to /pci@i0cf8/pci-root@N in >>>>>> seabios, >>>>> >>>>> For me this is still Question 1 -- 'everything in that pattern that is >>>>> not "N"'. >>>>> >>>>> You seem to care about the *semantics* of that OFW device path fragment. >>>>> I don't. First, the relevant IEEE spec is prohibitively hard for me to >>>>> interpret semantically. Second, there is no known firmware that actually >>>>> looks at the "i0cf8" unit-address term and decides *based on that term* >>>>> that it has to talk PCI via 0xCF8 and 0xCFC. In other words, the current >>>>> second node is entirely opaque in my interpretation. >>>>> >>>>>> unconditionally - not if (QEMU). >>>>> >>>>> This might qualify as some kind of semantic cleanup, but it will >>>>> nonetheless break the SeaBIOS boot options expressed in OFW notation >>>>> that are already persistently stored in cbfs, on physical machines. (As >>>>> far as I understood.) It might not break the Coreboot-SeaBIOS interface, >>>>> but it might invalidate preexistent entries that exist in the prior form >>>>> (wherever they exist on physical hardware). >>>>> >>>>>> And I thought Kevin agreed >>>>>> it's a good idea. >>>>>> >>>>>> Kevin - is this a good summary of your opinion? >>>>> >>>>> Kevin, please do answer. >>>> >>>> It is true that it would "invalidate preexistent entries" for >>>> coreboot/seabios users that upgrade, but I think that is manageable. >>>> So I defer the syntax discussion and decisions to the QEMU developers >>>> that are doing the bulk of the work. >>>> >>>> -Kevin >>> >>> I'm fine with either /pci@i0cf8,%x or /pci-root@%x/pci@i0cf8, with a >>> slight preference to the later - in particular it's easier >>> to implement in QEMU. >>> >>> It means old bios won't boot from a pxb, but I think that's >>> manageable - it works otherwise. >> >> I don't understand -- the second option you named >> ("/pci-root@%x/pci@i0cf8") is what this patch implements, and "old" (ie. >> current) SeaBIOS does boot from it. >> >> Laszlo > > Ouch. I meant /pci@i0cf8//pci-root@%x. > As you see, it's confusing. If you insist on /pci@i0cf8/pci-root@%x, then all of SeaBIOS, QEMU, and OVMF must be (further) modified. Please confirm if this is what you'd like. (As I said, IMO this change is not warranted for; it just replaces one opaque string with another opaque string, without semantic effects, but it causes extra churn and even requires a patch for SeaBIOS.) Laszlo