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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

All Intel VTi-merge patches are now in the xen-ia64-unstable.hg
and xelinux-ia64-2.6.12.hg trees.

Congratulations to everyone who contributed!

Matt's libxc patch (with Kevin's VTI fixes) will be submitted
shortly to Keir.  Hopefully that will go in cleanly.

Now that the merge patch is in, I have to devote some time to some
other activities, so please refrain from a barrage of follow-on
patches :-)

Dan

> -----Original Message-----
> From: Yang, Fred [mailto:fred.yang@xxxxxxxxx] 
> Sent: Thursday, July 28, 2005 10:22 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Ia64 arch_vcpu_info_t merge follow-up
> 
> 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
> 
> 

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