H. Peter Anvin wrote: > Jan Kiszka wrote: >> Shall the protection start _before_ INT 19 or somewhere _while_ it is >> processed? I'm asking as extboot redirect the handler and writes to some >> variable in its own handler. If the protection is already active at this >> point, we must move at least one of the variables out of the shadow ROM. >> > > The protection kicks in as the PMM system is torn down, which is done > immediately before INT 19h. So > >>> However, as I did point out in the original comment, there are some >>> BIOSes in the field which uses vectors 0xc0-0xdf as a scratch memory >>> pool -- usually to have somewhere to stash a small stack -- so if you >>> absolutely have to go down this route that range those probably be the >>> safest. An alternative would be to use memory in the BDA in the range >>> 0x4ac-0x4ff (absolute), which appears to be available for BIOS-specific >>> uses. >> No problem moving to 0xc0 vectors if we have to (though my PC interrupt >> vector docs all state that already 0x80 is BIOS/BASIC domain). >> >>>>> NEITHER OF THESE OPTIONS ARE SAFE ON REAL HARDWARE << >>> These are both BIOS-specific use areas. >>> >> Extboot is not targeting real hardware. It is built for a paravirtual >> interface to QEMU. >> > > Actually, extboot, or at least one variant of it, is used on real > hardware in the gPXE stack. Nothing that says it has to be identical > code, of course. > > For the Qemu case it sounds like the easiest thing is to just reserve > two dwords in the BIOS Data Area that your BIOS doesn't use. Actually, I'm still in favor of proper (Sea)BIOS support for virtio and scsi, either via the paravirt port 0x405 and its qemu backend or via minimalistic support of the hardware directly in the BIOS. That would free us from all those hooking and unhooking dances at least. Kevin, Anthony, and all others: what is now the merge road map for the bootable scsi/virtio feature? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
