All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: peter.maydell@linaro.org, drjones@redhat.com, david@redhat.com,
	qemu-devel@nongnu.org, shameerali.kolothum.thodi@huawei.com,
	dgilbert@redhat.com, qemu-arm@nongnu.org,
	david@gibson.dropbear.id.au, eric.auger.pro@gmail.com
Subject: Re: [Qemu-devel] [PATCH v7 03/17] hw/arm/virt: Split the memory map description
Date: Thu, 21 Feb 2019 17:19:44 +0100	[thread overview]
Message-ID: <20190221171944.1cc65a33@redhat.com> (raw)
In-Reply-To: <20190220224003.4420-4-eric.auger@redhat.com>

On Wed, 20 Feb 2019 23:39:49 +0100
Eric Auger <eric.auger@redhat.com> wrote:

> In the prospect to introduce an extended memory map supporting more
> RAM, let's split the memory map array into two parts:
> 
> - the former a15memmap contains regions below and including the RAM

> - extended_memmap, only initialized with entries located after the RAM.
>   Only the size of the region is initialized there since their base
>   address will be dynamically computed, depending on the top of the
>   RAM (initial RAM at the moment), with same alignment as their size.
can't parse this part and pinpoint what is 'their', care to rephrase?


> This new split will allow to grow the RAM size without changing the
> description of the high regions.
> 
> The patch also moves the memory map setup
s/moves/makes/
s/$/dynamic and moves it/

> into machvirt_init().

> The rationale is the memory map will be soon affected by the

> kvm_type() call that happens after virt_instance_init() and
is dependency on kvm_type() still valid,
shouldn't split memmap work for TCG just fine as well?

