[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101007025923.GB8272@dumpdata.com>
Date: Wed, 6 Oct 2010 22:59:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Bruce Edge <bruce.edge@...il.com>
Cc: linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
hpa@...or.com, alex.williamson@...hat.com, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Stefano Stabellini <stefano.stabellini@...citrix.com>
Subject: Re: [Xen-devel] Re: [PATCH 16/20] x86: Introduce x86_msi_ops
On Thu, Sep 23, 2010 at 04:18:42PM -0700, Bruce Edge wrote:
> On Thu, Sep 23, 2010 at 7:48 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@...cle.com> wrote:
> > On Tue, Aug 31, 2010 at 02:31:40PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Aug 04, 2010 at 02:19:11PM -0400, Konrad Rzeszutek Wilk wrote:
> >> > From: Stefano Stabellini <stefano.stabellini@...citrix.com>
> >> >
> >> > Introduce an x86 specific indirect mechanism to setup MSIs.
> >> > The MSI setup functions become function pointers in an x86_msi_ops
> >> > struct, that defaults to the implementation in io_apic.c
> >>
> >> Hey Peter,
> >>
> >> I was wondering if you have time to take a look at this?
> >
> > ping?
> >>
> >> The patchset introduces a driver which takes care of allowing
> >> pci_conf_read/write in a virtualized environements with PCI
> >> passthrough devices. Unfortunatly for MSI operations that is not
> >> so simple, so this patch alongside with the previous one
> >> (https://patchwork.kernel.org/patch/117105/)
> >> expands the arch_* calls. This makes it possible to register on top
> >> of the native callback (the virtualized ones can), if required.
> >>
>
> Is this patch required for PCI passthrough devices that use MSI interrupts?
Yes. And also for MSI-X. However, I've just posted a new updated mechanism based
on Thomas's idea - which is superior to this one.
>
> I'm wondering because I'm seeing drivers for PCI passthrough are able
> to init the MSI interrupts OK, but never get any interrupts with pvops
> domU kernels.
The problem you are seeing is different, I think we can narrow it down
to the dom0 doing something wacked.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists