On 2013-08-29 15:23, Jan Beulich wrote:
On 29.08.13 at 04:52, Zhenzhong Duan <zhenzhong.d...@oracle.com> wrote:
But in initial domain (aka priviliged guest), it's different.
Driver init call graph under initial domain:
driver_init->
msix_capability_init->
msix_program_entries->
msix_mask_irq->
entry->masked = 1
request_irq->
__setup_irq->
irq_startup->
__startup_pirq->
EVTCHNOP_bind_pirq hypercall (trap into Xen)
[Xen:]
pirq_guest_bind->
startup_msi_irq->
unmask_msi_irq->
msi_set_mask_bit->
entry->msi_attrib.masked = 0
So entry->msi_attrib.masked in xen side always has newest value. entry->masked
in initial domain is untouched and is 1 after msix_capability_init.
And as said several times before - Linux shouldn't be touching
the MSI-X table at all during initial setup or resume (it should in
particular not rely on such accesses to not fault, as being a
privilege violation); all it needs to do is update its software state.
My patch just remove access to msix mask register in dom0. Anything
wrong with that?
Hence fiddling with default_restore_msi_irqs() seems the wrong
approach towards solving the problem.
dom0 uses xen_initdom_restore_msi_irqs, default_restore_msi_irqs is for
baremetal.
zduan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
