All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel@redhat.com>
To: Alexander Bezzubikov <zuban32s@gmail.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	seabios@seabios.org, Kevin OConnor <kevin@koconnor.net>,
	lersek@redhat.com, qemu-devel@nongnu.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Qemu-devel] [RFC PATCH v2 4/4] pci: enable RedHat PCI bridges to reserve additional buses on PCI init
Date: Mon, 24 Jul 2017 17:55:43 +0300	[thread overview]
Message-ID: <f4460ae4-6783-fc41-01d4-026b690f5cae@redhat.com> (raw)
In-Reply-To: <CAKSfGUDBRj8QMi45EKaDb0Ce19Yd_XqkMVUWQiaeUqCyMVcQpQ@mail.gmail.com>

On 24/07/2017 17:39, Alexander Bezzubikov wrote:
> 2017-07-24 12:42 GMT+03:00 Gerd Hoffmann <kraxel@redhat.com 
> <mailto:kraxel@redhat.com>>:
> 
>     On Sun, 2017-07-23 at 22:44 +0300, Alexander Bezzubikov wrote:
>     > By the way, any ideas on how to avoid 'bus overstealing' would 
>     > be greatly appreciated.
>     > Static BIOS variable isn't applicable since its value isn't saved
>     > across reboots.
> 
>     I think the reservation hints should be a absolute number, not a
>     increment.  i.e. if qemu suggests to reserve three extra bus numbers
>     seabios should reserve three, no matter whenever there are zero, one,
>     two or three child busses present.  And I guess seabios should
>     interpret that as minimum, so in case it finds five child busses it
>     will allocate five bus numbers of course ...
> 
> 
> Personally I have nothing against it. Marcel, Michael, what do you think?

Sounds good to me.

> 
> 
>     Same with the other limit hints.  If the hint says to allocate 16M, and
>     existing device bars sum up to 4M, allocate 16M (and therefore leave
>     12M address space for hotplug).  If the device bars sum up to 32M,
>     allocate that.
> 
>     While being at it:  I have my doubts the capability struct layout
>     (which mimics register layout) buys us that much, seabios wouldn't
>     blindly copy over the values anyway.  Having regular u32 fields looks
>     more useful to me.
> 
> 
> Again, if nobody has any objections, I can change it in v3.
> 

I also had my reservations about prev layout, let's see
if it will look cleaner.

Thanks,
Marcel

>     cheers,
>        Gerd
> 
> 
> 
> 
> -- 
> Alexander Bezzubikov

  reply	other threads:[~2017-07-24 15:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-22 22:11 [Qemu-devel] [RFC PATCH v2 0/4] Allow RedHat PCI bridges reserve more buses than necessary during init Aleksandr Bezzubikov
2017-07-22 22:11 ` [Qemu-devel] [RFC PATCH v2 1/4] pci: refactor pci_find_capapibilty to get bdf as the first argument instead of the whole pci_device Aleksandr Bezzubikov
2017-07-23 16:04   ` Marcel Apfelbaum
2017-07-23 16:24   ` Kevin O'Connor
2017-07-22 22:11 ` [Qemu-devel] [RFC PATCH v2 2/4] pci: add RedHat vendor ID Aleksandr Bezzubikov
2017-07-23 16:05   ` Marcel Apfelbaum
2017-07-22 22:11 ` [Qemu-devel] [RFC PATCH v2 3/4] pci: add QEMU-specific PCI capability structure Aleksandr Bezzubikov
2017-07-23  2:44   ` Michael S. Tsirkin
2017-07-23 16:12     ` Alexander Bezzubikov
2017-07-23 16:30   ` Kevin O'Connor
2017-07-23 16:47     ` Alexander Bezzubikov
2017-07-22 22:11 ` [Qemu-devel] [RFC PATCH v2 4/4] pci: enable RedHat PCI bridges to reserve additional buses on PCI init Aleksandr Bezzubikov
2017-07-23  2:49   ` Michael S. Tsirkin
2017-07-23 16:43     ` Alexander Bezzubikov
2017-07-23 19:44       ` Alexander Bezzubikov
2017-07-24  9:42         ` Gerd Hoffmann
2017-07-24 14:39           ` Alexander Bezzubikov
2017-07-24 14:55             ` Marcel Apfelbaum [this message]
2017-07-25 15:46 ` [Qemu-devel] [RFC PATCH v2 0/4] Allow RedHat PCI bridges reserve more buses than necessary during init Laszlo Ersek
2017-07-26  6:48   ` Marcel Apfelbaum
2017-07-26 15:20     ` Laszlo Ersek
2017-07-26 16:22       ` Marcel Apfelbaum
2017-07-26 18:31         ` Laszlo Ersek
2017-07-27 18:18           ` Marcel Apfelbaum
2017-07-26 18:49         ` Michael S. Tsirkin
2017-07-27 18:24           ` Marcel Apfelbaum

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=f4460ae4-6783-fc41-01d4-026b690f5cae@redhat.com \
    --to=marcel@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=konrad.wilk@oracle.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    --cc=zuban32s@gmail.com \
    /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.