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: "Guy Zana" <guy@xxxxxxxxxxxx>, "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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 31 May 2007 21:20:40 +0800
Delivery-date: Thu, 31 May 2007 06:18:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <9392A06CB0FDC847B3A530B3DC174E7B02A9577D@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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+WeAABwdLMABRnVWAADaM8MA==
Thread-topic: [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.

[Case two]
        Similar to case one, two PCI devices share one interrupt pin:
___|     1  |_______________________
______________|      2       
    _______    _____________________________
___|        |___|    ^EOI

        - 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.

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


>From: Guy Zana
>Sent: 2007年5月31日 14:05
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>> Keir Fraser
>> Sent: Wednesday, May 30, 2007 10:56 PM
>> To: Kay, Allen M; xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] [VTD][patch 0/5] HVM device
>> assignment using vt-d
>> Actually I also know there are some other patches coming down
>> the pipeline to do pci passthrough to HVM guests without need
>> for hardware support (of course it is not so general; in
>> particular it will only work for one special hvm guest).
>> However, they deal with this interrupt issue quite cunningly,
>> by inverting the interrupt polarity so that they get
>> interrupts on both +ve and -ve edges of the INTx line. This
>> allows the virtual interrupt wire to be 'wiggled' precisely
>> according to the behaviour of the physical interrupt wire.
>> Which is rather nice, although of course it does double the
>> interrupt rate, which is not so great but perhaps acceptable
>> for the kind of low interrupt rate devices that most people
>> would want to hand off to a hvm guest.
>Just FYI.
>Neocleus' pass-through patches performs the "change polarity" trick.
>With changing the polarity, our motivation was to reflect the allocated
>device's assertion state to the HVM AS IS.
>Regarding the performance, using a USB 2.0 storage device (working
>with DMA), a huge file copy was compared when working in
>pass-through, and when working in native (on the same OS), the time
>differences were negligible so I'm not sure yet about the impact of
>doubling the number of interrupts. The advantage of changing the
>polarity is the simplicity.
>Anyways, We'll release some patches during the day so you could give
>your comments.
>Xen-devel mailing list

Xen-devel mailing list