[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |