[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.