This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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-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
>> signal, which doesn't require to change polarity in the line frequently.
>> 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
>> to ->end() if flag is on. Does it work basically?
>I didn't realise you were suggesting another mechanism. It's not clear to
>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
>avoids switching polarity, and another where you do end up switching
> -- 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_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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>