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