All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Zamazal <mzamazal@redhat.com>
To: "Liu, Jingqi" <jingqi.liu@intel.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	"Lai, Paul C" <paul.c.lai@intel.com>,
	Cornelia Huck <cohuck@redhat.com>, Arik Hadas <ahadas@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	Amnon Ilan <ailan@redhat.com>
Subject: Re: Adjustments of NVDIMM devices and future data safety
Date: Tue, 18 May 2021 17:29:33 +0200	[thread overview]
Message-ID: <8735ukhxgi.fsf@redhat.com> (raw)
In-Reply-To: <be4c2ff5-9de9-1843-fd1f-1295e64fd68a@intel.com> (Jingqi Liu's message of "Sat, 8 May 2021 15:30:15 +0800")

"Liu, Jingqi" <jingqi.liu@intel.com> writes:

> Hi Milan,
>
> On 4/30/2021 8:18 PM, Milan Zamazal wrote:
>> Hi,
>>
>> I work on NVDIMM support in oVirt/RHV, I think other virtualization
>> management software built on top of QEMU may have similar concerns.
>>
>> When a virtual NVDIMM device size is specified, it's not necessarily the
>> eventual NVDIMM device size visible to the guest OS.  As seen in
>> https://github.com/qemu/qemu/blob/v6.0.0/hw/mem/nvdimm.c#L117, QEMU
>> makes some adjustments (other adjustments are performed by libvirt but
>> that's a topic for a different forum):
>>
>> - NVDIMM label size is subtracted from the NVDIMM size.
>>
>> - NVDIMM label is pointed to a certain memory region.
>>
>> - The remaining NVDIMM size is aligned down.
>>
>> There are some related potential problems:
>>
>> - If the alignment rules change in a future QEMU version, it may result
>>    in a different device size visible to the guest (even if the requested
>>    size remains the same) and cause trouble there up to data loss.
>>
>> - If the layout on the backing device changes, e.g. a label placement,
>>    then the stored data may become corrupt or inaccessible.
>>
>> - I'm not sure about the current QEMU version, but at least in previous
>>    QEMU versions, the resulting size is important for memory hot plug.
>>    The NVDIMM alignment size is smaller than the required regular memory
>>    DIMM placement alignment.  If a VM contains an NVDIMM with the
>>    resulting size not matching the DIMM placement requirements and a
>>    memory hot plug is attempted then the hot plug fails because the DIMM
>>    is mapped next to the end of the NVDIMM region, which is not
>>    DIMM-aligned.
>
> Can you explain the details and give an example of how to reproduce
> this issue ?

I rechecked it with current QEMU and several different NVDIMM device
sizes and I can no longer reproduce the issue.  So hopefully it's no
longer present.

Regards,
Milan



      reply	other threads:[~2021-05-18 15:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 12:18 Adjustments of NVDIMM devices and future data safety Milan Zamazal
2021-05-03 14:09 ` Igor Mammedov
2021-05-05 20:46   ` Milan Zamazal
2021-05-08  7:30 ` Liu, Jingqi
2021-05-18 15:29   ` Milan Zamazal [this message]

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=8735ukhxgi.fsf@redhat.com \
    --to=mzamazal@redhat.com \
    --cc=ahadas@redhat.com \
    --cc=ailan@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=ehabkost@redhat.com \
    --cc=jingqi.liu@intel.com \
    --cc=paul.c.lai@intel.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: 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.