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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@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: "Guy Zana" <guy@xxxxxxxxxxxx>
Date: Thu, 31 May 2007 10:08:56 -0400
Delivery-date: Thu, 31 May 2007 07:10:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F013B1EB0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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+WeAABwdLMABRnVWAADaM8MAACelKA
Thread-topic: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] 
> Sent: Thursday, May 31, 2007 4:21 PM
> To: Guy Zana; Keir Fraser; Kay, Allen M; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [VTD][patch 0/5] HVM device 
> assignment using vt-d
> It does be a 'cunning' approach, which however seems to only 
> apply to interrupt instance with both rising edge and falling 
> edge like:
>     _____________      ______________
> ___|      1        |____|       2        |____________
> Just be curious whether following cases can be addressed, 
> when one edge is missing.
> [Case one]
>       Is it possible for one device to keep line 'high' for 
> two successive instances, like:
>     _________________________________________
> ___|      1        |       2                      ...
>     When driver requests device to clear interrupt assertion 
> at end of handling 1st, it's possible that device keeps 
> assertion if interrupt condition still matches in 2nd. In 
> that case, no interrupt will happen any more when EOI is 
> written to IOAPIC due to polarity inversion.

Since the HVM's assertion state is kept "asserted" until the _external_ line 
'fall', the HVM itself will keep getting interrupts on VMENTRYs, until the 
_external_ line is deasserted (by the external device). This reflects the real 
behavior of the external line.

If this behavior of interrupt is treated differently, you'll get redundant 
interrupts :)

> [Case two]
>       Similar to case one, two PCI devices share one interrupt pin:
>     _______
> ___|     1  |_______________________
>                 _____________________________
> ______________|      2       
>     _______    _____________________________
> ___|        |___|    ^EOI
> If:
>       - Guest finishes invocation to all irq actions hooked 
> to that pin before PCI-B does assertion.
>       - EOI to IOAPIC happens after PCI-B does assertion
> The net effect is that line status keeps 'high' after EOI and 
> polarity inverse makes no interrupt again.

If both devices works in pass-through, it should work, since it is the ORed 
line that is reflected.
We can add functionality for sharing such devices between dom0 and a guest, by 
changing the way dom0 handles level-triggered interrupts.


> Maybe I didn't get the exact detail of your named 'change polarity' 
> idea, and if yes, appreciate your elaboration here. :-)
> Thanks,
> Kevin

Xen-devel mailing list