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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
