qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Verma, Vishal L" <vishal.l.verma@intel.com>
Cc: "lvivier@redhat.com" <lvivier@redhat.com>,
	"thuth@redhat.com" <thuth@redhat.com>,
	"xiaoguangrong.eric@gmail.com" <xiaoguangrong.eric@gmail.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"Liu, Jingqi" <jingqi.liu@intel.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"ehabkost@redhat.com" <ehabkost@redhat.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [PATCH v4 2/3] hw/acpi/nvdimm: add a helper to augment SRAT generation
Date: Fri, 5 Jun 2020 10:23:45 +0200	[thread overview]
Message-ID: <20200605102345.52b2008a@redhat.com> (raw)
In-Reply-To: <73b11cd452acffc18f7083f1ea7e5ca22cade31f.camel@intel.com>

On Fri, 5 Jun 2020 00:54:28 +0000
"Verma, Vishal L" <vishal.l.verma@intel.com> wrote:

> On Thu, 2020-06-04 at 12:33 +0200, Igor Mammedov wrote:
> > On Thu, 28 May 2020 16:34:36 -0600
> > Vishal Verma <vishal.l.verma@intel.com> wrote:
> >   
> > > NVDIMMs can belong to their own proximity domains, as described by the
> > > NFIT. In such cases, the SRAT needs to have Memory Affinity structures
> > > in the SRAT for these NVDIMMs, otherwise Linux doesn't populate node
> > > data structures properly during NUMA initialization. See the following
> > > for an example failure case.
> > > 
> > > https://lore.kernel.org/linux-nvdimm/20200416225438.15208-1-vishal.l.verma@intel.com/
> > > 
> > > Introduce a new helper, nvdimm_build_srat(), and call it for both the
> > > i386 and arm versions of 'build_srat()' to augment the SRAT with
> > > memory affinity information for NVDIMMs.
> > > 
> > > The relevant command line options to exercise this are below. Nodes 0-1
> > > contain CPUs and regular memory, and nodes 2-3 are the NVDIMM address
> > > space.
> > > 
> > >   -numa node,nodeid=0,mem=2048M,
> > >   -numa node,nodeid=1,mem=2048M,  
> > 
> > pls note that 'mem' is about to be disabled for new machine types in favor of memdev
> > so this CLI won't work.
> > It would be nice to update commit message with memdev variant of CLI  
> 
> I saw the warnings printed - I did try to use memdevs, but it didn't
> quite work with my use case. I'm supplying mem=0 for the pmem/nvdimm
> devices that I want to give a specific numa node, but not give them any
> more regular memory aside from the nvdimm itself (see nodes 4 and 5
> below). And for some reason I couldn't do that with memdevs.
it should work since 4.1

here is example 
qemu-system-x86_64 -object memory-backend-ram,id=mem0,size=1G -m 1G \
 -numa node,memdev=mem0 -numa node -monitor stdio

QEMU 5.0.50 monitor - type 'help' for more information
(qemu) VNC server running on ::1:5900
info numa
2 nodes
node 0 cpus: 0
node 0 size: 1024 MB
node 0 plugged: 0 MB
node 1 cpus:
node 1 size: 0 MB
node 1 plugged: 0 MB
(qemu)
> 
> Here is the full command line I'm using for example. I'd appreciate any
> pointers on converting over to memdevs fully.
> 
>    qemu-system-x86_64 
>    -machine pc,accel=kvm,nvdimm, 
>    -m 8192M,slots=4,maxmem=40960M 
>    -smp 8,sockets=2,cores=2,threads=2 
>    -enable-kvm 
>    -display none 
>    -nographic 
>    -drive file=root.img,format=raw,media=disk 
>    -kernel ./mkosi.extra/boot/vmlinuz-5.7.0-00001-g87ad963bac23 
>    -initrd mkosi.extra/boot/initramfs-5.7.0-00001-g87ad963bac23.img 
>    -append selinux=0 audit=0 console=tty0 console=ttyS0 root=/dev/sda2 ignore_loglevel rw 
>    -device e1000,netdev=net0 
>    -netdev user,id=net0,hostfwd=tcp::10022-:22 
>    -snapshot 
>    -numa node,nodeid=0,mem=2048M, 
>    -numa cpu,node-id=0,socket-id=0 
>    -numa node,nodeid=1,mem=2048M, 
>    -numa cpu,node-id=1,socket-id=1 
>    -numa node,nodeid=2,mem=2048M, 
>    -numa node,nodeid=3,mem=2048M, 
>    -numa node,nodeid=4,mem=0, 
>    -object memory-backend-file,id=nvmem0,share,mem-path=nvdimm-0,size=16384M,align=1G 
>    -device nvdimm,memdev=nvmem0,id=nv0,label-size=2M,node=4 
>    -numa node,nodeid=5,mem=0, 
>    -object memory-backend-file,id=nvmem1,share,mem-path=nvdimm-1,size=16384M,align=1G 
>    -device nvdimm,memdev=nvmem1,id=nv1,label-size=2M,node=5 
> 
> >   
> > >   -numa node,nodeid=2,mem=0,
> > >   -object memory-backend-file,id=nvmem0,share,mem-path=nvdimm-0,size=16384M,align=128M
> > >   -device nvdimm,memdev=nvmem0,id=nv0,label-size=2M,node=2
> > >   -numa node,nodeid=3,mem=0,
> > >   -object memory-backend-file,id=nvmem1,share,mem-path=nvdimm-1,size=16384M,align=128M
> > >   -device nvdimm,memdev=nvmem1,id=nv1,label-size=2M,node=3
> > > 
> > > Cc: Jingqi Liu <jingqi.liu@intel.com>
> > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > Reviewed-by: Jingqi Liu <jingqi.liu@intel.com>
> > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>  
> > 
> > Reviewed-by: Igor Mammedov <imammedo@redhat.com>  
> 
> Thanks for the review Igor - I'm pretty unfamiliar with qemu development
> - what are the next steps? Is there a certain maintainer/tree I could
> watch for the inclusion of this?
> 
> >   
> > > ---
> > >  hw/acpi/nvdimm.c         | 23 +++++++++++++++++++++++
> > >  hw/arm/virt-acpi-build.c |  4 ++++
> > >  hw/i386/acpi-build.c     |  5 +++++
> > >  include/hw/mem/nvdimm.h  |  1 +
> > >  4 files changed, 33 insertions(+)
> > > 
> > >   



  reply	other threads:[~2020-06-05  8:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 22:34 [PATCH v4 0/3] account for NVDIMM nodes during SRAT generation Vishal Verma
2020-05-28 22:34 ` [PATCH v4 1/3] diffs-allowed: add the SRAT AML to diffs-allowed Vishal Verma
2020-05-28 22:34 ` [PATCH v4 2/3] hw/acpi/nvdimm: add a helper to augment SRAT generation Vishal Verma
2020-06-04 10:33   ` Igor Mammedov
2020-06-05  0:54     ` Verma, Vishal L
2020-06-05  8:23       ` Igor Mammedov [this message]
2020-06-05 23:52         ` Verma, Vishal L
2020-05-28 22:34 ` [PATCH v4 3/3] tests/acpi: update expected SRAT files Vishal Verma

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=20200605102345.52b2008a@redhat.com \
    --to=imammedo@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=ehabkost@redhat.com \
    --cc=jingqi.liu@intel.com \
    --cc=lvivier@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    --cc=vishal.l.verma@intel.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 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).