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

RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d



>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年5月31日 23:03
>
>On 31/5/07 14:59, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> But... still one question, seems that current Xen doesn't allow
>> multiple end() methods called for one physical interrupt instance,
>> while a new physical interrupt will happen only as result of end()
>> (EOI for ioapic_new, and unmask RTE for ioapic_old). See below
>> case:
>
>Yeah, well I haven't looked at how the Neocleus patches actually deal
>with
>this, but I expect they might steal hvm-bound physical irqs completely,
>hook
>them off early in do_IRQ() and have bespoke code to deal with them.
>Possibly
>it could be integrated with existing ->ack and ->end methods, actually.
>->end() would be no-op while ->ack() would switch polarity in the IOAPIC
>and
>then EOI the LAPIC. Then the handler function called by do_IRQ() would
>toggle virtual HVM wires.
>
>Anyhow, integrating with existing Xen IRQ handling subsystem clearly
>isn't a
>rocket-science problem. :-)
>

Sure. :-) But I'm still thinking the effect to use virtual EOI as de-assertion 
signal, which doesn't require to change polarity in the line frequently. We 
can just add a flag per gsi to indicate whether a physical irq is injected 
on this line. When intercepting HVM EOI, invoke deassert and also jump 
to ->end() if flag is on. Does it work basically?

Thanks,
Kevin

_______________________________________________
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®.