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
|
|
|