On Thu, Aug 22, 2013 at 03:14:34PM -0600, Bjorn Helgaas wrote:Yes, 3rd patch doesn't depend on the first two.On Mon, Aug 5, 2013 at 1:21 AM, Zhenzhong DuanHey Bjorn,
<zhenzhong.duan@xxxxxxxxxx> wrote:
xen_initdom_restore_msi_irqs trigger a hypercall to restore addr/data/maskKonrad, this changelog still doesn't make any sense to me, but if you
in dom0. It's better to do the same in default_restore_msi_irqs for baremetal.
Move restore of mask in default_restore_msi_irqs, this could avoid mask
restored twice in dom0, and the logic for baremetal keep same.
First mask restore is in xen_initdom_restore_msi_irqs->PHYSDEVOP_restore_msi,
Second restore is __pci_restore_msix_state->msix_mask_irq.
Mask bits are under full control of xen, and the entry->masked in dom0 kernel
is invalid. restore an invalid value to mask register could mask the msix
interrupt.
Without fix, qlcnic driver calling pci_reset_function will lost interrupt
in dom0.
ack this, I guess I can apply it.
Zhenzhong is patiently working to rewrite up the commit message based on
my naive questions and emails back and forth. Once it is good shape he
will post it. The code will look the same but the commit message will
be a bit more verbose and clear.
Is there an ETA when you would like these? I recall the merge window
is just around the corner - so when is your comfortable cut-off-day
so that you can make a go/no-go decision?
I guess there are also:<scratches his head>.
Jul 24 [PATCH 1/3] Refactor msi/msix restore code Part1
Jul 30 [PATCH 3/3 v2] Update x86_msi.restore_msi_irqs API param
and all three should be applied as a series?
I think the
Jul 30 [PATCH 3/3 v2] Update x86_msi.restore_msi_irqs API param
can go in anytime. That is mostly a cosmetic fixup in the API.
Zhenzhong - right?