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-ia64-devel

RE: [Xen-ia64-devel] xencons interrupt problem

To: "Alex Williamson" <alex.williamson@xxxxxx>, "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] xencons interrupt problem
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 26 Jun 2006 10:25:30 +0800
Delivery-date: Sun, 25 Jun 2006 19:25:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaYZhK6AB6g6g8+QSOPrrmNFNgC4QAXeqvQ
Thread-topic: [Xen-ia64-devel] xencons interrupt problem
>From: Alex Williamson
>Sent: 2006年6月25日 22:46
>   I was hoping to enable xencons as the default console, but I've run
>into a problem.  I have a system that has the console UART and core
>I/O
>NIC sharing the same interrupt (both are PCI devices).  The
>ia64_xen_vector bit array does not prevent the guest from writing the
>IOSAPIC RTE value because it's only checking the vector value
>programmed
>into the RTE, not the existing value (ie. Xen programs it to vector 49,
>the guest wants to program it to vector 50, Xen allows the guest write).
>That much seems fairly easily fixable, but how do we allow Xen and
>dom0
>to share an RTE?  We not only need to forward on the interrupt to the
>domain, but we may need to translate it to the vector the guest tried to
>program.  Thanks,
>
>       Alex

Hi, Alex,
        Currently xen irq subsystem doesn't support PCI device to be 
shared between xen and dom0. For example, easy to find some check 
against this scenario like in pirq_guest_bind.

        It easy to fix above checks, like to add an IRQ_BOTH flag on top 
of IRQ_GUEST to allow such a case. However the real issue is that full 
PCI knowledge is owned by dom0 instead of xen. To let xen allocate 
resources for PCI serial and check whether specific irq line is shared 
between, ACPI namespace enumeration and PCI initialization are 
required to be brought back to xen. A big effort and whether worthy of 
doing that? Or some special workaround to bypass that for this special 
serial case?

        For the interrupt name space, currently xen and dom0 share the 
same space, meant that vector allocation always happens in xen and 
dom0 issues hypercall to retrieve allocated vector back as the one used 
in dom0 context directly. Based on this point, xen can ensure same 
vector returned to dom0 as the one owned by xen itself if irq sharing 
happens. But xen needs PCI knowledge as said above.

        Final question is, do we really need support such a PCI serial port 
owned by xen? :-)

Thanks,
Kevin

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