qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Michael S. Tsirkin" <mst@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: Wed, 17 Jun 2015 21:44:07 +0200	[thread overview]
Message-ID: <5581CE07.20302@redhat.com> (raw)
In-Reply-To: <20150617213011-mutt-send-email-mst@redhat.com>

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

  reply	other threads:[~2015-06-17 19:44 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 [this message]
2015-06-17 21:50                       ` Michael S. Tsirkin
2015-06-18 13:22                         ` Laszlo Ersek
2015-06-18 13:40                           ` Michael S. Tsirkin
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=5581CE07.20302@redhat.com \
    --to=lersek@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=marcel@redhat.com \
    --cc=mst@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).