qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>
Cc: ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com,
	gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	stefanha@redhat.com, imammedo@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH 00/16] implement vNVDIMM
Date: Fri, 03 Jul 2015 02:01:30 +0800	[thread overview]
Message-ID: <55957C7A.9050200@linux.intel.com> (raw)
In-Reply-To: <559509FA.20509@redhat.com>


Thanks for your review, Stefan and Paolo!

On 07/02/2015 05:52 PM, Paolo Bonzini wrote:
>
>
> On 02/07/2015 11:20, Stefan Hajnoczi wrote:
>>> Currently, the NVDIMM driver has been merged into upstream Linux Kernel and
>>> this patchset tries to enable it in virtualization field
>>
>>  From a device model perspective, have you checked whether it makes sense
>> to integrate nvdimms into the pc-dimm and hostmem code that is used for
>> memory hotplug and NUMA?
>>
>> The NVDIMM device in your patches is a completely new TYPE_DEVICE so it
>> doesn't share any interfaces or code with existing memory devices.
>> Maybe that is the right solution here because NVDIMMs have different
>> characteristics, but I'm not sure.
>
> The hostmem code should definitely be shared, e.g. by adding a new
> "file" property to the memory-backend-file class.  ivshmem can also use
> it---CCing Marc-Andr�.

However, file-based memory used by NVDIMM is special, it divides the file
to two parts, one part is used as PMEM and another part is used to store
NVDIMM's configure data.

Maybe we can introduce "end-reserved" property to reserve specified size
at the end of the file. Or create a new class type based on
memory-backend-file (named nvdimm-backend-file) class to hide this magic
thing?

>
> I don't know about the pc-dimm devices.  If the NVDIMM devices can do
> _OST and can be hotplugged, then the answer is probably yes.

_OST is not needed for NVDIMM.

NVDIMM is completely different with dimm memory device in ACPI - it has
different HID, method object, memory range detection, device organization,
etc. So i prefer to introducing new device class for NVDIMM.

For hotplug, NVDIMM and DIMM can share some logic, e.g, free-address-range
management, slot management ... ( but new Object initiation in ACPI is
complete different), we can abstract these operation as common part.

NUMA detection is also different between NVDIMM, DIMM is also different,
NVDIMM need to report its NUMA affinity in SPA table. But they can share
some common function i think.

BTW, i am going to implement vNVDIMM hotplug once linux NVDIMM driver
supports it.

  reply	other threads:[~2015-07-02 18:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-01 14:50 [Qemu-devel] [PATCH 00/16] implement vNVDIMM Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 01/16] acpi: allow aml_operation_region() working on 64 bit offset Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 02/16] i386/acpi-build: allow SSDT to operate on 64 bit Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 03/16] acpi: add aml_derefof Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 04/16] acpi: add aml_sizeof Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 05/16] acpi: add aml_create_field Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 06/16] pc: implement NVDIMM device abstract Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 07/16] nvdimm: reserve address range for NVDIMM Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 08/16] nvdimm: init backend memory mapping and config data area Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 09/16] nvdimm: build ACPI NFIT table Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 10/16] nvdimm: init the address region used by _DSM method Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 11/16] nvdimm: build ACPI nvdimm devices Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 12/16] nvdimm: save arg3 for NVDIMM device _DSM method Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 13/16] nvdimm: support NFIT_CMD_IMPLEMENTED function Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 14/16] nvdimm: support NFIT_CMD_GET_CONFIG_SIZE function Xiao Guangrong
2015-07-02  9:23   ` Stefan Hajnoczi
2015-07-02 18:02     ` Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 15/16] nvdimm: support NFIT_CMD_GET_CONFIG_DATA Xiao Guangrong
2015-07-01 14:50 ` [Qemu-devel] [PATCH 16/16] nvdimm: support NFIT_CMD_SET_CONFIG_DATA Xiao Guangrong
2015-07-02  6:17 ` [Qemu-devel] [PATCH 00/16] implement vNVDIMM Michael S. Tsirkin
2015-07-02  6:34   ` Xiao Guangrong
2015-07-02  8:31     ` Stefan Hajnoczi
2015-07-02  8:35       ` Michael S. Tsirkin
2015-07-02  9:20 ` Stefan Hajnoczi
2015-07-02  9:52   ` Paolo Bonzini
2015-07-02 18:01     ` Xiao Guangrong [this message]
2015-07-02 18:11       ` Paolo Bonzini
2015-07-29  8:41         ` Xiao Guangrong

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=55957C7A.9050200@linux.intel.com \
    --to=guangrong.xiao@linux.intel.com \
    --cc=ehabkost@redhat.com \
    --cc=gleb@kernel.org \
    --cc=imammedo@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=marcandre.lureau@gmail.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).