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] Event channel vs current scheme speed [wasvIOSAPIC

To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Event channel vs current scheme speed [wasvIOSAPIC and IRQs delivery]
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Fri, 10 Mar 2006 23:46:14 +0800
Delivery-date: Fri, 10 Mar 2006 15:47:41 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZEVuveu9yk7y9WR5CbVmokKU/OJQAAN9xg
Thread-topic: [Xen-ia64-devel] Event channel vs current scheme speed [wasvIOSAPIC and IRQs delivery]
Tristan Gingold wrote:
> Sorry, I was not clear enough.  I agree event channel can mostly
> respect priority.

That is OK, everybody may forget something or ignore something.

> 
> Except clock and IPI, I think Linux doesn't use priority.  I can't
> force a card to have an higher priority than another card.
> Is it right ?
No. Linux well handle this.
In Itanium architecture, IRQ priority is generated in LSPAIC by vector 
number, see SDM2 Table 5-8. In summary, software can program
each RTE on IOSAPIC with certain vector #.  High vector # usually 
means high priority (plus class inf). Then in linux software,
ia64_handle_irq() do like following:
   while (IRQ exist) {
        vector=CR.IVR;
        mask TPR for lower than vector;
        do_IRQ();
        Issue CR.EOI
   }

   Here read IVR get highest priority IRQ and mask lower IRQ using TPR. 
Within do_IRQ(), if a IRQ higher than previous one happens, processor is

interrupted again and reenter  ia64_handle_irq(). So everything turns
fine :-)

    Actually clock and IPI is also handled in this mechanism, they are
equal 
with other IRQs except the vector #.  So you can assign a card with
higher
IRQ # such as for ethernet card, or assign lower one for something like
mouse.


    Current Xen do things similar.

Eddie

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