[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] [PATCH] Fix domainU boot when VTi domainexists


  • To: "Alex Williamson" <alex.williamson@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
  • Date: Thu, 30 Mar 2006 17:18:54 +0800
  • Delivery-date: Thu, 30 Mar 2006 09:20:20 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcZSfnOa5PniuIKdQ16FJ2nynSl0SQAr7jbg
  • Thread-topic: [Xen-ia64-devel] [PATCH] Fix domainU boot when VTi domainexists

Hi Alex,
        We are sure this patch has no problem except indent issue. According to 
logic, it is necessary in schedule_tial to boot XenU when VTi exists. 
Insteadly, It exposes another vhpt_flush bug in smp environment. We will 
explain it in detail in next patch.

Note: This patch maybe have confilict with Anthony's hash_vtlb patch due to 
modifying the same file. Please help to make them consistent handly:)
Thanks
-Xiantao

> -----Original Message-----
> From: Alex Williamson [mailto:alex.williamson@xxxxxx]
> Sent: 2006年3月28日 23:39
> To: Zhang, Xiantao
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] [PATCH] Fix domainU boot when VTi domainexists
> 
> On Tue, 2006-03-28 at 13:09 +0800, Zhang, Xiantao wrote:
> > Sorry for ugly alignment.
> > Maybe this one will be better:)
> >
> > This patch intends to fix domainU boot after VTi domain booted up.
> > Currently domainU can't boot after domain VTi booted up. The root cause
> > is when VTi domain exists, after DomU createing and being scheduled for
> > first time, context_switch won't be executed completely but through
> > another execution path to leave kernel. So iva and pta can't be switched
> > to domU in this case. This will lead to LP's(run domU) iva and pta point
> > to VTi domain's ivt and pta. So when DomainU boots, domain VTi and
> > domainU will hang on one LP.
> 
>    I'm seeing a regression in domU reboot support w/ this patch.  When I
> reboot domU, I only get this far:
> 
> (XEN) efi.reset_system called ###allocating rid_range, domain
> f000000007ffa1b8: starting_rid=80000, ending_rid=c0000
> (XEN) arch_domain_create: domain=f000000007ffa1b8
> (XEN) arch_set_info_guest
> (XEN) sync_split_caches ignored for CPU with no split cache
> (XEN)  ACPI 2.0=0x698domain mem: type=2, attr=0x8,
> range=[0x0000000000000000-0x0000000000100000) (1MB)
> (XEN) domain mem: type=13, attr=0x8,
> range=[0x0000000000100000-0x0000000000200000) (1MB)
> (XEN) domain mem: type=7, attr=0x8,
> range=[0x0000000000200000-0x000000003fff4000) (1021MB)
> (XEN) domain mem: type=12, attr=0x1,
> range=[0x00000ffffc000000-0x00000ffffffff000) (63MB)
> (XEN) domain mem: type=0, attr=0x0,
> range=[0x0000000000000000-0x0000000000000000) (0MB)
> (XEN)  initrd start 0x0 initrd size 0x0
> (XEN) ia64_handle_reflection: unhandled vector=0x1f
> 
> This leaves domU in a running state, but there's no console output and
> trying to destroy it with xm destroy hangs the box.   Also,
> schedule_tail() is a tab indented function, please try to maintain
> consistency with the existing code when making modifications.  Thanks,
> 
>     Alex
> 
> --
> Alex Williamson                             HP Linux & Open Source Lab

Attachment: fix_domU_boot_after_vti.patch
Description: fix_domU_boot_after_vti.patch

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.