[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PVH]: Help: msi.c
On Wed, 12 Dec 2012 17:15:23 -0800 Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote: > On Tue, 11 Dec 2012 12:10:19 +0000 > Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote: > > > On Tue, 11 Dec 2012, Mukesh Rathor wrote: > > > On Mon, 10 Dec 2012 09:43:34 +0000 > > > "Jan Beulich" <JBeulich@xxxxxxxx> wrote: > > > > That's strange because AFAIK Linux is never editing the MSI-X > > entries directly: give a look at > > arch/x86/pci/xen.c:xen_initdom_setup_msi_irqs, Linux only remaps > > MSIs into pirqs using hypercalls. Xen should be the only one to > > touch the real MSI-X table. > > So, this is what's happening. The side effect of : > > if ( rangeset_add_range(mmio_ro_ranges, dev->msix_table.first, > dev->msix_table.last) ) > WARN(); > if ( rangeset_add_range(mmio_ro_ranges, dev->msix_pba.first, > dev->msix_pba.last) ) > WARN(); > > in msix_capability_init() in xen is that the dom0 EPT entries that > I've mapped are going from RW to read only. Then when dom0 accesses > it, I get EPT violation. In case of pure PV, the PTE entry to access > the iomem is RW, and the above rangeset adding doesn't affect it. I > don't understand why? Looking into that now... Ah, it's coming from: ept_p2m_type_to_flags(): case p2m_mmio_direct: entry->r = entry->x = 1; entry->w = !rangeset_contains_singleton(mmio_ro_ranges, entry->mfn); I suppose, the best fix would be to add a check here for dom0 and let it have w access? thanks mukesh _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |