From: Alexander Graf <agraf@suse.de>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: kvm@vger.kernel.org, mina86@mina86.com, linux-mm@kvack.org,
paulus@samba.org, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, m.szyprowski@samsung.com
Subject: Re: [PATCH -V3 3/4] powerpc/kvm: Contiguous memory allocator based RMA allocation
Date: Tue, 02 Jul 2013 16:36:56 +0000 [thread overview]
Message-ID: <51D301A8.50406@suse.de> (raw)
In-Reply-To: <87r4fhylhe.fsf@linux.vnet.ibm.com>
On 07/02/2013 06:28 PM, Aneesh Kumar K.V wrote:
> Alexander Graf<agraf@suse.de> writes:
>
>> On 07/02/2013 05:29 PM, Aneesh Kumar K.V wrote:
>>> Alexander Graf<agraf@suse.de> writes:
>>>
>>>> On 07/02/2013 07:45 AM, Aneesh Kumar K.V wrote:
>>>>> From: "Aneesh Kumar K.V"<aneesh.kumar@linux.vnet.ibm.com>
>>>>>
>>>>> Older version of power architecture use Real Mode Offset register and Real Mode Limit
>>>>> Selector for mapping guest Real Mode Area. The guest RMA should be physically
>>>>> contigous since we use the range when address translation is not enabled.
>>>>>
>>>>> This patch switch RMA allocation code to use contigous memory allocator. The patch
>>>>> also remove the the linear allocator which not used any more
>>>>>
>>>>> Acked-by: Paul Mackerras<paulus@samba.org>
>>>>> Signed-off-by: Aneesh Kumar K.V<aneesh.kumar@linux.vnet.ibm.com>
>>>>> ---
>>> .... snip ....
>>>
>>>>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>>>>> index 550f592..55c8519 100644
>>>>> --- a/arch/powerpc/kvm/book3s_hv.c
>>>>> +++ b/arch/powerpc/kvm/book3s_hv.c
>>>>> @@ -1511,10 +1511,10 @@ static inline int lpcr_rmls(unsigned long rma_size)
>>>>>
>>>>> static int kvm_rma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri = vma->vm_file->private_data;
>>>>> struct page *page;
>>>>> + struct kvm_rma_info *ri = vma->vm_file->private_data;
>>>>>
>>>>> - if (vmf->pgoff>= ri->npages)
>>>>> + if (vmf->pgoff>= kvm_rma_pages)
>>>>> return VM_FAULT_SIGBUS;
>>>>>
>>>>> page = pfn_to_page(ri->base_pfn + vmf->pgoff);
>>>>> @@ -1536,7 +1536,7 @@ static int kvm_rma_mmap(struct file *file, struct vm_area_struct *vma)
>>>>>
>>>>> static int kvm_rma_release(struct inode *inode, struct file *filp)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri = filp->private_data;
>>>>> + struct kvm_rma_info *ri = filp->private_data;
>>>>>
>>>>> kvm_release_rma(ri);
>>>>> return 0;
>>>>> @@ -1549,8 +1549,17 @@ static const struct file_operations kvm_rma_fops = {
>>>>>
>>>>> long kvm_vm_ioctl_allocate_rma(struct kvm *kvm, struct kvm_allocate_rma *ret)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri;
>>>>> long fd;
>>>>> + struct kvm_rma_info *ri;
>>>>> + /*
>>>>> + * Only do this on PPC970 in HV mode
>>>>> + */
>>>>> + if (!cpu_has_feature(CPU_FTR_HVMODE) ||
>>>>> + !cpu_has_feature(CPU_FTR_ARCH_201))
>>>>> + return -EINVAL;
>>>> Is this really what we want? User space may want to use an RMA on POWER7
>>>> systems, no?
>>> IIUC they will use virtual real mode area (VRMA) and not RMA
>> Then I suppose we should at least update the comment a bit further down
>> the patch that indicates that on POWER7 systems we do support a real
>> RMA. I can't really think of any reason why user space would want to use
>> RMA over VRMA.
>>
> where ? We have comments like
>
> /* On POWER7, use VRMA; on PPC970, give up */
> /*
> - * This maintains a list of RMAs (real mode areas) for KVM guests to use.
> + * We allocate RMAs (real mode areas) for KVM guests from the KVM CMA area.
> * Each RMA has to be physically contiguous and of a size that the
> * hardware supports. PPC970 and POWER7 support 64MB, 128MB and 256MB,
> * and other larger sizes. Since we are unlikely to be allocate that
> * much physically contiguous memory after the system is up and running,
> - * we preallocate a set of RMAs in early boot for KVM to use.
> + * we preallocate a set of RMAs in early boot using CMA.
> + * should be power of 2.
> */
This could be falsely interpreted as "POWER7 can use an RMA".
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linux-mm@kvack.org,
paulus@samba.org, mina86@mina86.com,
linuxppc-dev@lists.ozlabs.org, m.szyprowski@samsung.com
Subject: Re: [PATCH -V3 3/4] powerpc/kvm: Contiguous memory allocator based RMA allocation
Date: Tue, 02 Jul 2013 18:36:56 +0200 [thread overview]
Message-ID: <51D301A8.50406@suse.de> (raw)
In-Reply-To: <87r4fhylhe.fsf@linux.vnet.ibm.com>
On 07/02/2013 06:28 PM, Aneesh Kumar K.V wrote:
> Alexander Graf<agraf@suse.de> writes:
>
>> On 07/02/2013 05:29 PM, Aneesh Kumar K.V wrote:
>>> Alexander Graf<agraf@suse.de> writes:
>>>
>>>> On 07/02/2013 07:45 AM, Aneesh Kumar K.V wrote:
>>>>> From: "Aneesh Kumar K.V"<aneesh.kumar@linux.vnet.ibm.com>
>>>>>
>>>>> Older version of power architecture use Real Mode Offset register and Real Mode Limit
>>>>> Selector for mapping guest Real Mode Area. The guest RMA should be physically
>>>>> contigous since we use the range when address translation is not enabled.
>>>>>
>>>>> This patch switch RMA allocation code to use contigous memory allocator. The patch
>>>>> also remove the the linear allocator which not used any more
>>>>>
>>>>> Acked-by: Paul Mackerras<paulus@samba.org>
>>>>> Signed-off-by: Aneesh Kumar K.V<aneesh.kumar@linux.vnet.ibm.com>
>>>>> ---
>>> .... snip ....
>>>
>>>>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>>>>> index 550f592..55c8519 100644
>>>>> --- a/arch/powerpc/kvm/book3s_hv.c
>>>>> +++ b/arch/powerpc/kvm/book3s_hv.c
>>>>> @@ -1511,10 +1511,10 @@ static inline int lpcr_rmls(unsigned long rma_size)
>>>>>
>>>>> static int kvm_rma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri = vma->vm_file->private_data;
>>>>> struct page *page;
>>>>> + struct kvm_rma_info *ri = vma->vm_file->private_data;
>>>>>
>>>>> - if (vmf->pgoff>= ri->npages)
>>>>> + if (vmf->pgoff>= kvm_rma_pages)
>>>>> return VM_FAULT_SIGBUS;
>>>>>
>>>>> page = pfn_to_page(ri->base_pfn + vmf->pgoff);
>>>>> @@ -1536,7 +1536,7 @@ static int kvm_rma_mmap(struct file *file, struct vm_area_struct *vma)
>>>>>
>>>>> static int kvm_rma_release(struct inode *inode, struct file *filp)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri = filp->private_data;
>>>>> + struct kvm_rma_info *ri = filp->private_data;
>>>>>
>>>>> kvm_release_rma(ri);
>>>>> return 0;
>>>>> @@ -1549,8 +1549,17 @@ static const struct file_operations kvm_rma_fops = {
>>>>>
>>>>> long kvm_vm_ioctl_allocate_rma(struct kvm *kvm, struct kvm_allocate_rma *ret)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri;
>>>>> long fd;
>>>>> + struct kvm_rma_info *ri;
>>>>> + /*
>>>>> + * Only do this on PPC970 in HV mode
>>>>> + */
>>>>> + if (!cpu_has_feature(CPU_FTR_HVMODE) ||
>>>>> + !cpu_has_feature(CPU_FTR_ARCH_201))
>>>>> + return -EINVAL;
>>>> Is this really what we want? User space may want to use an RMA on POWER7
>>>> systems, no?
>>> IIUC they will use virtual real mode area (VRMA) and not RMA
>> Then I suppose we should at least update the comment a bit further down
>> the patch that indicates that on POWER7 systems we do support a real
>> RMA. I can't really think of any reason why user space would want to use
>> RMA over VRMA.
>>
> where ? We have comments like
>
> /* On POWER7, use VRMA; on PPC970, give up */
> /*
> - * This maintains a list of RMAs (real mode areas) for KVM guests to use.
> + * We allocate RMAs (real mode areas) for KVM guests from the KVM CMA area.
> * Each RMA has to be physically contiguous and of a size that the
> * hardware supports. PPC970 and POWER7 support 64MB, 128MB and 256MB,
> * and other larger sizes. Since we are unlikely to be allocate that
> * much physically contiguous memory after the system is up and running,
> - * we preallocate a set of RMAs in early boot for KVM to use.
> + * we preallocate a set of RMAs in early boot using CMA.
> + * should be power of 2.
> */
This could be falsely interpreted as "POWER7 can use an RMA".
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: kvm@vger.kernel.org, mina86@mina86.com, linux-mm@kvack.org,
paulus@samba.org, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, m.szyprowski@samsung.com
Subject: Re: [PATCH -V3 3/4] powerpc/kvm: Contiguous memory allocator based RMA allocation
Date: Tue, 02 Jul 2013 18:36:56 +0200 [thread overview]
Message-ID: <51D301A8.50406@suse.de> (raw)
In-Reply-To: <87r4fhylhe.fsf@linux.vnet.ibm.com>
On 07/02/2013 06:28 PM, Aneesh Kumar K.V wrote:
> Alexander Graf<agraf@suse.de> writes:
>
>> On 07/02/2013 05:29 PM, Aneesh Kumar K.V wrote:
>>> Alexander Graf<agraf@suse.de> writes:
>>>
>>>> On 07/02/2013 07:45 AM, Aneesh Kumar K.V wrote:
>>>>> From: "Aneesh Kumar K.V"<aneesh.kumar@linux.vnet.ibm.com>
>>>>>
>>>>> Older version of power architecture use Real Mode Offset register and Real Mode Limit
>>>>> Selector for mapping guest Real Mode Area. The guest RMA should be physically
>>>>> contigous since we use the range when address translation is not enabled.
>>>>>
>>>>> This patch switch RMA allocation code to use contigous memory allocator. The patch
>>>>> also remove the the linear allocator which not used any more
>>>>>
>>>>> Acked-by: Paul Mackerras<paulus@samba.org>
>>>>> Signed-off-by: Aneesh Kumar K.V<aneesh.kumar@linux.vnet.ibm.com>
>>>>> ---
>>> .... snip ....
>>>
>>>>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>>>>> index 550f592..55c8519 100644
>>>>> --- a/arch/powerpc/kvm/book3s_hv.c
>>>>> +++ b/arch/powerpc/kvm/book3s_hv.c
>>>>> @@ -1511,10 +1511,10 @@ static inline int lpcr_rmls(unsigned long rma_size)
>>>>>
>>>>> static int kvm_rma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri = vma->vm_file->private_data;
>>>>> struct page *page;
>>>>> + struct kvm_rma_info *ri = vma->vm_file->private_data;
>>>>>
>>>>> - if (vmf->pgoff>= ri->npages)
>>>>> + if (vmf->pgoff>= kvm_rma_pages)
>>>>> return VM_FAULT_SIGBUS;
>>>>>
>>>>> page = pfn_to_page(ri->base_pfn + vmf->pgoff);
>>>>> @@ -1536,7 +1536,7 @@ static int kvm_rma_mmap(struct file *file, struct vm_area_struct *vma)
>>>>>
>>>>> static int kvm_rma_release(struct inode *inode, struct file *filp)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri = filp->private_data;
>>>>> + struct kvm_rma_info *ri = filp->private_data;
>>>>>
>>>>> kvm_release_rma(ri);
>>>>> return 0;
>>>>> @@ -1549,8 +1549,17 @@ static const struct file_operations kvm_rma_fops = {
>>>>>
>>>>> long kvm_vm_ioctl_allocate_rma(struct kvm *kvm, struct kvm_allocate_rma *ret)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri;
>>>>> long fd;
>>>>> + struct kvm_rma_info *ri;
>>>>> + /*
>>>>> + * Only do this on PPC970 in HV mode
>>>>> + */
>>>>> + if (!cpu_has_feature(CPU_FTR_HVMODE) ||
>>>>> + !cpu_has_feature(CPU_FTR_ARCH_201))
>>>>> + return -EINVAL;
>>>> Is this really what we want? User space may want to use an RMA on POWER7
>>>> systems, no?
>>> IIUC they will use virtual real mode area (VRMA) and not RMA
>> Then I suppose we should at least update the comment a bit further down
>> the patch that indicates that on POWER7 systems we do support a real
>> RMA. I can't really think of any reason why user space would want to use
>> RMA over VRMA.
>>
> where ? We have comments like
>
> /* On POWER7, use VRMA; on PPC970, give up */
> /*
> - * This maintains a list of RMAs (real mode areas) for KVM guests to use.
> + * We allocate RMAs (real mode areas) for KVM guests from the KVM CMA area.
> * Each RMA has to be physically contiguous and of a size that the
> * hardware supports. PPC970 and POWER7 support 64MB, 128MB and 256MB,
> * and other larger sizes. Since we are unlikely to be allocate that
> * much physically contiguous memory after the system is up and running,
> - * we preallocate a set of RMAs in early boot for KVM to use.
> + * we preallocate a set of RMAs in early boot using CMA.
> + * should be power of 2.
> */
This could be falsely interpreted as "POWER7 can use an RMA".
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: kvm@vger.kernel.org, mina86@mina86.com, linux-mm@kvack.org,
paulus@samba.org, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, m.szyprowski@samsung.com
Subject: Re: [PATCH -V3 3/4] powerpc/kvm: Contiguous memory allocator based RMA allocation
Date: Tue, 02 Jul 2013 18:36:56 +0200 [thread overview]
Message-ID: <51D301A8.50406@suse.de> (raw)
In-Reply-To: <87r4fhylhe.fsf@linux.vnet.ibm.com>
On 07/02/2013 06:28 PM, Aneesh Kumar K.V wrote:
> Alexander Graf<agraf@suse.de> writes:
>
>> On 07/02/2013 05:29 PM, Aneesh Kumar K.V wrote:
>>> Alexander Graf<agraf@suse.de> writes:
>>>
>>>> On 07/02/2013 07:45 AM, Aneesh Kumar K.V wrote:
>>>>> From: "Aneesh Kumar K.V"<aneesh.kumar@linux.vnet.ibm.com>
>>>>>
>>>>> Older version of power architecture use Real Mode Offset register and Real Mode Limit
>>>>> Selector for mapping guest Real Mode Area. The guest RMA should be physically
>>>>> contigous since we use the range when address translation is not enabled.
>>>>>
>>>>> This patch switch RMA allocation code to use contigous memory allocator. The patch
>>>>> also remove the the linear allocator which not used any more
>>>>>
>>>>> Acked-by: Paul Mackerras<paulus@samba.org>
>>>>> Signed-off-by: Aneesh Kumar K.V<aneesh.kumar@linux.vnet.ibm.com>
>>>>> ---
>>> .... snip ....
>>>
>>>>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>>>>> index 550f592..55c8519 100644
>>>>> --- a/arch/powerpc/kvm/book3s_hv.c
>>>>> +++ b/arch/powerpc/kvm/book3s_hv.c
>>>>> @@ -1511,10 +1511,10 @@ static inline int lpcr_rmls(unsigned long rma_size)
>>>>>
>>>>> static int kvm_rma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri = vma->vm_file->private_data;
>>>>> struct page *page;
>>>>> + struct kvm_rma_info *ri = vma->vm_file->private_data;
>>>>>
>>>>> - if (vmf->pgoff>= ri->npages)
>>>>> + if (vmf->pgoff>= kvm_rma_pages)
>>>>> return VM_FAULT_SIGBUS;
>>>>>
>>>>> page = pfn_to_page(ri->base_pfn + vmf->pgoff);
>>>>> @@ -1536,7 +1536,7 @@ static int kvm_rma_mmap(struct file *file, struct vm_area_struct *vma)
>>>>>
>>>>> static int kvm_rma_release(struct inode *inode, struct file *filp)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri = filp->private_data;
>>>>> + struct kvm_rma_info *ri = filp->private_data;
>>>>>
>>>>> kvm_release_rma(ri);
>>>>> return 0;
>>>>> @@ -1549,8 +1549,17 @@ static const struct file_operations kvm_rma_fops = {
>>>>>
>>>>> long kvm_vm_ioctl_allocate_rma(struct kvm *kvm, struct kvm_allocate_rma *ret)
>>>>> {
>>>>> - struct kvmppc_linear_info *ri;
>>>>> long fd;
>>>>> + struct kvm_rma_info *ri;
>>>>> + /*
>>>>> + * Only do this on PPC970 in HV mode
>>>>> + */
>>>>> + if (!cpu_has_feature(CPU_FTR_HVMODE) ||
>>>>> + !cpu_has_feature(CPU_FTR_ARCH_201))
>>>>> + return -EINVAL;
>>>> Is this really what we want? User space may want to use an RMA on POWER7
>>>> systems, no?
>>> IIUC they will use virtual real mode area (VRMA) and not RMA
>> Then I suppose we should at least update the comment a bit further down
>> the patch that indicates that on POWER7 systems we do support a real
>> RMA. I can't really think of any reason why user space would want to use
>> RMA over VRMA.
>>
> where ? We have comments like
>
> /* On POWER7, use VRMA; on PPC970, give up */
> /*
> - * This maintains a list of RMAs (real mode areas) for KVM guests to use.
> + * We allocate RMAs (real mode areas) for KVM guests from the KVM CMA area.
> * Each RMA has to be physically contiguous and of a size that the
> * hardware supports. PPC970 and POWER7 support 64MB, 128MB and 256MB,
> * and other larger sizes. Since we are unlikely to be allocate that
> * much physically contiguous memory after the system is up and running,
> - * we preallocate a set of RMAs in early boot for KVM to use.
> + * we preallocate a set of RMAs in early boot using CMA.
> + * should be power of 2.
> */
This could be falsely interpreted as "POWER7 can use an RMA".
Alex
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-07-02 16:36 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 5:45 [PATCH -V3 1/4] mm/cma: Move dma contiguous changes into a seperate config Aneesh Kumar K.V
2013-07-02 5:57 ` Aneesh Kumar K.V
2013-07-02 5:45 ` Aneesh Kumar K.V
2013-07-02 5:45 ` [PATCH -V3 2/4] powerpc/kvm: Contiguous memory allocator based hash page table allocation Aneesh Kumar K.V
2013-07-02 5:57 ` Aneesh Kumar K.V
2013-07-02 5:45 ` Aneesh Kumar K.V
2013-07-02 15:12 ` Alexander Graf
2013-07-02 15:12 ` Alexander Graf
2013-07-02 15:12 ` Alexander Graf
2013-07-02 15:12 ` Alexander Graf
2013-07-02 15:31 ` Aneesh Kumar K.V
2013-07-02 15:43 ` Aneesh Kumar K.V
2013-07-02 15:31 ` Aneesh Kumar K.V
2013-07-02 15:31 ` Aneesh Kumar K.V
2013-07-02 15:32 ` Alexander Graf
2013-07-02 15:32 ` Alexander Graf
2013-07-02 15:32 ` Alexander Graf
2013-07-02 15:32 ` Alexander Graf
2013-07-02 22:28 ` Benjamin Herrenschmidt
2013-07-02 22:28 ` Benjamin Herrenschmidt
2013-07-02 22:28 ` Benjamin Herrenschmidt
2013-07-02 22:31 ` Alexander Graf
2013-07-02 22:31 ` Alexander Graf
2013-07-02 22:31 ` Alexander Graf
2013-07-03 6:15 ` Paul Mackerras
2013-07-03 6:15 ` Paul Mackerras
2013-07-03 6:15 ` Paul Mackerras
2013-07-02 5:45 ` [PATCH -V3 3/4] powerpc/kvm: Contiguous memory allocator based RMA allocation Aneesh Kumar K.V
2013-07-02 5:57 ` Aneesh Kumar K.V
2013-07-02 5:45 ` Aneesh Kumar K.V
2013-07-02 15:17 ` Alexander Graf
2013-07-02 15:17 ` Alexander Graf
2013-07-02 15:17 ` Alexander Graf
2013-07-02 15:17 ` Alexander Graf
2013-07-02 15:29 ` Aneesh Kumar K.V
2013-07-02 15:41 ` Aneesh Kumar K.V
2013-07-02 15:29 ` Aneesh Kumar K.V
2013-07-02 15:29 ` Aneesh Kumar K.V
2013-07-02 15:32 ` Alexander Graf
2013-07-02 15:32 ` Alexander Graf
2013-07-02 15:32 ` Alexander Graf
2013-07-02 15:32 ` Alexander Graf
2013-07-02 16:28 ` Aneesh Kumar K.V
2013-07-02 16:40 ` Aneesh Kumar K.V
2013-07-02 16:28 ` Aneesh Kumar K.V
2013-07-02 16:36 ` Alexander Graf [this message]
2013-07-02 16:36 ` Alexander Graf
2013-07-02 16:36 ` Alexander Graf
2013-07-02 16:36 ` Alexander Graf
2013-07-02 5:45 ` [PATCH -V3 4/4] powerpc/kvm: Use 256K chunk to track both RMA and hash page table allocation Aneesh Kumar K.V
2013-07-02 5:57 ` Aneesh Kumar K.V
2013-07-02 5:45 ` Aneesh Kumar K.V
2013-07-02 6:29 ` virtual machine windows freeze on copy data to an samba share Marko Weber | ZBF
2013-07-03 6:16 ` [PATCH -V3 4/4] powerpc/kvm: Use 256K chunk to track both RMA and hash page table allocation Paul Mackerras
2013-07-03 6:16 ` Paul Mackerras
2013-07-03 6:16 ` Paul Mackerras
2013-07-03 6:16 ` Paul Mackerras
2013-07-02 8:20 ` [PATCH -V3 1/4] mm/cma: Move dma contiguous changes into a seperate config Marek Szyprowski
2013-07-02 8:20 ` Marek Szyprowski
2013-07-02 8:20 ` Marek Szyprowski
2013-07-02 15:33 ` Aneesh Kumar K.V
2013-07-02 15:45 ` Aneesh Kumar K.V
2013-07-02 15:33 ` Aneesh Kumar K.V
2013-07-08 14:21 ` Alexander Graf
2013-07-08 14:21 ` Alexander Graf
2013-07-08 14:21 ` Alexander Graf
2013-07-08 14:21 ` 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=51D301A8.50406@suse.de \
--to=agraf@suse.de \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=m.szyprowski@samsung.com \
--cc=mina86@mina86.com \
--cc=paulus@samba.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.