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