On Thu, 2009-08-20 at 03:22 +0800, Jeremy Fitzhardinge wrote:
> >> I'm not actually sure this approach is going to work; so far it just
> >> locks up the machine shortly after ACPI initialization. Trapping an
> >> emulating (IO-)APIC accesses may well turn out to be simpler (on the
> >> Linux side, at least) and more robust in the end...
> >>
> > MSI by nature is vector based, but xen uses pirq as the interface to
> > communicate with dom0, 2/3 is actually used to handle the pirq thing
> > instead of solely vectors.
> >
>
> Yes, that's awkward. The new-interrupt-routing branch moves towards
> eliminating vectors from the kernel<->xen, replacing them entirely with
> pirqs. Part of the motivation for this is to insulate the kernel from
> Xen's decisions on how to allocate and route vectors (ie, the number of
> vectors and whether they're percpu or not).
>
> Extending this to MSI would presumably require Xen to do the actual PCI
> (config space?) programming given a pirq for the device interrupt.
> Perhaps this could be best achieved by making the x86
> arch_setup_msi_irqs call through a function pointer so we can direct it
> to a Xen-specific version. Would that be clean?
I finished reading the new-interrupt-routing branch and had some revisit
on MSI. Basically, I think this branch is OK, exposing Xen vectors to
guest is quite weird (also includes `index' field of map_pirq call),
this `vector' is now even renamed to `irq' because of per-cpu vector.
And my MSI patches don't conflict significantly with the
new-interrupt-routing branch. We can consider the setting up of MSI as
two aspects: one is programming the interrupt source (by writing to
config space and MSIX mmio), the other is software: creating new irqs,
and starting them. The method I use now is to add a branching
in arch_setup_msi_irqs, to (1) set the irq_chip of these new irqs to
pirq; (2) avoid programming the config space. This can be changed to
funciton pointers with no additional pain.
> > So trapping and emulating for msi will first need a decoupling of that,
> > allowing dom0 to use only vector to index its msi. This requires changing
> > of the current pirq based xen irq, which seems quite annoying at Xen side,
> > especially if per-cpu vector is in.
> >
>
> What about making pirq == vector, so the "vector" seen by the kernel
> isn't a real vector at all, and Xen remaps from the pirq/vector to the
> real vector when emulating the write?
But the vector is allocated by the kernel, right? How can Xen know which
vector (and its CPU affinity) is related to a pirq?
For suspend/resume of MSI devices support, what the kernel does on bare
metal is simply to reprogram the interrupt source, including writing vectors
and set enable bit. On Xen, the reprogramming is done in the hypervisor,
so we just need to bypass kernel the kernel reprogramming: If using T&E,
just ignore address/data writing and if not, an arch specific hook is
needed.
And what do you mean by I/O APIC T&E? Since dom0 is eventually notified
by evtchn, a relation between vector and evtchn has to be established,
which doesn't exist yet. I ever think of mapping evtchns for (vcpu,
vector) pairs at vector allocation time, so that everything else can be
keep untouched. But that seems to involve to much change.
Thanks,
Qing
>
> J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home