Re: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu error

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

Could you try the following patch to ioemu?
NOTE:This is only a band aid patch. GFW needs modifcation.

ioemu: prevent qemu-dm segv.

With dade7f0bdc8d and old bios, qemu-dm results in segv.

Signed-off-by: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>

diff -r 9b5e1e05e886 tools/ioemu/hw/cirrus_vga.c
--- a/tools/ioemu/hw/cirrus_vga.c       Mon Sep 01 17:50:13 2008 +0900
+++ b/tools/ioemu/hw/cirrus_vga.c       Fri Sep 05 12:42:37 2008 +0900
@@ -2553,7 +2553,11 @@
         end = begin + VGA_RAM_SIZE;
 
     fprintf(logfile,"mapping vram to %lx - %lx\n", begin, end);
-
+    if (!s->vram_mfns) {
+        fprintf(logfile, "Found old firmware skiping mapping vram\n");
+        return;
+    }
+    
     xatp.domid = domid;
     xatp.space = XENMAPSPACE_mfn;
 


On Fri, Sep 05, 2008 at 11:32:28AM +0900, Isaku Yamahata wrote:
> On Tue, Sep 02, 2008 at 03:02:20PM +0800, Zhang, Jingke wrote:
> > Zhang, Jingke wrote:
> > > Isaku Yamahata wrote:
> > >> On Tue, Sep 02, 2008 at 11:22:27AM +0800, Zhang, Jingke wrote:
> > >>> Hi all,
> > >>>     We found all the VTI guests can not be booted up with this
> > >>>     Cset#18421 (XenU can boot). Last test on Cset#18369 is good to
> > >>> work. The failure is: when we boot up VTI, qemu will show a white
> > >>> box and disappeared after 1 second. I have checked both local ioemu
> > >>> and remote-ioemu, they both can not work. Did anyone find this by
> > >>> using latest Xen-ia64?
> > >>
> > >> Hmm, I'm afraid that c/s 18394:dade7f0bdc8d causes it.
> > >> Could you confirm that?
> > >>
> > >> I suppose that even if the window of virtual frame buffer dissapears,
> > >> VTi guest OS is still working and serial console can be accessed.
> > >> If so, GFW should be patched to tell qemu-dm where the virtual frame
> > >> buffer memory is.
> > >
> > > Hi Isaku,
> > >     I checked the console of VTI, it does not work. CPU time always
> > >     stays 0.2 (guest should hang). Anyway, I will try 18394 to narrow
> > > down this issue.
> > >
> > 
> > Hi Isaku,
> >     It should be as you said. 18394 caused the issue. I tested 18394, issue 
> > exists. With 18393, VTI can be booted well. Thanks!
> 
> Hi Zhang.
> I tried to reproduce it.
> With ioemu, I confirmed it.
> qemu-dm died from /var/log/xen/xend.log 
> > model failure: pid 9584: died due to signal 11; see 
> > /var/log/xen/qemu-dm-ExampleVTIDomain.log 
> 
> However with ioemu-remote, I wasn't able to reproduce the issue.
> I couldn't find the corresponding patch looking changelog and source code.
> I checked it with the following repository.
> Am I looking at the wrong tree/branch/changeset?
> 
> repo:
>       http://xenbits.xensource.com/git-http/staging/qemu-xen-unstable.git/
> branch:
>       mater
> HEAD checksum
>       77fba269deee38293b44ba5a1ce7ef4c39482975
> 
> 
> Anyway I expect that the changeset will go to qemu-remote eventually,
> we should address the issue.
> 

-- 
yamahata

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