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

RE: [Xen-devel] [VTD][PATCH] Support intra-domain shared interrupt


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Han, Weidong" <weidong.han@xxxxxxxxx>
  • Date: Mon, 5 Nov 2007 23:21:59 +0800
  • Cc: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
  • Delivery-date: Mon, 05 Nov 2007 07:22:58 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcgfbbYOsSWYB6MMQDuBGkYt+XjCJwAEwx4KAAASPxAAAXKGpgAAClDAAAJfMewACx+7IA==
  • Thread-topic: [Xen-devel] [VTD][PATCH] Support intra-domain shared interrupt

Keir Fraser wrote:
> On 5/11/07 08:52, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
> 
>> that situation two devices with different pyhsical IRQs getting
>> aliased to the same guest GSI is hard to occur. And we need one
>> guest GSI mapped to only one physical IRQ, or we can't know which
>> device issues the guest GSI. Ideally, if we can make 1:1 mapping
>> between guest GSI and physcial IRQ, the intra-domain shared
>> interrupt can naturally handled by guest. 
> 
> Ah, that's true. I suppose you can assign virtual devfn locations for
> devices to purposely avoid aliasing in GSI space. What do you do about
> aliasing into the ISA IRQ space?
> 

I map device/intx to link, and then map to the isa irq of the link. When
link route is updated, device/intx will map to the new isa irq of the
link. But due to different links may be set the same  isa irq, it can't
guarantee that one guest isa irq maps to only one device/intx. So now I
don't have a good solution to avoid aliasing into the ISA IRQ space.

-- Weidong

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


 


Rackspace

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