Re: [Xen-ia64-devel] iosapic virtualisation

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Mardi 31 Janvier 2006 20:53, Alex Williamson a Ãcrit :
> 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.
Correct, I will add a check.
(However this can't happen currently, since only dom0 use iosapic).

>       * Please define a couple macros for the offset value used in
>         xen_iosapic_write(), rather than using 0 & 1.
Ok.

>       * There are a couple of debug additions to linux-xen/iosapic.c not
>         enclosed in #ifdef XEN.
Sorry, I will fix that.

>       * 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.
I fully agree on the 'heavy weight' point.
I will create a global map.  I think this point should be revisited when we 
will switch from interrupts to event channel (if we do).

>       * 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.
I don't really understand your point here.
With the patch there is no relations between IOSAPIC vector and domain vector.  
That's the reason why there is an heavy weight look-up.  If we create a 
look-up table (see previous point), we do what you describe here, don't we ?

>       * 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.
Ok.  I think this point is rather moot because linux doesn't read IOSAPIC 
(except version, which is not windowed).  However for completion I will do 
it.

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

Thank you for your comments,
Tristan.


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