qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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)

  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).