Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Guy Zana" <guy@xxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 31 May 2007 23:30:08 +0800
Delivery-date: Thu, 31 May 2007 08:28:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C284A4E9.FC99%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acei7YJ0pr6pL1ntT2Wzdmq3YT+WeAABwdLMABRnVWAADaM8MAADBqQEAAAbqrAAAuWvEQAADOZgAABXPZsAAAfH8A==
Thread-topic: [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>