linux-kernel - Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1270731845.26244.20.camel@dc7800.home>
Date:	Thu, 08 Apr 2010 07:04:05 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Yinghai <yinghai.lu@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, linux-pci@...r.kernel.org,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	Andy Isaacson <adi@...apodia.org>,
	Thomas Renninger <trenn@...e.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well
	as x86_32

On Wed, 2010-04-07 at 21:42 -0700, H. Peter Anvin wrote:
> On 04/07/2010 08:24 PM, Bjorn Helgaas wrote:
> > 
> > I actually did propose doing something in pci_setup_device(), similar to
> > what we already do for legacy IDE resources, but HPA thought it should
> > be done in the arch code instead, again for reasons I don't completely
> > understand.

> "Non-PCI devices" is hard to understand?

I understand that part, and the patch I posted is for the arch code, as
you suggested.

I just thought you were suggesting an x86 change *instead* of something
in PCI, even though it seems like the PCI spec does mention that devices
with VGA class code respond at 0xa0000.  Or maybe you were just
suggesting that we should do something in *both* PCI and in the arch
code?

Of course, the PCI part might be complicated by the VGA arbiter,
although I would think that if the system contains at least one VGA
device, reserving the 0xa0000 region once would solve 99% of the
problem.  If the arbiter changes the actual device that responds there,
the reservation will be for the wrong device, but we still want to avoid
putting anything else there.

Honestly, I don't know enough about x86_32 vs x86_64 to understand
Yinghai's objection.  Is there some platform architecture difference
that means x86_64 can reliably determine whether a non-PCI VGA device is
present, when x86_32 can't?  Unless there's a real difference, we ought
to handle them both the same, as my patch does.

Yinghai mentioned a box with no VGA and another device using 0xa0000.
Unless there's some x86_64-specific spec or convention that addresses
this, maybe we could handle that by (1) doing the legacy reservation as
in this patch, and (2) special-casing the PCI device setup so that if we
find a BAR set to that area, we undo the legacy reservation.  Or maybe
we just leave the legacy reservation unused and relocate the device that
BIOS left there.

Bjorn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/