All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Bernat <vincent@bernat.ch>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Igor Mammedov" <imammedo@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v4] hw/smbios: support for type 41 (onboard devices extended information)
Date: Sat, 08 May 2021 06:20:27 +0200	[thread overview]
Message-ID: <877dk9luus.fsf@bernat.ch> (raw)
In-Reply-To: <20210503154024-mutt-send-email-mst@kernel.org> (Michael S. Tsirkin's message of "Mon, 3 May 2021 15:42:16 -0400")

 ❦  3 mai 2021 15:42 -04, Michael S. Tsirkin:

>> >> +            /*
>> >> +             * We only handle the case were the device is attached to
>> >> +             * the PCI root bus. The general case is more complex as
>> >> +             * bridges are enumerated later and the table would need
>> >> +             * to be updated at this moment.
>> >> +             */
>> >> +            if (!pci_bus_is_root(pci_get_bus(pdev))) {
>> >> +                error_setg(errp,
>> >> +                           "Cannot create type 41 entry for PCI device %s: "
>> >> +                           "not attached to the root bus",
>> >> +                           t41->pcidev);
>> >> +                return;
>> >> +            }
>> > Is this limitation really necessary?
>> >
>> > As far as I see caller of this smbios_get_tables(), is called at machine_done time
>> > when all devices (including bridges) present on CLI are created.
>> 
>> I wasn't sure how to get the segment group number in this case. It seems
>> this is not exposed directly. There is a root_bus_path method returning
>> a string that would need to be parsed to extract the segment group
>> number. Looking a bit, it seems to be always 0.
>
> and not just that. the code comments explains the motivation even
> with a single segment.

Yes, now I remember you told me that in complex cases, the bus is
configured by guest and therefore, we cannot get the right address at
boot. I could update the comment to say "enumerated by guest" or
"configured by guest" if it makes the reason clearer.
-- 
Suspicion always haunts the guilty mind.
		-- Wm. Shakespeare


      reply	other threads:[~2021-05-08  4:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 17:11 [PATCH v4] hw/smbios: support for type 41 (onboard devices extended information) Vincent Bernat
2021-04-30  9:51 ` Vincent Bernat
2021-05-03 15:05 ` Igor Mammedov
2021-05-03 19:34   ` Vincent Bernat
2021-05-03 19:42     ` Michael S. Tsirkin
2021-05-08  4:20       ` Vincent Bernat [this message]

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=877dk9luus.fsf@bernat.ch \
    --to=vincent@bernat.ch \
    --cc=berrange@redhat.com \
    --cc=imammedo@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 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.