All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: peter.maydell@linaro.org, kevin.tian@intel.com,
	drjones@redhat.com, mst@redhat.com,
	jean-philippe.brucker@arm.com, tn@semihalf.com,
	will.deacon@arm.com, qemu-devel@nongnu.org, marc.zyngier@arm.com,
	alex.williamson@redhat.com, qemu-arm@nongnu.org,
	robin.murphy@arm.com, bharat.bhushan@nxp.com,
	christoffer.dall@linaro.org, eric.auger.pro@gmail.com
Subject: Re: [Qemu-arm] [Qemu-devel] [RFC v2 6/8] virtio-iommu: Implement the translation and commands
Date: Fri, 14 Jul 2017 10:17:33 +0800	[thread overview]
Message-ID: <20170714021733.GA27284@pxdev.xzpeter.org> (raw)
In-Reply-To: <1496851287-9428-7-git-send-email-eric.auger@redhat.com>

On Wed, Jun 07, 2017 at 06:01:25PM +0200, Eric Auger wrote:
> This patch adds the actual implementation for the translation routine
> and the virtio-iommu commands.
> 
> Signed-off-by: Eric Auger <eric.auger@redhat.com>

[...]

>  static int virtio_iommu_attach(VirtIOIOMMU *s,
>                                 struct virtio_iommu_req_attach *req)
> @@ -95,10 +135,34 @@ static int virtio_iommu_attach(VirtIOIOMMU *s,
>      uint32_t asid = le32_to_cpu(req->address_space);
>      uint32_t devid = le32_to_cpu(req->device);
>      uint32_t reserved = le32_to_cpu(req->reserved);
> +    viommu_as *as;
> +    viommu_dev *dev;
>  
>      trace_virtio_iommu_attach(asid, devid, reserved);
>  
> -    return VIRTIO_IOMMU_S_UNSUPP;
> +    dev = g_tree_lookup(s->devices, GUINT_TO_POINTER(devid));
> +    if (dev) {
> +        return -1;
> +    }
> +
> +    as = g_tree_lookup(s->address_spaces, GUINT_TO_POINTER(asid));
> +    if (!as) {
> +        as = g_malloc0(sizeof(*as));
> +        as->id = asid;
> +        as->mappings = g_tree_new_full((GCompareDataFunc)interval_cmp,
> +                                         NULL, NULL, (GDestroyNotify)g_free);
> +        g_tree_insert(s->address_spaces, GUINT_TO_POINTER(asid), as);
> +        trace_virtio_iommu_new_asid(asid);
> +    }
> +
> +    dev = g_malloc0(sizeof(*dev));
> +    dev->as = as;
> +    dev->id = devid;
> +    as->nr_devices++;
> +    trace_virtio_iommu_new_devid(devid);
> +    g_tree_insert(s->devices, GUINT_TO_POINTER(devid), dev);

Here do we need to record something like a refcount for address space?
Since...

> +
> +    return VIRTIO_IOMMU_S_OK;
>  }
>  
>  static int virtio_iommu_detach(VirtIOIOMMU *s,
> @@ -106,10 +170,13 @@ static int virtio_iommu_detach(VirtIOIOMMU *s,
>  {
>      uint32_t devid = le32_to_cpu(req->device);
>      uint32_t reserved = le32_to_cpu(req->reserved);
> +    int ret;
>  
>      trace_virtio_iommu_detach(devid, reserved);
>  
> -    return VIRTIO_IOMMU_S_UNSUPP;
> +    ret = g_tree_remove(s->devices, GUINT_TO_POINTER(devid));

... here when detach, imho we should check the refcount: if there is
no device using specific address space, we should release the address
space as well.

Otherwise there would have no way to destroy an address space?

> +
> +    return ret ? VIRTIO_IOMMU_S_OK : VIRTIO_IOMMU_S_INVAL;
>  }

[...]

>  static int virtio_iommu_unmap(VirtIOIOMMU *s,
> @@ -133,10 +227,64 @@ static int virtio_iommu_unmap(VirtIOIOMMU *s,
>      uint64_t virt_addr = le64_to_cpu(req->virt_addr);
>      uint64_t size = le64_to_cpu(req->size);
>      uint32_t flags = le32_to_cpu(req->flags);
> +    viommu_mapping *mapping;
> +    viommu_interval interval;
> +    viommu_as *as;
>  
>      trace_virtio_iommu_unmap(asid, virt_addr, size, flags);
>  
> -    return VIRTIO_IOMMU_S_UNSUPP;
> +    as = g_tree_lookup(s->address_spaces, GUINT_TO_POINTER(asid));
> +    if (!as) {
> +        error_report("%s: no as", __func__);
> +        return VIRTIO_IOMMU_S_INVAL;
> +    }
> +    interval.low = virt_addr;
> +    interval.high = virt_addr + size - 1;
> +
> +    mapping = g_tree_lookup(as->mappings, (gpointer)&interval);
> +
> +    while (mapping) {
> +        viommu_interval current;
> +        uint64_t low  = mapping->virt_addr;
> +        uint64_t high = mapping->virt_addr + mapping->size - 1;
> +
> +        current.low = low;
> +        current.high = high;
> +
> +        if (low == interval.low && size >= mapping->size) {
> +            g_tree_remove(as->mappings, (gpointer)&current);
> +            interval.low = high + 1;
> +            trace_virtio_iommu_unmap_left_interval(current.low, current.high,
> +                interval.low, interval.high);
> +        } else if (high == interval.high && size >= mapping->size) {
> +            trace_virtio_iommu_unmap_right_interval(current.low, current.high,
> +                interval.low, interval.high);
> +            g_tree_remove(as->mappings, (gpointer)&current);
> +            interval.high = low - 1;
> +        } else if (low > interval.low && high < interval.high) {
> +            trace_virtio_iommu_unmap_inc_interval(current.low, current.high);
> +            g_tree_remove(as->mappings, (gpointer)&current);
> +        } else {
> +            break;
> +        }
> +        if (interval.low >= interval.high) {
> +            return VIRTIO_IOMMU_S_OK;
> +        } else {
> +            mapping = g_tree_lookup(as->mappings, (gpointer)&interval);
> +        }
> +    }

IIUC for unmap here we are very strict - a extreme case is that when
an address space is just created (so no mapping inside), if we send
one UNMAP to a range, it'll fail currently, right? Should we loosen
it?

IMHO as long as we make sure all the mappings in the range of an UNMAP
request are destroyed, then we are good. I think at least both vfio
api and vt-d emuation have this assumption. But maybe I am wrong.
Please correct me if so.

> +
> +    if (mapping) {
> +        error_report("****** %s: Unmap 0x%"PRIx64" size=0x%"PRIx64
> +                     " from 0x%"PRIx64" size=0x%"PRIx64" is not supported",
> +                     __func__, interval.low, size,
> +                     mapping->virt_addr, mapping->size);
> +    } else {
> +        error_report("****** %s: no mapping for [0x%"PRIx64",0x%"PRIx64"]",
> +                     __func__, interval.low, interval.high);
> +    }
> +
> +    return VIRTIO_IOMMU_S_INVAL;
>  }

Thanks,

-- 
Peter Xu

WARNING: multiple messages have this Message-ID (diff)
From: Peter Xu <peterx@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: eric.auger.pro@gmail.com, peter.maydell@linaro.org,
	alex.williamson@redhat.com, mst@redhat.com, qemu-arm@nongnu.org,
	qemu-devel@nongnu.org, jean-philippe.brucker@arm.com,
	wei@redhat.com, kevin.tian@intel.com, bharat.bhushan@nxp.com,
	marc.zyngier@arm.com, tn@semihalf.com, will.deacon@arm.com,
	drjones@redhat.com, robin.murphy@arm.com,
	christoffer.dall@linaro.org
Subject: Re: [Qemu-devel] [RFC v2 6/8] virtio-iommu: Implement the translation and commands
Date: Fri, 14 Jul 2017 10:17:33 +0800	[thread overview]
Message-ID: <20170714021733.GA27284@pxdev.xzpeter.org> (raw)
In-Reply-To: <1496851287-9428-7-git-send-email-eric.auger@redhat.com>

On Wed, Jun 07, 2017 at 06:01:25PM +0200, Eric Auger wrote:
> This patch adds the actual implementation for the translation routine
> and the virtio-iommu commands.
> 
> Signed-off-by: Eric Auger <eric.auger@redhat.com>

[...]

>  static int virtio_iommu_attach(VirtIOIOMMU *s,
>                                 struct virtio_iommu_req_attach *req)
> @@ -95,10 +135,34 @@ static int virtio_iommu_attach(VirtIOIOMMU *s,
>      uint32_t asid = le32_to_cpu(req->address_space);
>      uint32_t devid = le32_to_cpu(req->device);
>      uint32_t reserved = le32_to_cpu(req->reserved);
> +    viommu_as *as;
> +    viommu_dev *dev;
>  
>      trace_virtio_iommu_attach(asid, devid, reserved);
>  
> -    return VIRTIO_IOMMU_S_UNSUPP;
> +    dev = g_tree_lookup(s->devices, GUINT_TO_POINTER(devid));
> +    if (dev) {
> +        return -1;
> +    }
> +
> +    as = g_tree_lookup(s->address_spaces, GUINT_TO_POINTER(asid));
> +    if (!as) {
> +        as = g_malloc0(sizeof(*as));
> +        as->id = asid;
> +        as->mappings = g_tree_new_full((GCompareDataFunc)interval_cmp,
> +                                         NULL, NULL, (GDestroyNotify)g_free);
> +        g_tree_insert(s->address_spaces, GUINT_TO_POINTER(asid), as);
> +        trace_virtio_iommu_new_asid(asid);
> +    }
> +
> +    dev = g_malloc0(sizeof(*dev));
> +    dev->as = as;
> +    dev->id = devid;
> +    as->nr_devices++;
> +    trace_virtio_iommu_new_devid(devid);
> +    g_tree_insert(s->devices, GUINT_TO_POINTER(devid), dev);

Here do we need to record something like a refcount for address space?
Since...

> +
> +    return VIRTIO_IOMMU_S_OK;
>  }
>  
>  static int virtio_iommu_detach(VirtIOIOMMU *s,
> @@ -106,10 +170,13 @@ static int virtio_iommu_detach(VirtIOIOMMU *s,
>  {
>      uint32_t devid = le32_to_cpu(req->device);
>      uint32_t reserved = le32_to_cpu(req->reserved);
> +    int ret;
>  
>      trace_virtio_iommu_detach(devid, reserved);
>  
> -    return VIRTIO_IOMMU_S_UNSUPP;
> +    ret = g_tree_remove(s->devices, GUINT_TO_POINTER(devid));

... here when detach, imho we should check the refcount: if there is
no device using specific address space, we should release the address
space as well.

Otherwise there would have no way to destroy an address space?

> +
> +    return ret ? VIRTIO_IOMMU_S_OK : VIRTIO_IOMMU_S_INVAL;
>  }

[...]

>  static int virtio_iommu_unmap(VirtIOIOMMU *s,
> @@ -133,10 +227,64 @@ static int virtio_iommu_unmap(VirtIOIOMMU *s,
>      uint64_t virt_addr = le64_to_cpu(req->virt_addr);
>      uint64_t size = le64_to_cpu(req->size);
>      uint32_t flags = le32_to_cpu(req->flags);
> +    viommu_mapping *mapping;
> +    viommu_interval interval;
> +    viommu_as *as;
>  
>      trace_virtio_iommu_unmap(asid, virt_addr, size, flags);
>  
> -    return VIRTIO_IOMMU_S_UNSUPP;
> +    as = g_tree_lookup(s->address_spaces, GUINT_TO_POINTER(asid));
> +    if (!as) {
> +        error_report("%s: no as", __func__);
> +        return VIRTIO_IOMMU_S_INVAL;
> +    }
> +    interval.low = virt_addr;
> +    interval.high = virt_addr + size - 1;
> +
> +    mapping = g_tree_lookup(as->mappings, (gpointer)&interval);
> +
> +    while (mapping) {
> +        viommu_interval current;
> +        uint64_t low  = mapping->virt_addr;
> +        uint64_t high = mapping->virt_addr + mapping->size - 1;
> +
> +        current.low = low;
> +        current.high = high;
> +
> +        if (low == interval.low && size >= mapping->size) {
> +            g_tree_remove(as->mappings, (gpointer)&current);
> +            interval.low = high + 1;
> +            trace_virtio_iommu_unmap_left_interval(current.low, current.high,
> +                interval.low, interval.high);
> +        } else if (high == interval.high && size >= mapping->size) {
> +            trace_virtio_iommu_unmap_right_interval(current.low, current.high,
> +                interval.low, interval.high);
> +            g_tree_remove(as->mappings, (gpointer)&current);
> +            interval.high = low - 1;
> +        } else if (low > interval.low && high < interval.high) {
> +            trace_virtio_iommu_unmap_inc_interval(current.low, current.high);
> +            g_tree_remove(as->mappings, (gpointer)&current);
> +        } else {
> +            break;
> +        }
> +        if (interval.low >= interval.high) {
> +            return VIRTIO_IOMMU_S_OK;
> +        } else {
> +            mapping = g_tree_lookup(as->mappings, (gpointer)&interval);
> +        }
> +    }

IIUC for unmap here we are very strict - a extreme case is that when
an address space is just created (so no mapping inside), if we send
one UNMAP to a range, it'll fail currently, right? Should we loosen
it?

IMHO as long as we make sure all the mappings in the range of an UNMAP
request are destroyed, then we are good. I think at least both vfio
api and vt-d emuation have this assumption. But maybe I am wrong.
Please correct me if so.

> +
> +    if (mapping) {
> +        error_report("****** %s: Unmap 0x%"PRIx64" size=0x%"PRIx64
> +                     " from 0x%"PRIx64" size=0x%"PRIx64" is not supported",
> +                     __func__, interval.low, size,
> +                     mapping->virt_addr, mapping->size);
> +    } else {
> +        error_report("****** %s: no mapping for [0x%"PRIx64",0x%"PRIx64"]",
> +                     __func__, interval.low, interval.high);
> +    }
> +
> +    return VIRTIO_IOMMU_S_INVAL;
>  }

Thanks,

-- 
Peter Xu

  parent reply	other threads:[~2017-07-14  2:27 UTC|newest]

Thread overview: 145+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-07 16:01 [Qemu-arm] [RFC v2 0/8] VIRTIO-IOMMU device Eric Auger
2017-06-07 16:01 ` [Qemu-devel] " Eric Auger
2017-06-07 16:01 ` [Qemu-arm] [RFC v2 1/8] update-linux-headers: import virtio_iommu.h Eric Auger
2017-06-07 16:01   ` [Qemu-devel] " Eric Auger
2017-06-07 16:01 ` [Qemu-arm] [RFC v2 2/8] linux-headers: Update for virtio-iommu Eric Auger
2017-06-07 16:01   ` [Qemu-devel] " Eric Auger
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 3/8] virtio_iommu: add skeleton Eric Auger
2017-06-07 16:01   ` Eric Auger
2017-06-08 11:09   ` Bharat Bhushan
2017-06-08 11:09     ` Bharat Bhushan
2017-06-23 16:08     ` [Qemu-arm] " Jean-Philippe Brucker
2017-06-23 16:08       ` [Qemu-devel] " Jean-Philippe Brucker
2017-06-07 16:01 ` [Qemu-arm] [RFC v2 4/8] virtio-iommu: Decode the command payload Eric Auger
2017-06-07 16:01   ` [Qemu-devel] " Eric Auger
2017-06-07 16:01 ` [Qemu-arm] [RFC v2 5/8] virtio_iommu: Add the iommu regions Eric Auger
2017-06-07 16:01   ` [Qemu-devel] " Eric Auger
2017-06-12  5:59   ` [Qemu-arm] " Bharat Bhushan
2017-06-12  5:59     ` [Qemu-devel] " Bharat Bhushan
2017-06-07 16:01 ` [Qemu-arm] [RFC v2 6/8] virtio-iommu: Implement the translation and commands Eric Auger
2017-06-07 16:01   ` [Qemu-devel] " Eric Auger
2017-06-23 16:09   ` [Qemu-arm] " Jean-Philippe Brucker
2017-06-23 16:09     ` [Qemu-devel] " Jean-Philippe Brucker
2017-07-04  9:13   ` [Qemu-arm] " Bharat Bhushan
2017-07-04  9:13     ` [Qemu-devel] " Bharat Bhushan
2017-07-05  6:40     ` [Qemu-arm] " Auger Eric
2017-07-05  6:40       ` Auger Eric
2017-07-14  2:17   ` Peter Xu [this message]
2017-07-14  2:17     ` Peter Xu
2017-07-14  6:40     ` [Qemu-arm] " Bharat Bhushan
2017-07-14  6:40       ` Bharat Bhushan
2017-07-17  1:28       ` [Qemu-arm] " Peter Xu
2017-07-17  1:28         ` Peter Xu
2017-07-31 13:08         ` [Qemu-arm] " Auger Eric
2017-07-31 13:08           ` Auger Eric
2017-08-03 10:48           ` [Qemu-arm] " Bharat Bhushan
2017-08-03 10:48             ` Bharat Bhushan
2017-07-14 11:25     ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-14 11:25       ` Jean-Philippe Brucker
2017-07-17  1:37       ` [Qemu-arm] " Peter Xu
2017-07-17  1:37         ` Peter Xu
2017-06-07 16:01 ` [Qemu-arm] [RFC v2 7/8] hw/arm/virt: Add 2.10 machine type Eric Auger
2017-06-07 16:01   ` [Qemu-devel] " Eric Auger
2017-06-07 16:01 ` [Qemu-arm] [RFC v2 8/8] hw/arm/virt: Add virtio-iommu the virt board Eric Auger
2017-06-07 16:01   ` [Qemu-devel] " Eric Auger
2017-06-09  6:16 ` [Qemu-arm] [RFC v2 0/8] VIRTIO-IOMMU device Bharat Bhushan
2017-06-09  6:16   ` [Qemu-devel] " Bharat Bhushan
2017-06-09  6:43   ` [Qemu-arm] " Auger Eric
2017-06-09  6:43     ` [Qemu-devel] " Auger Eric
2017-06-09 11:30     ` [Qemu-arm] " Bharat Bhushan
2017-06-09 11:30       ` [Qemu-devel] " Bharat Bhushan
2017-06-09 11:53       ` [Qemu-arm] " Auger Eric
2017-06-09 11:53         ` Auger Eric
2017-06-19  7:54         ` [Qemu-arm] " Bharat Bhushan
2017-06-19  7:54           ` Bharat Bhushan
2017-06-19 10:15           ` [Qemu-arm] " Jean-Philippe Brucker
2017-06-19 10:15             ` Jean-Philippe Brucker
2017-06-26  8:22             ` [Qemu-arm] " Auger Eric
2017-06-26  8:22               ` Auger Eric
2017-06-26 16:13               ` [Qemu-arm] " Jean-Philippe Brucker
2017-06-26 16:13                 ` Jean-Philippe Brucker
2017-06-27  6:38                 ` [Qemu-arm] " Auger Eric
2017-06-27  6:38                   ` Auger Eric
2017-06-27  8:46                   ` [Qemu-arm] " Will Deacon
2017-06-27  8:46                     ` Will Deacon
2017-06-27  8:59                     ` [Qemu-arm] " Auger Eric
2017-06-27  8:59                       ` Auger Eric
2017-07-05  7:25                 ` Tian, Kevin
2017-07-05  7:25                   ` Tian, Kevin
2017-07-05 12:44                   ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-05 12:44                     ` Jean-Philippe Brucker
2017-07-05  7:14             ` Tian, Kevin
2017-07-05  7:14               ` Tian, Kevin
2017-07-05 12:44               ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-05 12:44                 ` Jean-Philippe Brucker
2017-07-07  6:21                 ` [Qemu-arm] " Tian, Kevin
2017-07-07  6:21                   ` Tian, Kevin
2017-07-07 15:15                   ` Jean-Philippe Brucker
2017-07-07 15:15                     ` Jean-Philippe Brucker
2017-07-14  7:20                     ` [Qemu-arm] " Tian, Kevin
2017-07-14  7:20                       ` Tian, Kevin
2017-07-14 11:25                       ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-14 11:25                         ` Jean-Philippe Brucker
2017-07-17  2:20                         ` [Qemu-arm] " Tian, Kevin
2017-07-17  2:20                           ` Tian, Kevin
2017-07-05  7:15             ` [Qemu-arm] " Bharat Bhushan
2017-07-05  7:15               ` Bharat Bhushan
2017-06-26  7:54           ` [Qemu-arm] " Auger Eric
2017-06-26  7:54             ` Auger Eric
2017-07-05  8:23             ` [Qemu-arm] " Bharat Bhushan
2017-07-05  8:23               ` Bharat Bhushan
2017-07-05  8:44               ` [Qemu-arm] " Auger Eric
2017-07-05  8:44                 ` Auger Eric
2017-07-05  8:49                 ` [Qemu-arm] " Bharat Bhushan
2017-07-05  8:49                   ` Bharat Bhushan
2017-07-06 10:02                   ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-06 10:02                     ` Jean-Philippe Brucker
2017-07-06 11:24                     ` [Qemu-arm] " Bharat Bhushan
2017-07-06 11:24                       ` Bharat Bhushan
2017-07-06 11:55                       ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-06 11:55                         ` Jean-Philippe Brucker
2017-07-06 21:16                       ` [Qemu-arm] " Auger Eric
2017-07-06 21:16                         ` Auger Eric
2017-07-06 23:23                         ` [Qemu-arm] " Kalra, Ashish
2017-07-06 23:23                           ` [Qemu-devel] [Qemu-arm] " Kalra, Ashish
2017-07-06 23:29                           ` [Qemu-arm] [Qemu-devel] " Michael S. Tsirkin
2017-07-06 23:29                             ` [Qemu-devel] [Qemu-arm] " Michael S. Tsirkin
2017-07-06 23:33                           ` [Qemu-arm] [Qemu-devel] " Tian, Kevin
2017-07-06 23:33                             ` [Qemu-devel] [Qemu-arm] " Tian, Kevin
2017-07-07 15:14                             ` [Qemu-arm] [Qemu-devel] " Jean-Philippe Brucker
2017-07-07 15:14                               ` [Qemu-devel] [Qemu-arm] " Jean-Philippe Brucker
2017-07-07 22:11                               ` [Qemu-arm] [Qemu-devel] " Kalra, Ashish
2017-07-07 22:11                                 ` [Qemu-devel] [Qemu-arm] " Kalra, Ashish
2017-07-11 11:31                                 ` [Qemu-arm] [Qemu-devel] " Jean-Philippe Brucker
2017-07-11 11:31                                   ` [Qemu-devel] [Qemu-arm] " Jean-Philippe Brucker
2017-07-14  6:58                               ` [Qemu-arm] [Qemu-devel] " Tian, Kevin
2017-07-14  6:58                                 ` [Qemu-devel] [Qemu-arm] " Tian, Kevin
2017-07-07  6:25                         ` [Qemu-arm] [Qemu-devel] " Bharat Bhushan
2017-07-07  6:25                           ` Bharat Bhushan
2017-07-07  7:25                           ` [Qemu-arm] " Auger Eric
2017-07-07  7:25                             ` Auger Eric
2017-07-07 11:36                             ` [Qemu-arm] " Bharat Bhushan
2017-07-07 11:36                               ` Bharat Bhushan
2017-07-07 15:19                               ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-07 15:19                                 ` Jean-Philippe Brucker
2017-07-11  5:54                                 ` [Qemu-arm] " Bharat Bhushan
2017-07-11  5:54                                   ` Bharat Bhushan
2017-07-11 12:51                                   ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-11 12:51                                     ` Jean-Philippe Brucker
2017-07-12  3:50                                     ` [Qemu-arm] " Bharat Bhushan
2017-07-12  3:50                                       ` Bharat Bhushan
2017-07-12 10:18                                       ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-12 10:18                                         ` Jean-Philippe Brucker
2017-07-12 10:27                                         ` [Qemu-arm] " Bharat Bhushan
2017-07-12 10:27                                           ` Bharat Bhushan
2017-07-12 10:58                                           ` Jean-Philippe Brucker
2017-07-12 11:12                                             ` [Qemu-arm] " Bharat Bhushan
2017-07-12 11:12                                               ` Bharat Bhushan
2017-07-06 21:11                     ` [Qemu-arm] " Auger Eric
2017-07-06 21:11                       ` Auger Eric
2017-07-07  7:31                       ` [Qemu-arm] " Auger Eric
2017-07-07  7:31                         ` Auger Eric
2017-07-07 15:20                       ` [Qemu-arm] " Jean-Philippe Brucker
2017-07-07 15:20                         ` Jean-Philippe Brucker
2017-06-09 12:15       ` [Qemu-arm] " Auger Eric
2017-06-09 12:15         ` [Qemu-devel] " Auger Eric

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=20170714021733.GA27284@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=bharat.bhushan@nxp.com \
    --cc=christoffer.dall@linaro.org \
    --cc=drjones@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=kevin.tian@intel.com \
    --cc=marc.zyngier@arm.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=robin.murphy@arm.com \
    --cc=tn@semihalf.com \
    --cc=will.deacon@arm.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 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.