From: Alexander Graf <agraf@suse.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: kvm@vger.kernel.org, Gleb Natapov <gleb@kernel.org>,
linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org,
Paul Mackerras <paulus@samba.org>,
Paolo Bonzini <pbonzini@redhat.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
Date: Thu, 05 Jun 2014 13:56:11 +0200 [thread overview]
Message-ID: <53905ADB.8000100@suse.de> (raw)
In-Reply-To: <1401964037.3247.129.camel@pasglop>
On 05.06.14 12:27, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
>> No trees yet. For 64GB window we need (64<<30)/(16<<20)*8 = 32K TCE table.
>> Do we really need trees?
> The above is assuming hugetlbfs backed guests. These are the least of my worry
> indeed. But we need to deal with 4k and 64k guests.
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE modifications, but would have some
nicely swappable memory we can store the TCE entries in.
In fact, the code as is today can allocate an arbitrary amount of pinned
kernel memory from within user space without any checks.
Alex
next prev parent reply other threads:[~2014-06-05 11:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-05 7:25 [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration Alexey Kardashevskiy
2014-06-05 7:25 ` [PATCH 1/3] PPC: KVM: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number Alexey Kardashevskiy
2014-06-05 7:25 ` [PATCH 2/3] PPC: KVM: Reserve KVM_CAP_SPAPR_TCE_64 " Alexey Kardashevskiy
2014-06-05 7:25 ` [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows Alexey Kardashevskiy
2014-06-05 7:38 ` Benjamin Herrenschmidt
2014-06-05 9:26 ` Alexey Kardashevskiy
2014-06-05 10:27 ` Benjamin Herrenschmidt
2014-06-05 11:56 ` Alexander Graf [this message]
2014-06-05 12:30 ` Benjamin Herrenschmidt
2014-06-05 12:32 ` Alexander Graf
2014-06-05 13:04 ` Alexey Kardashevskiy
2014-06-05 11:57 ` [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration Alexander Graf
2014-06-06 0:20 ` Alexey Kardashevskiy
2014-06-25 21:12 ` Alexander Graf
2014-06-25 23:59 ` Alexey Kardashevskiy
2014-06-26 10:37 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53905ADB.8000100@suse.de \
--to=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=benh@kernel.crashing.org \
--cc=gleb@kernel.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).