All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Baron <jbaron@redhat.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
	bhelgaas@google.com, linux-pci@vger.kernel.org
Subject: Re: [PATCH] pci hotplug: rescan bridge after device hotplug
Date: Wed, 23 May 2012 22:20:19 +0300	[thread overview]
Message-ID: <20120523192018.GA302@redhat.com> (raw)
In-Reply-To: <20120523190841.GC32207@redhat.com>

On Wed, May 23, 2012 at 10:08:41PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 23, 2012 at 02:44:49PM -0400, Jason Baron wrote:
> > On Wed, May 23, 2012 at 10:16:06AM -0700, Yinghai Lu wrote:
> > > On Wed, May 23, 2012 at 8:53 AM, Jason Baron <jbaron@redhat.com> wrote:
> > > >> > but still would prefer you to make qemu to support pciehp.
> > > >>
> > > >> another solution could be:
> > > >>
> > > >> in qemu acpi dsdt, you could set bridge size for new added bridge.
> > > >>
> > > >> current pbus_size_mem() will not shrink the old bridge resource size.
> > > >
> > > > ok, I also tried hard-wiring the bridge io/mem base and limit registers on the
> > > > qemu side. That seems to work without any guest-side hotplug code changes. And
> > > > would seem to be more flexible than putting the limits in acpi.
> > > 
> > > that should be acpi asl code or SMI work. and should make sure that
> > > range is not overlapped with resources that are used by other bridges
> > > and pci devices.
> > > 
> > 
> > Ok. So you are saying to define a 'Name (_CRS, ResourceTemplate() {
> > Memory() IO() })' block for each bridge?
> 
> We are talking about hotplugging bridges.
> This sounds strange.

However if it works it is certainly simple.


  reply	other threads:[~2012-05-23 19:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-22 20:11 [PATCH] pci hotplug: rescan bridge after device hotplug Jason Baron
2012-05-22 20:34 ` Yinghai Lu
2012-05-22 21:18   ` Yinghai Lu
2012-05-22 21:21 ` Yinghai Lu
2012-05-23  2:43   ` Jason Baron
2012-05-23  3:31     ` Yinghai Lu
2012-05-23  4:07       ` Yinghai Lu
2012-05-23 15:53         ` Jason Baron
2012-05-23 17:16           ` Yinghai Lu
2012-05-23 18:44             ` Jason Baron
2012-05-23 19:08               ` Michael S. Tsirkin
2012-05-23 19:20                 ` Michael S. Tsirkin [this message]
2012-05-23 20:53                 ` Yinghai Lu
2012-05-23 21:18                   ` Michael S. Tsirkin
2012-05-23 20:31               ` Yinghai Lu
2012-05-23 20:49                 ` Michael S. Tsirkin
2012-05-23 19:13       ` Michael S. Tsirkin
2012-05-23 20:52       ` Jason Baron
2012-05-24  0:00         ` Yinghai Lu
2012-05-24 13:43           ` Jason Baron

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=20120523192018.GA302@redhat.com \
    --to=mst@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=jbaron@redhat.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=yinghai@kernel.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.