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