WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [RFC][PATCH] hypercall_preempt_check() andpsr.i

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [RFC][PATCH] hypercall_preempt_check() andpsr.i
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Thu, 30 Mar 2006 10:32:21 +0900
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 30 Mar 2006 01:33:44 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E7A23@pdsmsx403>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <571ACEFD467F7749BC50E0A98C17CDD8094E7A23@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
Hi.

I think Kevin's patch is better.
In fact my patch was a hack. So I called it work around and used RFC.

- I wanted to work on balloon driver instead of this issue.
- Event channel would be changed.
  I hoped the change will solve the issue when I posted my patch.
  But Kevin solved it.

thnaks.

On Thu, Mar 30, 2006 at 09:04:05AM +0800, Tian, Kevin wrote:
> >From: Alex Williamson [mailto:alex.williamson@xxxxxx]
> >Sent: 2006年3月30日 2:55
> >On Wed, 2006-03-29 at 22:14 +0800, Tian, Kevin wrote:
> >> Hi, Isaku,
> >>    Seems we're shooting same issue by different way. In the
> >beginning,
> >> I also came up same simple approach as yours. However after more
> >> thinking, I think it's better to tune xen/ia64 to adapt to common concept
> >> where evtchn_upcall_mask is the flag whether events/interrupts can be
> >injected into guest. Or else we have to add similar #ifdef as yours time to
> >> time, which especially only be observed when important bugs are
> >tracked
> >> down after many debugs.
> >
> >   The simplicity and compact-ness of Isaku's patch is certainly
> >appealing.  What if instead of fixing this one case with a #ifdef we
> >were to something like this:
> >
> >#define event_pending(v)                         \
> >    ((!!(v)->vcpu_info->evtchn_upcall_pending &  \
> >       !(v)->vcpu_info->evtchn_upcall_mask)) &&  \
> >      arch_event_pending(v))
> >
> >x86:
> >
> >#define arch_event_pending(v) (1)
> >
> >ia64:
> >
> >#define arch_event_pending(v) (PSCB(v, interrupt_delivery_enabled))
> >
> >Thanks,
> >
> >    Alex
> >
> 
> Yes, I agree Isaku's patch is simpler, which however still leaves window 
> for similar bug to jump out in the future. If we still keep two flags:
>       - There're other common places to operate evtchn_upcall_mask 
> directly, which should be changed like this too
>       - This breaks VTI domain, since VTI domain has no separated 
> interrupt enable bit (instead a full PSR)
>       - Most important, as I said in another paragraph, soon we'll change 
> the model to event channel mechanism where external interrupt is 
> eliminated and all pirq/virq/ipi are bound to events. At that time, two 
> similar flags can't be updated atomically and dangerous window may be 
> left there.
> 
> Due to above reasons, there's no need to change common code since 
> finally there'll be no difference from xen/ia64 side. 
> 
> Maybe I should put it in this way, my patch is bigger as a necessary step 
> to merge two flags for correctness issue which is required by coming 
> event channel changes. As a side effect, that bug is also solved. :-)
> 
> Thanks,
> Kevin
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel
> 

-- 
yamahata

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

<Prev in Thread] Current Thread [Next in Thread>