RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

["Guy Zana" <guy@xxxxxxxxxxxx>]

Sort of... Our method might doubles the number of interrupts if both devices 
are connected to the same pin, but since all devices are OR wired, you might 
even "save" *physical* interrupts from happening -> I guess that we'll get a 
decisive answer only after performing some profiling. 

Our method will not work "out of the box" if you're trying to use it when 
sharing a pin between dom0 and an HVM. 
Consider the following scenario:

HVM:
               _____________________
        ____|                                    |___________________

Dom0:
                          ____________________________________
        __________|

Phys Line:
                __________________________________________
        ____|


        A    B         C                       D


In point B you changed the polarity. In point C and D you won't be getting any 
interrupts since of the polarity-change, and the device that is allocated for 
dom0 will keep its line asserted until the dom0 driver will handle the 
interrupt, but it won't get a chance to do so, moreover, the hvm vline will 
still be kept asserted.

We are currently modeling the problem, it seems that it's a complicated 
concept, regardless of changing-polarity. For instance, an HVM with a Linux OS 
will die if 99,900 interrupts out of 100,000 are not handled. 

>From a logical POV, the aforementioned race is solved like this: we can hold a 
>virtual assertion line for _dom0_ (which will be updated by the arrival of 
>interrupts as a result from change-polarity) and concatenate the HVM's ISR 
>chain with dom0's ISR chain, and dom0 must be the first to try handle the 
>interrupt (because of the 99,000 to 100,000 problem), I guess that 
>pass-through shared interrupts probably should be handled as the last 
>(default) function in dom0's ISR chain.

How do you plan to provide interrupts sharing with your method exactly?
Please provide your thoughts.

Thanks,
Guy.

> -----Original Message-----
> From: Kay, Allen M [mailto:allen.m.kay@xxxxxxxxx] 
> Sent: Sunday, June 03, 2007 11:29 AM
> To: Guy Zana; Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [VTD][patch 0/5] HVM device 
> assignment using vt-d
> 
> Base on my understanding of the Neocleus' passthrough patch, 
> it seems all devices sharing that interrupt will get the 
> double number of interrupts.  This means if a interrupt is 
> shared between a NIC device used by a HVM guest and a SATA 
> device used by dom0, the SATA driver in dom0 will also get 
> twice the number of interrupts.  Am I correct?
> 
> Allen 
> 
> >-----Original Message-----
> >From: Guy Zana [mailto:guy@xxxxxxxxxxxx]
> >Sent: Wednesday, May 30, 2007 11:05 PM
> >To: Keir Fraser; Kay, Allen M; xen-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xen-devel] [VTD][patch 0/5] HVM device 
> assignment using 
> >vt-d
> >
> >
> >> -----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.
> >
> >Thanks,
> >Guy.
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel