> I agree the current model has implicit priorities.
>
> But I am a little bit skeptical how the priority argument. As far as
> I understand, in Xen or in Linux first asked is first priority.
Yes, here we see 3 concerns about priority:
1: When multiple IRQs arrive at same time, higher priority one get
earlier serviced in native. In xen event channel, higher priority IRQ
can have higher priority event channel. So they are basically same.
2: A lower IRQ arrives first, then followed by an high priority IRQ.
In this case, the situation is relative complicate. If the duration is
big enough, yes the first asked is serviced. If the duration is small,
then later one may preempt the first one. In virtual machine
environment, the time is virtualized. So no matter which one is service
first has no correctness issue (you can think the virtual duration maybe
big maybe large).
3: A higher IRQ arrives first, then followed by an lower priority IRQ.
In this case, higher IRQ must be serviced earlier than lower one. Xen
event channel search the highest priority IRQ and do service. At service
time, the callbreak is masked but the event can still be set. So a lower
IRQ can't interrupt higher one. Semantics are guaranteed.
>
>> All in all, above long context is just one factor that I view to
>> choose the proper mechanism. :-)
> If you are that worried about priorities, we way find solution in the
> current scheme. I'd just like to understand why priorities are that
> important.
These are all corner cases that we must consider as product, but at
early development we can take shortcut like using pseudo IRQ for event
channel here to let the whole project go ahead. And this is what we
talked at xensummit, people (Dan, Ian, Keir, Jun) all have no object for
potential issue concerns (for example mask/unmask support and priority
issue) and agree to take next. PPC guy also uses pseudo physical IRQ for
event channel as I remembered. Their community is much smaller than us
now and their development is also lagger than IA64.
This is why we need to clean up now as callback based event channel
approach has already been in production stage. Making a new mechanism
has high risk.
BTW, even with this strong event channel mechanism in Xen, we sometime
saw bugs in xen-devl such as a deadlock in a VMX SMP system like Xin
rootcaused before new year. But anyway it is very few now.
Eddie
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home