> before machvirt_init().
> 
> The memory map is unchanged (the top of the initial RAM still is
> 256GiB). Then come the high IO regions with same layout as before.
> 
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> 
> ---
> v6 -> v7:
> - s/a15memmap/base_memmap
> - slight rewording of the commit message
> - add "if there is less than 256GiB of RAM then the floating area
>   starts at the 256GiB mark" in the comment associated to the floating
>   memory map
> - Added Peter's R-b
> 
> v5 -> v6
> - removal of many macros in units.h
> - introduce the virt_set_memmap helper
> - new computation for offsets of high IO regions
> - add comments
> ---
>  hw/arm/virt.c         | 48 +++++++++++++++++++++++++++++++++++++------
>  include/hw/arm/virt.h | 14 +++++++++----
>  2 files changed, 52 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index a1955e7764..12039a0367 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -29,6 +29,7 @@
>   */
>  
>  #include "qemu/osdep.h"
> +#include "qemu/units.h"
>  #include "qapi/error.h"
>  #include "hw/sysbus.h"
>  #include "hw/arm/arm.h"
> @@ -121,7 +122,7 @@
>   * Note that devices should generally be placed at multiples of 0x10000,
>   * to accommodate guests using 64K pages.
>   */
> -static const MemMapEntry a15memmap[] = {
> +static const MemMapEntry base_memmap[] = {
>      /* Space up to 0x8000000 is reserved for a boot ROM */
>      [VIRT_FLASH] =              {          0, 0x08000000 },
>      [VIRT_CPUPERIPHS] =         { 0x08000000, 0x00020000 },
> @@ -149,11 +150,21 @@ static const MemMapEntry a15memmap[] = {
>      [VIRT_PCIE_PIO] =           { 0x3eff0000, 0x00010000 },
>      [VIRT_PCIE_ECAM] =          { 0x3f000000, 0x01000000 },
>      [VIRT_MEM] =                { 0x40000000, RAMLIMIT_BYTES },
> +};
> +
> +/*
> + * Highmem IO Regions: This memory map is floating, located after the RAM.
> + * Each IO region offset will be dynamically computed, depending on the
s/IO region offset/MemMapEntry base (GPA)/
> + * top of the RAM, so that its base get the same alignment as the size,

> + * ie. a 512GiB region will be aligned on a 512GiB boundary. If there is
s/region/entry/

> + * less than 256GiB of RAM, the floating area starts at the 256GiB mark.
> + */
> +static MemMapEntry extended_memmap[] = {
>      /* Additional 64 MB redist region (can contain up to 512 redistributors) */
> -    [VIRT_HIGH_GIC_REDIST2] =   { 0x4000000000ULL, 0x4000000 },
> -    [VIRT_HIGH_PCIE_ECAM] =     { 0x4010000000ULL, 0x10000000 },
> -    /* Second PCIe window, 512GB wide at the 512GB boundary */
> -    [VIRT_HIGH_PCIE_MMIO] =     { 0x8000000000ULL, 0x8000000000ULL },
> +    [VIRT_HIGH_GIC_REDIST2] =   { 0x0, 64 * MiB },
> +    [VIRT_HIGH_PCIE_ECAM] =     { 0x0, 256 * MiB },
> +    /* Second PCIe window */
> +    [VIRT_HIGH_PCIE_MMIO] =     { 0x0, 512 * GiB },
>  };
>  
>  static const int a15irqmap[] = {
> @@ -1354,6 +1365,30 @@ static uint64_t virt_cpu_mp_affinity(VirtMachineState *vms, int idx)
>      return arm_cpu_mp_affinity(idx, clustersz);
>  }
>  
> +static void virt_set_memmap(VirtMachineState *vms)
> +{
> +    hwaddr base;
> +    int i;
> +
> +    vms->memmap = extended_memmap;
I probably don't see something but ...

> +
> +    for (i = 0; i < ARRAY_SIZE(base_memmap); i++) {
> +        vms->memmap[i] = base_memmap[i];

ARRAY_SIZE(base_memmap) > 3
ARRAY_SIZE(extended_memmap) == 3
as result shouldn't we observe OOB at vms->memmap[i] access
starting from i==3 ?

> +    }
> +
> +    vms->high_io_base = 256 * GiB; /* Top of the legacy initial RAM region */
> +    base = vms->high_io_base;
> +
> +    for (i = VIRT_LOWMEMMAP_LAST; i < ARRAY_SIZE(extended_memmap); i++) {
not sure why VIRT_LOWMEMMAP_LAST is needed at all, one could just continue
with current 'i' value, provided extended_memmap wasn't corrupted by previous
loop.
And does this loop ever executes? VIRT_LOWMEMMAP_LAST > ARRAY_SIZE(extended_memmap)

> +        hwaddr size = extended_memmap[i].size;
> +
> +        base = ROUND_UP(base, size);
> +        vms->memmap[i].base = base;
> +        vms->memmap[i].size = size;
> +        base += size;
> +    }
> +}
> +
>  static void machvirt_init(MachineState *machine)
>  {
>      VirtMachineState *vms = VIRT_MACHINE(machine);
> @@ -1368,6 +1403,8 @@ static void machvirt_init(MachineState *machine)
>      bool firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
>      bool aarch64 = true;
>  
> +    virt_set_memmap(vms);
> +
>      /* We can probe only here because during property set
>       * KVM is not available yet
>       */
> @@ -1843,7 +1880,6 @@ static void virt_instance_init(Object *obj)
>                                      "Valid values are none and smmuv3",
>                                      NULL);
>  
> -    vms->memmap = a15memmap;
>      vms->irqmap = a15irqmap;
>  }
>  
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index a27086d524..3dc7a6c5d5 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -64,7 +64,6 @@ enum {
>      VIRT_GIC_VCPU,
>      VIRT_GIC_ITS,
>      VIRT_GIC_REDIST,
> -    VIRT_HIGH_GIC_REDIST2,
>      VIRT_SMMU,
>      VIRT_UART,
>      VIRT_MMIO,
> @@ -74,12 +73,18 @@ enum {
>      VIRT_PCIE_MMIO,
>      VIRT_PCIE_PIO,
>      VIRT_PCIE_ECAM,
> -    VIRT_HIGH_PCIE_ECAM,
>      VIRT_PLATFORM_BUS,
> -    VIRT_HIGH_PCIE_MMIO,
>      VIRT_GPIO,
>      VIRT_SECURE_UART,
>      VIRT_SECURE_MEM,
> +    VIRT_LOWMEMMAP_LAST,
> +};
> +
> +/* indices of IO regions located after the RAM */
> +enum {
> +    VIRT_HIGH_GIC_REDIST2 =  VIRT_LOWMEMMAP_LAST,
> +    VIRT_HIGH_PCIE_ECAM,
> +    VIRT_HIGH_PCIE_MMIO,
>  };
>  
>  typedef enum VirtIOMMUType {
> @@ -116,7 +121,7 @@ typedef struct {
>      int32_t gic_version;
>      VirtIOMMUType iommu;
>      struct arm_boot_info bootinfo;
> -    const MemMapEntry *memmap;
> +    MemMapEntry *memmap;
>      const int *irqmap;
>      int smp_cpus;
>      void *fdt;
> @@ -126,6 +131,7 @@ typedef struct {
>      uint32_t msi_phandle;
>      uint32_t iommu_phandle;
>      int psci_conduit;
> +    hwaddr high_io_base;
>  } VirtMachineState;
>  
>  #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)


WARNING: multiple messages have this Message-ID (diff)
From: Igor Mammedov <imammedo@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
	qemu-arm@nongnu.org, peter.maydell@linaro.org,
	shameerali.kolothum.thodi@huawei.com, david@redhat.com,
	dgilbert@redhat.com, david@gibson.dropbear.id.au,
	drjones@redhat.com
Subject: Re: [Qemu-devel] [PATCH v7 03/17] hw/arm/virt: Split the memory map description
Date: Thu, 21 Feb 2019 17:19:44 +0100	[thread overview]
Message-ID: <20190221171944.1cc65a33@redhat.com> (raw)
In-Reply-To: <20190220224003.4420-4-eric.auger@redhat.com>

On Wed, 20 Feb 2019 23:39:49 +0100
Eric Auger <eric.auger@redhat.com> wrote:

> In the prospect to introduce an extended memory map supporting more
> RAM, let's split the memory map array into two parts:
> 
> - the former a15memmap contains regions below and including the RAM

> - extended_memmap, only initialized with entries located after the RAM.
>   Only the size of the region is initialized there since their base
>   address will be dynamically computed, depending on the top of the
>   RAM (initial RAM at the moment), with same alignment as their size.
can't parse this part and pinpoint what is 'their', care to rephrase?


> This new split will allow to grow the RAM size without changing the
> description of the high regions.
> 
> The patch also moves the memory map setup
s/moves/makes/
s/$/dynamic and moves it/

> into machvirt_init().

> The rationale is the memory map will be soon affected by the

> kvm_type() call that happens after virt_instance_init() and
is dependency on kvm_type() still valid,
shouldn't split memmap work for TCG just fine as well?

> before machvirt_init().
> 
> The memory map is unchanged (the top of the initial RAM still is
> 256GiB). Then come the high IO regions with same layout as before.
> 
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> 
> ---
> v6 -> v7:
> - s/a15memmap/base_memmap
> - slight rewording of the commit message
> - add "if there is less than 256GiB of RAM then the floating area
>   starts at the 256GiB mark" in the comment associated to the floating
>   memory map
> - Added Peter's R-b
> 
> v5 -> v6
> - removal of many macros in units.h
> - introduce the virt_set_memmap helper
> - new computation for offsets of high IO regions
> - add comments
> ---
>  hw/arm/virt.c         | 48 +++++++++++++++++++++++++++++++++++++------
>  include/hw/arm/virt.h | 14 +++++++++----
>  2 files changed, 52 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index a1955e7764..12039a0367 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -29,6 +29,7 @@
>   */
>  
>  #include "qemu/osdep.h"
> +#include "qemu/units.h"
>  #include "qapi/error.h"
>  #include "hw/sysbus.h"
>  #include "hw/arm/arm.h"
> @@ -121,7 +122,7 @@
>   * Note that devices should generally be placed at multiples of 0x10000,
>   * to accommodate guests using 64K pages.
>   */
> -static const MemMapEntry a15memmap[] = {
> +static const MemMapEntry base_memmap[] = {
>      /* Space up to 0x8000000 is reserved for a boot ROM */
>      [VIRT_FLASH] =              {          0, 0x08000000 },
>      [VIRT_CPUPERIPHS] =         { 0x08000000, 0x00020000 },
> @@ -149,11 +150,21 @@ static const MemMapEntry a15memmap[] = {
>      [VIRT_PCIE_PIO] =           { 0x3eff0000, 0x00010000 },
>      [VIRT_PCIE_ECAM] =          { 0x3f000000, 0x01000000 },
>      [VIRT_MEM] =                { 0x40000000, RAMLIMIT_BYTES },
> +};
> +
> +/*
> + * Highmem IO Regions: This memory map is floating, located after the RAM.
> + * Each IO region offset will be dynamically computed, depending on the
s/IO region offset/MemMapEntry base (GPA)/
> + * top of the RAM, so that its base get the same alignment as the size,

> + * ie. a 512GiB region will be aligned on a 512GiB boundary. If there is
s/region/entry/

> + * less than 256GiB of RAM, the floating area starts at the 256GiB mark.
> + */
> +static MemMapEntry extended_memmap[] = {
>      /* Additional 64 MB redist region (can contain up to 512 redistributors) */
> -    [VIRT_HIGH_GIC_REDIST2] =   { 0x4000000000ULL, 0x4000000 },
> -    [VIRT_HIGH_PCIE_ECAM] =     { 0x4010000000ULL, 0x10000000 },
> -    /* Second PCIe window, 512GB wide at the 512GB boundary */
> -    [VIRT_HIGH_PCIE_MMIO] =     { 0x8000000000ULL, 0x8000000000ULL },
> +    [VIRT_HIGH_GIC_REDIST2] =   { 0x0, 64 * MiB },
> +    [VIRT_HIGH_PCIE_ECAM] =     { 0x0, 256 * MiB },
> +    /* Second PCIe window */
> +    [VIRT_HIGH_PCIE_MMIO] =     { 0x0, 512 * GiB },
>  };
>  
>  static const int a15irqmap[] = {
> @@ -1354,6 +1365,30 @@ static uint64_t virt_cpu_mp_affinity(VirtMachineState *vms, int idx)
>      return arm_cpu_mp_affinity(idx, clustersz);
>  }
>  
> +static void virt_set_memmap(VirtMachineState *vms)
> +{
> +    hwaddr base;
> +    int i;
> +
> +    vms->memmap = extended_memmap;
I probably don't see something but ...

> +
> +    for (i = 0; i < ARRAY_SIZE(base_memmap); i++) {
> +        vms->memmap[i] = base_memmap[i];

ARRAY_SIZE(base_memmap) > 3
ARRAY_SIZE(extended_memmap) == 3
as result shouldn't we observe OOB at vms->memmap[i] access
starting from i==3 ?

> +    }
> +
> +    vms->high_io_base = 256 * GiB; /* Top of the legacy initial RAM region */
> +    base = vms->high_io_base;
> +
> +    for (i = VIRT_LOWMEMMAP_LAST; i < ARRAY_SIZE(extended_memmap); i++) {
not sure why VIRT_LOWMEMMAP_LAST is needed at all, one could just continue
with current 'i' value, provided extended_memmap wasn't corrupted by previous
loop.
And does this loop ever executes? VIRT_LOWMEMMAP_LAST > ARRAY_SIZE(extended_memmap)

> +        hwaddr size = extended_memmap[i].size;
> +
> +        base = ROUND_UP(base, size);
> +        vms->memmap[i].base = base;
> +        vms->memmap[i].size = size;
> +        base += size;
> +    }
> +}
> +
>  static void machvirt_init(MachineState *machine)
>  {
>      VirtMachineState *vms = VIRT_MACHINE(machine);
> @@ -1368,6 +1403,8 @@ static void machvirt_init(MachineState *machine)
>      bool firmware_loaded = bios_name || drive_get(IF_PFLASH, 0, 0);
>      bool aarch64 = true;
>  
> +    virt_set_memmap(vms);
> +
>      /* We can probe only here because during property set
>       * KVM is not available yet
>       */
> @@ -1843,7 +1880,6 @@ static void virt_instance_init(Object *obj)
>                                      "Valid values are none and smmuv3",
>                                      NULL);
>  
> -    vms->memmap = a15memmap;
>      vms->irqmap = a15irqmap;
>  }
>  
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index a27086d524..3dc7a6c5d5 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -64,7 +64,6 @@ enum {
>      VIRT_GIC_VCPU,
>      VIRT_GIC_ITS,
>      VIRT_GIC_REDIST,
> -    VIRT_HIGH_GIC_REDIST2,
>      VIRT_SMMU,
>      VIRT_UART,
>      VIRT_MMIO,
> @@ -74,12 +73,18 @@ enum {
>      VIRT_PCIE_MMIO,
>      VIRT_PCIE_PIO,
>      VIRT_PCIE_ECAM,
> -    VIRT_HIGH_PCIE_ECAM,
>      VIRT_PLATFORM_BUS,
> -    VIRT_HIGH_PCIE_MMIO,
>      VIRT_GPIO,
>      VIRT_SECURE_UART,
>      VIRT_SECURE_MEM,
> +    VIRT_LOWMEMMAP_LAST,
> +};
> +
> +/* indices of IO regions located after the RAM */
> +enum {
> +    VIRT_HIGH_GIC_REDIST2 =  VIRT_LOWMEMMAP_LAST,
> +    VIRT_HIGH_PCIE_ECAM,
> +    VIRT_HIGH_PCIE_MMIO,
>  };
>  
>  typedef enum VirtIOMMUType {
> @@ -116,7 +121,7 @@ typedef struct {
>      int32_t gic_version;
>      VirtIOMMUType iommu;
>      struct arm_boot_info bootinfo;
> -    const MemMapEntry *memmap;
> +    MemMapEntry *memmap;
>      const int *irqmap;
>      int smp_cpus;
>      void *fdt;
> @@ -126,6 +131,7 @@ typedef struct {
>      uint32_t msi_phandle;
>      uint32_t iommu_phandle;
>      int psci_conduit;
> +    hwaddr high_io_base;
>  } VirtMachineState;
>  
>  #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)

  reply	other threads:[~2019-02-21 16:22 UTC|newest]

Thread overview: 125+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-20 22:39 [Qemu-arm] [PATCH v7 00/17] ARM virt: Initial RAM expansion and PCDIMM/NVDIMM support Eric Auger
2019-02-20 22:39 ` [Qemu-devel] " Eric Auger
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 01/17] hw/arm/boot: introduce fdt_add_memory_node helper Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-21 14:58   ` [Qemu-arm] " Igor Mammedov
2019-02-21 14:58     ` [Qemu-devel] " Igor Mammedov
2019-02-20 22:39 ` [Qemu-devel] [PATCH v7 02/17] hw/arm/virt: Rename highmem IO regions Eric Auger
2019-02-20 22:39   ` Eric Auger
2019-02-21 15:05   ` [Qemu-arm] " Igor Mammedov
2019-02-21 15:05     ` [Qemu-devel] " Igor Mammedov
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 03/17] hw/arm/virt: Split the memory map description Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-21 16:19   ` Igor Mammedov [this message]
2019-02-21 16:19     ` Igor Mammedov
2019-02-21 17:21     ` [Qemu-arm] " Auger Eric
2019-02-21 17:21       ` Auger Eric
2019-02-22 10:15       ` [Qemu-arm] " Igor Mammedov
2019-02-22 10:15         ` Igor Mammedov
2019-02-22 14:28         ` [Qemu-arm] " Auger Eric
2019-02-22 14:28           ` Auger Eric
2019-02-22 14:51           ` Igor Mammedov
2019-02-22 14:51             ` Igor Mammedov
2019-02-22  7:34   ` Heyi Guo
2019-02-22  7:34     ` Heyi Guo
2019-02-22  8:08     ` Auger Eric
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 04/17] hw/boards: Add a MachineState parameter to kvm_type callback Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-22 10:18   ` [Qemu-arm] " Igor Mammedov
2019-02-22 10:18     ` [Qemu-devel] " Igor Mammedov
2019-02-20 22:39 ` [Qemu-devel] [PATCH v7 05/17] kvm: add kvm_arm_get_max_vm_ipa_size Eric Auger
2019-02-20 22:39   ` Eric Auger
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 06/17] vl: Set machine ram_size, maxram_size and ram_slots earlier Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-22 10:40   ` [Qemu-arm] " Igor Mammedov
2019-02-22 10:40     ` [Qemu-devel] " Igor Mammedov
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 07/17] hw/arm/virt: Dynamic memory map depending on RAM requirements Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-22 12:57   ` [Qemu-arm] " Igor Mammedov
2019-02-22 12:57     ` [Qemu-devel] " Igor Mammedov
2019-02-22 14:06     ` [Qemu-arm] " Auger Eric
2019-02-22 14:06       ` [Qemu-devel] " Auger Eric
2019-02-22 14:23       ` [Qemu-arm] " Igor Mammedov
2019-02-22 14:23         ` [Qemu-devel] " Igor Mammedov
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 08/17] hw/arm/virt: Implement kvm_type function for 4.0 machine Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-22 12:45   ` [Qemu-arm] " Igor Mammedov
2019-02-22 12:45     ` [Qemu-devel] " Igor Mammedov
2019-02-22 14:01     ` Auger Eric
2019-02-22 14:01       ` Auger Eric
2019-02-22 14:39       ` [Qemu-arm] " Igor Mammedov
2019-02-22 14:39         ` Igor Mammedov
2019-02-22 14:53         ` Auger Eric
2019-02-22 14:53           ` Auger Eric
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 09/17] hw/arm/virt: Bump the 255GB initial RAM limit Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-20 22:39 ` [Qemu-devel] [PATCH v7 10/17] hw/arm/virt: Add memory hotplug framework Eric Auger
2019-02-20 22:39   ` Eric Auger
2019-02-22 13:25   ` Igor Mammedov
2019-02-22 13:25     ` Igor Mammedov
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 11/17] hw/arm/boot: Expose the PC-DIMM nodes in the DT Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-22 13:30   ` [Qemu-arm] " Igor Mammedov
2019-02-22 13:30     ` [Qemu-devel] " Igor Mammedov
2019-02-20 22:39 ` [Qemu-arm] [PATCH v7 12/17] hw/arm/virt-acpi-build: Add PC-DIMM in SRAT Eric Auger
2019-02-20 22:39   ` [Qemu-devel] " Eric Auger
2019-02-20 22:39 ` [Qemu-devel] [PATCH v7 13/17] hw/arm/virt: Allocate device_memory Eric Auger
2019-02-20 22:39   ` Eric Auger
2019-02-22 13:48   ` [Qemu-arm] " Igor Mammedov
2019-02-22 13:48     ` [Qemu-devel] " Igor Mammedov
2019-02-22 14:15     ` [Qemu-arm] " Auger Eric
2019-02-22 14:15       ` [Qemu-devel] " Auger Eric
2019-02-22 14:58       ` Igor Mammedov
2019-02-22 14:58         ` Igor Mammedov
2019-02-20 22:40 ` [Qemu-arm] [PATCH v7 14/17] nvdimm: use configurable ACPI IO base and size Eric Auger
2019-02-20 22:40   ` [Qemu-devel] " Eric Auger
2019-02-22 15:28   ` Igor Mammedov
2019-02-22 15:28     ` Igor Mammedov
2019-02-20 22:40 ` [Qemu-devel] [PATCH v7 15/17] hw/arm/virt: Add nvdimm hot-plug infrastructure Eric Auger
2019-02-20 22:40   ` Eric Auger
2019-02-22 15:36   ` [Qemu-arm] " Igor Mammedov
2019-02-22 15:36     ` Igor Mammedov
2019-02-20 22:40 ` [Qemu-arm] [PATCH v7 16/17] hw/arm/boot: Expose the pmem nodes in the DT Eric Auger
2019-02-20 22:40   ` [Qemu-devel] " Eric Auger
2019-02-20 22:40 ` [Qemu-devel] [PATCH v7 17/17] hw/arm/virt: Add nvdimm and nvdimm-persistence options Eric Auger
2019-02-20 22:40   ` Eric Auger
2019-02-22 15:48   ` Igor Mammedov
2019-02-22 15:48     ` Igor Mammedov
2019-02-22 15:57     ` [Qemu-arm] " Auger Eric
2019-02-22 15:57       ` Auger Eric
2019-02-20 22:46 ` [Qemu-devel] [PATCH v7 00/17] ARM virt: Initial RAM expansion and PCDIMM/NVDIMM support Auger Eric
2019-02-20 22:46   ` Auger Eric
2019-02-22 16:27 ` [Qemu-arm] " Igor Mammedov
2019-02-22 16:27   ` Igor Mammedov
2019-02-22 17:35   ` [Qemu-arm] " Auger Eric
2019-02-22 17:35     ` Auger Eric
2019-02-25  9:42     ` [Qemu-arm] " Igor Mammedov
2019-02-25  9:42       ` Igor Mammedov
2019-02-25 10:13       ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-25 10:13         ` Shameerali Kolothum Thodi
2019-02-26  8:40       ` Auger Eric
2019-02-26  8:40         ` Auger Eric
2019-02-26 13:11         ` [Qemu-arm] " Auger Eric
2019-02-26 13:11           ` Auger Eric
2019-02-26 16:56           ` [Qemu-arm] " Igor Mammedov
2019-02-26 16:56             ` Igor Mammedov
2019-02-26 17:53             ` [Qemu-arm] " Auger Eric
2019-02-26 17:53               ` Auger Eric
2019-02-27 10:10               ` [Qemu-arm] " Igor Mammedov
2019-02-27 10:10                 ` Igor Mammedov
2019-02-27 10:27                 ` [Qemu-arm] " Auger Eric
2019-02-27 10:27                   ` Auger Eric
2019-02-27 10:41                   ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-27 10:41                     ` Shameerali Kolothum Thodi
2019-02-27 17:51                     ` [Qemu-arm] " Igor Mammedov
2019-02-27 17:51                       ` Igor Mammedov
2019-02-28  7:48                       ` [Qemu-arm] " Auger Eric
2019-02-28  7:48                         ` Auger Eric
2019-02-28 14:05                         ` [Qemu-arm] " Igor Mammedov
2019-02-28 14:05                           ` Igor Mammedov
2019-03-01 14:18                           ` Auger Eric
2019-03-01 14:18                             ` Auger Eric
2019-03-01 16:33                             ` [Qemu-arm] " Igor Mammedov
2019-03-01 16:33                               ` Igor Mammedov
2019-03-01 17:52                               ` [Qemu-arm] " Auger Eric
2019-03-01 17:52                                 ` 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=20190221171944.1cc65a33@redhat.com \
    --to=imammedo@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=drjones@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shameerali.kolothum.thodi@huawei.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.