Re: [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration

[Alexander Graf]

On 26.06.14 01:59, Alexey Kardashevskiy wrote:
> On 06/26/2014 07:12 AM, Alexander Graf wrote:
> > On 06.06.14 02:20, Alexey Kardashevskiy wrote:
> > > On 06/05/2014 09:57 PM, Alexander Graf wrote:
> > > > On 05.06.14 09:25, Alexey Kardashevskiy wrote:
> > > > > This reserves 2 capability numbers.
> > > > >
> > > > > This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
> > > > >
> > > > > Please advise how to proceed with these patches as I suspect that
> > > > > first two should go via Paolo's tree while the last one via Alex Graf's
> > > > > tree
> > > > > (correct?).
> > > > They would just go via my tree, but only be actually allocated (read:
> > > > mergable to qemu) when they hit Paolo's tree.
> > > >
> > > > In fact, I don't think it makes sense to split them off at all.
> > > So? Are these patches going anywhere? Thanks.
> > So? Are you going to address the comments?
> Sorry, I cannot find here anything to fix. Ben asked some questions, I
> answered and there were no objections. What do I miss this time?...

> >> In fact, the code as is today can allocate an arbitrary amount of pinned
> >> kernel memory from within user space without any checks.
> >
> > Right. We should at least account it in the locked limit.
>
> Yup. And (probably) this thing will keep a counter of how many windows were
> created per KVM instance to avoid having multiple copies of the same table.


Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/