Re: [SeaBIOS] [Qemu-devel] seabios serial console vs. sgabios

[Markus Armbruster]

Gerd Hoffmann  writes:

[...]
>> Libvirt doesn't use  '-machine graphics=off' AFAIK, only '-
>> nographic'.
>
> I think that is pretty much the same.  Setting "graphichs=off" is one
> of the effects of passing -nographic, and the other effects (like
> setting up default serial + monitor in a different way) don't happen
> due to libvirt also using -nodefaults.

-nographic is a legacy / convenience option these days.  I'd recommend
management tools use -machine graphics=off instead.

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] Minimum RAM size for PC machines?

[Markus Armbruster]

Last time I checked[1], SeaBIOS required 1MiB of RAM, and the failure
modes were mean.

Back then, I asked whether we should enforce a suitable minimum RAM
size[2].  Peter Maydell replied that modelling RAM constraints involves
an expedition into the Generality Swamps, and wished me better luck than
he had.

Four and a half years later, the failure modes are as mean as ever.  For
instance,

$ qemu-system-x86_64 --nodefaults -device VGA -m 640k

simply hangs for me, and

$ qemu-system-x86_64 --nodefaults -device VGA -m 16k

crashes with "qemu: fatal: Trying to execute code outside RAM or ROM at
0x4000" and a register dump with TCG, or the even less
helpful "KVM internal error. Suberror: 1" with KVM.

Waiting for "someone" to design and implement the completely general
solution has had the predictable result: nothing.

Are we now ready to accept a simple & stupid patch that actually helps
users, say letting boards that care declare minimum and maximum RAM
size?  And make PC reject RAM size less than 1MiB, even though "someone"
might conceivably have firmware that works with less?



[1] Message-ID: <87fw7xwqkq@blackfin.pond.sub.org>
https://www.seabios.org/pipermail/seabios/2012-August/004343.html
[2] Message-ID: <87wr1921rd@blackfin.pond.sub.org>
https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01319.html

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://www.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [PATCH v4 1/3] ich9: add TCO interface emulation

[Markus Armbruster]

