From: Linda Knippers <linda.knippers@hpe.com>
To: joeyli <jlee@suse.com>, Dan Williams <dan.j.williams@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux ACPI <linux-acpi@vger.kernel.org>, Lee,
Subject: Re: [PATCH] libnvdimm, nfit: treat volatile virtual CD region as read-only pmem
Date: Thu, 9 Jun 2016 18:08:17 -0400 [thread overview]
Message-ID: <888aeb53-69b4-652b-8f89-822af4622acf@hpe.com> (raw)
In-Reply-To: <20160604110156.GA4558@linux-rxt1.site>
On 6/4/2016 7:01 AM, joeyli wrote:
> Hi Dan,
>
> Thanks for your review.
>
> On Fri, Jun 03, 2016 at 12:27:34PM -0700, Dan Williams wrote:
>> On Fri, Jun 3, 2016 at 12:13 AM, Lee, Chun-Yi <joeyli.kernel@gmail.com> wrote:
>>> This patch adds codes to treat a volatile virtual CD region as a
>>> read-only pmem region, then read-only /dev/pmem* device can be mounted
>>> with iso9660.
>>>
>>> It's useful to work with the httpboot in EFI firmware to pull a remote
>>> ISO file to the local memory region for booting and installation.
>>>
>>> Wiki page of UEFI HTTPBoot with OVMF:
>>> https://en.opensuse.org/UEFI_HTTPBoot_with_OVMF
>>>
>>> Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
>>> Cc: Gary Lin <GLin@suse.com>
>>> Cc: Dan Williams <dan.j.williams@intel.com>
>>> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>>> ---
>>> drivers/acpi/nfit.c | 8 +++++++-
>>> drivers/nvdimm/region_devs.c | 26 +++++++++++++++++++++++++-
>>> include/linux/libnvdimm.h | 2 ++
>>> 3 files changed, 34 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
>>> index 2215fc8..b100a17 100644
>>> --- a/drivers/acpi/nfit.c
>>> +++ b/drivers/acpi/nfit.c
>>> @@ -1949,6 +1949,7 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc *acpi_desc,
>>> switch (nfit_spa_type(spa)) {
>>> case NFIT_SPA_PM:
>>> case NFIT_SPA_VOLATILE:
>>> + case NFIT_SPA_VCD:
>>> nd_mapping->start = memdev->address;
>>> nd_mapping->size = memdev->region_size;
>>> break;
>>
>> Why do we need to distinguish NFIT_SPA_VOLATILE vs NFIT_SPA_VCD, i.e.
>> what happens if something writes to a VCD device?
>
> Actually I didn't try to write SPA-VCD device before. Every time I mount it
> that the system responses read-only:
>
> # mount /dev/pmem0 /mnt/
> mount: /dev/pmem0 is write-protected, mounting read-only
>
> If it can be written, then I think there have no difference between
> NFIT_SPA_VOLATILE with NFIT_SPA_VCD region.
It's not clear to me what the expectations for this type of device are, or
whether they should be read-only. The ACPI spec is not helpful here.
The other Disk Region and CD Region types are also unclear. Anyone
care to define them?
> I implemented this patch to treat VCD region as read-only pmem because the
> pmem region generates /dev/pmem* device that it can be mounted.
I'm a bit worried about this type of device showing up as a "pmem" device.
I realize they're described in the NFIT (not sure why but they are) but do
any of the operations that we support for other pmem devices work on these?
Do root device DSMs make any sense? Are there other DSMs? What will happen
if someone uses ndctl to reconfigure the device?
I'm especially concerned on systems that might have one of these devices
and also have NVDIMMs. Do all the pmem devices get numbered different if
this device comes and goes across reboots? (I know, we shouldn't rely on
those names but it will still confuse people.) Can they be some other name
that better represents what they're trying to be?
> Maybe I missed. Does NFIT_SPA_VOLATILE region also generate a device in /dev
> that it can be mounted with filesystem?
Yes.
-- ljk
> Then I think treat the VCD region as
> a read-only VOLATILE region that's also a solution.
>
>
> Thanks a lot!
> Joey Lee
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2016-06-09 22:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-03 7:13 [PATCH] libnvdimm, nfit: treat volatile virtual CD region as read-only pmem Lee, Chun-Yi
2016-06-03 19:27 ` Dan Williams
2016-06-04 11:01 ` joeyli
2016-06-04 16:24 ` Dan Williams
2016-06-05 14:45 ` joeyli
2016-06-05 14:52 ` joeyli
2016-06-09 22:08 ` Linda Knippers [this message]
2016-06-09 22:34 ` Dan Williams
2016-06-12 2:10 ` joeyli
2016-06-12 1:58 ` joeyli
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=888aeb53-69b4-652b-8f89-822af4622acf@hpe.com \
--to=linda.knippers@hpe.com \
--cc=dan.j.williams@intel.com \
--cc=jlee@suse.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=rjw@rjwysocki.net \
/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