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: Thu, 02 Feb 2006 11:16:45 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 02 Feb 2006 18:26:45 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200602021501.57894.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: <200602021501.57894.Tristan.Gingold@xxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Tristan,

   I took another quick skim through and have a few more comments.  It's
looking good, thanks for all your work here!

        Alex


On Thu, 2006-02-02 at 15:01 +0100, Tristan Gingold wrote:

> -       *pval = ia64_getreg(_IA64_REG_CR_LID);
> +       *pval = vcpu->vcpu_id * 0x01010000;

   A comment describing this magic multiplier might be nice.

> +#ifdef CONFIG_XEN
> +       xen_iosapic_write (rte, IOSAPIC_RTE_HIGH (rte_index), high32);
> +       xen_iosapic_write (rte, IOSAPIC_RTE_LOW (rte_index), low32);
> +#else
> +       iosapic_write(addr, IOSAPIC_RTE_HIGH(rte_index), high32);
> +       iosapic_write(addr, IOSAPIC_RTE_LOW(rte_index), low32);
> +#endif

   Should we make these runtime checks (ie. if (running_on_xen))?  We
may end up with other things that prevent transparent
paravirtualization, but this probably shouldn't.

   Another random idea; it might also be cleaner for eventual upstream
inclusion if the xen code were pushed up into the iosapic_read/write/eoi
functions.  Maybe modify the functions to take an rte instead of the
addr.  Then the running_on_xen or CONFIG_XEN checks could be fairly
consolidated.


> +       else {
> +               /* Interrupt is unmasked.  */
> +               if (intr->low32 & IOSAPIC_MASK) {
> +                       /* And was masked.  */
> +                       rte->vcpu = current;
> +                       rte->vcpu_vec = val & 0xff;
> +                       spin_unlock_irqrestore(&iosapic_lock, flags);
> +                       unmask_vec (rte->xen_vec);
> +               }
> +               else {
> +                       /* Was already unmasked.  */
> +                       if (rte->vcpu->domain != current->domain) {
> +                               spin_unlock_irqrestore(&iosapic_lock,
> flags);
> +                               printf ("Oops: GSI %d is reenabled by
> another"
> +                                       " domain\n", gsi);
> +                       }
> +               }
> +       }

   Is the domain check before unmasking still missing here?  Seems like
this block should be almost a mirror image of the masking block.

-- 
Alex Williamson                             HP Linux & Open Source Lab


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