[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


  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Guy Zana" <guy@xxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.