Michael S. Tsirkin m...@redhat.com writes:

 On Mon, Jun 22, 2015 at 02:32:17PM +0200, Paolo Bonzini wrote:
 
 
 On 22/06/2015 14:30, Paulo Alcantara wrote:
   +/*
   + * QEMU ICH9 TCO emulation
   + *
   + * Copyright (c) 2015 Paulo Alcantara pca...@zytor.com
   + *
   + * Permission is hereby granted, free of charge, to any person
   obtaining a copy
   + * of this software and associated documentation files (the
   Software), to deal
   + * in the Software without restriction, including without limitation
   the rights
   + * to use, copy, modify, merge, publish, distribute,
   sublicense, and/or
   sell
   + * copies of the Software, and to permit persons to whom the Software
   is
   + * furnished to do so, subject to the following conditions:
   + *
   + * The above copyright notice and this permission notice shall be
   included in
   + * all copies or substantial portions of the Software.
   + *
   + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
   EXPRESS OR
   + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
   MERCHANTABILITY,
   + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
   SHALL
   + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
   DAMAGES OR
   OTHER
   + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
   ARISING FROM,
   + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   DEALINGS IN
   + * THE SOFTWARE.
  
   Please make new original code GPLv2+. If you have copied from another
   file, then you should follow that file's licensing, but in that case
   you should also acknowledge the original copyright.
  OK.
 
 Why?  The only forbidden license for new code is GPLv2.
 
 If you want to make things more permissive, that's accepted.
 
 Paolo

 Because it's a pain if I need to move code between files with different
 licenses.  MIT is GPL compatible but mixing licenses at random is still
 not a good idea.

Seconded.  New code should be GPLv2+ unless you have a really good
reason for something else.

Keeping the original license in a derivative work is a really good
reason (assuming it's compatible to GPLv2; if it's not, we can't use the
derivative work anyway).

LGPLv2+ license for code meant to be linked into differently licensed
other projects may be a good reason.

Other reasons exist.

Whatever your reason is, you need to explain it.

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFCv2] Add SeaBIOS wiki documents to git repo

[Markus Armbruster]

Kevin O'Connor ke...@koconnor.net writes:

 Based on the previous feedback, I've converted the current wiki
 documents to markdown format (via the pandoc tool) and then touched up
 the translation.  The attached patch shows what moving the wiki
 documents into the seabios repo might look like.  (It creates a new
 docs/ directory with files for each page currently on the wiki.)

 The pandoc tool seams to be able to translate back to mediawiki format
 without much issue.  So, a possible workflow would be to use the git
 patch submission process to update documentation, and then use pandoc
 to translate the pages and push them to the wiki.  (Or, if at some
 future point the wiki is decommissioned, then use pandoc or a similar
 tool to create html directly.)

 Thoughts?

If this workflow works for you, go right ahead!  Patch looks fine on a
glance.

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH v3] boot: Fix boot order for SCSI target, lun 9

[Markus Armbruster]

Paolo Bonzini pbonz...@redhat.com writes:

 Il 15/08/2014 08:58, Markus Armbruster ha scritto:
 
 No actual impact on USB, because QEMU only uses LUN 0 there.

 With usb-bot, you can actually add multiple LUNs to QEMU, up to LUN 15.

You're right; I forgot about the newer device.

  (USB Attached SCSI supports LUNs up to 255).  Still it's a very rare case.

Right again.  This is usb-uas.

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH v2] boot: Fix boot order for SCSI target, lun 9

[Markus Armbruster]

Kevin O'Connor ke...@koconnor.net writes:

 On Thu, Aug 14, 2014 at 10:18:34PM +0200, Markus Armbruster wrote:
 We identify devices by their Open Firmware device paths.  The path
 component for the logical unit on a bus is incorrect:
 bootprio_find_pci_device() formats target (a.k.a. SCSI ID) and lun in
 decimal, while QEMU uses hexadecimal.  Bootorder list entries with
 target, lun  9 aren't found (lucky case), or attributed to the wrong
 logical unit (unlucky case).
 
 The relevant spec[*] agrees with QEMU (and OVMF, for that matter).
 Change %d to %x.
 
 RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1096560
 
 [*] Open Firmware Recommended Practice: SCSI-3 Parallel Interface,
 Version 1, section 3.1 Physical Address Formats and Representations
 http://www.openfirmware.org/1275/practice/spi/spi1_0.ps

 Thanks.  The patch looks okay to me.  But, does bootprio_find_usb()
 also need to change?

You're right, there's a LUN hiding in that path.  I'll send v3.

Aside: the USB port number is also inconsistent with QEMU. but in that
case, SeaBIOS is correct and QEMU is wrong.  I'm going to fix it.

 I also wonder if the :rom%d stuff in bootprio_find_*_rom() should
 also be made hex just for consistency (though it seems unlikely a
 single rom would ever have more than 10 drives on it).

I don't know.  QEMU never generates a :NUMBER suffix, and I haven't
found a specification for this device path.

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH v3] boot: Fix boot order for SCSI target, lun 9

[Markus Armbruster]

We identify devices by their Open Firmware device paths.  The path
component for the logical unit on a bus is incorrect:
bootprio_find_scsi_device() and bootprio_find_usb() format target
(a.k.a. SCSI ID) and lun in decimal, while QEMU uses hexadecimal.
Bootorder list entries with target, lun  9 aren't found (lucky case),
or attributed to the wrong logical unit (unlucky case).

The relevant spec[*] agrees with QEMU (and OVMF, for that matter).
Change %d to %x.

No actual impact on USB, because QEMU only uses LUN 0 there.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1096560

[*] Open Firmware Recommended Practice: SCSI-3 Parallel Interface,
Version 1, Section 3.1 Physical Address Formats and Representations
http://www.openfirmware.org/1275/practice/spi/spi1_0.ps
IEEE Standard for Boot (Initialization Configuration) Firmware: Core
Requirements and Practices, IEEE Std 1275-1994, Annex E SCSI host
adapter package class, section E.2.1 Physical address formats and
representations

Signed-off-by: Markus Armbruster arm...@redhat.com
---
v3:
* Fix bootprio_find_usb() as well [Kevin]
* Also point to IEEE 1275 Annex E in commit message
v2:
* Fix the link to the spec (d'oh)
* While we're linking, link to RHBZ

 src/boot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/boot.c b/src/boot.c
index 5837ad0..34088c8 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -145,7 +145,7 @@ int bootprio_find_scsi_device(struct pci_device *pci, int 
target, int lun)
 // Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0
 char desc[256], *p;
 p = build_pci_path(desc, sizeof(desc), *, pci);
-snprintf(p, desc+sizeof(desc)-p, /*@0/*@%d,%d, target, lun);
+snprintf(p, desc+sizeof(desc)-p, /*@0/*@%x,%x, target, lun);
 return find_prio(desc);
 }
 
@@ -224,7 +224,7 @@ int bootprio_find_usb(struct usbdevice_s *usbdev, int lun)
 char desc[256], *p;
 p = build_pci_path(desc, sizeof(desc), usb, usbdev-hub-cntl-pci);
 p = build_usb_path(p, desc+sizeof(desc)-p, usbdev-hub);
-snprintf(p, desc+sizeof(desc)-p, /storage@%x/*@0/*@0,%d
+snprintf(p, desc+sizeof(desc)-p, /storage@%x/*@0/*@0,%x
  , usbdev-port+1, lun);
 int ret = find_prio(desc);
 if (ret = 0)
-- 
1.9.3


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH v3] boot: Fix boot order for SCSI target, lun 9

[Markus Armbruster]

Laszlo Ersek ler...@redhat.com writes:

 On 08/15/14 08:58, Markus Armbruster wrote:
 We identify devices by their Open Firmware device paths.  The path
 component for the logical unit on a bus is incorrect:
 bootprio_find_scsi_device() and bootprio_find_usb() format target
 (a.k.a. SCSI ID) and lun in decimal, while QEMU uses hexadecimal.
 Bootorder list entries with target, lun  9 aren't found (lucky case),
 or attributed to the wrong logical unit (unlucky case).
 
 The relevant spec[*] agrees with QEMU (and OVMF, for that matter).
 Change %d to %x.
 
 No actual impact on USB, because QEMU only uses LUN 0 there.
 
 RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1096560
 
 [*] Open Firmware Recommended Practice: SCSI-3 Parallel Interface,
 Version 1, Section 3.1 Physical Address Formats and Representations
 http://www.openfirmware.org/1275/practice/spi/spi1_0.ps
 IEEE Standard for Boot (Initialization Configuration) Firmware: Core
 Requirements and Practices, IEEE Std 1275-1994, Annex E SCSI host
 adapter package class, section E.2.1 Physical address formats and
 representations
 
 Signed-off-by: Markus Armbruster arm...@redhat.com
 ---
 v3:
 * Fix bootprio_find_usb() as well [Kevin]
 * Also point to IEEE 1275 Annex E in commit message
 v2:
 * Fix the link to the spec (d'oh)
 * While we're linking, link to RHBZ
 
  src/boot.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/src/boot.c b/src/boot.c
 index 5837ad0..34088c8 100644
 --- a/src/boot.c
 +++ b/src/boot.c
 @@ -145,7 +145,7 @@ int bootprio_find_scsi_device(struct pci_device *pci, 
 int target, int lun)
  // Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0
  char desc[256], *p;
  p = build_pci_path(desc, sizeof(desc), *, pci);
 -snprintf(p, desc+sizeof(desc)-p, /*@0/*@%d,%d, target, lun);
 +snprintf(p, desc+sizeof(desc)-p, /*@0/*@%x,%x, target, lun);
  return find_prio(desc);
  }
  
 @@ -224,7 +224,7 @@ int bootprio_find_usb(struct usbdevice_s *usbdev, int 
 lun)
  char desc[256], *p;
  p = build_pci_path(desc, sizeof(desc), usb, usbdev-hub-cntl-pci);
  p = build_usb_path(p, desc+sizeof(desc)-p, usbdev-hub);
 -snprintf(p, desc+sizeof(desc)-p, /storage@%x/*@0/*@0,%d
 +snprintf(p, desc+sizeof(desc)-p, /storage@%x/*@0/*@0,%x
   , usbdev-port+1, lun);
  int ret = find_prio(desc);
  if (ret = 0)
 

 We had discussed bootprio_find_usb() too on IRC; I thought you were
 going to send a separate patch for that. But it's OK this way as well,
 obviously.

Stupid misunderstanding on my part.  I saw only the port number
mismatch, and that needs fixing in QEMU.  I missed the lun mismatch.

 Reviewed-by: Laszlo Ersek ler...@redhat.com

Thanks!

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH v2] boot: Fix boot order for SCSI target, lun 9

[Markus Armbruster]

Kevin O'Connor ke...@koconnor.net writes:

 On Fri, Aug 15, 2014 at 08:39:19AM +0200, Markus Armbruster wrote:
  I also wonder if the :rom%d stuff in bootprio_find_*_rom() should
  also be made hex just for consistency (though it seems unlikely a
  single rom would ever have more than 10 drives on it).
 
 I don't know.  QEMU never generates a :NUMBER suffix, and I haven't
 found a specification for this device path.

 It isn't part of a spec and I don't think QEMU ever used it.  Now that
 I think about it, I believe I added it to make sure multiple BCV
 declarations in a rom could be uniquely identified and wouldn't be
 confused with each other during pattern matching.  So, a change to %x
 would purely be for consistency.

 I'll put up a separate patch for it.

Makes sense, as everything else is hexadecimal.

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH] boot: Change :rom%d boot order rom instance to :rom%x

[Markus Armbruster]

Kevin O'Connor ke...@koconnor.net writes:

 Use hex numbers for the rom instance count in boot order open firmware
 device naming.  The :rom suffix isn't part of a standard and it's
 highly unlikely any rom would have 10 or more drives on it, but this
 change makes the code more similar to the numbering of other boot
 order devices.

Reviewed-by: Markus Armbruster arm...@redhat.com

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH] boot: Fix boot order for SCSI target, lun 9

[Markus Armbruster]

We identify devices by their Open Firmware device paths.  The path
component for the logical unit on a bus is incorrect:
bootprio_find_pci_device() formats target (a.k.a. SCSI ID) and lun in
decimal, while QEMU uses hexadecimal.  Bootorder list entries with
target, lun  9 aren't found (lucky case), or attributed to the wrong
logical unit (unlucky case).

The relevant spec[*] agrees with QEMU (and OVMF, for that matter).
Change %d to %x.

[*] Open Firmware Recommended Practice: SCSI-3 Parallel Interface,
Version 1, section 3.1 Physical Address Formats and Representations
http://www.openfirmware.org/1275/bindings/usb/usb-1_0.ps

Signed-off-by: Markus Armbruster arm...@redhat.com
---
 src/boot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/boot.c b/src/boot.c
index 5837ad0..6e41ccf 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -145,7 +145,7 @@ int bootprio_find_scsi_device(struct pci_device *pci, int 
target, int lun)
 // Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0
 char desc[256], *p;
 p = build_pci_path(desc, sizeof(desc), *, pci);
-snprintf(p, desc+sizeof(desc)-p, /*@0/*@%d,%d, target, lun);
+snprintf(p, desc+sizeof(desc)-p, /*@0/*@%x,%x, target, lun);
 return find_prio(desc);
 }
 
-- 
1.9.3


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH v2] boot: Fix boot order for SCSI target, lun 9

[Markus Armbruster]

We identify devices by their Open Firmware device paths.  The path
component for the logical unit on a bus is incorrect:
bootprio_find_pci_device() formats target (a.k.a. SCSI ID) and lun in
decimal, while QEMU uses hexadecimal.  Bootorder list entries with
target, lun  9 aren't found (lucky case), or attributed to the wrong
logical unit (unlucky case).

The relevant spec[*] agrees with QEMU (and OVMF, for that matter).
Change %d to %x.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1096560

[*] Open Firmware Recommended Practice: SCSI-3 Parallel Interface,
Version 1, section 3.1 Physical Address Formats and Representations
http://www.openfirmware.org/1275/practice/spi/spi1_0.ps

Signed-off-by: Markus Armbruster arm...@redhat.com
---
v2:
- Fix the link to the spec (d'oh)
- While we're linking, link to RHBZ

 src/boot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/boot.c b/src/boot.c
index 5837ad0..6e41ccf 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -145,7 +145,7 @@ int bootprio_find_scsi_device(struct pci_device *pci, int 
target, int lun)
 // Find scsi drive - for example: /pci@i0cf8/scsi@5/channel@0/disk@1,0
 char desc[256], *p;
 p = build_pci_path(desc, sizeof(desc), *, pci);
-snprintf(p, desc+sizeof(desc)-p, /*@0/*@%d,%d, target, lun);
+snprintf(p, desc+sizeof(desc)-p, /*@0/*@%x,%x, target, lun);
 return find_prio(desc);
 }
 
-- 
1.9.3


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] Coverity detected issues in SeaBIOS

[Markus Armbruster]

Kevin O'Connor ke...@koconnor.net writes:

 On Wed, Jul 16, 2014 at 04:27:18PM +0100, Ian Campbell wrote:
 Hello,
 
 We run Coverity on the Xen source code occasionally and it happens to
 include SeaBIOS. The following new warnings have appeared since I pulled
 in rel-1.7.5.

 Thanks.  All five look like false positives to me.  I'm happy to take
 patches if you want to rework the code to prevent the warnings.

 At least the MISSING_BREAK ones look likely to be valid to me. Not sure
 about the other two...

 It's a bit ugly, but it should be okay because all three cases start
 with if (!MODESEGMENT) which is a compile time constant.  So, when
 compiled in 32bit mode the three cases will each return the results
 from their respective functions, and in 16bit mode all three will
 return DISK_RET_EPARAM.

A comment would make your intention clearn and shut up Coverity:

case DTYPE_USB_32:
if (!MODESEGMENT)
return usb_cmd_data(op, cdbcmd, blocksize);
/* fall through */
case DTYPE_UAS_32:
if (!MODESEGMENT)
return uas_cmd_data(op, cdbcmd, blocksize);

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [QEMU v6 PATCH 00/17] SMBIOS: build full tables in QEMU

