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
|
Home