Re: [SeaBIOS] [Qemu-devel] seabios serial console vs. sgabios
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?
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
"Michael S. Tsirkin" 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 >> >>> >> + * >> >>> >> + * 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
"Kevin O'Connor" 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] [RFC] Add SeaBIOS wiki documents to git repo
"Kevin O'Connor" writes: > On Wed, Dec 17, 2014 at 01:01:59PM +0100, Gerd Hoffmann wrote: >> Hi, >> >> > I'm not sure if doing this is a good idea. It would be nice to have >> > the documents in version control, and it would be good to allow >> > patches to simultaneously update the code and documentation. However, >> > modifying wiki syntax from an editor isn't that easy. >> >> I don't see editing wiki syntax in $editor as a problem. > > The really long lines are annoying to work with. git-send-email even > complains about lines over 998 characters long. A sufficiently powerful editor (Emacs: visual-line-mode) should make it somewhat less annoying. Alternatively, edit *only* in an editor, and avoid long lines. >> But what is the plan for the wiki then? Discontinue? Switch to >> read-only and update from git? Two-way sync between wiki+git? > > Update the wiki from git. Right now, only I have write access to the > wiki anyway (as no one has requested a wiki account). A solution > other than a wiki is also possible, but that wasn't something I was > thinking of, at least in the short term. Should two-way become desirable, a Wiki backed by git and included as a submodule could be practical. ___ 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
Paolo Bonzini 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] boot: Change ":rom%d" boot order rom instance to ":rom%x"
"Kevin O'Connor" 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 ___ 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
"Kevin O'Connor" 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 v3] boot: Fix boot order for SCSI target, lun > 9
Laszlo Ersek 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 >> --- >> 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 Thanks! ___ 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
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 --- 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 v2] boot: Fix boot order for SCSI target, lun > 9
"Kevin O'Connor" 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 v2] boot: Fix boot order for SCSI target, lun > 9
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 --- 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
[SeaBIOS] [PATCH] boot: Fix boot order for SCSI target, lun > 9
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 --- 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
"Kevin O'Connor" 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
Gerd Hoffmann 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] [Qemu-devel] [QEMU v6 PATCH 00/17] SMBIOS: build full tables in QEMU
"Kevin O'Connor" writes: > On Tue, Apr 15, 2014 at 10:29:26AM +0200, Gerd Hoffmann wrote: >> Leave the old interface code basically as-is. type0 and type1 >> individual fields are passed like they are passed today. We don't >> change to to pass full tables, and we don't extend that to new table >> types. Continue to provide these in parallel to the new interface, for >> compatibility with old firmware (and old machine types). >> >> The code to generate complete tables will only be used for >> "etc/smbios/smbios-tables". Only machine types for 2.1 + newer will >> provide them, so with older machine types seabios will continue to >> generate the smbios tables and guest wouldn't notice a difference. > > This does mean that SeaBIOS would need to continue to support > generating of smbios tables for the foreseeable future as it would > need that support whenever one wanted to run a v2.0 or earlier machine > type. It would be nice if a future version of SeaBIOS could drop the > smbios generation code. > > However, I'm okay with either direction. If we want to retire the SMBIOS tables generation from SeaBIOS entirely, we first need to stop use of the old interface in QEMU, then let enough time pass to avoid awkward upgrade dependencies. Gerd's proposal is compatible with that. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [SeaBIOS v3 PATCH] SMBIOS: Check for full tables & entry point in fw_cfg
"Gabriel L. Somlo" writes: > Check fw_cfg for the presence of a complete set of smbios > tables (etc/smbios/smbios-tables) and an entry point structure > (etc/smbios/smbios-anchor), and, if found, use them instead of > generating our own copies locally. > > We ensure the presence of a type 0 (bios information) structure > by generating one locally if necessary, which is expected to be > the common case. > > Signed-off-by: Gabriel L. Somlo > --- > > This now goes on top of Kevin's patch factoring out smbios table walking > into smbios_next(). > > On Sat, Apr 12, 2014 at 11:56:08AM -0400, Kevin O'Connor wrote: >> I'd prefer to add this code to src/fw/paravirt.c and >> src/fw/biostables.c instead of src/fw/smbios.c. That way, the >> smbios.c file is limited to the legacy smbios generation and we can >> more clearly document that the whole file is deprecated. > > OK, so most of the new code is now in biostables.c, hope that's OK. > >> QEMU currently has command-line options that can modify the fields of >> the type0 tables (-smbios type=0,vendor='foo'). To continue to >> support that, I think QEMU should be able to build the type0 table as >> it feels fit to, and SeaBIOS should be able to pass it through. Of >> course, if there's no specific request from the end user, then I think >> QEMU can tell SeaBIOS that it may replace the type0 content with its >> own data (eg, via "etc/update-smbios-type0"). > > Something like that, except (hopefully) even simpler :) > > If QEMU adds its (still optional) type 0 structure, SeaBIOS just uses > everything as-is. If no type 0 structure is found, we generate and > prepend our own, and update the entry point fields accordingly. > > I expect the latter to be the common case (having QEMU add its own > type 0 sub-table is rare, and discouraged in practice, according to > the QEMU guys). Messing with SMBIOS entries is a rather obscure feature, and messing with type 0 is perhaps more obscure than messing with type 1. QEMU provides two ways to mess with SMBIOS entries: * -smbios type=T,KEY=VAL... T can be either 0 or 1. * -smbios file=F F contains an SMBIOS struct. Its type is parsed from file F. If -smbios file=F is given, it completely defines the type T entry. Else, the type T entry is to be constructed from SeaBIOS defaults and any -smbios type=T,... given. If I read your discussion correctly, you're proposing to change "from SeaBIOS defaults" to "from QEMU defaults". Correct? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [QEMU v5 PATCH 00/18] SMBIOS: build full tables in QEMU
"Gabriel L. Somlo" writes:
> Kevin,
>
> Thanks for the comments. I'll work your feedback (and any other
> feedback I get by early next week) into another iteration of smbios
> patches for both SeaBIOS and QEMU.
>
> In the mean time, there's one remaining "big picture" design question:
>
> On Sat, Apr 12, 2014 at 11:56:08AM -0400, Kevin O'Connor wrote:
>> QEMU currently has command-line options that can modify the fields of
>> the type0 tables (-smbios type=0,vendor='foo'). To continue to
>> support that, I think QEMU should be able to build the type0 table as
>> it feels fit to, and SeaBIOS should be able to pass it through. Of
>> course, if there's no specific request from the end user, then I think
>> QEMU can tell SeaBIOS that it may replace the type0 content with its
>> own data (eg, via "etc/update-smbios-type0").
>>
>> [...]
>>
>> As a minor quibble, I think patch 18 should make type0 required
>> instead of optional (once there are the new fw_cfg entries there is no
>> harm in always producing type0). Also, it would be nice to move up
>> patch 18 to after patch 10 - that way an end-to-end test between
>> old/new smbios with the new interface could be done. I defer to
>> regular qemu developers on these comments though.
>
> There's three options I can think of:
>
> 1. QEMU always generates its own type 0 table. In this case, SeaBIOS
> can probably just use that, along with the rest of the tables, as
> provided. QEMU would have to "impersonate" or "channel" SeaBIOS when
> generating the type 0 table (or "channel" TianoCore, depending on which
> bios is being used).
Begs the question how QEMU would figure out what exactly the BIOS wants
it to put into the type 0 table. Unless somebody can come up with a
practical answer, we can ignore this option :)
> 2. QEMU only generates type 0 if explicitly told to do so on the
> command line (i.e., *not* by default). In this case, SeaBIOS (or OVMF,
> or any other BIOS) would have to scan the tables and insert its own
> default type 0 if one was not purposely supplied by QEMU. (I know my
> current SeaBIOS patch always overrides type 0, and agree that's
> inconsistent with this option, and plan on fixing it :)
>
> 3. QEMU never generates a type 0 structure (i.e. we remove that
> command line option), and the BIOS is *always* responsible for
> generating it ("allowing type 0 on the qemu command line was a bad
> idea, nobody uses it, we shouldn't have done it in the first place",
> to paraphrase from an earlier thread).
This is a simplification of 2: the BIOS doesn't have to check whether
QEMU provided type 0 information. Paid for with an incompatible change
of a somewhat obscure QEMU feature.
> I personally like #2 as it appears simple and flexible, and doesn't
> require any further coordination (beyond qemu providing an entry
> point and a set of tables).
>
> However, I'm not religious about it -- I'm only really after type 2
> and 17, for OS X's sake, as you all may remember... :)
>
> Gerd, Laszlo, what do you guys think ?
My unsolicited advice: if 2. is easy for you, go for it.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] smbios: catch zero-length strings
Gerd Hoffmann 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
Spelling correction inline.
Reviewed-by: Markus Armbruster
> ---
> 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] [Qemu-devel] [PATCH] don't expose pvpanic device in the UI
Gleb Natapov writes: > On Tue, Aug 06, 2013 at 01:03:34PM +0200, Andreas Färber wrote: >> Am 06.08.2013 12:44, schrieb Gleb Natapov: >> > On Tue, Aug 06, 2013 at 01:19:53PM +0300, Michael S. Tsirkin wrote: >> It's a QEMU issue, devices that are added with -device are >> documented in -device help and removed by dropping them from >> command line. Devices added by default have no way to >> be dropped from QOM except -nodefaults. >> >> >>> Are you saying that because pvpanic is added automatically QEMU -device >> >>> help does not print help about it? Why not fix that? What QEMU --help >> >>> issues has to do with deciding which devices should or should not be >> >>> present by default? >> >> >> >> No, I'm saying what I said: that there's no way to remove a device >> >> added by default except -nodefaults, and no way to >> >> find out what does -nodefaults exclude so you >> >> can add things you need back selectively. >> >> >> > And what are the rules that govern device exclusion from -nodefaults >> > list? Why -nodefaults does not create empty machine? >> >> We have -M none to create an empty machine. >> >> FWIW -M q35 does not create all Q35 devices, there's -readconfig >> docs/q35-chipset.cfg for the rest. The criteria certainly is not >> migratability, since ICH9 AHCI (part of -M q35) is unmigratable, >> unfortunately. >> One practical reason not to create everything via config is that we >> cannot create SysBusDevices via -device when they require MMIO mapping >> or IRQ setup. Support wiring up a machine without board code, just configuration has been the ever-distant goal of the qdev effort. >> For ISADevices such as pvpanic that's not a problem. >> Anthony has proposed QOM'ifying MemoryRegions and qemu_irq as solution >> to do the wiring-up from command line or config file, but those attempts >> got stuck a long time ago. >> > But -M creates not only things that cannot be created from a command > line, it includes some default set of devices, so what is the criteria > for those? I'm not aware of defined, coherent criteria. I can give you descriptive rather than prescriptive, though. Used to be "whatever anyone felt users would want". It's now "whatever has always been there, plus whatever survives interminable bikeshedding^W^Wvigorous debate. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH] don't expose pvpanic device in the UI
Andreas Färber writes: > Am 06.08.2013 10:36, schrieb Gleb Natapov: >> On Tue, Aug 06, 2013 at 11:33:10AM +0300, Michael S. Tsirkin wrote: >>> On Tue, Aug 06, 2013 at 10:21:52AM +0300, Gleb Natapov wrote: > If you see a mouse in a room, how likely is it that there's > a single mouse there? > > This is a PV technology which to me looks like it was > rushed through and not only set on by default, but > without a way to disable it - apparently on the assumption > there's 0 chance it can cause any damage. Now that > we do know the chance it's not there, why not go back > to the standard interface, and why not give > users a chance to enable/disable it? You should be able to disable it with: -device pvpanic,ioport=0 >>> >>> Doesn't work for me. >> Bug that should be fixed. With this command line _STA should return >> zero. >> >>> Besides, both -device pvpanic and use of ioport=0 to disable it >>> are completely undocumented. >>> >> Not the only undocumented thing in QEMU command line :) > [snip] > > I disagree: -device adds a device, not removes one. It will still be > present. > > I am neutral as to whether qemu-system-x86_64 should have it enabled by > default or not. Me too. > But if we want to suppress it, then -nodefaults should > disable it. ACK: that's how we do optional devices that are there by default. ioport=0 affecting _STA is *not* "removing" the device, it's changing how the device is exposed to the guest. No opinion on whether it's a good idea or not. > Since libvirt uses that though, it would mean libvirt would > need to add it back, whether via user's XML domain config or by libvirt > itself based on some version/etc. heuristics. Doubt that'll be a problem for libvirt. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
Anthony Liguori writes: > Gerd Hoffmann 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
Amos Kong 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 writes:
> "Kevin O'Connor" writes:
>
>> On Fri, Aug 10, 2012 at 04:54:06PM +0200, Markus Armbruster wrote:
>>> Peter Stuge 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
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] [PATCH] Makefile: delete output on error
"Michael S. Tsirkin" writes: > I had a disk full condition and a partial hex file > got generated. Following make failed trying to use it. > We can make build a bit more robust by instructing > make to remove output files on error. > > Signed-off-by: Michael S. Tsirkin > --- > Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Makefile b/Makefile > index 33b3e69..e5e2735 100644 > --- a/Makefile > +++ b/Makefile > @@ -75,6 +75,7 @@ all: $(target-y) > > # Make definitions > .PHONY : all clean distclean FORCE > +.DELETE_ON_ERROR: > > vpath %.c src vgasrc > vpath %.S src vgasrc Every Makefile should have this. Reviewed-by: Markus Armbruster ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
"Kevin O'Connor" writes:
> On Fri, Aug 10, 2012 at 04:54:06PM +0200, Markus Armbruster wrote:
>> Peter Stuge 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?
"Fred ." writes: > On Fri, Aug 10, 2012 at 5:28 PM, Markus Armbruster wrote: >> Frediano Ziglio 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
Re: [SeaBIOS] How much RAM is required?
Frediano Ziglio 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 [...] ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
Peter Stuge 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?
"Fred ." writes: > On Thu, Aug 9, 2012 at 10:15 AM, Markus Armbruster wrote: >> "Kevin O'Connor" writes: >> >>> On Wed, Aug 08, 2012 at 01:50:13PM +0200, Markus Armbruster wrote: >>>> 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 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. Could SeaBIOS fail more cleanly when it detects insufficient RAM? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
"Kevin O'Connor" writes: > On Wed, Aug 08, 2012 at 01:50:13PM +0200, Markus Armbruster wrote: >> 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 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. Thanks! ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] How much RAM is required?
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
