From: "Michael S. Tsirkin" <mst@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>,
Kevin O'Connor <kevin@koconnor.net>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v6 7/7] hw/pci-bridge: format SeaBIOS-compliant OFW device node for PXB
Date: Thu, 18 Jun 2015 15:40:49 +0200 [thread overview]
Message-ID: <20150618152749-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <5582C633.2000205@redhat.com>
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.
--
MST
next prev parent reply other threads:[~2015-06-18 13:41 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 12:44 [Qemu-devel] [PATCH v6 0/7] PXB changes Laszlo Ersek
2015-06-17 12:44 ` [Qemu-devel] [PATCH v6 1/7] migration: introduce VMSTATE_BUFFER_UNSAFE_INFO_TEST() Laszlo Ersek
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 2/7] hw/pci-bridge: expose _test parameter in SHPC_VMSTATE() Laszlo Ersek
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 3/7] hw/pci-bridge: introduce "hotplug" property Laszlo Ersek
2015-06-17 13:42 ` Michael S. Tsirkin
2015-06-17 13:55 ` Laszlo Ersek
2015-06-17 14:02 ` Michael S. Tsirkin
2015-06-17 14:15 ` Laszlo Ersek
2015-06-17 19:54 ` Marcel Apfelbaum
2015-06-18 13:47 ` Paolo Bonzini
2015-06-18 14:44 ` Michael S. Tsirkin
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 4/7] hw/pci-bridge: disable hotplug in PXB Laszlo Ersek
2015-06-17 13:45 ` Michael S. Tsirkin
2015-06-17 19:52 ` Marcel Apfelbaum
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 5/7] hw/core: rebase sysbus_get_fw_dev_path() to g_strdup_printf() Laszlo Ersek
2015-06-17 13:46 ` Michael S. Tsirkin
2015-06-17 13:56 ` Laszlo Ersek
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 6/7] hw/core: explicit OFW unit address callback for SysBusDeviceClass Laszlo Ersek
2015-06-17 12:45 ` [Qemu-devel] [PATCH v6 7/7] hw/pci-bridge: format SeaBIOS-compliant OFW device node for PXB Laszlo Ersek
2015-06-17 13:57 ` Michael S. Tsirkin
2015-06-17 14:00 ` Laszlo Ersek
2015-06-17 14:03 ` Michael S. Tsirkin
2015-06-17 14:18 ` Kevin O'Connor
2015-06-17 14:45 ` Laszlo Ersek
2015-06-17 15:05 ` Michael S. Tsirkin
2015-06-17 18:16 ` Laszlo Ersek
2015-06-17 18:54 ` Michael S. Tsirkin
2015-06-17 19:15 ` Laszlo Ersek
2015-06-17 19:28 ` Kevin O'Connor
2015-06-17 19:32 ` Michael S. Tsirkin
2015-06-17 19:44 ` Laszlo Ersek
2015-06-17 21:50 ` Michael S. Tsirkin
2015-06-18 13:22 ` Laszlo Ersek
2015-06-18 13:40 ` Michael S. Tsirkin [this message]
2015-06-18 15:42 ` Laszlo Ersek
2015-06-17 19:09 ` Kevin O'Connor
2015-06-17 19:21 ` Michael S. Tsirkin
2015-06-17 19:35 ` Laszlo Ersek
2015-06-17 21:49 ` Michael S. Tsirkin
2015-06-18 13:18 ` Laszlo Ersek
2015-06-17 19:38 ` Kevin O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150618152749-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=armbru@redhat.com \
--cc=kevin@koconnor.net \
--cc=lersek@redhat.com \
--cc=marcel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.