Re: [Xen-devel] [PATCH 2/3 v3] Refactor MSI restore call-chain to drop unnecessary argument

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2013-08-29 15:23, Jan Beulich wrote:
On 29.08.13 at 04:52, Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx> 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-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux