Re: [Qemu-devel] [RFC PATCH 1/3] hw/arm/virt: add hotplug memory support

[kwangwoo....@sk.com]

Hi Igor,

Thank you for your guide to split the hotplug patch.
Currently I'm looking at the Linux kernel codes related with huge page size.

> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: Tuesday, August 02, 2016 9:18 PM
> To: Peter Maydell
> Cc: Xiao Guangrong; Eduardo Habkost; Michael S. Tsirkin; QEMU Developers; 
> 정우석(CHUNG WOO SUK) MS SW;
> qemu-arm; Shannon Zhao; Shannon Zhao; Paolo Bonzini; 김현철(KIM HYUNCHUL) MS SW; 
> 이광우(LEE KWANGWOO) MS
> SW; Richard Henderson
> Subject: Re: [Qemu-devel] [RFC PATCH 1/3] hw/arm/virt: add hotplug memory 
> support
> 
> On Tue, 2 Aug 2016 08:59:46 +0100
> Peter Maydell  wrote:
> 
> > On 1 August 2016 at 10:14, Igor Mammedov  wrote:
> > > On Mon, 1 Aug 2016 09:13:34 +0100
> > > Peter Maydell  wrote:
> > >> On 1 August 2016 at 08:46, Igor Mammedov  wrote:
> > >> > Base alignment comes from max supported hugepage size,
> > >>
> > >> Max hugepage size for any host? (if so, should be defined
> > >> in a common header somewhere)
> > >> Max hugepage size for ARM hosts? (if so, why is TCG
> > >> different from KVM?, and should still be in a common
> > >> header somewhere)
> > > It's the same for TCG but it probably doesn't matter much there,
> > > main usage is to provide better performance with KVM.
> > >
> > > So I'd say it's host depended (for x86 it's 1Gb),
> > > probably other values for ARM and PPC
> >
> > We probably don't want to make the memory layout depend
> > on the host architecture, though :-(
> Important here is not change it dynamically so it won't
> break migration.
> Otherwise it could be a value that makes a sense for
> the use-case where performance matters most, i.e. KVM
> which makes us to derive value from max supported page
> size for a KVM host (meaning guest is the same arch)
> 
> In case of x86 value is constant hardcoded in target
> specific code which applies to both KVM and TCG.
> 
> Perhaps there is a better way to handle it which I just
> don't see.
> 
> >
> > >>
> > >> > while
> > >> > size alignment should depend on backend's page size
> > >>
> > >> Which page size do you have in mind here? TARGET_PAGE_SIZE
> > >> is often not the right answer, since it doesn't
> > >> correspond either to the actual page size being used
> > >> by the host kernel or to the actual page size used
> > >> by the guest kernel...
> > > alignment comes from here: memory_region_get_alignment()
> > >
> > > exec:c
> > >MAX(page_size, QEMU_VMALLOC_ALIGN)
> > > so it's either backend's page size or a min chunk QEMU
> > > allocates memory to make KVM/valgrind/whatnot happy.
> >
> > Since that's always larger than TARGET_PAGE_SIZE
> > why are we checking for an alignment here that's
> > not actually sufficient to make things work?
> You mean following hunk:
> 
> +if (QEMU_ALIGN_UP(machine->maxram_size,
> + TARGET_PAGE_SIZE) != machine->maxram_size) {
> 
> It's a bit late to fix for x86 without breaking CLI,
> side effect would be inability to hotplug upto maxmem if maxmem
> is misaligned wrt used backend page size
> 
> ARCH_VIRT_HOTPLUG_MEM_ALIGN should be used instead of TARGET_PAGE_SIZE
> 
> PS:
> I haven't reviewed series yet, but I'd split this patch in 3
> to make review easier
>   1st - introduce machine level hotplug hooks
>   2nd - add MemoryHotplugState to VirtMachineState and initialize it
>   3rd - add virt_dimm_plug() handler

OK. I'll try to split it.

> >
> > thanks
> > -- PMM
> >

Best Regards,
Kwangwoo Lee

Re: [Qemu-devel] [RFC PATCH 1/3] hw/arm/virt: add hotplug memory support

[kwangwoo....@sk.com]

Hi,

Thank you for the alignment information and discussion, Igor and Peter!

I'll try to find out proper alignment by looking at the codes.

Best Regards,
Kwangwoo Lee

> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: Monday, August 01, 2016 6:15 PM
> To: Peter Maydell
> Cc: 이광우(LEE KWANGWOO) MS SW; Xiao Guangrong; Michael S. Tsirkin; Paolo 
> Bonzini; Richard Henderson;
> Eduardo Habkost; Shannon Zhao; Shannon Zhao; QEMU Developers; qemu-arm; 
> 정우석(CHUNG WOO SUK) MS SW; 김
> 현철(KIM HYUNCHUL) MS SW
> Subject: Re: [RFC PATCH 1/3] hw/arm/virt: add hotplug memory support
> 
> On Mon, 1 Aug 2016 09:13:34 +0100
> Peter Maydell <peter.mayd...@linaro.org> wrote:
> 
> > On 1 August 2016 at 08:46, Igor Mammedov <imamm...@redhat.com> wrote:
> > > On Mon, 1 Aug 2016 00:35:35 +
> > > "kwangwoo@sk.com" <kwangwoo@sk.com> wrote:
> >
> > >> > > +/* 1GB alignment for hotplug memory region */
> > >> > > +#define ARCH_VIRT_HOTPLUG_MEM_ALIGN (1ULL << 30)
> > >> >
> > >> > Where does the 1GB alignment come from? Why do we need 1GB
> > >> > alignment for the base but only 1KB alignment for the size?
> > >>
> > >> The alignment value of hotplug_memory.base referred from i386 pc.c and 
> > >> ppc spapr.c.
> > >> Could you suggest a proper range for this?
> >
> > > Base alignment comes from max supported hugepage size,
> >
> > Max hugepage size for any host? (if so, should be defined
> > in a common header somewhere)
> > Max hugepage size for ARM hosts? (if so, why is TCG
> > different from KVM?, and should still be in a common
> > header somewhere)
> It's the same for TCG but it probably doesn't matter much there,
> main usage is to provide better performance with KVM.
> 
> So I'd say it's host depended (for x86 it's 1Gb),
> probably other values for ARM and PPC
> 
> >
> > > while
> > > size alignment should depend on backend's page size
> >
> > Which page size do you have in mind here? TARGET_PAGE_SIZE
> > is often not the right answer, since it doesn't
> > correspond either to the actual page size being used
> > by the host kernel or to the actual page size used
> > by the guest kernel...
> alignment comes from here: memory_region_get_alignment()
> 
> exec:c
>MAX(page_size, QEMU_VMALLOC_ALIGN)
> so it's either backend's page size or a min chunk QEMU
> allocates memory to make KVM/valgrind/whatnot happy.
> 
> >
> > thanks
> > -- PMM

Re: [Qemu-devel] [RFC PATCH 1/3] hw/arm/virt: add hotplug memory support

[kwangwoo....@sk.com]

Hi Peter,

Thanks a lot for your comments! I answered in line below.

> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Saturday, July 30, 2016 3:10 AM
> To: 이광우(LEE KWANGWOO) MS SW
> Cc: Xiao Guangrong; Michael S. Tsirkin; Igor Mammedov; Paolo Bonzini; Richard 
> Henderson; Eduardo
> Habkost; Shannon Zhao; Shannon Zhao; QEMU Developers; qemu-arm; 정우석(CHUNG WOO 
> SUK) MS SW; 김현철(KIM
> HYUNCHUL) MS SW
> Subject: Re: [RFC PATCH 1/3] hw/arm/virt: add hotplug memory support
> 
> On 20 July 2016 at 01:49, Kwangwoo Lee <kwangwoo@sk.com> wrote:
> > Add hotplug memory feature on aarch64 virt platfom. This patch is
> > required to emulate a DIMM type memory like NVDIMM.
> >
> > Signed-off-by: Kwangwoo Lee <kwangwoo@sk.com>
> > ---
> >  default-configs/aarch64-softmmu.mak |   1 +
> >  hw/arm/virt.c   | 110 
> > 
> >  include/hw/arm/virt.h   |   3 +
> >  3 files changed, 114 insertions(+)
> >
> > diff --git a/default-configs/aarch64-softmmu.mak 
> > b/default-configs/aarch64-softmmu.mak
> > index 2449483..5790cd2 100644
> > --- a/default-configs/aarch64-softmmu.mak
> > +++ b/default-configs/aarch64-softmmu.mak
> > @@ -7,3 +7,4 @@ CONFIG_AUX=y
> >  CONFIG_DDC=y
> >  CONFIG_DPCD=y
> >  CONFIG_XLNX_ZYNQMP=y
> > +CONFIG_MEM_HOTPLUG=y
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index a193b5a..f7ff411 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -58,6 +58,8 @@
> >  #include "hw/smbios/smbios.h"
> >  #include "qapi/visitor.h"
> >  #include "standard-headers/linux/input.h"
> > +#include "hw/mem/pc-dimm.h"
> > +#include "hw/acpi/acpi.h"
> >
> >  /* Number of external interrupt lines to configure the GIC with */
> >  #define NUM_IRQS 256
> > @@ -91,6 +93,7 @@ typedef struct {
> >  bool secure;
> >  bool highmem;
> >  int32_t gic_version;
> > +MemoryHotplugState hotplug_memory;
> >  } VirtMachineState;
> >
> >  #define TYPE_VIRT_MACHINE   MACHINE_TYPE_NAME("virt")
> > @@ -1376,6 +1379,40 @@ static void machvirt_init(MachineState *machine)
> >  guest_info_state->machine_done.notify = virt_guest_info_machine_done;
> >  qemu_add_machine_init_done_notifier(_info_state->machine_done);
> >
> > +/* initialize hotplug memory address space */
> > +if (machine->ram_size < machine->maxram_size) {
> > +ram_addr_t hotplug_mem_size = machine->maxram_size - 
> > machine->ram_size;
> > +
> > +if (machine->ram_slots > ACPI_MAX_RAM_SLOTS) {
> > +error_report("unsupported amount of memory slots: %"PRIu64,
> 
> "number of"

OK. I'll fix this.

> > + machine->ram_slots);
> > +exit(EXIT_FAILURE);
> > +}
> > +
> > +if (QEMU_ALIGN_UP(machine->maxram_size,
> > + TARGET_PAGE_SIZE) != machine->maxram_size) {
> > +error_report("maximum memory size must by aligned to multiple 
> > of "
> 
> "must be"

OK. I'll fix this

> > + "%d bytes", TARGET_PAGE_SIZE);
> > +exit(EXIT_FAILURE);
> > +}
> > +
> > +vms->hotplug_memory.base =
> > + ROUND_UP(vbi->memmap[VIRT_MEM].base + 
> > machine->ram_size,
> > +  ARCH_VIRT_HOTPLUG_MEM_ALIGN);
> > +
> > +if ((vms->hotplug_memory.base + hotplug_mem_size) <
> > +hotplug_mem_size) {
> 
> This expression is confusing. Is it trying to test for overflow?
> When can that happen?

Ah.. you are right. No need to check this. I'll remove this. Thanks!

> > +error_report("unsupported amount of maximum memory: " 
> > RAM_ADDR_FMT,
> > + machine->maxram_size);
> > +exit(EXIT_FAILURE);
> > +}
> > +
> > +memory_region_init(>hotplug_memory.mr, OBJECT(vms),
> > +   "hotplug-memory", hotplug_mem_size);
> > +memory_region_add_subregion(sysmem, vms->hotplug_memory.base,
> > +>hotplug_memory.mr);
> > +}
> > +
> >  vbi->bootinfo.ram_size = machine->ram_size;
> >  vbi->bootinfo.kernel_filename = machine->kernel_filename;
&

Re: [Qemu-devel] [RFC PATCH 3/3] hw/arm/virt: add nvdimm emulation support

[kwangwoo....@sk.com]

Hi Peter,

Thanks for your guidance!

> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Tuesday, July 26, 2016 5:23 PM
> To: 이광우(LEE KWANGWOO) MS SW
> Cc: Xiao Guangrong; Michael S. Tsirkin; Igor Mammedov; Paolo Bonzini; Richard 
> Henderson; Eduardo
> Habkost; Shannon Zhao; Shannon Zhao; QEMU Developers; qemu-arm; 정우석(CHUNG WOO 
> SUK) MS SW; 김현철(KIM
> HYUNCHUL) MS SW
> Subject: Re: [RFC PATCH 3/3] hw/arm/virt: add nvdimm emulation support
> 
> On 26 July 2016 at 08:03, kwangwoo@sk.com <kwangwoo@sk.com> wrote:
> > Hi Peter,
> >
> > Please, check the comments below. Thanks a lot!
> >
> >> -Original Message-
> >> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> >> This seems to be missing code to write the device tree
> >> information about whatever this device is?
> >
> > Is it OK to just add a memory region which cannot be used without ACPI?
> > This is unclear to me. If you suggest that it is better way, I'll revise
> > this patch to add a device tree node. Please, help me to understand.
> 
> They don't necessarily both have to be added in the exact same patch
> if it's less confusing to split it, but the series as a whole
> should support both DT and ACPI (and your kernel patches also
> ought to have both DT and ACPI bindings I think).

Although NVDIMM is dependent on ACPI NFIT table currently, I'll keep
this comment in mind and revise it step by step.

> thanks
> -- PMM

Best Regards,
Kwangwoo Lee

Re: [Qemu-devel] [RFC PATCH 3/3] hw/arm/virt: add nvdimm emulation support

[kwangwoo....@sk.com]

Hi Peter,

Please, check the comments below. Thanks a lot!

> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Tuesday, July 26, 2016 1:06 AM
> To: 이광우(LEE KWANGWOO) MS SW
> Cc: Xiao Guangrong; Michael S. Tsirkin; Igor Mammedov; Paolo Bonzini; Richard 
> Henderson; Eduardo
> Habkost; Shannon Zhao; Shannon Zhao; QEMU Developers; qemu-arm; 정우석(CHUNG WOO 
> SUK) MS SW; 김현철(KIM
> HYUNCHUL) MS SW
> Subject: Re: [RFC PATCH 3/3] hw/arm/virt: add nvdimm emulation support
> 
> On 20 July 2016 at 01:49, Kwangwoo Lee <kwangwoo@sk.com> wrote:
> > This patch enables evaluating NVDIMM on aarch64 virt platform. The
> > option - nvdimm - passed after machine type is disabled by default.
> >
> > The command below has been used to test the feature:
> >
> > ./aarch64-softmmu/qemu-system-aarch64  \
> > -machine type=virt,nvdimm=on   \
> > -cpu cortex-a57 -smp 1 \
> > -bios ~/oss/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC49/FV/QEMU_EFI.fd \
> > -m 512,maxmem=2G,slots=2   \
> > -object memory-backend-file,id=mem1,share,mem-path=./nvdimm1,size=1G \
> > -device nvdimm,memdev=mem1,id=nv1  \
> > -fsdev local,id=r,path=/media/sf_Share,security_model=none \
> > -device virtio-9p-device,fsdev=r,mount_tag=r   \
> > -kernel ../linux/arch/arm64/boot/Image \
> >     --append "console=ttyAMA0 acpi=force"  \
> > -nographic
> >
> > Signed-off-by: Kwangwoo Lee <kwangwoo@sk.com>
> > ---
> >  default-configs/aarch64-softmmu.mak |  2 ++
> >  hw/arm/virt-acpi-build.c|  5 +
> >  hw/arm/virt.c   | 34 ++
> >  include/hw/arm/virt-acpi-build.h|  1 +
> >  include/hw/arm/virt.h   |  4 
> >  5 files changed, 46 insertions(+)
> >
> > diff --git a/default-configs/aarch64-softmmu.mak 
> > b/default-configs/aarch64-softmmu.mak
> > index 5790cd2..295816b 100644
> > --- a/default-configs/aarch64-softmmu.mak
> > +++ b/default-configs/aarch64-softmmu.mak
> > @@ -8,3 +8,5 @@ CONFIG_DDC=y
> >  CONFIG_DPCD=y
> >  CONFIG_XLNX_ZYNQMP=y
> >  CONFIG_MEM_HOTPLUG=y
> > +CONFIG_NVDIMM=y
> > +CONFIG_ACPI_NVDIMM=y
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index 28fc59c..c3caaa9 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -648,6 +648,7 @@ struct AcpiBuildState {
> >  static
> >  void virt_acpi_build(VirtGuestInfo *guest_info, AcpiBuildTables *tables)
> >  {
> > +AcpiNVDIMMState *acpi_nvdimm = guest_info->acpi_nvdimm;
> >  GArray *table_offsets;
> >  unsigned dsdt, rsdt;
> >  GArray *tables_blob = tables->table_data;
> > @@ -695,6 +696,10 @@ void virt_acpi_build(VirtGuestInfo *guest_info, 
> > AcpiBuildTables *tables)
> >  build_srat(tables_blob, tables->linker, guest_info);
> >  }
> >
> > +if (acpi_nvdimm->is_enabled) {
> > +nvdimm_build_acpi(table_offsets, tables_blob, tables->linker,
> > +  acpi_nvdimm);
> > +}
> >  /* RSDT is pointed to by RSDP */
> >  rsdt = tables_blob->len;
> >  build_rsdt(tables_blob, tables->linker, table_offsets, NULL, NULL);
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index f7ff411..f9db19c 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -94,6 +94,7 @@ typedef struct {
> >  bool highmem;
> >  int32_t gic_version;
> >  MemoryHotplugState hotplug_memory;
> > +AcpiNVDIMMState acpi_nvdimm;
> >  } VirtMachineState;
> >
> >  #define TYPE_VIRT_MACHINE   MACHINE_TYPE_NAME("virt")
> > @@ -180,6 +181,7 @@ static const MemMapEntry a15memmap[] = {
> >  [VIRT_FW_CFG] = { 0x0902, 0x0018 },
> >  [VIRT_GPIO] =   { 0x0903, 0x1000 },
> >  [VIRT_SECURE_UART] ={ 0x0904, 0x1000 },
> > +[VIRT_ACPI_IO] ={ 0x0905, 0x1000 },
> >  [VIRT_MMIO] =   { 0x0a00, 0x0200 },
> >  /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that 
> > size */
> >  [VIRT_PLATFORM_BUS] =   { 0x0c00, 0x0200 },
> > @@ -1376,6 +1378,7 @@ static void machvirt_init(MachineState *machine)
> >  guest_info->irqmap 

Re: [Qemu-devel] [RFC PATCH 2/3] nvdimm: use configurable ACPI IO base and size

[kwangwoo....@sk.com]

Hi Peter,

Thanks for reviewing the patches! I added some comments below.

> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Tuesday, July 26, 2016 1:13 AM
> To: 이광우(LEE KWANGWOO) MS SW
> Cc: Xiao Guangrong; Michael S. Tsirkin; Igor Mammedov; Paolo Bonzini; Richard 
> Henderson; Eduardo
> Habkost; Shannon Zhao; Shannon Zhao; QEMU Developers; qemu-arm; 정우석(CHUNG WOO 
> SUK) MS SW; 김현철(KIM
> HYUNCHUL) MS SW
> Subject: Re: [RFC PATCH 2/3] nvdimm: use configurable ACPI IO base and size
> 
> On 20 July 2016 at 01:49, Kwangwoo Lee <kwangwoo@sk.com> wrote:
> > This patch uses configurable IO base and size to create NPIO AML for
> > ACPI NFIT. Since a different architecture like AArch64 does not use
> > port-mapped IO, a configurable IO base is required to create correct
> > mapping of ACPI IO address and size.
> >
> > Signed-off-by: Kwangwoo Lee <kwangwoo@sk.com>
> > ---
> >  hw/acpi/nvdimm.c| 23 +++
> >  hw/i386/acpi-build.c|  2 +-
> >  hw/i386/pc_piix.c   |  8 +++-
> >  hw/i386/pc_q35.c|  8 +++-
> >  include/hw/mem/nvdimm.h | 17 -
> >  5 files changed, 46 insertions(+), 12 deletions(-)
> >
> > diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
> > index e486128..57e03ee 100644
> > --- a/hw/acpi/nvdimm.c
> > +++ b/hw/acpi/nvdimm.c
> > @@ -765,8 +765,8 @@ void nvdimm_init_acpi_state(AcpiNVDIMMState *state, 
> > MemoryRegion *io,
> >  FWCfgState *fw_cfg, Object *owner)
> >  {
> >  memory_region_init_io(>io_mr, owner, _dsm_ops, state,
> > -  "nvdimm-acpi-io", NVDIMM_ACPI_IO_LEN);
> > -memory_region_add_subregion(io, NVDIMM_ACPI_IO_BASE, >io_mr);
> > +  "nvdimm-acpi-io", state->dsm_io.size);
> > +memory_region_add_subregion(io, state->dsm_io.base, >io_mr);
> >
> >  state->dsm_mem = g_array_new(false, true /* clear */, 1);
> >  acpi_data_push(state->dsm_mem, sizeof(NvdimmDsmIn));
> 
> Why does this function take a MemoryRegion to insert itself into,
> rather than returning a MemoryRegion for the caller to map into
> wherever is appropriate, or even being a DeviceState which has
> mappable memory regions via the sysbus API ?

On i386, the region is added to system_io which is ported-mapped IO at 0x0a18.
Therefore, to use memory-mapped IO for NVDIMM DSM(Device Specific Method), a
member variable - dsm_io - which containing type, base address and size need to
be added on ARM64 platform.

> I guess the answer is "that's the way it happens to be at the moment",
> so I'm not really asking for a change here necessarily.

Thanks for your understanding!

> > @@ -912,9 +912,10 @@ static void nvdimm_build_nvdimm_devices(GSList 
> > *device_list, Aml *root_dev)
> >
> >  static void nvdimm_build_ssdt(GSList *device_list, GArray *table_offsets,
> >GArray *table_data, BIOSLinker *linker,
> > -  GArray *dsm_dma_arrea)
> > +  AcpiNVDIMMState *acpi_nvdimm_state)
> >  {
> >  Aml *ssdt, *sb_scope, *dev, *field;
> > +AmlRegionSpace rs;
> >  int mem_addr_offset, nvdimm_ssdt;
> >
> >  acpi_add_table(table_offsets, table_data);
> > @@ -940,8 +941,14 @@ static void nvdimm_build_ssdt(GSList *device_list, 
> > GArray *table_offsets,
> >  aml_append(dev, aml_name_decl("_HID", aml_string("ACPI0012")));
> >
> >  /* map DSM memory and IO into ACPI namespace. */
> > -aml_append(dev, aml_operation_region("NPIO", AML_SYSTEM_IO,
> > -   aml_int(NVDIMM_ACPI_IO_BASE), NVDIMM_ACPI_IO_LEN));
> > +if (acpi_nvdimm_state->dsm_io.type == NVDIMM_ACPI_IO_PORT) {
> > +rs = AML_SYSTEM_IO;
> > +} else {
> > +rs = AML_SYSTEM_MEMORY;
> > +}
> > +aml_append(dev, aml_operation_region("NPIO", rs,
> > +   aml_int(acpi_nvdimm_state->dsm_io.base),
> > +   acpi_nvdimm_state->dsm_io.size));
> >  aml_append(dev, aml_operation_region("NRAM", AML_SYSTEM_MEMORY,
> > aml_name(NVDIMM_ACPI_MEM_ADDR), sizeof(NvdimmDsmIn)));
> >
> > @@ -1014,7 +1021,7 @@ static void nvdimm_build_ssdt(GSList *device_list, 
> > GArray *table_offsets,
> > NVDIMM_ACPI_MEM_ADDR);
> >
> >  bios_linker_loader_alloc(linker,
> > -

Re: [Qemu-devel] [RFC PATCH 0/3] add nvdimm support on AArch64 virt platform

[kwangwoo....@sk.com]

Hi Peter,

Thanks for your kind comment! I described about NVDIMM briefly below.

> -Original Message-
> From: Peter Maydell [mailto:peter.mayd...@linaro.org]
> Sent: Tuesday, July 26, 2016 1:07 AM
> To: 이광우(LEE KWANGWOO) MS SW
> Cc: Xiao Guangrong; Michael S. Tsirkin; Igor Mammedov; Paolo Bonzini; Richard 
> Henderson; Eduardo
> Habkost; Shannon Zhao; Shannon Zhao; QEMU Developers; qemu-arm; 정우석(CHUNG WOO 
> SUK) MS SW; 김현철(KIM
> HYUNCHUL) MS SW
> Subject: Re: [RFC PATCH 0/3] add nvdimm support on AArch64 virt platform
> 
> On 20 July 2016 at 01:49, Kwangwoo Lee <kwangwoo@sk.com> wrote:
> > This patch series add an evaluation environment of NVDIMM on AArch64
> > virt platform. Three parts need to be implemented to make this feature
> > working properly.
> >
> > 1. memory hotplug on arm virt platform
> > 2. configurable ACPI IO base and size both for i386 and arm platform
> > 3. enable NVDIMM on arm virt platform
> >
> > The memory hotplug is required to recognize DIMM type memory and this
> > is also used for NVDIMM device recognition.
> >
> > The ACPI IO base and size need to be changed on creating ACPI NFIT
> > because arm platform uses memory-mapped IO which is different from
> > i386 platform. Thus, this patch set includes the changes of setting
> > ACPI IO base and size during NVDIMM initialization.
> >
> > The last part enables NVDIMM on arm virt platform. The feature is
> > disabled by default. So explicit option - nvdimm=on - is required to
> > enable the feature.
> 
> Thanks for this patchset. Could you provide a brief summary of
> why this is interesting/useful for the benefit of people who don't
> know what an NVDIMM is, please?

NVDIMM stands for Non-Volatile DIMM which has DIMM form factor like PC-DIMM
(Memory Module used in PC) and can be used like a memory, but the stored data
is preserved on power failure. So it can be used as a memory, a storage, or
backup memory on power failure.

NVDIMM-N is already out in the market and Intel, HPE, and other companies
actively developing related software. In Linux kernel, several usages exist
like PMEM, BLK-aperture, and mixed mode. They are actively under developing.

In QEMU, NVDIMM has been emulated on i386 platform. My patch series tries to
enable the environment in AArch64 platform. Related Linux kernel patches were
posted into the mailing list and they are under review/revise process currently.

> thanks
> -- PMM

Best Regards,
Kwangwoo Lee