xen-devel
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, (continued)
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Kay, Allen M
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Guy Zana
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d,
Tian, Kevin <=
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Guy Zana
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Guy Zana
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Kay, Allen M
|
|
|