From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5bxW-0004ne-HM for qemu-devel@nongnu.org; Thu, 18 Jun 2015 11:42:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5bxQ-0001uI-QX for qemu-devel@nongnu.org; Thu, 18 Jun 2015 11:42:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5bxQ-0001u3-Ir for qemu-devel@nongnu.org; Thu, 18 Jun 2015 11:42:24 -0400 Message-ID: <5582E6DD.8010104@redhat.com> Date: Thu, 18 Jun 2015 17:42:21 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <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> <5582C633.2000205@redhat.com> <20150618152749-mutt-send-email-mst@redhat.com> In-Reply-To: <20150618152749-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/18/15 15:40, Michael S. Tsirkin wrote: > On Thu, Jun 18, 2015 at 03:22:59PM +0200, Laszlo Ersek wrote: >> 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 > > I think I prefer the string to match the actual hierarchy (using any > syntax), yes. Current guests don't seem to care but this needs to > be maintained forever, worth being as correct as we can be. Alright. When I find the drive in myself to do so, I'll post a v7 with patches v6 #1 through #4 included, addressing your pci-bridge comments on top. (If Marcel would prefer to take over those patches immediately, I'm game.) Patch #5 you have already included in a pull request, Cc'ing stable; thanks for that. Patches #6 and #7 I am hereby dropping (the boot order sub-feature). I might revoke the related OVMF-side patches from my latest (v2) OVMF series, or just let them go in in their current form. Once this sub-feature is sorted out between QEMU and SeaBIOS, I might revisit the related OVMF patches. Since we discussed this topic several times over, I trust whatever we'll find in QEMU at that point shall be possible to support in OVMF. I don't necessarily want to sneak patches #6 and #7 onto Marcel's plate -- because they are a feature not intimately related to the expander bridge's core functionality --, so I guess #6 and #7 are free for the taking, for anyone who cares enough (including you). Thanks Laszlo