Messages in this thread | | | Date | Tue, 23 Oct 2012 17:27:18 +0100 | From | Matthew Garrett <> | Subject | Re: [PATCH RFC] function probe_roms accessing improper addresses |
| |
On Tue, Oct 23, 2012 at 10:05:01AM -0600, Randy Wright wrote:
> On the first: one way to be compliant with such a requirement would be > to design systems that implement softfail in this particular region. > What about a system that hardfails, but on which the resulting machine > check can be handled by the kernel machine check handler? Would > appropriate re-ordering of the kernel initialization code to support > such systems be acceptable?
Good question. I don't maintain that code, so I can't really answer it...
> Also, let me mention a possible amendment to your first idea: what if > the mandate that probing be supported were qualified by some attribute > that could be indicated in the UEFI environment? For example: instead > of just a hole in the UEFI memory map, what if this range was > specifically present and typed as EfiUnusableMemory? Another idea for > UEFI systems - but one requiring a UEFI specification change - might be > adding a UEFI variable that if present, indicates any area not > explicitly included and typed in the UEFI memory map (including the > legacy adapter region) must be explicitly avoided by an OS.
Yeah, I think if it were marked unusable we could probably justify staying away from it.
> > 2) Don't call probe_roms() by default, but leave it up to the graphics > > drivers. If they can get the rom by any other means then don't call it. > > One the second idea: there are a quite a lot of video drivers in the kernel > source tree. Do you have a suggestion for how to evaluate which ones > rely on the setup performed by probe_roms?
Realistically - intel, radeon and nouveau. Basically, anything that calls pci_map_rom() and is under drivers/gpu/drm. I'll look into a patch that does that.
-- Matthew Garrett | mjg59@srcf.ucam.org
| |