WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] VT/ioemu: vga memory access?

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Subject: Re: [Xen-devel] VT/ioemu: vga memory access?
From: Gerd Hoffmann <kraxel@xxxxxxx>
Date: Tue, 16 May 2006 17:57:14 +0200
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 16 May 2006 08:57:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0BA7FC73@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <907625E08839C4409CE5768403633E0BA7FC73@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.2 (X11/20060411)
  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?
> 
> 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

-- 
Gerd Hoffmann <kraxel@xxxxxxx>
Erst mal heiraten, ein, zwei Kinder, und wenn alles läuft
geh' ich nach drei Jahren mit der Familie an die Börse.
http://www.suse.de/~kraxel/julika-dora.jpeg

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel