On Wed, Nov 28, 2018 at 12:14:07PM +0100, Laszlo Ersek wrote:
Right. Before I raised my short question about *not* short-circuiting get_pnp_rom() with "isvga" set, I had read through the BZ, and I was *very* tempted to say "this is what's wrong with our industry". :) The oprom in question is mind-bogglingly broken, from the discussion / analysis in the BZ.
(I'm sure somewhere deep in an internal bug tracking system at the card vendor there is a ticket about some broken platform BIOS where the BEV wouldn't work, and they had to hook Int19h.)
Right - fundamental to X86 booting is the idea that firmware developers write code, PC manufacturers write code, peripheral manufacturers write code, and only users test all the code together. It's a broken workflow. It's been nearly 40 years and X86 is still stuck in this broken workflow.
I'm leery of making a change like this, because there's a good chance it will break something in some other obscure software.
I've added a rather verbose message printing some information about the rom because of that.
I think fixing this in iPXE would be preferable if possible.
See above. ipxe doesn't need fixing.
I support the addition of this "safety code", and I tend to agree (with the BZ discussion) that making it *dynamically* configurable could be difficult and/or overkill.
Kevin, would you feel easier about the Int19h vector restoration if it were controlled by a new, static, config knob?
If we could do it safely that would be fine. My fear is that it introduces a regression. A new config option would be okay, but it doesn't sound like that will help, as it seems that once one narrows down the problem to a bad behaving optionrom, one could just as easily block that optionrom instead..
I'm not sure what the best choice is.
-Kevin