On 08/31/09 18:54, Qing He wrote:
> 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.
>
OK, good.
> 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.
>
Yep.
>>> 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?
>
In the current dom0 scheme, the kernel does a hypercall to ask Xen to
allocate the vector for a given 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.
>
That's fairly straightforward, since the PCI config space is mapped
anyway. We just need to have some way to create mappings that will trap
(ie, we can't use the ptes the kernel establishes as-is, as they won't
cause a pagefault).
> 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.
>
At the moment we need to paravirtualize IO APIC register writes via
hypercall, specifically so that Xen can completely establish the
apic+pin -> vector -> pirq -> evtchn mapping. It needs to be a
hypercall because the IO APIC doesn't have an explicit mapping within
the dom0 address space. If we created such a mapping and trapped reads
and writes to it, it would be logically equivalent to the hypercall, but
wouldn't require kernel changes.
However, this is moot in the new-interrupt-routing branch as we take
over the whole interrupt path, so there's no problem making hypercalls
(either to update the IO APIC via register writes, or the new hypercall
to establish a gsi -> pirq mapping).
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home