From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Ralf Jung <ralfjung-e@gmx.de>, Yinghai Lu <yinghai@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] x86, ioapic: Reserve only 128 bytes for IOAPICs
Date: Fri, 26 Aug 2011 10:22:24 +0400 [thread overview]
Message-ID: <20110826062224.GA3903@sun> (raw)
In-Reply-To: <CAErSpo7N3UBJgQTb+zePnsf5YuFSQT8zy9CftwceyAKKfcHUjA@mail.gmail.com>
On Thu, Aug 25, 2011 at 06:17:06PM -0600, Bjorn Helgaas wrote:
> On Thu, Aug 25, 2011 at 5:33 PM, Suresh Siddha
> <suresh.b.siddha@intel.com> wrote:
> > On Thu, 2011-08-25 at 16:05 -0700, Bjorn Helgaas wrote:
> >> Previously we reserved 1024 bytes, but that's more space than the IOAPIC
> >> consumes, and it can cause conflicts with nearby devices. The known
> >> requirement is 68 bytes (sizeof(struct io_apic)), and rounding up to a
> >> power-of-2 gives us 128.
> >>
> >
> > Bjorn, Given the info from Intel that most of its io-apic
> > implementations has registers up to 0xff offset (reserved), does
> > reserving just the 128 bytes for the io-apic cause any address conflicts
> > if the next 128 bytes are allocated (by the OS) for any other device.
>
> If the OS allocated the next 128 bytes to another device, it sounds
> like it would cause a conflict on Intel boxes. This must be an area
> that differs between vendors. I haven't seen a spec that mentions 256
> bytes as the required minimum MMIO size for IOAPICs, and apparently
> the AMD IOAPIC decodes 240 bytes or fewer.
>
Hi Bjorn,
the former idea (as far as I remember) of all this IO_APIC_SLOT_SIZE
was to be sure the io-apics are allocated with 1K step (which
is requirements for io-apics), but definitely it doesn't consume
that much space neither it decode the whole range.
Which means, I would prefer if we have (since we change IO_APIC_SLOT_SIZE
anyway) some additional check and WARN_ON in this code. Something like
if (io-apic-base-address & 0x3ff)
WARN_ON();
Hm? (also we have bad_ioapic() check, probably should put such test
there instead).
Cyrill
next prev parent reply other threads:[~2011-08-26 6:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-25 23:05 [PATCH 1/2] x86, ioapic: Reserve only 128 bytes for IOAPICs Bjorn Helgaas
2011-08-25 23:05 ` [PATCH 2/2] x86, ioapic: Announce resources reserved " Bjorn Helgaas
2011-08-25 23:33 ` [PATCH 1/2] x86, ioapic: Reserve only 128 bytes " Suresh Siddha
2011-08-26 0:17 ` Bjorn Helgaas
2011-08-26 1:41 ` H. Peter Anvin
2011-08-26 6:18 ` Yinghai Lu
2011-08-26 6:48 ` Cyrill Gorcunov
2011-08-26 9:22 ` Ralf Jung
2011-08-26 9:39 ` Cyrill Gorcunov
2011-08-26 9:53 ` Ralf Jung
2011-08-26 9:56 ` Cyrill Gorcunov
2011-08-26 6:22 ` Cyrill Gorcunov [this message]
2011-08-26 16:21 ` Bjorn Helgaas
2011-08-26 16:24 ` H. Peter Anvin
2011-08-26 18:09 ` Cyrill Gorcunov
2011-08-26 18:21 ` H. Peter Anvin
2011-08-26 19:15 ` Cyrill Gorcunov
[not found] ` <CAErSpo5kEw=VTVv-=_D3hQg5oRNL9yEyJUnpP0biH=t3WRXMZw@mail.gmail.com>
2011-08-26 21:09 ` Fwd: " Ralf Jung
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=20110826062224.GA3903@sun \
--to=gorcunov@gmail.com \
--cc=bhelgaas@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ralfjung-e@gmx.de \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox