On 11/28/18 07:24, Gerd Hoffmann wrote: > On Tue, Nov 27, 2018 at 09:19:09PM -0500, Kevin O'Connor wrote: >> On Tue, Nov 27, 2018 at 01:10:38PM +0100, Gerd Hoffmann wrote: >>> Check whenever pnp roms attempt to redirect int19, and in case it does >>> log a message and undo the redirect. >>> >>> A pnp rom should not need this, we have BEVs and BCVs for that. >>> Nevertheless there are roms in the wild which are redirecting int19. >>> At least some BIOS implementations for physical hardware have a config >>> option in the setup to allow/disallow int19 redirections, so just not >>> allowing this seems to be the way to deal with this situation. >>> >>> Buglink: https://bugzilla.redhat.com//show_bug.cgi?id=1642135 >> >> That is very odd. I'm pretty sure iPXE normally does register itself >> as a BEV - any idea why it's now hooking int19? > > It's not ipxe. > > It is the rom of a intel nic, attached to a guest via pci passthrough. > It does both, register bev and hook int19. No clue why. The only > reason I can think of is backward compatibility to firmware so old that > it doesn't know pnp roms. Which is a silly thing in pci express > hardware. Maybe they carry forward that code since decades ...
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.) >> 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? Thanks, Laszlo _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
