qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Gabriel Somlo <gsomlo@gmail.com>
Cc: armbru@redhat.com, agraf@suse.de, qemu-devel@nongnu.org,
	alex.williamson@redhat.com, kevin@koconnor.net,
	Gerd Hoffmann <kraxel@redhat.com>,
	lersek@redhat.com
Subject: Re: [Qemu-devel] SMBIOS vs. NUMA (was: Build full type 19 tables)
Date: Fri, 14 Mar 2014 18:51:05 +0100	[thread overview]
Message-ID: <20140314185105.03ef739e@thinkpad> (raw)
In-Reply-To: <20140314151434.GA30418@LINUXLAB-0.INI.CMU.EDU>

On Fri, 14 Mar 2014 11:14:35 -0400
Gabriel Somlo <gsomlo@gmail.com> wrote:

> On Fri, Mar 14, 2014 at 10:28:30AM +0100, Igor Mammedov wrote:
> > On Thu, 13 Mar 2014 15:01:16 -0400
> > "Gabriel L. Somlo" <gsomlo@gmail.com> wrote:
> > 
> > > On Thu, Mar 13, 2014 at 04:36:12PM +0100, Igor Mammedov wrote:
> > > > 
> > > > After memory hotplug is in I might add e820 entries after above_4g
> > > > for present at boot hotpluggable DIMMDevices. They would have 1:1 mapping
> > > > i.e. t19<-t20<-t17 and belong only to 1 node.
> > > 
> > > Any idea what the max size could be for each one of those ?
> > So far there isn't anything to limit max size of a DEIMMDevice except of
> > allowed max RAM size on QEMU CLI at startup time.
> 
> OK, so then it's more like:
> 
> <-----t19----->
> t20 t20 ... t20
> t17 t17 ... t17
> 
> since t17 is currently limited to 16G. Unless we went to smbios v2.7,
> but that would require lots more external coordination (the bios still
> generates the smbios entry point, where version is recorded). Right
> now that's 2.4.
> 
> More questions about e820: 
> 
> 1. is it safe to assume that E820_RAM (start_addr, size) entries are
> non-overlapping and sorted by increasing start_addr ?
They might overlap, grep for e820_add_entry(). If you interested in
what kernel does with such table look for sanitize_e820_map() there.

Does SMBIOS/t17 actually care about shadowing parts of it by something
else in unrelated e820?

> 
> 2. will there always be a below-4g entry ? if so, will it *and* the
> next entry automatically be assumed to belong to the first node, and
> only subsequently will there be one E820_RAM entry per node (for nodes
> 2, 3, etc) ? 
Once we have DIMMDevices, I'm planning to convert below-4g and above-4g to
a set of DIMMDevices, there will be at least 1 device per node but there could
be more of them to satisfy different backend requirements like hugepage
size, alignment, e.t.c.

BTW why do we care how smbios tables are build in relation to NUMA mapping,
they seem to be totally independent.

> Thanks,
> --Gabriel
> 


-- 
Regards,
  Igor

  reply	other threads:[~2014-03-14 17:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12 21:55 [Qemu-devel] SMBIOS vs. NUMA (was: Build full type 19 tables) Gabriel L. Somlo
2014-03-13  8:04 ` Gerd Hoffmann
2014-03-13 14:37   ` Gabriel L. Somlo
2014-03-13 15:36     ` Igor Mammedov
2014-03-13 19:01       ` Gabriel L. Somlo
2014-03-14  9:28         ` Igor Mammedov
2014-03-14 15:14           ` Gabriel Somlo
2014-03-14 17:51             ` Igor Mammedov [this message]
2014-03-14 19:36               ` Gabriel Somlo

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=20140314185105.03ef739e@thinkpad \
    --to=imammedo@redhat.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=gsomlo@gmail.com \
    --cc=kevin@koconnor.net \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).