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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Gerd Hoffmann
> Sent: 16 May 2006 15:44
> To: Xen devel list
> Subject: [Xen-devel] VT/ioemu: vga memory access?
> 
>   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(). 

Note also that if paging isn't enabled (real-mode or some other similar 
situation), any page-fault is unconditonally dealt with by calling 
handle_mmio() without checking if it's a MMIO address - because nothing else 
should give a page-fault in non-paging mode.

> 
> I'm seeing obscure crashes in vga text mode, looks like they 
> are triggered by a memmove in vga vram, at least this is what 
> xenctx prints me:
> 
> 
> master-xen root /vm/hvm# /usr/lib/xen/bin/xenctx 35
> eip: c01a59a9
> esp: cf2dbe58
> eax: c00b99a0   ebx: c00b99a0   ecx: fffff661   edx: c00b9860
> esi: c00b8ec0   edi: c00b9000   ebp: c1207000
>  cs: 00000060    ds: 0000007b    fs: 00000000    gs: 00000033
> 
> Stack:
> failed to map PT
> failed to map page.
> 
> 
> EIP c01a59a9 points into memmove (linux kernel):
> 
> c01a5990 <memmove>:
> c01a5990:       57                      push   %edi
> c01a5991:       39 d0                   cmp    %edx,%eax
> c01a5993:       56                      push   %esi
> c01a5994:       53                      push   %ebx
> c01a5995:       89 c3                   mov    %eax,%ebx
> c01a5997:       73 07                   jae    c01a59a0 <memmove+0x10>
> c01a5999:       e8 ca ff ff ff          call   c01a5968 <memcpy>
> c01a599e:       eb 0c                   jmp    c01a59ac <memmove+0x1c>
> c01a59a0:       8d 74 0a ff             lea 
> 0xffffffff(%edx,%ecx,1),%esi
> c01a59a4:       8d 7c 08 ff             lea 
> 0xffffffff(%eax,%ecx,1),%edi
> c01a59a8:       fd                      std
> c01a59a9:       f3 a4                   repz movsb 
> %ds:(%esi),%es:(%edi)
>                                         ^^^^^^^^^^^^^^^^ here
> c01a59ab:       fc                      cld
> c01a59ac:       89 d8                   mov    %ebx,%eax
> c01a59ae:       5b                      pop    %ebx
> c01a59af:       5e                      pop    %esi
> c01a59b0:       5f                      pop    %edi
> c01a59b1:       c3                      ret
> 
> 
> Note that the edi register points to a page boundary and ecx 
> looks bogous.  Also note that "xm unpause", then xenctx again 
> prints the very same register dump, feels like someone 
> handling a fault incorrectly, leading to the very same fault 
> instantly ...
> 
> Idea anyone what this might be?

It looks like the length for memmove has been calculated incorrectly (negative 
number), and that would move aroung 4GB of memory. 

I can't really explain why b9000 shouldn't be a valid VGA memory page tho'. 
Perhaps it's because the mode of graphics you're in, and that doesn't allow 
more than 4KB of display memory - I'm surprised about that tho'. 

So it's weird that it's haning there... 

--
Mats 
> 
> 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
> 
> 


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