From: Alex Williamson <alex.williamson@hp.com>
To: Beth Kon <eak@us.ibm.com>
Cc: bochs-developers@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH] Correct SMBIOS handling of multiple tables
Date: Wed, 27 May 2009 19:38:21 -0600 [thread overview]
Message-ID: <1243474701.15223.12.camel@2710p.home> (raw)
In-Reply-To: <4A1DD659.7090604@us.ibm.com>
On Wed, 2009-05-27 at 20:10 -0400, Beth Kon wrote:
> Without this patch, the current code has a problem even in the case of
> default tables (nothing specified on command line). Following the code
> path for add_struct(4, p, cpu_num) (for example) add_struct is called
> once for each cpu. add_struct calls smbios_load_external, and the first
> thing that does is check used_bitmap. The first pass through for table 4
> works. But if the vm is smp, the second pass through doesn't work
> because used_bitmap reports that a table 4 entry was already created, so
> smbios_load_external returns a 1 and add_struct becomes a noop in
> effect. I think this patch does what you intended, to override default
> creation with external creation if specified on the command line, and to
> get only one complete set of tables for each type.
Oh, I see the problem now, thanks for the explanation. I don't think
that's the right fix though. If we remove the duplicate check at the
start of smbios_load_external() and the user passes a binary, we might
add it more than once. For instance the case where the user specifies
'-smp 2' and passes 2 type 4 entries, they would end up with 4 type 4
entries.
Don't we just need to only mark the bitmap if we load something
externally? Something like this:
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
--
diff --git a/bios/rombios32.c b/bios/rombios32.c
index f861f81..c869798 100644
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -2554,13 +2554,14 @@ smbios_load_external(int type, char **p, unsigned *nr_structs,
*max_struct_size = *p - (char *)header;
}
- /* Mark that we've reported on this type */
- used_bitmap[(type >> 6) & 0x3] |= (1ULL << (type & 0x3f));
+ if (start != *p) {
+ /* Mark that we've reported on this type */
+ used_bitmap[(type >> 6) & 0x3] |= (1ULL << (type & 0x3f));
+ return 1;
+ }
- return (start != *p);
-#else /* !BX_QEMU */
+#endif /* !BX_QEMU */
return 0;
-#endif
}
void smbios_init(void)
next prev parent reply other threads:[~2009-05-28 1:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-27 21:42 [Qemu-devel] [PATCH] Correct SMBIOS handling of multiple tables Beth Kon
2009-05-27 23:17 ` [Qemu-devel] " Alex Williamson
2009-05-28 0:10 ` Beth Kon
2009-05-28 1:38 ` Alex Williamson [this message]
2009-05-28 15:05 ` Beth Kon
2009-05-28 15:51 ` Alex Williamson
2009-05-28 16:29 ` Beth Kon
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=1243474701.15223.12.camel@2710p.home \
--to=alex.williamson@hp.com \
--cc=bochs-developers@lists.sourceforge.net \
--cc=eak@us.ibm.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).