All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Chris Wright <chrisw@sous-sol.org>,
	xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@XenSource.com>
Subject: Re: Physical and dynamic event channels
Date: Fri, 11 Aug 2006 08:04:33 -0700	[thread overview]
Message-ID: <44DC9C81.9040305@goop.org> (raw)
In-Reply-To: <C1020E1C.C3B%Keir.Fraser@cl.cam.ac.uk>

Keir Fraser wrote:
> 256 would be enough for anyone I think. domain0 is obviously the main user
> of event channels but most of those are demuxed to userspace rather than the
> kernel IRQ space.
>
> Adding a level of indirection for non-domain-0 wouldn't be too hard. We have
> control over which IRQ a PCI device driver thinks it is binding to because
> we control the PCI config space via pciback. We need more care for older
> devices, but could arrange that by maintaining a 1:1 mapping for legacy PIC
> irq range (0 to 15).
>
> Doing the same for domain 0 is probably more 'exciting'. If we could force
> the 'vector space' IRQ allocation strategy of PCI_MSI then I think this is
> more plausible -- since that effectively gives a level of indirection from
> the GSI space. The vectors that Xen currently hands out to domain0 are real
> vector numbers but, of course, it would be trivial to add a level of
> indirection there, or in the caller.
>
> This all raises an obvious question: what do you think the scope of work for
> upstream merging right now should be? Previously it was non-driver domUs
> only (and a simplified form at that). Are you thinking about upstreaming
> everything, or is this just review and preparation for that effort in the
> future?
>   

My plan is:

   1. simple domU (UP only, shadow page tables, no pciback)
   2. domU SMP (to really exercise the paravirt interface)
   3. add more to domU (explicit MMU ops, optimising, etc)
   4. port to x86-64
   5. dom0

Once the paravirt version of simple domU is working, it will be time to 
consider how to sync all this with the xen-unstable tree.  Also after 
step 1, I don't have any strong feelings about the order.  I haven't 
really looked into what the dom0 work really requires, so I'm not sure 
whether it can start early, or if it would be best done once domU is 
relatively sophisticated.  Similarly I'm not sure how much work would be 
required for 64-bit (though an obvious prerequisite is that we implement 
paravirtops for x86-64).

As far as the event channels stuff goes, I think I'll keep it as simple 
as possible for now, and just support as much as needed to get domU 
going, with a view to making it more complex later.

    J

  reply	other threads:[~2006-08-11 15:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <44DBC41A.3080201@goop.org>
2006-08-11  9:36 ` Physical and dynamic event channels Keir Fraser
2006-08-11 15:04   ` Jeremy Fitzhardinge [this message]
2006-08-11 15:05     ` Keir Fraser
2006-08-11 15:09       ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44DC9C81.9040305@goop.org \
    --to=jeremy@goop.org \
    --cc=Ian.Campbell@XenSource.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=chrisw@sous-sol.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.