xen-devel
RE: [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:
> PCI-A
> _______
> ___| 1 |_______________________
> PCI-B
> _____________________________
> ______________| 2
> PIN
> _______ _____________________________
> ___| |___| ^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.
Thanks,
Guy.
>
> 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
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, 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
- 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
|
|
|