[Markus Armbruster]

Gerd Hoffmann kra...@redhat.com writes:

 On Di, 2014-04-22 at 09:01 -0400, Gabriel L. Somlo wrote:
 On Tue, Apr 22, 2014 at 08:42:29AM +0200, Gerd Hoffmann wrote:
  acpi is pretty much in the same boat ...
  
  /me looks ...
  
  Ah, there is a notifier where you (hopefully) can hook in easily:
  pc_guest_info_machine_done (see hw/i386/pc.c).
 
 Not sure this can help me though. The order in which things happen is:
 
   1. smbios_entry_add() gets called for every -smbios file=... and
  -smbios type=... command line argument
 
 a. type=... is OK, we just remember the values for later
 
 b. file=... less so, because we have to load the blobs into
*something*.

 Remember the filenames for later ...

  In my v7 patch set I decided to load the blobs
into *both* the legacy and new-fangled aggregate tables.
 
   2. smbios_set_defaults() is called
 
 - by now we *already* know the machine version we have, so
   we get to free the table we now know we won't need
   (aggregate if we're on = v2.0, legacy if 2.1 or newer,
see 1.b. above)

 ... and load the blobs here?

I don't like this technique, because it tends to degrade error messages.
When you're processing the option, your error messages come out with
nice location information automatically.  If you just store filenames,
that's lost.  To preserve it, you need to do extra work.

