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] iosapic virtualisation

To: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Subject: Re: [Xen-ia64-devel] iosapic virtualisation
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Tue, 31 Jan 2006 12:53:49 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 31 Jan 2006 20:03:42 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200601311229.57905.Tristan.Gingold@xxxxxxxx>
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>
Organization: LOSL
References: <200601311229.57905.Tristan.Gingold@xxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2006-01-31 at 12:29 +0100, Tristan Gingold wrote:
> Hi,
> 
> here is the path for iosapic virtualisation.
> Currently this is just for review and comments.

Hi Tristan,

   Looks pretty good.  A few comments:

      * The unmask patch of iosapic_guest_write() doesn't check the
        domain before unmasking. Looks like maybe we could unmask
        interrupts on the wrong domain.
      * Please define a couple macros for the offset value used in
        xen_iosapic_write(), rather than using 0 & 1.
      * There are a couple of debug additions to linux-xen/iosapic.c not
        enclosed in #ifdef XEN.
      * The vector-to-rte lookup in xen_reflect_interrupt_to_domain()
        looks rather heavy weight.  It seems like we should be able to
        construct the data structures for a direct look up here.  I
        don't think we can afford to scan the rte list for every
        interrupt.
      * Assigning vectors as defined by the domain; I think this is
        covered by some of the comments included about future problems,
        but maybe we should address this one now.  We should probably
        start out with separate vector spaces between xen and each
        domain and keep a mapping table between xen vectors (ie. what's
        actually programmed into the IOSAPIC RTE) and what the domains
        tried to program via iosapic_guest_write().  It's probably
        reasonable to assign xen vectors from highest to lowest such
        that xen will end up with the highest priority external
        interrupts, dom0 the next highest, and so on.
      * We need to paravirtualize reads of the IOSAPIC as well as
        writes.  Since the IOSAPICs use a windowing register scheme, a
        domain reading an IOSAPIC could interfere with Xen writing or
        cause races with other domains.  This will also enable us to
        hide the physical IOSAPIC structure if we need to at some point.

I'll see if I can get this to build and run on my box.  Thanks,

        Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


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

<Prev in Thread] Current Thread [Next in Thread>