On 06/05/2014 10:30 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
>> 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 TC
On 05.06.14 14:30, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
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 modification
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
> 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 me
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
ind
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 guest
On 06/05/2014 05:38 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-05 at 17:25 +1000, Alexey Kardashevskiy wrote:
>> +This creates a virtual TCE (translation control entry) table, which
>> +is an IOMMU for PAPR-style virtual I/O. It is used to translate
>> +logical addresses used in virtual I
On Thu, 2014-06-05 at 17:25 +1000, Alexey Kardashevskiy wrote:
> +This creates a virtual TCE (translation control entry) table, which
> +is an IOMMU for PAPR-style virtual I/O. It is used to translate
> +logical addresses used in virtual I/O into guest physical addresses,
> +and provides a scatter
The existing KVM_CREATE_SPAPR_TCE only supports 32bit windows which is not
enough for directly mapped windows as the guest can get more than 4GB.
This adds KVM_CREATE_SPAPR_TCE_64 ioctl and advertises it
via KVM_CAP_SPAPR_TCE_64 capability.
Since 64bit windows are to support Dynamic DMA windows (