Note that smbios.c already stores the -smbios type=... for later use by
smbios_get_table()'s table building.  Could you store the blob, too?

[...]

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH] smbios: catch zero-length strings

[Markus Armbruster]

Gerd Hoffmann kra...@redhat.com writes:

 qemu may pass us zero-length strings for smbios fields, when starting
 qemu this way  ...

   qemu -smbios type=1,version=,serial=test

 ... for example.

 Today we don't specifically handle them and simply append them to the
 string list.  Therefore we get two string-terminating zeros in a row.
 Result is that we by accident create a end-of-entry marker in the middle
 of the entry.

And dmidecode screaming bloody murder :)  More detail than you probably
want to know at https://bugzilla.redhat.com/show_bug.cgi?id=1052837

 Fix this by handling zero-length strings like non-present strings.

 Cc: arm...@redhat.com
 Signed-off-by: Gerd Hoffmann kra...@redhat.com

Spelling correction inline.

Reviewed-by: Markus Armbruster arm...@redhat.com

 ---
  src/fw/smbios.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/src/fw/smbios.c b/src/fw/smbios.c
 index affb9be..d549329 100644
 --- a/src/fw/smbios.c
 +++ b/src/fw/smbios.c
 @@ -133,20 +133,24 @@ get_external(int type, char **p, unsigned *nr_structs,
  do {\
  size = get_field(type, offsetof(struct smbios_type_##type,  \
  field), end);   \
 -if (size  0) { \
 +if (size == 1) {\
 +/* zero-length string, skip to avoid bogous end marker */   \

s/bogous/bogus/

 +p-field = 0;   \
 +} else if (size  1) {  \
  end += size;\
 +p-field = ++str_index; \
  } else {\
  memcpy(end, def, sizeof(def));  \
  end += sizeof(def); \
 +p-field = ++str_index; \
  }   \
 -p-field = ++str_index; \
  } while (0)
  
  #define load_str_field_or_skip(type, field) \
  do {\
  size = get_field(type, offsetof(struct smbios_type_##type,  \
  field), end);   \
 -if (size  0) { \
 +if (size  1) { \
  end += size;\
  p-field = ++str_index; \
  } else {\

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] KVM call agenda for 2013-05-28

[Markus Armbruster]

Anthony Liguori anth...@codemonkey.ws writes:

 Gerd Hoffmann kra...@redhat.com writes:

 On 05/29/13 01:53, Kevin O'Connor wrote:
 On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
 Juan is not available now, and Anthony asked for
 agenda to be sent early.
 So here comes:

 Agenda for the meeting Tue, May 28:

 - Generating acpi tables
 
 I didn't see any meeting notes, but I thought it would be worthwhile
 to summarize the call.  This is from memory so correct me if I got
 anything wrong.
 
 Anthony believes that the generation of ACPI tables is the task of the
 firmware.  Reasons cited include security implications of running more
 code in qemu vs the guest context,

 I fail to see the security issues here.  It's not like the apci table
 generation code operates on untrusted input from the guest ...

 But possibly untrusted input from a malicious user.  You can imagine
 something like a IaaS provider that let's a user input arbitrary values
 for memory, number of nics, etc.

 It's a stretch of an example, I agree, but the general principle I think
 is sound:  we should push as much work as possible to the least
 privileged part of the stack.  In this case, firmware has much less
 privileges than QEMU.

Firmware runs in a primitive, unforgiving environment, and should do as
little as humanly possible.  For an instructive example of deviating
from that rule, check out UEFI.

[...]

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [RFC] introduce a general query-config cmd

[Markus Armbruster]

Amos Kong ak...@redhat.com writes:

[...]
 But info command of hmp doesn't support parameter
   (eg: (hmp) info config boot)

It does since Wenchao Xia's recent improvements (commit 84c44613).  For
an example how to use them, check out his hmp: add function
hmp_info_snapshots() (on list, not yet committed).

[More questions, left to more competent folks...]

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] How much RAM is required?

[Markus Armbruster]

Markus Armbruster arm...@redhat.com writes:

 Kevin O'Connor ke...@koconnor.net writes:

 On Fri, Aug 10, 2012 at 04:54:06PM +0200, Markus Armbruster wrote:
 Peter Stuge pe...@stuge.se writes:
  Markus Armbruster wrote:
  Could SeaBIOS fail more cleanly when it detects insufficient RAM?
 
  What would you propose?
 
 Fail POST with panic(Not enough RAM)?

 The amount of memory is communicated from QEMU to SeaBIOS via nvram
 variables.  As far as I know, those variables can only communicate ram
 sizes in 1meg chunks - so there is no way to communicate (and/or
 detect) a ramsize of under 1 meg.

 Not true, the variables *can* communicate more.

 Here's what QEMU stores in the RTC's NVRAM (CMOS memory) on RAM:

 addr  size  meaning [unit]
 0x15 2  base memory (below 1MiB) [KiB]
 0x17 2  extended memory (between 1MiB and 64MiB) [KiB]
 0x30 2  copy of 0x17/0x18
 0x34 2  memory between 16MiB and 4GiB [64KiB]
 0x5b 3  memory above 4GiB [64KiB]

 Thus, memory sizes up to 16MiB can be declared with 1KiB granularity,
 and up to 1TiB with 64KiB granularity.

 Note that RAM 0xa..0xf is inaccessible.

 However, the values QEMU *currently* stores are buggy for RAM sizes
 under 640KiB: base memory is set to 640KiB, and extended memory
 underflows.  Code is pc_cmos_init() in hw/pc.c.  I'll try to get that
 fixed, either by storing correct values, or by enforcing a 1MiB minimum.

1MiB minimum was rejected.  Instead, QEMU 1.2 got this fix:

commit e89001f72edde37fb36fa7c964daa1bbeb2eca26
Author: Markus Armbruster arm...@redhat.com
Date:   Wed Aug 15 13:12:20 2012 +0200

pc: Fix RTC CMOS info on RAM for ram_size  1MiB

pc_cmos_init() always claims 640KiB base memory, and ram_size - 1MiB
extended memory.  The latter can underflow to lots of extended
memory.  Fix both, and clean up some.

Note: SeaBIOS currently requires 1MiB of RAM, and doesn't check
whether it got enough.

[...]

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] How much RAM is required?

[Markus Armbruster]

Kevin O'Connor ke...@koconnor.net writes:

 On Fri, Aug 10, 2012 at 04:54:06PM +0200, Markus Armbruster wrote:
 Peter Stuge pe...@stuge.se writes:
  Markus Armbruster wrote:
  Could SeaBIOS fail more cleanly when it detects insufficient RAM?
 
  What would you propose?
 
 Fail POST with panic(Not enough RAM)?

 The amount of memory is communicated from QEMU to SeaBIOS via nvram
 variables.  As far as I know, those variables can only communicate ram
 sizes in 1meg chunks - so there is no way to communicate (and/or
 detect) a ramsize of under 1 meg.

Not true, the variables *can* communicate more.

Here's what QEMU stores in the RTC's NVRAM (CMOS memory) on RAM:

addr  size  meaning [unit]
0x15 2  base memory (below 1MiB) [KiB]
0x17 2  extended memory (between 1MiB and 64MiB) [KiB]
0x30 2  copy of 0x17/0x18
0x34 2  memory between 16MiB and 4GiB [64KiB]
0x5b 3  memory above 4GiB [64KiB]

Thus, memory sizes up to 16MiB can be declared with 1KiB granularity,
and up to 1TiB with 64KiB granularity.

Note that RAM 0xa..0xf is inaccessible.

However, the values QEMU *currently* stores are buggy for RAM sizes
under 640KiB: base memory is set to 640KiB, and extended memory
underflows.  Code is pc_cmos_init() in hw/pc.c.  I'll try to get that
fixed, either by storing correct values, or by enforcing a 1MiB minimum.

Here's how SeaBIOS uses this information, in ram_probe():

1. read memory above 16MiB from 0x34/0x35.

2. if non-zero, add 16MiB,
   else read memory between 1MiB and 64MiB from 0x30/0x31, add 1MiB

3. read memory above 4GiB

SeaBIOS doesn't read 0x15/0x16 at all.  However, this SeaBIOS
shortcoming is currently masked by the QEMU bug.

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] How much RAM is required?

[Markus Armbruster]

Peter Stuge pe...@stuge.se writes:

 Markus Armbruster wrote:
  SeaBIOS requires a minimum of 1Meg of ram.  I didn't even know one
  could request less than 1meg of ram from QEMU.
 
  I'll cook up a QEMU patch to give it at least that much.
 
  But QEMU may use other firmware/payload than SeaBIOS which might
  require less than 1 MB of RAM.
 
 Good point.

 I disagree actually. It is not an invalid point, but please optimize
 for the common case and let's deal with microscopic corner cases if
 they actually happen.


 Could SeaBIOS fail more cleanly when it detects insufficient RAM?

 What would you propose?

Fail POST with panic(Not enough RAM)?

Perfect score if can limit ourselves to just ROM, registers, and
possibly CPU cache, but no RAM, before this check.  It's been done
elsewhere, but it may not be practical for us.

If we can't, we merely reduce the need this much RAM to avoid silent
failure limit to something pretty much any conceivable firmware will
require.  QEMU might be more willing to enforce such a low limit.
Making it enforce 1MiB will be a hard sell, I'm afraid...

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] How much RAM is required?

