From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: VT/ioemu: vga memory access? Date: Tue, 16 May 2006 17:57:14 +0200 Message-ID: <4469F65A.9040507@suse.de> References: <907625E08839C4409CE5768403633E0BA7FC73@sefsexmb1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <907625E08839C4409CE5768403633E0BA7FC73@sefsexmb1.amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Petersson, Mats" Cc: Xen devel list List-Id: xen-devel@lists.xenproject.org Hi, >> How is vga vram access handled in the device model? Is there some >> kind of notification system, by mapping those pages read-only, then >> trap and forward any write access to qemu-dm? >=20 > Actually, xen HVM handles all memory mapped IO in the same way - > pages are not present, causing a page-fault and then checking the > address against a "memory mapped IO range" in the function > mmio_space() [I haven't looked inside this function], and if it's a > match it's passed to QEMU via handle_mmio(). I think I found the bug. It's actually in handle_mmio() ;) The "case INSTR_MOVS" has code which deals with page boundaries. The code allways _adds_ the count (ecx) to figure whenever the "repz movsb" crosses a page boundary or not. In case the direction flag is set this isn't correct, it should subtract instead. Subsequently it mis-calculates count, making it _larger_ than it was because the copy wouldn't have crossed a page boundary, leading to the negative ecx value in the register dump ... cheers, Gerd --=20 Gerd Hoffmann Erst mal heiraten, ein, zwei Kinder, und wenn alles l=E4uft geh' ich nach drei Jahren mit der Familie an die B=F6rse. http://www.suse.de/~kraxel/julika-dora.jpeg