Re: [Xen-devel] [PVH]: Help: msi.c

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

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