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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> -----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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel