RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable

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

Agreed.  We could funnel all Xen pal calls through
a common routine that uses the lazy method too, but
we will leave your fix (eager in new_rr7) in and
revisit it in the future if/when we get to tuning
the context switch code for performance.

Dan 

> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx] 
> Sent: Thursday, October 13, 2005 11:50 PM
> To: Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make 
> xen0 more stable
> 
> After further thought, I have below concern.
> If real PAL call is called, only when guest is executing PAL 
> call, lazy PAL mapping is a good method. But HV may call PAL 
> call itself. On vti-domain, HV will call PAL_PTCE_INFO PAL 
> call to get purge local tc info to purge local tc. Yes, HV 
> can get PAL_PTCE_INFO in advance to avoid this issue. But HV 
> may call other PAL call directly. Eg. if VMM supports power 
> management, HV may call PAL_HALT or PAL_LIGHT_HALT. So it's 
> better to keep eager mapping.
> 
> >-----Original Message-----
> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Xu, Anthony
> >Sent: 2005å10æ14æ 10:26
> >To: Magenheimer, Dan (HP Labs Fort Collins)
> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xen-ia64-devel] [PATCH] fixed some bugs to 
> make xen0 more stable
> >
> >Yes, I think we can use lazy PAL mapping, for meeting 
> deadline, we didn't
> >carefully consider this.
> >
> >>-----Original Message-----
> >>From: Magenheimer, Dan (HP Labs Fort Collins) 
> [mailto:dan.magenheimer@xxxxxx]
> >>Sent: 2005å10æ13æ 20:49
> >>To: Xu, Anthony
> >>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>Subject: RE: [Xen-ia64-devel] [PATCH] fixed some bugs to 
> make xen0 more stable
> >>
> >>Thanks!  Looks like you found some very difficult bugs!
> >>
> >>> - Changing lazy PAL mapping switch to eager switch per domain
> >>> switch, since vti domain always depends on pal call.
> >>
> >>Can you explain this?  Aren't PAL calls always intercepted
> >>by Xen even with VTI?  It seems that the lazy PAL mapping
> >>approach should work for VTI also.  It's a shame to spend all
> >>those cycles on every context switch when PAL calls are so rare
> >>(after initial startup anyway).
> >>
> >>Thanks,
> >>Dan
> >>
> >>> -----Original Message-----
> >>> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
> >>> Sent: Thursday, October 13, 2005 3:28 AM
> >>> To: Magenheimer, Dan (HP Labs Fort Collins)
> >>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> Subject: [Xen-ia64-devel] [PATCH] fixed some bugs to make
> >>> xen0 more stable
> >>>
> >>> Dan,
> >>>
> >>> When we debugged VTIdomainN, we found and fixed some bugs.
> >>> This patch is based on ver 7332
> >>>
> >>> - Consistence of region id mangling algrithm:
> >>>     - Metaphysical RID is not mangled, which may conflict
> >>> with other domain's virtual RID
> >>>     - Sometimes rr0 is mangled, but sometimes not
> >>>     - Sometimes only rid value is saved to
> >>> saved_rr0_metaphysical, but sometimes the whole value.
> >>>
> >>> - Nat bit consumption happens but handled as priv_emulate to
> >>> forward progress.But this is definitely wrong. We found
> >>> reason of nat consumption from fast_rfi,which doesn't save
> >>> unat again after spill guest states, and then use guest unat
> >>> to fill guest states when return.
> >>>
> >>> - In some corner case, timer interrupt handler won't update
> >>> itm and then return directly. When that happens, machine
> >>> timer interrupt disappears until guest timer interrupt sets
> >>> v_itm actively. But vti domain depends on ac_timer while the
> >>> latter will stop when above condition happens. Then if
> >>> current context is vti domain, context switch disappears and
> >>> machine halt.
> >>>
> >>> Also many compatibility issues to support non-vti and vti
> >>> domain are solved,eg:
> >>> - Changing lazy PAL mapping switch to eager switch per domain
> >>> switch, since vti domain always depends on pal call.
> >>> - evtchn_notify should also vcpu_wake target domain, since
> >>> vti domain may block for io emulation. Xenolinux is free of
> >>> this issue, since it's always runnable.
> >>>
> >>>
> >>> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
> >>> Signed-off-by Anthony Xu <anthony.xu@xxxxxxxxx>
> >>>
> >>>
> >>> Thanks
> >>> Anthony
> >>>
> >>>
> >
> >_______________________________________________
> >Xen-ia64-devel mailing list
> >Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-ia64-devel
> 

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