Megha.
"Dey, Megha" writes:
> On 8/8/2020 12:47 PM, Thomas Gleixner wrote:
>>> 3. Come up with a ground up approach which adheres to the layering
>>> constraints of the IRQ subsystem
>> Yes. It's something which can be used by all devices which have:
>>
>> 1) A device specific irq chip
"Dey, Megha" writes:
> On 8/11/2020 2:53 AM, Thomas Gleixner wrote:
>>> And the annoying fact that you need XEN support which opens another can
>>> of worms...
>
> hmm I am not sure why we need Xen support... are you referring to idxd
> using xen?
What about using IDXD when you are running on
Hi Thomas,
On 8/11/2020 2:53 AM, Thomas Gleixner wrote:
Thomas Gleixner writes:
CC+: XEN folks
Thomas Gleixner writes:
The infrastructure itself is not more than a thin wrapper around the
existing msi domain infrastructure and might even share code with
platform-msi.
And the annoying
Hi Thomas,
On 8/8/2020 12:47 PM, Thomas Gleixner wrote:
Megha,
"Dey, Megha" writes:
On 8/7/2020 9:47 AM, Thomas Gleixner wrote:
I'm all for sharing code and making the life of driver writers simple
because that makes my life simple as well, but not by creating a layer
at the wrong level and
Thomas Gleixner writes:
CC+: XEN folks
> Thomas Gleixner writes:
>> The infrastructure itself is not more than a thin wrapper around the
>> existing msi domain infrastructure and might even share code with
>> platform-msi.
>
> And the annoying fact that you need XEN support which opens another
Thomas Gleixner writes:
> The infrastructure itself is not more than a thin wrapper around the
> existing msi domain infrastructure and might even share code with
> platform-msi.
And the annoying fact that you need XEN support which opens another can
of worms...
Megha,
"Dey, Megha" writes:
> On 8/7/2020 9:47 AM, Thomas Gleixner wrote:
>> I'm all for sharing code and making the life of driver writers simple
>> because that makes my life simple as well, but not by creating a layer
>> at the wrong level and then hacking it into submission until it finally
On 8/7/2020 11:39 AM, Jason Gunthorpe wrote:
On Fri, Aug 07, 2020 at 10:54:51AM -0700, Dey, Megha wrote:
So from the hierarchical domain standpoint, we will have:
- For DSA device: vector->intel-IR->IDXD
- For Jason's device: root domain-> domain A-> Jason's device's IRQ domain
- For any
On Fri, Aug 07, 2020 at 10:54:51AM -0700, Dey, Megha wrote:
> So from the hierarchical domain standpoint, we will have:
> - For DSA device: vector->intel-IR->IDXD
> - For Jason's device: root domain-> domain A-> Jason's device's IRQ domain
> - For any other intel IMS device in the future which
>
Hi Thomas,
On 8/7/2020 9:47 AM, Thomas Gleixner wrote:
Jason Gunthorpe writes:
Though it is more of a rational and a cookbook on how to combine
existing technology pieces. (eg PASID, platform_msi, etc)
The basic approach of SIOV's IMS is that there is no longer a generic
interrupt
Jason Gunthorpe writes:
> Though it is more of a rational and a cookbook on how to combine
> existing technology pieces. (eg PASID, platform_msi, etc)
>
> The basic approach of SIOV's IMS is that there is no longer a generic
> interrupt indirection from numbers to addr/data pairs like
>
Jason,
Jason Gunthorpe writes:
> On Thu, Aug 06, 2020 at 10:21:11PM +0200, Thomas Gleixner wrote:
>
>> Optionally? Please tell the hardware folks to make this mandatory. We
>> have enough pain with non maskable MSI interrupts already so introducing
>> yet another non maskable interrupt
On Fri, Aug 07, 2020 at 02:38:31PM +0200, gre...@linuxfoundation.org wrote:
> On Fri, Aug 07, 2020 at 09:06:50AM -0300, Jason Gunthorpe wrote:
> > On Thu, Aug 06, 2020 at 10:21:11PM +0200, Thomas Gleixner wrote:
> >
> > > Optionally? Please tell the hardware folks to make this mandatory. We
> > >
On Fri, Aug 07, 2020 at 09:06:50AM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 06, 2020 at 10:21:11PM +0200, Thomas Gleixner wrote:
>
> > Optionally? Please tell the hardware folks to make this mandatory. We
> > have enough pain with non maskable MSI interrupts already so introducing
> > yet
On Thu, Aug 06, 2020 at 10:21:11PM +0200, Thomas Gleixner wrote:
> Optionally? Please tell the hardware folks to make this mandatory. We
> have enough pain with non maskable MSI interrupts already so introducing
> yet another non maskable interrupt trainwreck is not an option.
Can you elaborate
Megha,
"Dey, Megha" writes:
> On 8/6/2020 1:21 PM, Thomas Gleixner wrote:
>> If you expect or know that there are other devices coming up with IMS
>> integrated then most of that code can be made a common library. But for
>> this to make sense, you really want to make sure that these other
>>
Hi Thomas,
On 8/6/2020 1:21 PM, Thomas Gleixner wrote:
Megha,
"Dey, Megha" writes:
On 8/6/2020 10:10 AM, Thomas Gleixner wrote:
If the DEV/MSI domain has it's own per IR unit resource management, then
you need one per IR unit.
If the resource management is solely per device then having a
Megha,
"Dey, Megha" writes:
> On 8/6/2020 10:10 AM, Thomas Gleixner wrote:
>> If the DEV/MSI domain has it's own per IR unit resource management, then
>> you need one per IR unit.
>>
>> If the resource management is solely per device then having a domain per
>> device is the right choice.
>
>
Hi Thomas,
On 8/6/2020 10:10 AM, Thomas Gleixner wrote:
Megha,
"Dey, Megha" writes:
-Original Message-
From: Jason Gunthorpe
Subject: Re: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI
irq domain
can you please fix your mail client not to copy the wh
Megha,
"Dey, Megha" writes:
>> -Original Message-
>> From: Jason Gunthorpe
>> Subject: Re: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI
>> irq domain
can you please fix your mail client not to copy the whole header of the
mail you
On Thu, Aug 06, 2020 at 12:32:31AM +, Dey, Megha wrote:
> > Oops, I was thinking of platform_msi_domain_alloc_irqs() not
> > create_device_domain()
> >
> > ie call it in the device driver that wishes to consume the extra MSIs.
> >
> > Is there a harm if each device driver creates a new
lanox.com;
> shah...@mellanox.com; yan.y.z...@linux.intel.com; pbonz...@redhat.com;
> Ortiz, Samuel ; Hossain, Mona
> ; dmaeng...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; linux-...@vger.kernel.org;
> k...@vger.kernel.org
> Subject: Re: [PATCH RFC v2 02
On Thu, Aug 06, 2020 at 12:13:24AM +, Dey, Megha wrote:
> > Well, I had suggested to pass in the parent struct device, but it could
> > certainly
> > use an irq_domain instead:
> >
> > platform_msi_assign_domain(dev, device_to_iommu(p_dev)->ir_domain);
> >
> > Or
> >
> >
lanox.com;
> shah...@mellanox.com; yan.y.z...@linux.intel.com; pbonz...@redhat.com;
> Ortiz, Samuel ; Hossain, Mona
> ; dmaeng...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; linux-...@vger.kernel.org;
> k...@vger.kernel.org
> Subject: Re: [PATCH RFC v2 02
nel.org; x...@kernel.org; linux-...@vger.kernel.org;
> > k...@vger.kernel.org
> > Subject: Re: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI
> > irq domain
> >
> > On Wed, Aug 05, 2020 at 07:18:39PM +, Dey, Megha wrote:
> >
> > >
lanox.com;
> shah...@mellanox.com; yan.y.z...@linux.intel.com; pbonz...@redhat.com;
> Ortiz, Samuel ; Hossain, Mona
> ; dmaeng...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; linux-...@vger.kernel.org;
> k...@vger.kernel.org
> Subject: Re: [PATCH RFC v2 02
On Wed, Aug 05, 2020 at 07:18:39PM +, Dey, Megha wrote:
> Hence we will only have one create_dev_msi_domain which can be
> called by any device driver that wants to use the dev-msi IRQ domain
> to alloc/free IRQs. It would be the responsibility of the device
> driver to provide the correct
lanox.com;
> shah...@mellanox.com; yan.y.z...@linux.intel.com; pbonz...@redhat.com;
> Ortiz, Samuel ; Hossain, Mona
> ; dmaeng...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; linux-...@vger.kernel.org;
> k...@vger.kernel.org
> Subject: Re: [PATCH RFC v2 02
lanox.com;
> shah...@mellanox.com; yan.y.z...@linux.intel.com; pbonz...@redhat.com;
> Ortiz, Samuel ; Hossain, Mona
> ; dmaeng...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.org; linux-...@vger.kernel.org;
> k...@vger.kernel.org
> Subject: Re: [PATCH RFC v2 02
Jason Gunthorpe writes:
> On Thu, Jul 23, 2020 at 09:51:52AM +0100, Marc Zyngier wrote:
>> > IIRC on Intel/AMD at least once a MSI is launched it is not maskable.
>>
>> Really? So you can't shut a device with a screaming interrupt,
>> for example, should it become otherwise unresponsive?
>
>
On Thu, Jul 23, 2020 at 09:51:52AM +0100, Marc Zyngier wrote:
> > IIRC on Intel/AMD at least once a MSI is launched it is not maskable.
>
> Really? So you can't shut a device with a screaming interrupt,
> for example, should it become otherwise unresponsive?
Well, it used to be like that in the
On 2020-07-22 20:59, Jason Gunthorpe wrote:
On Wed, Jul 22, 2020 at 07:52:33PM +0100, Marc Zyngier wrote:
Which is exactly what platform-MSI already does. Why do we need
something else?
It looks to me like all the code is around managing the
dev->msi_domain of the devices.
The intended use
On Wed, Jul 22, 2020 at 07:52:33PM +0100, Marc Zyngier wrote:
> Which is exactly what platform-MSI already does. Why do we need
> something else?
It looks to me like all the code is around managing the
dev->msi_domain of the devices.
The intended use would have PCI drivers create children
On Tue, 21 Jul 2020 17:02:28 +0100,
Dave Jiang wrote:
>
> From: Megha Dey
>
> Add support for the creation of a new DEV_MSI irq domain. It creates a
> new irq chip associated with the DEV_MSI domain and adds the necessary
> domain operations to it.
>
> Add a new config option DEV_MSI which
Hi Jason,
On 7/21/2020 9:13 AM, Jason Gunthorpe wrote:
On Tue, Jul 21, 2020 at 09:02:28AM -0700, Dave Jiang wrote:
From: Megha Dey
Add support for the creation of a new DEV_MSI irq domain. It creates a
new irq chip associated with the DEV_MSI domain and adds the necessary
domain operations
On Tue, Jul 21, 2020 at 09:02:28AM -0700, Dave Jiang wrote:
> From: Megha Dey
>
> Add support for the creation of a new DEV_MSI irq domain. It creates a
> new irq chip associated with the DEV_MSI domain and adds the necessary
> domain operations to it.
>
> Add a new config option DEV_MSI which
From: Megha Dey
Add support for the creation of a new DEV_MSI irq domain. It creates a
new irq chip associated with the DEV_MSI domain and adds the necessary
domain operations to it.
Add a new config option DEV_MSI which must be enabled by any
driver that wants to support device-specific
37 matches
Mail list logo
