VT/ioemu: vga memory access?

VT/ioemu: vga memory access?

[Gerd Hoffmann]

  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?

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?

cheers,

  Gerd


-- 
Gerd Hoffmann <kraxel@suse.de>
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

RE: VT/ioemu: vga memory access?

[Petersson, Mats]

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] 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@suse.de>
> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 

Re: VT/ioemu: vga memory access?

[Gerd Hoffmann]

  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@suse.de>
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

RE: VT/ioemu: vga memory access?

[Petersson, Mats]

> -----Original Message-----
> From: Gerd Hoffmann [mailto:kraxel@suse.de] 
> Sent: 16 May 2006 16:57
> To: Petersson, Mats
> Cc: Xen devel list
> Subject: Re: [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().
> 
> 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 ...

I think you're right... 

I'll write some simple test code to check it out, and let you know... 

--
Mats
> 
> cheers,
> 
>   Gerd
> 
> --
> Gerd Hoffmann <kraxel@suse.de>
> 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
> 
> 

Re: VT/ioemu: vga memory access?

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

  Hi,

> I'll write some simple test code to check it out, and let you know... 

Fix attached, seems to work ok on a quick test.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
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

[-- Attachment #2: fix --]
[-- Type: text/plain, Size: 968 bytes --]

diff -r be5a6188cd9f xen/arch/x86/hvm/platform.c
--- a/xen/arch/x86/hvm/platform.c	Thu May 11 10:34:34 2006
+++ b/xen/arch/x86/hvm/platform.c	Tue May 16 18:11:57 2006
@@ -865,7 +865,7 @@
          * copy ourself. After this copy succeeds, "rep movs" is executed
          * again.
          */
-        if ((addr & PAGE_MASK) != ((addr + size - 1) & PAGE_MASK)) {
+        if ((addr & PAGE_MASK) != ((addr + sign * (size - 1)) & PAGE_MASK)) {
             unsigned long value = 0;
 
             mmio_opp->flags |= OVERLAP;
@@ -876,7 +876,7 @@
                 hvm_copy(&value, addr, size, HVM_COPY_IN);
             send_mmio_req(IOREQ_TYPE_COPY, gpa, 1, size, value, dir, 0);
         } else {
-            if ((addr & PAGE_MASK) != ((addr + count * size - 1) & PAGE_MASK)) {
+            if ((addr & PAGE_MASK) != ((addr + sign * (count * size - 1)) & PAGE_MASK)) {
                 regs->eip -= inst_len; /* do not advance %eip */
 
                 if (sign > 0)

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: VT/ioemu: vga memory access?

[Keir Fraser]

On 16 May 2006, at 17:20, Petersson, Mats wrote:

>> 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 ...
>
> I think you're right...
>
> I'll write some simple test code to check it out, and let you know...

Hmmm... wouldn't it be nice if we didn't have a bespoke, buggy & 
incomplete emulator for hvm mmio. ;-)

  -- Keir

RE: VT/ioemu: vga memory access?

[Petersson, Mats]

> -----Original Message-----
> From: Gerd Hoffmann [mailto:kraxel@suse.de] 
> Sent: 16 May 2006 17:50
> To: Petersson, Mats
> Cc: Xen devel list
> Subject: Re: [Xen-devel] VT/ioemu: vga memory access?
> 
>   Hi,
> 
> > I'll write some simple test code to check it out, and let 
> you know... 
> 
> Fix attached, seems to work ok on a quick test.

Yes, that looks like what I expected it to look like in the first place...  

I'll still work a little bit on a simple test, because that would help proving corner cases (like a single transfer across page boundary and such things, which probably doesn't happen very often in real-life). 

--
Mats
> 
> cheers,
> 
>   Gerd
> 
> --
> Gerd Hoffmann <kraxel@suse.de>
> 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
> 

RE: VT/ioemu: vga memory access?

[Petersson, Mats]

 

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
> Sent: 16 May 2006 17:58
> To: Petersson, Mats
> Cc: Xen devel list; Gerd Hoffmann
> Subject: Re: [Xen-devel] VT/ioemu: vga memory access?
> 
> 
> On 16 May 2006, at 17:20, Petersson, Mats wrote:
> 
> >> 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 ...
> >
> > I think you're right...
> >
> > I'll write some simple test code to check it out, and let 
> you know...
> 
> Hmmm... wouldn't it be nice if we didn't have a bespoke, 
> buggy & incomplete emulator for hvm mmio. ;-)

Yup, that would be rather nice if we didn't have bugs like this... 

And by the way, I think IOIO is buggy in exactly the same way... 

I'm still working on a test-case that can be used - it'll come in handy
for testing later on when I have FIXED the code by reusing the
x86_emulate.c in QEMU too... 

--
Mats
> 
>   -- Keir
> 
> 
>