From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Horman 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 Message-ID: <20090304225322.GA1000@verge.net.au> References: <20090304222657.GA31293@verge.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Yuji Shimada , "xen-devel@lists.xensource.com" , Ian Jackson List-Id: xen-devel@lists.xenproject.org On Wed, Mar 04, 2009 at 10:32:11PM +0000, Keir Fraser wrote: > On 04/03/2009 22:26, "Simon Horman" 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