From: Ross Zwisler <ross.zwisler@linux.intel.com> To: Igor Mammedov <imammedo@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com>, "Michael S . Tsirkin" <mst@redhat.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com> Subject: Re: [Qemu-devel] [PATCH 3/3] nvdimm: platform capabilities command line option Date: Tue, 15 May 2018 17:03:51 -0600 [thread overview] Message-ID: <20180515230351.GA741@linux.intel.com> (raw) In-Reply-To: <20180510152848.0f99ea07@redhat.com> On Thu, May 10, 2018 at 03:28:48PM +0200, Igor Mammedov wrote: > On Fri, 27 Apr 2018 15:53:14 -0600 > Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > > > Add a device command line option to allow the user to control the Platform > > Capabilities Structure in the virtualized NFIT. > > > > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> > > --- > > docs/nvdimm.txt | 22 ++++++++++++++++++++++ > > hw/acpi/nvdimm.c | 29 +++++++++++++++++++++++++---- > > hw/mem/nvdimm.c | 28 ++++++++++++++++++++++++++++ > > include/hw/mem/nvdimm.h | 6 ++++++ > > 4 files changed, 81 insertions(+), 4 deletions(-) > > > > diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt > > index e903d8bb09..13a2c15b70 100644 > > --- a/docs/nvdimm.txt > > +++ b/docs/nvdimm.txt > > @@ -153,3 +153,25 @@ guest NVDIMM region mapping structure. This unarmed flag indicates > > guest software that this vNVDIMM device contains a region that cannot > > accept persistent writes. In result, for example, the guest Linux > > NVDIMM driver, marks such vNVDIMM device as read-only. > > + > > +Platform Capabilities > > +--------------------- > > + > > +ACPI 6.2 Errata A added support for a new Platform Capabilities Structure > > +which allows the platform to communicate what features it supports related to > > +NVDIMM data durability. Users can provide a capabilities value to a guest via > > +the optional "cap" device command line option: > > + > > + -device nvdimm,id=nvdimm1,memdev=mem1,cap=3 > > + > > +As of ACPI 6.2 Errata A, the following values are valid for the bottom two > > +bits: > > + > > +2 - Memory Controller Flush to NVDIMM Durability on Power Loss Capable. > > +3 - CPU Cache Flush to NVDIMM Durability on Power Loss Capable. > > + > > +For a complete list of the flags available please consult the ACPI spec. > > + > > +These platform capabilities apply to the entire virtual platform, so it is > > +recommended that only one "cap" device command option be given per virtual > > +machine. This value will apply to all NVDIMMs in the virtual platform. > This looks like it should be machine property instead of per device one, > you can get rid of static variable and mismatch check and a weird nvdimm CLI > option that implies that the option is per device. Yep, that's much better. I have this implemented and ready to go. > Also an extra patch to for make check that will test setting 'cap' > would be nice (an extra testcase in tests/bios-tables-test.c) Hmm...I've been looking at this, and it doesn't look like there is any verification around a lot of the ACPI tables (NFIT, SRAT, etc). I've verified my patch by interacting with a guest with various settings - is this good enough, or do you really want me to test the value (which I think would just be "do I get out what I put in at the command line") via the unit test infrastructure? Thank you for the review. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com> To: Igor Mammedov <imammedo@redhat.com> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>, Haozhong Zhang <haozhong.zhang@intel.com>, "Michael S . Tsirkin" <mst@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Eduardo Habkost <ehabkost@redhat.com>, qemu-devel@nongnu.org, linux-nvdimm <linux-nvdimm@lists.01.org> Subject: Re: [Qemu-devel] [PATCH 3/3] nvdimm: platform capabilities command line option Date: Tue, 15 May 2018 17:03:51 -0600 [thread overview] Message-ID: <20180515230351.GA741@linux.intel.com> (raw) In-Reply-To: <20180510152848.0f99ea07@redhat.com> On Thu, May 10, 2018 at 03:28:48PM +0200, Igor Mammedov wrote: > On Fri, 27 Apr 2018 15:53:14 -0600 > Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > > > Add a device command line option to allow the user to control the Platform > > Capabilities Structure in the virtualized NFIT. > > > > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> > > --- > > docs/nvdimm.txt | 22 ++++++++++++++++++++++ > > hw/acpi/nvdimm.c | 29 +++++++++++++++++++++++++---- > > hw/mem/nvdimm.c | 28 ++++++++++++++++++++++++++++ > > include/hw/mem/nvdimm.h | 6 ++++++ > > 4 files changed, 81 insertions(+), 4 deletions(-) > > > > diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt > > index e903d8bb09..13a2c15b70 100644 > > --- a/docs/nvdimm.txt > > +++ b/docs/nvdimm.txt > > @@ -153,3 +153,25 @@ guest NVDIMM region mapping structure. This unarmed flag indicates > > guest software that this vNVDIMM device contains a region that cannot > > accept persistent writes. In result, for example, the guest Linux > > NVDIMM driver, marks such vNVDIMM device as read-only. > > + > > +Platform Capabilities > > +--------------------- > > + > > +ACPI 6.2 Errata A added support for a new Platform Capabilities Structure > > +which allows the platform to communicate what features it supports related to > > +NVDIMM data durability. Users can provide a capabilities value to a guest via > > +the optional "cap" device command line option: > > + > > + -device nvdimm,id=nvdimm1,memdev=mem1,cap=3 > > + > > +As of ACPI 6.2 Errata A, the following values are valid for the bottom two > > +bits: > > + > > +2 - Memory Controller Flush to NVDIMM Durability on Power Loss Capable. > > +3 - CPU Cache Flush to NVDIMM Durability on Power Loss Capable. > > + > > +For a complete list of the flags available please consult the ACPI spec. > > + > > +These platform capabilities apply to the entire virtual platform, so it is > > +recommended that only one "cap" device command option be given per virtual > > +machine. This value will apply to all NVDIMMs in the virtual platform. > This looks like it should be machine property instead of per device one, > you can get rid of static variable and mismatch check and a weird nvdimm CLI > option that implies that the option is per device. Yep, that's much better. I have this implemented and ready to go. > Also an extra patch to for make check that will test setting 'cap' > would be nice (an extra testcase in tests/bios-tables-test.c) Hmm...I've been looking at this, and it doesn't look like there is any verification around a lot of the ACPI tables (NFIT, SRAT, etc). I've verified my patch by interacting with a guest with various settings - is this good enough, or do you really want me to test the value (which I think would just be "do I get out what I put in at the command line") via the unit test infrastructure? Thank you for the review.
next prev parent reply other threads:[~2018-05-15 23:03 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-27 21:53 [PATCH 1/3] nvdimm: fix typo in label-size definition Ross Zwisler 2018-04-27 21:53 ` [Qemu-devel] " Ross Zwisler 2018-04-27 21:53 ` [PATCH 2/3] nvdimm, acpi: add NFIT platform capabilities Ross Zwisler 2018-04-27 21:53 ` [Qemu-devel] " Ross Zwisler 2018-04-30 11:39 ` Stefan Hajnoczi 2018-04-30 11:39 ` [Qemu-devel] " Stefan Hajnoczi 2018-05-10 13:39 ` Igor Mammedov 2018-05-10 13:39 ` Igor Mammedov 2018-04-27 21:53 ` [PATCH 3/3] nvdimm: platform capabilities command line option Ross Zwisler 2018-04-27 21:53 ` [Qemu-devel] " Ross Zwisler 2018-04-30 11:39 ` Stefan Hajnoczi 2018-04-30 11:39 ` [Qemu-devel] " Stefan Hajnoczi 2018-05-10 13:28 ` Igor Mammedov 2018-05-10 13:28 ` Igor Mammedov 2018-05-15 23:03 ` Ross Zwisler [this message] 2018-05-15 23:03 ` Ross Zwisler 2018-05-16 7:22 ` Igor Mammedov 2018-05-16 7:22 ` Igor Mammedov 2018-04-30 11:38 ` [PATCH 1/3] nvdimm: fix typo in label-size definition Stefan Hajnoczi 2018-04-30 11:38 ` [Qemu-devel] " Stefan Hajnoczi 2018-05-03 22:20 ` Ross Zwisler 2018-05-03 22:20 ` [Qemu-devel] " Ross Zwisler 2018-05-04 8:44 ` Stefan Hajnoczi 2018-05-04 8:44 ` [Qemu-devel] " Stefan Hajnoczi 2018-05-10 13:06 ` Igor Mammedov 2018-05-10 13:06 ` Igor Mammedov
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=20180515230351.GA741@linux.intel.com \ --to=ross.zwisler@linux.intel.com \ --cc=ehabkost@redhat.com \ --cc=imammedo@redhat.com \ --cc=linux-nvdimm@lists.01.org \ --cc=mst@redhat.com \ --cc=qemu-devel@nongnu.org \ --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: linkBe 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.