[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:15 > >On 31/5/07 16:10, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > >> 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? > >I didn't realise you were suggesting another mechanism. It's not clear to >me >how it works from the very brief description you give above. Could you >provide an example or two for how your method would work (e.g., one >which >avoids switching polarity, and another where you do end up switching >polarity)? > > -- Keir OK, my rough thought is as below: The reason to change polarity, IMO, is to capture the de-assert edge in the physical wire and then reflect de-assertion into the virtual wire. Then allow the statistics on gsi_assert_count to be updated correctly, when shared with virtual devices in Qemu. My proposal is to take virtual EOI as the de-assertion hint, without any change on physical RTE property like polarity. For example, the flow could be following by keeping a saying hw_assert_status array for all virtual GSIs: (take vioapic for example) - physical interrupt happens, and ->ack() - assert into virtual wire with assert count incremented, and also set hw_assert_status[gsi] - HVM handles the interrupt, and write EOI to vlapic, and then vioapic - vioapic_update_EOI then: - check whether hw_assert_status[gsi] is set, if yes: - invoke __hvm_pci_intx_deassert to decrement the count - ->end() - check whether injecting a new instance based on gsi count (original logic) ->end() may trigger another physical interrupt if physical wire keeps 'high' due to any reason. Of course, some code change may be required to allow hvm_irq logic and vioapic/vpic logic to call each other, like the lock issue. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |