From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bculm-0005fZ-O4 for qemu-devel@nongnu.org; Tue, 22 Jun 2004 19:33:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bcull-0005f7-HO for qemu-devel@nongnu.org; Tue, 22 Jun 2004 19:33:38 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bcull-0005f4-E1 for qemu-devel@nongnu.org; Tue, 22 Jun 2004 19:33:37 -0400 Received: from [216.109.118.97] (helo=web60202.mail.yahoo.com) by monty-python.gnu.org with smtp (Exim 4.34) id 1Bcuk7-0005lJ-Lq for qemu-devel@nongnu.org; Tue, 22 Jun 2004 19:31:55 -0400 Message-ID: <20040622233155.66272.qmail@web60202.mail.yahoo.com> Date: Tue, 22 Jun 2004 16:31:55 -0700 (PDT) From: Piotr Krysik Subject: Re: [Qemu-devel] BIOS checksums? In-Reply-To: <1087925753.30448.15.camel@sherbert> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --- Gianni Tedesco 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