[Xen-ia64-devel] Ia64 arch_vcpu_info_t merge follow-up

["Yang, Fred" <fred.yang@xxxxxxxxx>]

Hi, Dan,
        We have removed all common changes based on the new design,
which also reduce xeno change somehow.

        The core change is as following:
typedef struct {
        mapped_regs_t *privregs;
        int evtchn_vector;
} arch_vcpu_info_t;

        We have also checked in all modifications of Xen side into Intel
staging tree:
http://xenbits.xensource.com/ext/xen-ia64-unstable-Intel.hg, also
including:
        - Fix "complete rebuild for every file change" issue
        - Fix rsm.be emulation, which is seen in fast syscall path
        - Kregs change (seems you didn't check in)
        - A minor fix to bring ns16550 back on tiger4.

        Please pull that staging tree and check whether matching your
thought now.

        Because there's no staging tree for xenolinux, We  only attached
the change made so far.  Then there's no change to evtchn code now, due
to above change. 
        Another fix is included to solve KR emulation on fast syscall
path. (BTW, seems tiger defconfig also not checked in xenlinux yet;-)

        Together with a minor workarounds in libxc (on top of your
xc.patch.3), we can boot xen0 + xenU simultaneously again.

        Currently the major issue We are not sure is whether current
code can handle two level pointers in same hypercall? If both trigger
page fault, can it forward progress? This uncertainty is the reason why
we use a workaround in libxc. However all these issues are just actually
subsequent efforts if you agree this approach and patch can get in. 

Thanks,
-Fred

Attachment: patch_vcontext_merge_xeno
Description: patch_vcontext_merge_xeno

Attachment: patch_vcontext_merge_libxc
Description: patch_vcontext_merge_libxc

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