All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough
Date: Thu, 5 Mar 2009 09:53:22 +1100	[thread overview]
Message-ID: <20090304225322.GA1000@verge.net.au> (raw)
In-Reply-To: <C5D4B1EB.42F5%keir.fraser@eu.citrix.com>

On Wed, Mar 04, 2009 at 10:32:11PM +0000, Keir Fraser wrote:
> On 04/03/2009 22:26, "Simon Horman" <horms@verge.net.au> wrote:
> 
> >> Please note that _PRT method in ACPI AML should reflect GSIs. If you expand
> >> GSIs, it will be necessary to change the _PRT method. Please see
> >> tools/firmware/hvmloader/acpi/dsdt.asl.
> > 
> > Could someone explain why the current code uses 32 GSIs rather than using 128?
> 
> 32 should be plenty, and I'd want to emulate multiple IO-APICs beyond that
> just out of fear that some OS will choke on an IO-APIC with 128 pins (since
> no real single IO-APIC has so many pins). It just seemed a bit unnecessary
> when this support was originally implemented. At this point I haven't heard
> any concrete evidence so far that 32 GSIs is insufficient in any real
> scenario. So that's what we'll be sticking with for the time being, I think.

Thanks, I will see if I can dig out any real-world reasons.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

  reply	other threads:[~2009-03-04 22:53 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-17  9:07 [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough Simon Horman
2009-02-17  9:07 ` [rfc 01/18] Make register_real_device() and unregister_real_device() static Simon Horman
2009-02-17  9:07 ` [rfc 02/18] Make dpci_infos static Simon Horman
2009-02-17  9:07 ` [rfc 03/18] ioemu: vslots needs to be freed on error in power_off_php_slot() Simon Horman
2009-02-17  9:07 ` [rfc 04/18] ioemu: Remove lsi_scsi_init()s devfn parameter as it is always passed as -1 Simon Horman
2009-02-17  9:07 ` [rfc 05/18] " Simon Horman
2009-02-17  9:07 ` [rfc 06/18] ioemu: Remove usb_ohci_init*()s devfn parameter as they are " Simon Horman
2009-02-17  9:07 ` [rfc 07/18] iommu: Define PCI_DEVFN_AUTO and use it Simon Horman
2009-02-17  9:07 ` [rfc 08/18] iommu: Use PCI_DEVFN to create devfn numbers Simon Horman
2009-02-17  9:07 ` [rfc 09/18] ioemu: piix4acpi.c: make various variables static Simon Horman
2009-02-17  9:07 ` [rfc 10/18] ioemu: piix4acpi.c: Simplfy PHPSlots structure Simon Horman
2009-02-17  9:07 ` [rfc 11/18] ioemu: piix4acpi.c: Consistently dont cast opaque to PHPSlots Simon Horman
2009-02-17  9:08 ` [rfc 12/18] ioemu: piix4acpi.c: remove unnecessary assignment of pci_slots to local variables Simon Horman
2009-02-17  9:08 ` [rfc 13/18] ioemu: piix4acpi.c: remove ACPI_PHP_SLOT_NUM Simon Horman
2009-02-17  9:08 ` [rfc 14/18] ioemu: use devfn instead of slots as the unit for passthrough Simon Horman
2009-02-17  9:08 ` [rfc 15/18] ioemu: use struct php_dev to pass around PCI pass-through assignment parameters Simon Horman
2009-02-17  9:08 ` [rfc 16/18] ioemu: non-destructive parsing of PCI assignement strings Simon Horman
2009-02-17  9:08 ` [rfc 17/18] ioemu: sort pass-through PCI devices before inserting Simon Horman
2009-02-17  9:08 ` [rfc 18/18] ioemu: Allow virtual function to be speficied for PCI pass-through Simon Horman
2009-02-17 12:03 ` [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough Ian Jackson
2009-02-17 22:24   ` Simon Horman
2009-02-18  3:12 ` Yuji Shimada
2009-02-19  6:15   ` Simon Horman
2009-02-19  9:21     ` Yuji Shimada
2009-02-19  9:38       ` Keir Fraser
2009-02-20  7:07         ` Simon Horman
2009-02-23  6:24           ` Yuji Shimada
2009-02-23  6:55             ` Simon Horman
2009-02-23  8:39               ` Yuji Shimada
2009-02-23  9:33                 ` Simon Horman
2009-02-23 11:31               ` Keir Fraser
2009-02-23 22:18                 ` Simon Horman
2009-03-02  4:14                   ` Simon Horman
2009-03-02  8:44                     ` Keir Fraser
2009-03-02  9:53                       ` Simon Horman
2009-03-02 10:08                         ` Keir Fraser
2009-03-02 11:25                           ` Simon Horman
2009-03-02 11:33                             ` Keir Fraser
2009-03-03  5:57                               ` Yuji Shimada
2009-03-03  8:56                                 ` Keir Fraser
2009-03-04 22:26                                 ` Simon Horman
2009-03-04 22:32                                   ` Keir Fraser
2009-03-04 22:53                                     ` Simon Horman [this message]
2009-03-04 23:05                           ` Simon Horman
2009-03-05  8:34                             ` Keir Fraser
2009-03-05  9:05                               ` Simon Horman
2009-03-05  9:22                                 ` Keir Fraser
2009-03-05  9:42                                   ` Simon Horman
2009-03-06  1:29                                     ` Yuji Shimada
2009-03-06  2:46                                       ` Simon Horman
2009-03-06  6:55                                         ` Yuji Shimada
2009-03-06  8:19                                           ` Keir Fraser
2009-03-06  8:15                                       ` Keir Fraser
2009-03-05  9:26                                 ` Keir Fraser
2009-03-05  9:31                                   ` Jiang, Yunhong
2009-03-05  9:57                                     ` Simon Horman
2009-03-05 10:13                                       ` Simon Horman
2009-03-05 12:44                                         ` Keir Fraser
2009-03-05 14:47                                       ` Jiang, Yunhong
2009-03-05  9:41                                   ` Simon Horman
2009-02-24  1:29                 ` Ian Pratt
2009-02-24  1:50                   ` Simon Horman

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=20090304225322.GA1000@verge.net.au \
    --to=horms@verge.net.au \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=shimada-yxb@necst.nec.co.jp \
    --cc=xen-devel@lists.xensource.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.