WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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>
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:59:13 +0800
Delivery-date: Thu, 31 May 2007 06:57:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2848E1E.FC6F%keir@xxxxxxxxxxxxx>
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+WeAABwdLMABRnVWAADaM8MAADBqQEAAAbqrA=
Thread-topic: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d
>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年5月31日 21:37
>
>On 31/5/07 14:20, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>>     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.
>
>This is absolutely fine. The virtual wire status will remain HIGH in this
>case, which is correct since the 'runt' LOW pulse on the physical wire
>can
>be ignored. What we are looking for is to track the physical wire status in
>the long run; pulses one way or the other do not matter.
>
>Remember we are talking about *level-triggered* interrupt lines, not
>edge-triggered. This polarity-change trick would not be used, and would
>not
>be necessary, for edge-triggered interrupts. We would EOI the physical
>APIC
>early, before running the ISR, just as usual for edge-triggered interrupts.
>
>Because we are talking about level-triggered interrupts, if the line
>continues to be HIGH after the ISR runs then of course we'll just deliver
>another interrupt straight to the relevant VCPU. That's how
>level-triggered
>interrupts work. :-)
>
> -- Keir

Ha, you're exactly right. I forgot the virtual wire status which will 
anyway result a new virtual interrupt if no new hardware interrupt 
occurs as a de-assert signal. 

But... still one question, seems that current Xen doesn't allow 
multiple end() methods called for one physical interrupt instance, 
while a new physical interrupt will happen only as result of end() 
(EOI for ioapic_new, and unmask RTE for ioapic_old). See below 
case:
        - 1st interrupt is injected and polarity is inverted
        - HVM finishes handle and write EOI to vIOAPIC
                - 1st is deasserted
        - 2nd instance happens
        - that EOI is converted into an invocation to end() method
        - either EOI or unmask RTE is issued to physical IOAPIC
        - No physical interrupt triggered due to inversed polarity
        - a new virtual interrupt is injected at next resume to HVM
        - HVM finishes handle and write EOI to vIOAPIC
                - 2nd instance is deasserted
        - EOI to vIOAPIC gears to end() again

Then it's Xen to decide whether to allow one more end(), does it? 
I think this part may need some change for this 'change polarity' 
Approach, like check on pirq_mask. :-)

BTW, how about the alternative to take guest EOI to vIOAPIC as 
the deassertion hint for assigned device?

Thanks,
Kevin

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