From: Igor Mammedov <imammedo@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
Julia Suvorova <jusual@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Xiao Guangrong <xiaoguangrong.eric@gmail.com>
Subject: Re: [PATCH] hw/mem/nvdimm: fix error message for 'unarmed' flag
Date: Tue, 14 Jun 2022 16:08:24 +0200 [thread overview]
Message-ID: <20220614160824.342c03a6@redhat.com> (raw)
In-Reply-To: <ac7c0d9c-4fb2-c67b-db25-00e4bbc0eb42@redhat.com>
On Tue, 14 Jun 2022 11:50:43 +0200
David Hildenbrand <david@redhat.com> wrote:
> On 14.06.22 10:54, Igor Mammedov wrote:
> > On Mon, 13 Jun 2022 16:09:53 +0100
> > Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> >> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
> >>> On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >>>>
> >>>> On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:
> >>>>> In the ACPI specification [1], the 'unarmed' bit is set when a device
> >>>>> cannot accept a persistent write. This means that when a memdev is
> >>>>> read-only, the 'unarmed' flag must be turned on. The logic is correct,
> >>>>> just changing the error message.
> >>>>>
> >>>>> [1] ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM State Flags" Bit 3
> >>>>>
> >>>>> Signed-off-by: Julia Suvorova <jusual@redhat.com>
> >>>>> ---
> >>>>> hw/mem/nvdimm.c | 2 +-
> >>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> >>>
> >>> It seems like Xiao is not active, whose tree should this patch go to?
>
> Is that a temporary or a permanent thing? Do we know?
>
> >
> > Perhaps David can add himself as maintainer (i.e. put it
> > under memory mantanership umbrella) and merge it
>
> Maybe it makes sense to combine NVDIMM with pc-dimm.c and
> memory-device.c into a "MEMORY DEVICE" section. Then, remove "hw/mem/*"
> from "ACPI/SMBIOS".
just keep me on supporter list for them so I won't miss
patches that needs reviewing.
> cxl_type3.c, npcm7xx_mc.c and sparse-mem.c in /hw/mem/ are a bit
> different. We could add cxl_type3.c to "Compute Express Link".
> npcm7xx_mc.c and sparse-mem.c should be already covered.
for cxl I'd add Michael as it's mostly all PCI stuff
prev parent reply other threads:[~2022-06-14 14:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-31 14:51 [PATCH] hw/mem/nvdimm: fix error message for 'unarmed' flag Julia Suvorova
2022-05-31 15:32 ` Stefan Hajnoczi
2022-06-13 15:01 ` Julia Suvorova
2022-06-13 15:09 ` Stefan Hajnoczi
2022-06-14 8:54 ` Igor Mammedov
2022-06-14 9:50 ` David Hildenbrand
2022-06-14 12:13 ` Julia Suvorova
2022-06-15 8:24 ` David Hildenbrand
2022-06-15 11:17 ` Xiao Guangrong
2022-06-15 11:49 ` David Hildenbrand
2022-06-17 12:03 ` Xiao Guangrong
2022-06-14 14:08 ` Igor Mammedov [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=20220614160824.342c03a6@redhat.com \
--to=imammedo@redhat.com \
--cc=david@redhat.com \
--cc=jusual@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=xiaoguangrong.eric@gmail.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.