[Markus Armbruster]

Fred . eldman...@gmail.com writes:

 On Fri, Aug 10, 2012 at 5:28 PM, Markus Armbruster arm...@redhat.com wrote:
 Frediano Ziglio frediano.zig...@citrix.com writes:

 On Fri, 2012-08-10 at 16:24 +0200, Peter Stuge wrote:
 Fred . wrote:
  No, I am not.

 Ok, so there's only a hypothesis.


  But I believe QEMU does have the functionality to load an arbitrary
  firmware. So the firmware doesn't necessarily have to be SeaBIOS.

 As you may know the 8086 reset vector is at 1MB-16 so it will be
 really difficult to run a PC-like machine with less than 1MB of
 memory. I don't believe one has ever existed.


 I remember that my manual of the NEC V20 (a 8086 clone with 10 MHZ!) has
 settings for 256KB of RAM (jumpers of course!)

 The ROM was mapped (physically!) at f with extended ROM at e.

 According to Wikipedia, the original IBM PC was sold with as little as
 16KiB RAM.  IIRC, 64KiB BIOS ROM at the top of the 1MiB address space.

 http://en.wikipedia.org/wiki/IBM_PC

 [...]

 Some machines also have broken memory modules.
 So some computers have 0 byte RAM in that case. :D

Yup, be we *can* catch that in QEMU :)

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] How much RAM is required?

[Markus Armbruster]

Watch this:

$ qemu-system-x86_64 -nodefaults -vnc :0 -monitor stdio -m 16k
QEMU 1.1.50 monitor - type 'help' for more information
(qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 
0x4000

Admittedly a silly thing to try.  I don't really expect SeaBIOS to work
with 16KiB of RAM.  But I'm curious: how much does it require?

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios