From: "Michael R. Hines" <mrhines-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Hal Rosenstock
<hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>,
"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCHv2] rdma: add a new IB_ACCESS_GIFT flag
Date: Fri, 05 Apr 2013 16:17:36 -0400 [thread overview]
Message-ID: <515F3160.4020007@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130324155153.GA8597-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
The userland part of the patch was missing (IBV_ACCESS_GIFT).
I added flag that to /usr/include in addition to this patch and did a
test RDMA migrate and it seems to work without any problems.
I also removed the IBV_*_WRITE flags on the sender-side and activated
cgroups with the "memory.memsw.limit_in_bytes" activated and the
migration with RDMA also succeeded without any problems (both with *and*
without GIFT also worked).
Any additional tests you would like?
- Michael
On 03/24/2013 11:51 AM, Michael S. Tsirkin wrote:
> At the moment registering an MR breaks COW. This breaks memory
> overcommit for users such as KVM: we have a lot of COW pages, e.g.
> instances of the zero page or pages shared using KSM.
>
> If the application does not care that adapter sees stale data (for
> example, it tracks writes reregisters and resends), it can use a new
> IBV_ACCESS_GIFT flag to prevent registration from breaking COW.
>
> The semantics are similar to that of SPLICE_F_GIFT thus the name.
>
> Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>
> Please review and consider for 3.10.
>
> Changes from v1:
> rename APP_READONLY to _GIFT: similar to vmsplice's F_GIFT.
>
> drivers/infiniband/core/umem.c | 21 ++++++++++++---------
> include/rdma/ib_verbs.h | 9 ++++++++-
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index a841123..5dee86d 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -89,6 +89,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> int ret;
> int off;
> int i;
> + bool gift, writable;
> DEFINE_DMA_ATTRS(attrs);
>
> if (dmasync)
> @@ -96,6 +97,15 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
>
> if (!can_do_mlock())
> return ERR_PTR(-EPERM);
> + /*
> + * We ask for writable memory if any access flags other than
> + * "remote read" or "gift" are set. "Local write" and "remote write"
> + * obviously require write access. "Remote atomic" can do
> + * things like fetch and add, which will modify memory, and
> + * "MW bind" can change permissions by binding a window.
> + */
> + gift = access & IB_ACCESS_GIFT;
> + writable = access & ~(IB_ACCESS_REMOTE_READ | IB_ACCESS_GIFT);
>
> umem = kmalloc(sizeof *umem, GFP_KERNEL);
> if (!umem)
> @@ -105,14 +115,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> umem->length = size;
> umem->offset = addr & ~PAGE_MASK;
> umem->page_size = PAGE_SIZE;
> - /*
> - * We ask for writable memory if any access flags other than
> - * "remote read" are set. "Local write" and "remote write"
> - * obviously require write access. "Remote atomic" can do
> - * things like fetch and add, which will modify memory, and
> - * "MW bind" can change permissions by binding a window.
> - */
> - umem->writable = !!(access & ~IB_ACCESS_REMOTE_READ);
> + umem->writable = writable;
>
> /* We assume the memory is from hugetlb until proved otherwise */
> umem->hugetlb = 1;
> @@ -152,7 +155,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> ret = get_user_pages(current, current->mm, cur_base,
> min_t(unsigned long, npages,
> PAGE_SIZE / sizeof (struct page *)),
> - 1, !umem->writable, page_list, vma_list);
> + !gift, !umem->writable, page_list, vma_list);
>
> if (ret < 0)
> goto out;
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 98cc4b2..2e6e13c 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -871,7 +871,14 @@ enum ib_access_flags {
> IB_ACCESS_REMOTE_READ = (1<<2),
> IB_ACCESS_REMOTE_ATOMIC = (1<<3),
> IB_ACCESS_MW_BIND = (1<<4),
> - IB_ZERO_BASED = (1<<5)
> + IB_ZERO_BASED = (1<<5),
> + /*
> + * IB_ACCESS_GIFT: This memory is a gift to the adapter. If memory is
> + * modified after registration, the local version and data seen by the
> + * adapter through this region rkey may differ.
> + * Only legal with IB_ACCESS_REMOTE_READ or no permissions.
> + */
> + IB_ACCESS_GIFT = (1<<6)
> };
>
> struct ib_phys_buf {
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Roland Dreier <roland@kernel.org>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Sean Hefty <sean.hefty@intel.com>,
Hal Rosenstock <hal.rosenstock@gmail.com>,
Yishai Hadas <yishaih@mellanox.com>,
Christoph Lameter <cl@linux.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCHv2] rdma: add a new IB_ACCESS_GIFT flag
Date: Fri, 05 Apr 2013 16:17:36 -0400 [thread overview]
Message-ID: <515F3160.4020007@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130324155153.GA8597@redhat.com>
The userland part of the patch was missing (IBV_ACCESS_GIFT).
I added flag that to /usr/include in addition to this patch and did a
test RDMA migrate and it seems to work without any problems.
I also removed the IBV_*_WRITE flags on the sender-side and activated
cgroups with the "memory.memsw.limit_in_bytes" activated and the
migration with RDMA also succeeded without any problems (both with *and*
without GIFT also worked).
Any additional tests you would like?
- Michael
On 03/24/2013 11:51 AM, Michael S. Tsirkin wrote:
> At the moment registering an MR breaks COW. This breaks memory
> overcommit for users such as KVM: we have a lot of COW pages, e.g.
> instances of the zero page or pages shared using KSM.
>
> If the application does not care that adapter sees stale data (for
> example, it tracks writes reregisters and resends), it can use a new
> IBV_ACCESS_GIFT flag to prevent registration from breaking COW.
>
> The semantics are similar to that of SPLICE_F_GIFT thus the name.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Please review and consider for 3.10.
>
> Changes from v1:
> rename APP_READONLY to _GIFT: similar to vmsplice's F_GIFT.
>
> drivers/infiniband/core/umem.c | 21 ++++++++++++---------
> include/rdma/ib_verbs.h | 9 ++++++++-
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index a841123..5dee86d 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -89,6 +89,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> int ret;
> int off;
> int i;
> + bool gift, writable;
> DEFINE_DMA_ATTRS(attrs);
>
> if (dmasync)
> @@ -96,6 +97,15 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
>
> if (!can_do_mlock())
> return ERR_PTR(-EPERM);
> + /*
> + * We ask for writable memory if any access flags other than
> + * "remote read" or "gift" are set. "Local write" and "remote write"
> + * obviously require write access. "Remote atomic" can do
> + * things like fetch and add, which will modify memory, and
> + * "MW bind" can change permissions by binding a window.
> + */
> + gift = access & IB_ACCESS_GIFT;
> + writable = access & ~(IB_ACCESS_REMOTE_READ | IB_ACCESS_GIFT);
>
> umem = kmalloc(sizeof *umem, GFP_KERNEL);
> if (!umem)
> @@ -105,14 +115,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> umem->length = size;
> umem->offset = addr & ~PAGE_MASK;
> umem->page_size = PAGE_SIZE;
> - /*
> - * We ask for writable memory if any access flags other than
> - * "remote read" are set. "Local write" and "remote write"
> - * obviously require write access. "Remote atomic" can do
> - * things like fetch and add, which will modify memory, and
> - * "MW bind" can change permissions by binding a window.
> - */
> - umem->writable = !!(access & ~IB_ACCESS_REMOTE_READ);
> + umem->writable = writable;
>
> /* We assume the memory is from hugetlb until proved otherwise */
> umem->hugetlb = 1;
> @@ -152,7 +155,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> ret = get_user_pages(current, current->mm, cur_base,
> min_t(unsigned long, npages,
> PAGE_SIZE / sizeof (struct page *)),
> - 1, !umem->writable, page_list, vma_list);
> + !gift, !umem->writable, page_list, vma_list);
>
> if (ret < 0)
> goto out;
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 98cc4b2..2e6e13c 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -871,7 +871,14 @@ enum ib_access_flags {
> IB_ACCESS_REMOTE_READ = (1<<2),
> IB_ACCESS_REMOTE_ATOMIC = (1<<3),
> IB_ACCESS_MW_BIND = (1<<4),
> - IB_ZERO_BASED = (1<<5)
> + IB_ZERO_BASED = (1<<5),
> + /*
> + * IB_ACCESS_GIFT: This memory is a gift to the adapter. If memory is
> + * modified after registration, the local version and data seen by the
> + * adapter through this region rkey may differ.
> + * Only legal with IB_ACCESS_REMOTE_READ or no permissions.
> + */
> + IB_ACCESS_GIFT = (1<<6)
> };
>
> struct ib_phys_buf {
WARNING: multiple messages have this Message-ID (diff)
From: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Roland Dreier <roland@kernel.org>,
qemu-devel@nongnu.org,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Yishai Hadas <yishaih@mellanox.com>,
LKML <linux-kernel@vger.kernel.org>,
Hal Rosenstock <hal.rosenstock@gmail.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Sean Hefty <sean.hefty@intel.com>,
Christoph Lameter <cl@linux.com>
Subject: Re: [Qemu-devel] [PATCHv2] rdma: add a new IB_ACCESS_GIFT flag
Date: Fri, 05 Apr 2013 16:17:36 -0400 [thread overview]
Message-ID: <515F3160.4020007@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130324155153.GA8597@redhat.com>
The userland part of the patch was missing (IBV_ACCESS_GIFT).
I added flag that to /usr/include in addition to this patch and did a
test RDMA migrate and it seems to work without any problems.
I also removed the IBV_*_WRITE flags on the sender-side and activated
cgroups with the "memory.memsw.limit_in_bytes" activated and the
migration with RDMA also succeeded without any problems (both with *and*
without GIFT also worked).
Any additional tests you would like?
- Michael
On 03/24/2013 11:51 AM, Michael S. Tsirkin wrote:
> At the moment registering an MR breaks COW. This breaks memory
> overcommit for users such as KVM: we have a lot of COW pages, e.g.
> instances of the zero page or pages shared using KSM.
>
> If the application does not care that adapter sees stale data (for
> example, it tracks writes reregisters and resends), it can use a new
> IBV_ACCESS_GIFT flag to prevent registration from breaking COW.
>
> The semantics are similar to that of SPLICE_F_GIFT thus the name.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Please review and consider for 3.10.
>
> Changes from v1:
> rename APP_READONLY to _GIFT: similar to vmsplice's F_GIFT.
>
> drivers/infiniband/core/umem.c | 21 ++++++++++++---------
> include/rdma/ib_verbs.h | 9 ++++++++-
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index a841123..5dee86d 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -89,6 +89,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> int ret;
> int off;
> int i;
> + bool gift, writable;
> DEFINE_DMA_ATTRS(attrs);
>
> if (dmasync)
> @@ -96,6 +97,15 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
>
> if (!can_do_mlock())
> return ERR_PTR(-EPERM);
> + /*
> + * We ask for writable memory if any access flags other than
> + * "remote read" or "gift" are set. "Local write" and "remote write"
> + * obviously require write access. "Remote atomic" can do
> + * things like fetch and add, which will modify memory, and
> + * "MW bind" can change permissions by binding a window.
> + */
> + gift = access & IB_ACCESS_GIFT;
> + writable = access & ~(IB_ACCESS_REMOTE_READ | IB_ACCESS_GIFT);
>
> umem = kmalloc(sizeof *umem, GFP_KERNEL);
> if (!umem)
> @@ -105,14 +115,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> umem->length = size;
> umem->offset = addr & ~PAGE_MASK;
> umem->page_size = PAGE_SIZE;
> - /*
> - * We ask for writable memory if any access flags other than
> - * "remote read" are set. "Local write" and "remote write"
> - * obviously require write access. "Remote atomic" can do
> - * things like fetch and add, which will modify memory, and
> - * "MW bind" can change permissions by binding a window.
> - */
> - umem->writable = !!(access & ~IB_ACCESS_REMOTE_READ);
> + umem->writable = writable;
>
> /* We assume the memory is from hugetlb until proved otherwise */
> umem->hugetlb = 1;
> @@ -152,7 +155,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> ret = get_user_pages(current, current->mm, cur_base,
> min_t(unsigned long, npages,
> PAGE_SIZE / sizeof (struct page *)),
> - 1, !umem->writable, page_list, vma_list);
> + !gift, !umem->writable, page_list, vma_list);
>
> if (ret < 0)
> goto out;
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 98cc4b2..2e6e13c 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -871,7 +871,14 @@ enum ib_access_flags {
> IB_ACCESS_REMOTE_READ = (1<<2),
> IB_ACCESS_REMOTE_ATOMIC = (1<<3),
> IB_ACCESS_MW_BIND = (1<<4),
> - IB_ZERO_BASED = (1<<5)
> + IB_ZERO_BASED = (1<<5),
> + /*
> + * IB_ACCESS_GIFT: This memory is a gift to the adapter. If memory is
> + * modified after registration, the local version and data seen by the
> + * adapter through this region rkey may differ.
> + * Only legal with IB_ACCESS_REMOTE_READ or no permissions.
> + */
> + IB_ACCESS_GIFT = (1<<6)
> };
>
> struct ib_phys_buf {
next prev parent reply other threads:[~2013-04-05 20:17 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-24 15:51 [PATCHv2] rdma: add a new IB_ACCESS_GIFT flag Michael S. Tsirkin
2013-03-24 15:51 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-02 15:51 ` Michael S. Tsirkin
2013-04-02 15:51 ` [Qemu-devel] " Michael S. Tsirkin
[not found] ` <20130402155104.GA27382-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-02 16:57 ` Roland Dreier
2013-04-02 16:57 ` [Qemu-devel] " Roland Dreier
2013-04-02 16:57 ` Roland Dreier
[not found] ` <CAL1RGDUe1=Xd1mpNajiLY08fJ+gBKAMDGeX3SVkS+egOQyiCxQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-02 17:05 ` Michael S. Tsirkin
2013-04-02 17:05 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-02 17:05 ` Michael S. Tsirkin
2013-04-02 22:17 ` Michael R. Hines
2013-04-02 22:17 ` [Qemu-devel] " Michael R. Hines
2013-04-02 22:17 ` Michael R. Hines
[not found] ` <20130402170521.GA30295-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-03 16:07 ` Michael S. Tsirkin
2013-04-03 16:07 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-03 16:07 ` Michael S. Tsirkin
[not found] ` <20130324155153.GA8597-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-05 20:17 ` Michael R. Hines [this message]
2013-04-05 20:17 ` [Qemu-devel] " Michael R. Hines
2013-04-05 20:17 ` Michael R. Hines
2013-04-05 20:43 ` Roland Dreier
2013-04-05 20:43 ` [Qemu-devel] " Roland Dreier
2013-04-05 20:54 ` Michael R. Hines
2013-04-05 20:54 ` [Qemu-devel] " Michael R. Hines
[not found] ` <515F3A0F.5030507-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-09 16:39 ` Michael S. Tsirkin
2013-04-09 16:39 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-09 16:39 ` Michael S. Tsirkin
[not found] ` <20130409163929.GA7661-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-09 17:56 ` Michael R. Hines
2013-04-09 17:56 ` [Qemu-devel] " Michael R. Hines
2013-04-09 17:56 ` Michael R. Hines
[not found] ` <51645630.3030608-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-09 19:00 ` Michael S. Tsirkin
2013-04-09 19:00 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-09 19:00 ` Michael S. Tsirkin
[not found] ` <CAL1RGDU2jtrRrxi6srsH_ADiYGvJbCpCT3UvoLGTX3cvQ=s0kQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-05 20:51 ` Michael R. Hines
2013-04-05 20:51 ` [Qemu-devel] " Michael R. Hines
2013-04-05 20:51 ` Michael R. Hines
[not found] ` <515F3948.40205-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-05 21:03 ` Roland Dreier
2013-04-05 21:03 ` [Qemu-devel] " Roland Dreier
2013-04-05 21:03 ` Roland Dreier
[not found] ` <CAG4TOxPNHZadLjq6-HuOExf1XXLO6AYyvRQ1L09i6qVeA5dbLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-05 21:32 ` Michael R. Hines
2013-04-05 21:32 ` [Qemu-devel] " Michael R. Hines
2013-04-05 21:32 ` Michael R. Hines
[not found] ` <515F42EE.8060203-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-09 19:03 ` Michael S. Tsirkin
2013-04-09 19:03 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-09 19:03 ` Michael S. Tsirkin
[not found] ` <20130409190350.GB8212-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-10 1:26 ` Michael R. Hines
2013-04-10 1:26 ` [Qemu-devel] " Michael R. Hines
2013-04-10 1:26 ` Michael R. Hines
2013-04-10 3:24 ` Michael S. Tsirkin
2013-04-10 3:24 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-10 3:24 ` Michael S. Tsirkin
[not found] ` <20130410032449.GA12777-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-10 4:32 ` Michael R. Hines
2013-04-10 4:32 ` [Qemu-devel] " Michael R. Hines
2013-04-10 4:32 ` Michael R. Hines
[not found] ` <5164EB5F.80403-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-10 5:32 ` Michael S. Tsirkin
2013-04-10 5:32 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-10 5:32 ` Michael S. Tsirkin
2013-04-10 15:48 ` Michael R. Hines
2013-04-10 15:48 ` [Qemu-devel] " Michael R. Hines
[not found] ` <516589C8.1040606-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-10 15:05 ` Michael S. Tsirkin
2013-04-10 15:05 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-10 15:05 ` Michael S. Tsirkin
[not found] ` <20130410150539.GA24381-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-10 16:28 ` Michael R. Hines
2013-04-10 16:28 ` [Qemu-devel] " Michael R. Hines
2013-04-10 16:28 ` Michael R. Hines
2013-04-09 19:09 ` Michael S. Tsirkin
2013-04-09 19:09 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-09 19:09 ` Michael S. Tsirkin
2013-04-09 19:12 ` Michael S. Tsirkin
2013-04-09 19:12 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-09 19:12 ` Michael S. Tsirkin
[not found] ` <515F3160.4020007-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-09 20:34 ` Michael S. Tsirkin
2013-04-09 20:34 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-09 20:34 ` Michael S. Tsirkin
[not found] ` <20130409203409.GA9246-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-09 20:37 ` Michael S. Tsirkin
2013-04-09 20:37 ` [Qemu-devel] " Michael S. Tsirkin
2013-04-09 20:37 ` Michael S. Tsirkin
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=515F3160.4020007@linux.vnet.ibm.com \
--to=mrhines-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
--cc=cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org \
--cc=hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
--cc=roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.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.