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] [Patch] iosapic virtualization again

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
Subject: RE: [Xen-ia64-devel] [Patch] iosapic virtualization again
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 23 Feb 2006 21:05:47 +0800
Delivery-date: Thu, 23 Feb 2006 13:06: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: AcY4UQPwKlJKMNjTTl6xkLADQjHnLAAAb2vAAAGdedA=
Thread-topic: [Xen-ia64-devel] [Patch] iosapic virtualization again
So basically speaking, "IRQ" should be the basic resource to
be allocated and operated. There's no need to add mask_vec, 
and we can still let irq_to_vector to decide which vector to operate.
By moving that dispatch logic out to irq.c (dispatched in do_IRQ),
actually you can avoid complexity of iosapic to handle shared irq. 
E.g, multiple RTEs may belong to same domain and have same 
guest vector, however your patch didn't handle that:

+       if (offset == XEN_IOSAPIC_EOI) {
+               spin_lock_irqsave(&iosapic_lock, flags);
+               list_for_each_entry (rte, &iosapic->rtes, iosapic_list)
+                       if (rte->vcpu == current && rte->vcpu_vec == val)
+                               break;

Thanks,
Kevin

>From: Tian, Kevin
>Sent: 2006年2月23日 16:46
>>From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>>Sent: 2006年2月23日 16:15
>>> 2. Not sure why you pull in iosapic.h into your patch. Seems no
>>> modification there which just need copy from linux source at compile time.
>>> If you really want to include this file, you can avoid adding
>>> xen_iosapic_write in c file and instead move its content to iosapic_write
>>> defined in iosapic.h
>>I suppose you speak about the iosapic.h for linux.
>
>Yes.
>
>>I have removed the iosapic_version() declaration, since it has been modified
>>and is never used outside iosapic.
>
>Then you should stick to CONFIG_XEN for future track of updates. Also
>since this file is changed, I think you can remove xen_iosapic_write and
>instead extend iosapic_write in iosapic.h to have that check upon
>running_on_xen. This can reduce modifications in iosapic.c to replace
>iosapic_write with xen_iosapic_write. Same goes for read.
>
>>
>>> 4. It's ugly to see:
>>> +#define VCPU_XEN ((struct vcpu *)1)
>>> Also no place to init vcpu with this value, however later it's checked when
>>> reflecting interrupt
>>Maybe I should remove this ?
>>
>
>Yes. There's better way to indicate ownership of the specific vector.
>Xen is started from Linux and then same concept is inherited that
>so-called irq is the basic unit from system point of view. For
>small ia64 system, irq equals to vector but not true for large system.
>So it's natural to have guest indicator at irq level, like in irq_desc
>instead of at lower rte level, since multiple RTEs can be routed to
>same vector/irq.
>
>You can see from linux history, interrupt sub-system evolves from
>initial 80% (maybe inaccurate;-) arch dependent to nowadays 80%
>arch independent. To this point, we should follow common model
>defined in xen world.
>
>See xen/arch/x86/irq.c, which shows you the picture what we suggest
>to follow. ;-)
>
>Thanks,
>Kevin
>
>_______________________________________________
>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