* [Qemu-devel] BIOS checksums? @ 2004-06-21 15:04 Hetz Ben Hamo 2004-06-21 14:29 ` Piotr Krysik 0 siblings, 1 reply; 6+ messages in thread From: Hetz Ben Hamo @ 2004-06-21 15:04 UTC (permalink / raw) To: qemu devel Mailing list Hi, Since Fabrice opened the possibility to replace BIOSes, I decided to play a bit with few of them on QEMU. All of them seems to return one problem - Checksum error. I tried some Phoenix BIOSes, Award, MR. Bios - all with the same problem (some just giving a ROM checksum error messages, other simply doesn't show anything) All the BIOSes I tried are from the boards who supported pentium pro.. Have anyone had better luck? I'll be happy to provide links to some BIOSes (all from their vendors) Thanks, Hetz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] BIOS checksums? 2004-06-21 15:04 [Qemu-devel] BIOS checksums? Hetz Ben Hamo @ 2004-06-21 14:29 ` Piotr Krysik 2004-06-21 14:33 ` Gianni Tedesco 0 siblings, 1 reply; 6+ messages in thread From: Piotr Krysik @ 2004-06-21 14:29 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1278 bytes --] Hi, Are you talking about using proprietary closed-source BIOS-es of real PC? They are usually very hardware-depended. In fact I started a project to use QEMU to monitor interactions between guest OS and real hardware (similar to "PCI Host/Proxy" by Gianni Tedesco, but not limited to PCI hardware). At this point I have prof of concept prototype that successfully boots proprietary BIOS of my PC up to the point of testing the RAM. Regards, Piotrek Hetz Ben Hamo <hetz@witch.dyndns.org> wrote: Hi, Since Fabrice opened the possibility to replace BIOSes, I decided to play a bit with few of them on QEMU. All of them seems to return one problem - Checksum error. I tried some Phoenix BIOSes, Award, MR. Bios - all with the same problem (some just giving a ROM checksum error messages, other simply doesn't show anything) All the BIOSes I tried are from the boards who supported pentium pro.. Have anyone had better luck? I'll be happy to provide links to some BIOSes (all from their vendors) Thanks, Hetz _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! [-- Attachment #2: Type: text/html, Size: 1711 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] BIOS checksums? 2004-06-21 14:29 ` Piotr Krysik @ 2004-06-21 14:33 ` Gianni Tedesco 2004-06-21 22:10 ` Piotr Krysik 0 siblings, 1 reply; 6+ messages in thread From: Gianni Tedesco @ 2004-06-21 14:33 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1034 bytes --] On Mon, 2004-06-21 at 07:29 -0700, Piotr Krysik wrote: > Are you talking about using proprietary closed-source BIOS-es of real > PC? They are usually very hardware-depended. > > In fact I started a project to use QEMU to monitor interactions > between guest OS and real hardware (similar to "PCI Host/Proxy" by > Gianni Tedesco, but not limited to PCI hardware). At this point I have > prof of concept prototype that successfully boots proprietary BIOS of > my PC up to the point of testing the RAM. Sounds very interesting, are you doing this just generically by just hooking up virtual i/o ports to real ones? I guess to get a BIOS running it takes more than that? Doesn't the BIOS use the PMC config space to query DRAM bank layout? If so that shouldn't be too difficult to modify hw/pci.c to do the right thing(tm).... -- // Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] BIOS checksums? 2004-06-21 14:33 ` Gianni Tedesco @ 2004-06-21 22:10 ` Piotr Krysik 2004-06-22 17:35 ` Gianni Tedesco 0 siblings, 1 reply; 6+ messages in thread From: Piotr Krysik @ 2004-06-21 22:10 UTC (permalink / raw) To: qemu-devel Hi, A few words about the architecture. As I mentioned, I'm trying to use QEMU to monitor interactions between guest OS and real hardware. To avoid interactions between guest and host OS, I decided to run QEMU _without_ OS. It's started by boot loader. The QEMU log is send to another machine. The other machine can also be used to run remote gdb. 1. IO QEMU uses serial port to communicate with the other machine. There are also some other ports that should be protected from access by code executed in the emulator, as they may interact with QEMU (e.g. CPU reset, DRAM Controller reprogramming). All the other emulated IO ports are hooked to real machine. I'm emulating some of the protected IO ports. 2. Memory I have to reserve some memory for QEMU. I'm allocating some MB of top of RAM. The rest is visible to guest OS with it's real address (addresses used by emulated CPU is identical to addresses used by hardware), so it should be possible to use DMA without translating addresses. Also I don't have to treat memory mapped hardware in any special way. The QEMU area is not visible to emulated CPU, so it's protected from direct access by guest OS. It could be accessed by DMA (e.g. broken drivers). If such (unlikely) case is discovered, it can be handled by intercepting and modifying IO or memory access used to setup that DMA. To run BIOS, I had to intercept some IO that tried to reprogram RAM Controller. 3. CPU QEMU runs in real mode with 32-bit addressing. All the interrupts are redirected from host hardware to QEMU by IRQ handler calling cpu_interrupt. Guest OS uses emulated CPU provided by QEMU:-) I'm protecting real CPU from switching A20 and reset, and redirect them to emulated CPU. To run BIOS, I had to disable SMM (System Management Mode) by reprogramming ACPI, emulate self-test of Keyboard Controller and intercept IO access to ACPI and an unknown device at 0x03fX. After QEMU is started it's possible to: * reset some hardware and restart BIOS or * reload boot sector and start guest OS. It's not possible to build generic emulator capable of restating BIOS. My prototype runs 440BX-based PC with Award-based BIOS. The BIOS successfully reprograms emulated DRAM Controller, test interrupts, initializes PCI, etc. It's stating to test RAM and then goes into BIOS setup (I didn't discover the reason yet, but suspect timing). Emulating BIOS restart can be used to monitor interactions between BIOS and hardware during system start-up. And the mechanism is not limited to PC. Reloading boot sector and starting guest OS without restarting BIOS should remove most of chipset and BIOS dependencies. My prototype is capable to run Linux up to the point of login prompt, but keyboard is not functioning (my interrupt handler is not 100% correct). This mode was tested only with QEMU emulated hardware -- I run Linux inside my prototype inside QEMU inside Linux. BTW. What is "PMC config space"? Did you mean DIMM Serial Presence Detect? Regards, Piotrek --- Gianni Tedesco <gianni@scaramanga.co.uk> wrote: > On Mon, 2004-06-21 at 07:29 -0700, Piotr Krysik > wrote: > > Are you talking about using proprietary > closed-source BIOS-es of real > > PC? They are usually very hardware-depended. > > > > In fact I started a project to use QEMU to monitor > interactions > > between guest OS and real hardware (similar to > "PCI Host/Proxy" by > > Gianni Tedesco, but not limited to PCI hardware). > At this point I have > > prof of concept prototype that successfully boots > proprietary BIOS of > > my PC up to the point of testing the RAM. > > Sounds very interesting, are you doing this just > generically by just > hooking up virtual i/o ports to real ones? I guess > to get a BIOS running > it takes more than that? > > Doesn't the BIOS use the PMC config space to query > DRAM bank layout? If > so that shouldn't be too difficult to modify > hw/pci.c to do the right > thing(tm).... > > -- > // Gianni Tedesco (gianni at scaramanga dot co dot > uk) > lynx --source www.scaramanga.co.uk/scaramanga.asc | > gpg --import > 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 > 8646 BE7D > > ATTACHMENT part 1.2 application/pgp-signature name=signature.asc > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] BIOS checksums? 2004-06-21 22:10 ` Piotr Krysik @ 2004-06-22 17:35 ` Gianni Tedesco 2004-06-22 23:31 ` Piotr Krysik 0 siblings, 1 reply; 6+ messages in thread From: Gianni Tedesco @ 2004-06-22 17:35 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 4337 bytes --] On Mon, 2004-06-21 at 15:10 -0700, Piotr Krysik wrote: > Hi, > > A few words about the architecture. > > As I mentioned, I'm trying to use QEMU to monitor > interactions between guest OS and real hardware. > > To avoid interactions between guest and host OS, I > decided to run QEMU _without_ OS. It's started by boot > loader. The QEMU log is send to another machine. The > other machine can also be used to run remote gdb. Nice approach :) > 1. IO > > QEMU uses serial port to communicate with the other > machine. There are also some other ports that should > be protected from access by code executed in the > emulator, as they may interact with QEMU (e.g. CPU > reset, DRAM Controller reprogramming). All the other > emulated IO ports are hooked to real machine. > > I'm emulating some of the protected IO ports. With you. > 2. Memory > > I have to reserve some memory for QEMU. I'm allocating > some MB of top of RAM. The rest is visible to guest OS > with it's real address (addresses used by emulated CPU > is identical to addresses used by hardware), so it > should be possible to use DMA without translating > addresses. Also I don't have to treat memory mapped > hardware in any special way. How is e820 map obtained, would it be possible to intercept that to setup a new reserved area I wonder? ;) An uglier approach would be adding to the e820 map which is presumably stored in the ROM, and fixup the checksum... I wonder if this patch could be made to live inside the qemu tree, sounds invasive? > The QEMU area is not visible to emulated CPU, so it's > protected from direct access by guest OS. It could be > accessed by DMA (e.g. broken drivers). If such > (unlikely) case is discovered, it can be handled by > intercepting and modifying IO or memory access used to > setup that DMA. > > To run BIOS, I had to intercept some IO that tried to > reprogram RAM Controller. Is this because of the way you reserve RAM? > 3. CPU > > QEMU runs in real mode with 32-bit addressing. All the > interrupts are redirected from host hardware to QEMU > by IRQ handler calling cpu_interrupt. Guest OS uses > emulated CPU provided by QEMU:-) > > I'm protecting real CPU from switching A20 and reset, > and redirect them to emulated CPU. > > To run BIOS, I had to disable SMM (System Management > Mode) by reprogramming ACPI, emulate self-test of > Keyboard Controller and intercept IO access to ACPI > and an unknown device at 0x03fX. sounds like deep dark stuff, but potentially very useful for reverse engineering purposes such as is needed to create free BIOSes. > After QEMU is started it's possible to: > * reset some hardware and restart BIOS or > * reload boot sector and start guest OS. > > It's not possible to build generic emulator capable of > restating BIOS. My prototype runs 440BX-based PC with > Award-based BIOS. The BIOS successfully reprograms > emulated DRAM Controller, test interrupts, initializes > PCI, etc. It's stating to test RAM and then goes into > BIOS setup (I didn't discover the reason yet, but > suspect timing). Emulating BIOS restart can be used to > monitor interactions between BIOS and hardware during > system start-up. And the mechanism is not limited to > PC. > > Reloading boot sector and starting guest OS without > restarting BIOS should remove most of chipset and BIOS > dependencies. My prototype is capable to run Linux up > to the point of login prompt, but keyboard is not > functioning (my interrupt handler is not 100% > correct). This mode was tested only with QEMU emulated > hardware -- I run Linux inside my prototype inside > QEMU inside Linux. So when do we see the patches? ;)) > BTW. What is "PMC config space"? Did you mean DIMM > Serial Presence Detect? In the PCI configuration space of the PCI controller itself (0:0.0) are contained registers such as: DRAM Row Type DRAM Control DRAM Timing DRAM Row Boundary Fixed DRAM Hole Control SMRAM Control But as I see now, these values are programmed in to the PMC by the BIOS, duh. -- // Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] BIOS checksums? 2004-06-22 17:35 ` Gianni Tedesco @ 2004-06-22 23:31 ` Piotr Krysik 0 siblings, 0 replies; 6+ messages in thread From: Piotr Krysik @ 2004-06-22 23:31 UTC (permalink / raw) To: qemu-devel --- Gianni Tedesco <gianni@scaramanga.co.uk> wrote: > On Mon, 2004-06-21 at 15:10 -0700, Piotr Krysik > wrote: > > 2. Memory > > > > I have to reserve some memory for QEMU. I'm > > allocating some MB of top of RAM. The rest is > > visible to guest OS with it's real address > > (addresses used by emulated CPU is identical > > to addresses used by hardware), so it should > > be possible to use DMA without translating > > addresses. Also I don't have to treat memory > > mapped hardware in any special way. > > How is e820 map obtained, would it be possible to > intercept that to > setup a new reserved area I wonder? ;) > > An uglier approach would be adding to the e820 map > which is presumably > stored in the ROM, and fixup the checksum... It should be possible to modify op_raise_interrupt to handle int15/e820 as a special case for emulated CPU. I didn't implement it yet. For my Linux exercise with Bochs BIOS I just modified CMOS-stored memory size. BIOS did the rest:-) > > The QEMU area is not visible to emulated CPU, so > > it's protected from direct access by guest OS. > > It could be accessed by DMA (e.g. broken drivers). > > If such (unlikely) case is discovered, it can be > > handled by intercepting and modifying IO or memory > > access used to setup that DMA. > > > > To run BIOS, I had to intercept some IO that tried > > to reprogram RAM Controller. > > Is this because of the way you reserve RAM? Yes. In QEMU, the emulated CPU does direct access only to memory registered with cpu_register_physical_memory. The rest of CPU address space is handled by unassigned_mem_read/unassigned_mem_write functions (with exception of regions registered with cpu_register_io_memory). For the prototype I register RAM area allocated to guest OS with cpu_register_physical_memory(0, guest_ram_size, 0). The rest of CPU address space is handled by unassigned_mem_read/unassigned_mem_write. In these functions I forward memory access to the real machine (after checking that it doesn't overlap with the emulator). > So when do we see the patches? ;)) At this point it's just quick and dirty prototype not ready for public release. And I don't expect to reach release quality any time soon. As it matures I'd like to release it under GPL (it depends only on libqemu, so I'm not limited to GPL). > > BTW. What is "PMC config space"? Did you mean DIMM > > Serial Presence Detect? > > In the PCI configuration space of the PCI controller > itself (0:0.0) are > contained registers such as: > > DRAM Row Type > DRAM Control > DRAM Timing > DRAM Row Boundary > Fixed DRAM Hole Control > SMRAM Control > > But as I see now, these values are programmed in to > the PMC by the BIOS, > duh. Yes. And I had to intercept and emulate these registers, because at the point BIOS started reprogramming PMC I lost control over emulator. Regards, Piotrek __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-06-22 23:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-06-21 15:04 [Qemu-devel] BIOS checksums? Hetz Ben Hamo 2004-06-21 14:29 ` Piotr Krysik 2004-06-21 14:33 ` Gianni Tedesco 2004-06-21 22:10 ` Piotr Krysik 2004-06-22 17:35 ` Gianni Tedesco 2004-06-22 23:31 ` Piotr Krysik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).