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][RESEND]add a timer for the shared interrupt issue f

To: "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel][VTD][RESEND]add a timer for the shared interrupt issue for vt-d
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 18 Oct 2007 10:35:56 +0100
Delivery-date: Thu, 18 Oct 2007 02:36:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <9A1462408D6D394C8A7A812E98F00A4D0226A2DA@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: AcgQw+ProgCV0z3VTpKlJoAxcNdgrQApmSLp
Thread-topic: [Xen-devel][VTD][RESEND]add a timer for the shared interrupt issue for vt-d
User-agent: Microsoft-Entourage/11.3.6.070618
Getting better, some more points:
 1. The timeout values are bizarrely non-round (8192000). Do you really need 4 significant figures of precision? Do you really mean for an 8ms timeout? It would then be better to define as MILLISECS(8). Much clearer as it shows the units.
 2. You can’t stick timer_hvm[] in the generic common domain.c. It belongs in the hvm_irq_dpci structure, making it clear it is HVM-specific, and also meaning that memory for the array is only allocated for those domains that actually have devices passed through to them.
 3. The extra argument to hvm_dpci_eoi() is used only to decide whether to stop_timer() or not. You’re aware you can call stop_timer() quite safely from within the timeout callback handler? I think that means this extra argument is unnecessary.
 4. The comment added to hvm_pci_intx_assert() is delightfully vague. Also I think it may be wrong — do you really mean “before the driver loading, the vioapic redir entry may be unmasked”?

So you need another spin. I’m still unconvinced that the hvm_pci_intx_assert() changes are the right way to go, but I need to consider the patch some more to see if there is a cleaner way. If there is I will modify the patch myself before I check it in. The other points listed above you need to address yourself.

 -- Keir

On 17/10/07 14:44, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx> wrote:

Keir,
It’s a resending patch for the timeout mechanism to deal with the shared interrupt issue for vt-d enabled hvm guest.
We modify the patch following your comments last time and make some other small fix:
1)
      We don’t touch the locking around the hvm_dpci_eoi().
2)
      Remove the HZ from the TIME_OUT_PERIOD macro which may confuse others.
3)
      Add some explanation to the return value for the hvm_pci_intx_assert(), and the has_timer parameter for the hvm_dpci_eoi.
We have tested it with shared interrupt between dom0/HVM(pcie/disk) and HVM/HVM(pcie/pcie).
 
Signed-off-by: Xin, Xiaohui<xiaohui.xin@xxxxxxxxx
Signed-off-by: Kevin Tian <kevin.tian@xxxxxxxxx>

 


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

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