> From: Jason Gunthorpe
> Sent: Tuesday, August 18, 2020 7:50 PM
>
> On Tue, Aug 18, 2020 at 01:09:01AM +, Tian, Kevin wrote:
> > The difference in my reply is not just about the implementation gap
> > of growing a userspace DMA framework to a passthrough framework.
> > My real point is
On Tue, Aug 18, 2020 at 07:05:16PM +0200, Paolo Bonzini wrote:
> On 18/08/20 18:49, Jason Gunthorpe wrote:
> > On Tue, Aug 18, 2020 at 06:27:21PM +0200, Paolo Bonzini wrote:
> >> On 18/08/20 13:50, Jason Gunthorpe wrote:
> >>> For instance, what about suspend/resume of containers using idxd?
> >>>
On 18/08/20 18:49, Jason Gunthorpe wrote:
> On Tue, Aug 18, 2020 at 06:27:21PM +0200, Paolo Bonzini wrote:
>> On 18/08/20 13:50, Jason Gunthorpe wrote:
>>> For instance, what about suspend/resume of containers using idxd?
>>> Wouldn't you want to have the same basic approach of controlling the
>>>
On Tue, Aug 18, 2020 at 06:27:21PM +0200, Paolo Bonzini wrote:
> On 18/08/20 13:50, Jason Gunthorpe wrote:
> > For instance, what about suspend/resume of containers using idxd?
> > Wouldn't you want to have the same basic approach of controlling the
> > wq from userspace that virtualization uses?
On 18/08/20 13:50, Jason Gunthorpe wrote:
> For instance, what about suspend/resume of containers using idxd?
> Wouldn't you want to have the same basic approach of controlling the
> wq from userspace that virtualization uses?
The difference is that VFIO more or less standardizes the approach you
On Tue, Aug 18, 2020 at 01:09:01AM +, Tian, Kevin wrote:
> The difference in my reply is not just about the implementation gap
> of growing a userspace DMA framework to a passthrough framework.
> My real point is about the different goals that each wants to achieve.
> Userspace DMA is purely
> From: Jason Gunthorpe
> Sent: Tuesday, August 18, 2020 8:44 AM
>
> On Mon, Aug 17, 2020 at 02:12:44AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Friday, August 14, 2020 9:35 PM
> > >
> > > On Mon, Aug 10, 2020 at 07:32:24AM +, Tian, Kevin wrote:
> > >
> > > > > I
On Mon, Aug 17, 2020 at 02:12:44AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, August 14, 2020 9:35 PM
> >
> > On Mon, Aug 10, 2020 at 07:32:24AM +, Tian, Kevin wrote:
> >
> > > > I would prefer to see that the existing userspace interface have the
> > > > extra
> From: Jason Gunthorpe
> Sent: Friday, August 14, 2020 9:24 PM
>
> The same basic argument goes for all the points - the issue is really
> the only uAPI we have for this stuff is under VFIO, and the better
> solution is to disagregate that uAPI, not to try and make everything
> pretend to be a
> From: Jason Gunthorpe
> Sent: Friday, August 14, 2020 9:35 PM
>
> On Mon, Aug 10, 2020 at 07:32:24AM +, Tian, Kevin wrote:
>
> > > I would prefer to see that the existing userspace interface have the
> > > extra needed bits for virtualization (eg by having appropriate
> > > internal kernel
On Mon, Aug 10, 2020 at 07:32:24AM +, Tian, Kevin wrote:
> > I would prefer to see that the existing userspace interface have the
> > extra needed bits for virtualization (eg by having appropriate
> > internal kernel APIs to make this easy) and all the emulation to build
> > the synthetic PCI
On Thu, Aug 13, 2020 at 02:01:58PM +0800, Jason Wang wrote:
>
> On 2020/8/13 下午1:26, Tian, Kevin wrote:
> > > From: Jason Wang
> > > Sent: Thursday, August 13, 2020 12:34 PM
> > >
> > >
> > > On 2020/8/12 下午12:05, Tian, Kevin wrote:
> > > > > The problem is that if we tie all controls via VFIO
On 2020/8/13 下午1:26, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, August 13, 2020 12:34 PM
On 2020/8/12 下午12:05, Tian, Kevin wrote:
The problem is that if we tie all controls via VFIO uAPI, the other
subsystem like vDPA is likely to duplicate them. I wonder if there is a
way to
> From: Jason Wang
> Sent: Thursday, August 13, 2020 12:34 PM
>
>
> On 2020/8/12 下午12:05, Tian, Kevin wrote:
> >> The problem is that if we tie all controls via VFIO uAPI, the other
> >> subsystem like vDPA is likely to duplicate them. I wonder if there is a
> >> way to decouple the vSVA out of
On 2020/8/12 下午12:05, Tian, Kevin wrote:
The problem is that if we tie all controls via VFIO uAPI, the other
subsystem like vDPA is likely to duplicate them. I wonder if there is a
way to decouple the vSVA out of VFIO uAPI?
vSVA is a per-device (either pdev or mdev) feature thus naturally
> From: Jason Wang
> Sent: Wednesday, August 12, 2020 11:28 AM
>
>
> On 2020/8/10 下午3:32, Tian, Kevin wrote:
> >> From: Jason Gunthorpe
> >> Sent: Friday, August 7, 2020 8:20 PM
> >>
> >> On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote:
> >>
> >>> If you see this as an abuse of
> From: Alex Williamson
> Sent: Wednesday, August 12, 2020 10:36 AM
> On Wed, 12 Aug 2020 01:58:00 +
> "Tian, Kevin" wrote:
>
> > >
> > > I'll also remind folks that LPC is coming up in just a couple short
> > > weeks and this might be something we should discuss (virtually)
> > >
On 2020/8/10 下午3:32, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Friday, August 7, 2020 8:20 PM
On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote:
If you see this as an abuse of the framework, then let's identify those
specific issues and come up with a better approach.
On Wed, 12 Aug 2020 01:58:00 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, August 12, 2020 1:01 AM
> >
> > On Mon, 10 Aug 2020 07:32:24 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Jason Gunthorpe
> > > > Sent: Friday, August 7, 2020 8:20 PM
> > > >
> > > >
> From: Alex Williamson
> Sent: Wednesday, August 12, 2020 1:01 AM
>
> On Mon, 10 Aug 2020 07:32:24 +
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Friday, August 7, 2020 8:20 PM
> > >
> > > On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote:
> > >
> > > >
On Mon, 10 Aug 2020 07:32:24 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, August 7, 2020 8:20 PM
> >
> > On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote:
> >
> > > If you see this as an abuse of the framework, then let's identify those
> > >
> From: Jason Gunthorpe
> Sent: Friday, August 7, 2020 8:20 PM
>
> On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote:
>
> > If you see this as an abuse of the framework, then let's identify those
> > specific issues and come up with a better approach. As we've discussed
> >
On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote:
> If you see this as an abuse of the framework, then let's identify those
> specific issues and come up with a better approach. As we've discussed
> before, things like basic PCI config space emulation are acceptable
> overhead and
On Thu, 23 Jul 2020 21:19:30 -0300
Jason Gunthorpe wrote:
> On Tue, Jul 21, 2020 at 11:54:49PM +, Tian, Kevin wrote:
> > In a nutshell, applications don't require raw WQ controllability as guest
> > kernel drivers may expect. Extending DSA user space interface to be another
> > passthrough
On Tue, Jul 21, 2020 at 11:54:49PM +, Tian, Kevin wrote:
> In a nutshell, applications don't require raw WQ controllability as guest
> kernel drivers may expect. Extending DSA user space interface to be another
> passthrough interface just for virtualization needs is less compelling than
>
On Wed, Jul 22, 2020 at 10:31:28AM -0700, Dey, Megha wrote:
> > > I didn't notice any of this in the patch series? What is the calling
> > > context for the platform_msi_ops ? I think I already mentioned that
> > > ideally we'd need blocking/sleeping. The big selling point is that IMS
> > > allows
On 7/21/2020 11:00 AM, Dave Jiang wrote:
On 7/21/2020 9:45 AM, Jason Gunthorpe wrote:
On Tue, Jul 21, 2020 at 09:02:15AM -0700, Dave Jiang wrote:
v2:
IMS (now dev-msi):
With recommendations from Jason/Thomas/Dan on making IMS more generic:
Pass a non-pci generic device(struct device) for
> From: Jason Gunthorpe
> Sent: Wednesday, July 22, 2020 12:45 AM
>
> > Link to previous discussions with Jason:
> > https://lore.kernel.org/lkml/57296ad1-20fe-caf2-b83f-
> 46d823ca0...@intel.com/
> > The emulation part that can be moved to user space is very small due to
> the majority of the
>
On Tue, Jul 21, 2020 at 9:29 AM Greg KH wrote:
>
> On Tue, Jul 21, 2020 at 09:02:15AM -0700, Dave Jiang wrote:
> > v2:
>
> "RFC" to me means "I don't really think this is mergable, so I'm
> throwing it out there." Which implies you know it needs more work
> before others should review it as you
On 7/21/2020 9:45 AM, Jason Gunthorpe wrote:
On Tue, Jul 21, 2020 at 09:02:15AM -0700, Dave Jiang wrote:
v2:
IMS (now dev-msi):
With recommendations from Jason/Thomas/Dan on making IMS more generic:
Pass a non-pci generic device(struct device) for IMS management instead of mdev
Remove all
On 7/21/2020 9:28 AM, Greg KH wrote:
On Tue, Jul 21, 2020 at 09:02:15AM -0700, Dave Jiang wrote:
v2:
"RFC" to me means "I don't really think this is mergable, so I'm
throwing it out there." Which implies you know it needs more work
before others should review it as you are not comfortable
On Tue, Jul 21, 2020 at 09:02:15AM -0700, Dave Jiang wrote:
> v2:
> IMS (now dev-msi):
> With recommendations from Jason/Thomas/Dan on making IMS more generic:
> Pass a non-pci generic device(struct device) for IMS management instead of
> mdev
> Remove all references to mdev and symbol_get/put
>
On Tue, Jul 21, 2020 at 09:02:15AM -0700, Dave Jiang wrote:
> v2:
"RFC" to me means "I don't really think this is mergable, so I'm
throwing it out there." Which implies you know it needs more work
before others should review it as you are not comfortable with it :(
So, back-of-the-queue you
33 matches
Mail list logo
