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

Re: [Xen-devel] MSI causing softpanics in guest



On 23/9/08 08:50, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:

> Just some thoughts on Anish's problem. It seems he reveals a bug in current
> code, I think.
> 
> Currently, evnchn_map_pirq is hooked on msi_map_vector
> (pci_enable_msi->msi_capability_init->msi_map_vector). Here the pirq type is
> set to IRQT_PIRQ. Then request_irq should succeed since pirq type is already
> set.
> 
> However, this path only works on the assumption that msi_map_vector and
> request_irq are executed in the same domain, to be more specific, dom0.
> For PV domU guest, there is no msi_map_vector in its pci_enable_msi ( PV domU
> actually asks dom0 to do the msi map, instead. This is a decision made by Keir
> and Yunhong long ago. I think it is base on security considerations). So its
> irq type is not set correctly (What's more, it incorrectly sets the dom0's irq
> type). Then request_irq can trigger this bug_on().
> 
> Anish, if you use the device in dom0 itself, does it also have this bug_on?
> 
> Keir and Jan,
> Do you think this explanation is reasonable for issues Anish met?

Yes, actually I remember thinking there should be a hook for Jan's patch
into pcifront, but then forgot about it. When pcifront gets back a pirq from
pciback, it should evtchn_map_pirq(), right?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.