From: Robert Hancock <hancockr@shaw.ca>
To: Andi Kleen <andi@firstfloor.org>
Cc: Yinghai Lu <Yinghai.Lu@Sun.COM>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Greg KH <greg@kroah.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/5] x86: validate against acpi motherboard resources
Date: Mon, 18 Feb 2008 14:26:07 -0600 [thread overview]
Message-ID: <47B9E9DF.8010408@shaw.ca> (raw)
In-Reply-To: <20080218113107.GB24147@one.firstfloor.org>
Andi Kleen wrote:
>> With just this patch you will have this problem. You need either the
>> patch to disable decode during BAR sizing,
>
> Isn't that one already merged?
>
> I remember the BAR decoding patch did help with at least one
> of the original failures (there were multiple ones iirc0)
I believe that one's been dropped as it's not needed if we don't use
MMCONFIG for non-extended accesses (like we use during BAR sizing).
(Though, there may still be a case where it's needed, see below.)
>
> If someone points me to all the patches needed or a tree who
> has them all applied I can give it a quick spin on the boxes I have here.
> One of the systems where it originally failed I don't have anymore
> though.
>
>> or the patch to use MMCONFIG
>> for extended config space only, if you don't have them already.
>
> That would mean it would boot, but anything that uses extended config
> space would fail. While not as catastrophic as before I'm not sure
> it's that great either. At least there would be still breakage,
> but much more subtle ones.
The only issue on those boards is that since certain device BARs will
overlap the MMCONFIG area during BAR sizing, if you use MMCONFIG to do
the accesses used during BAR sizing itself, it'll fail. If you use conf1
to do the BAR sizing then that problem doesn't happen.
However, I suppose there could be an issue if you hotplugged a device
(causing BAR sizing) once you'd booted, while extended config space was
in use on another device. The BAR sizing wouldn't fail, but the guy
using extended config space would since he's actually reading
from/writing into the BAR of the device being sized instead of the
MMCONFIG area. That wouldn't be good. The disable-decode-during-sizing
patch would avoid that problem.
next prev parent reply other threads:[~2008-02-18 20:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.LKjQjbOw482S/QFVaQ9fSrM+IFw@ifi.uio.no>
[not found] ` <fa.wuwhrqFp6CufvpAJxShHqIaOPdI@ifi.uio.no>
2008-02-16 5:52 ` [PATCH 1/5] x86: validate against acpi motherboard resources Robert Hancock
2008-02-16 6:09 ` Yinghai Lu
2008-02-17 16:42 ` Ingo Molnar
2008-02-18 11:31 ` Andi Kleen
2008-02-18 20:26 ` Robert Hancock [this message]
2008-02-15 9:27 Yinghai Lu
2008-02-15 11:11 ` Andi Kleen
2008-02-15 18:46 ` Yinghai Lu
2008-02-15 22:11 ` Yinghai Lu
2008-02-15 22:16 ` Yinghai Lu
2008-02-17 14:06 ` Thomas Gleixner
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=47B9E9DF.8010408@shaw.ca \
--to=hancockr@shaw.ca \
--cc=Yinghai.Lu@Sun.COM \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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