All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: kevin@koconnor.net, seabios@seabios.org, qemu-devel@nongnu.org,
	Marcel Apfelbaum <marcel.a@redhat.com>
Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached
Date: Mon, 7 Apr 2014 16:34:15 +0300	[thread overview]
Message-ID: <20140407133415.GB16541@redhat.com> (raw)
In-Reply-To: <1396874646.5001.76.camel@nilsson.home.kraxel.org>

On Mon, Apr 07, 2014 at 02:44:06PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > +        u8 shpc_cap = pci_find_capability(s->bus_dev, PCI_CAP_ID_SHPC);
> 
> > One thing I'd do is maybe check that the relevant memory type is
> > enabled in the bridge (probably just by writing fff to base and reading
> > it back).
> 
> > This will give hypervisors an option to avoid wasting resources:
> > e.g. it's uncommon for express devices to claim IO.
> 
> I don't think we'll need that for the SHPC bridge.

Why not?
I'm referring to this text in the bridge specification:

	The I/O Base and I/O Limit registers are optional and define an address
	range that is used
	by the bridge to determine when to forward I/O transactions from one
	interface to the
	other.
	If a bridge does not implement an I/O address range, then both the I/O
	Base and I/O
	Limit registers must be implemented as read-only registers that return
	zero when read. If a
	bridge supports an I/O address range, then these registers must be
	initialized by
	configuration software so default states are not specified.

So we should probe bridge for I/O support before wasting I/O resources on it.
The spec does not provide a way to detect this, but we can do it like this:

	- write value ffffffff to I/O base register
	- read back value

value 0 means bridge does not support I/O.


A similar trick should work for other optional resources.


> For express it indeed makes sense to avoid claiming IO address space.
> I'd try to find something more automatic though, where you don't need
> some kind of "disable io for this express port" config option.

Won't same trick as above work?

> For express ports which can only have a single device underneath we can
> check whenever we have a device and if one is present already don't
> bother claiming extra resources for hotplug.
> 
> > > +    for (cap = pci_config_readb(pci->bdf, PCI_CAPABILITY_LIST); cap;
> > > +                cap = pci_config_readb(pci->bdf, cap + PCI_CAP_LIST_NEXT))
> > > +        if (pci_config_readb(pci->bdf, cap + PCI_CAP_LIST_ID) == cap_id)
> > > +            return cap;
> > 
> > I would also limit this to 256 iterations, to make sure
> > we dont' get into an infinite loop with a broken device.
> 
> Good point.
> 
> cheers,
>   Gerd
> 

  parent reply	other threads:[~2014-04-07 13:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07 10:59 [Qemu-devel] [SeaBIOS] [PATCH] hw/pci: reserve IO and mem for pci-2-pci bridges with no devices attached Marcel Apfelbaum
2014-04-07 12:01 ` Gerd Hoffmann
2014-04-07 12:11   ` Michael S. Tsirkin
2014-04-07 12:18     ` Marcel Apfelbaum
2014-04-07 12:15 ` Michael S. Tsirkin
2014-04-07 12:44   ` Gerd Hoffmann
2014-04-07 12:51     ` Marcel Apfelbaum
2014-04-07 13:34     ` Michael S. Tsirkin [this message]
2014-04-07 13:51       ` Marcel Apfelbaum
2014-04-07 13:55         ` Marcel Apfelbaum
2014-04-07 14:09         ` Michael S. Tsirkin
2014-04-07 14:16           ` Marcel Apfelbaum
2014-04-07 16:22             ` Michael S. Tsirkin
2014-04-08  6:05       ` Gerd Hoffmann
2014-04-08  8:54         ` Michael S. Tsirkin

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=20140407133415.GB16541@redhat.com \
    --to=mst@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=kraxel@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.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.