On Thu, 2023-02-02 at 10:10 +0100, Gerd Hoffmann wrote:
> > Thanks, Kevin.
> >
> > I'd like to get the rest of the Xen platform support in to qemu 8.0
> > if
> > possible. Which is currently scheduled for March.
> >
> > Is there likely to be a SeaBIOS release before then which Gerd
> > would
> >
On Wed, 2023-02-01 at 21:13 -0500, Kevin O'Connor wrote:
> On Fri, Jan 20, 2023 at 11:33:19AM +0000, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > When running under Xen, hvmloader places a table at 0x1000 with the e820
> > information and BIOS tables. If
On Mon, 2022-11-21 at 11:32 +0100, Gerd Hoffmann wrote:
> In case kvm emulates features of another hypervisor (for example hyperv)
> two VMM CPUID blocks will be present, one for the emulated hypervisor
> and one for kvm itself.
That isn't the case for emulating Xen on KVM, FWIW. Only for Hyper-V
From: David Woodhouse
When running under Xen, hvmloader places a table at 0x1000 with the e820
information and BIOS tables. If this isn't present, SeaBIOS will
currently panic.
We now have support for running Xen guests natively in QEMU/KVM, which
boots SeaBIOS directly instead of via
On Thu, 2020-11-05 at 16:09 +, David Woodhouse wrote:
> From: David Woodhouse
>
> This ended up with an odd mix of recursion (albeit *mostly*
> tail-recursion) and interation that could have been prettier. In
> addition, while recursing it potentially adjusted op->cou
From: David Woodhouse
This ended up with an odd mix of recursion (albeit *mostly*
tail-recursion) and interation that could have been prettier. In
addition, while recursing it potentially adjusted op->count which is
used by callers to see the amount of I/O actually performed.
Fix it by bring
On Wed, 2020-11-04 at 23:27 +, Graf (AWS), Alexander wrote:
> > Am 31.10.2020 um 00:49 schrieb David Woodhouse :
> >
> > From: David woodhouse
> >
> > This ended up with an odd mix of recursion (albeit *mostly* tail-recursion)
> > and interation
From: David woodhouse
This ended up with an odd mix of recursion (albeit *mostly* tail-recursion)
and interation that could have been prettier. Make it prettier by making
nvme_build_prpl() return the number of blocks it consumes, and just
looping.
If nvme_build_prpl() doesn't want to play, just
On Wed, 2020-10-07 at 12:13 -0400, Kevin O'Connor wrote:
> > > > --- a/src/hw/nvme.c
> > > > +++ b/src/hw/nvme.c
> > > > @@ -727,6 +727,22 @@ nvme_cmd_readwrite(struct nvme_namespace *ns,
> > > > struct disk_op_s *op, int write)
> > > > u16 const max_blocks = NVME_PAGE_SIZE / ns->block_size;
Explicitly handle the BBS_DO_NOT_BOOT_FROM and BBS_IGNORE_ENTRY values.
Also add one to the other priority values, as find_prio() does for
entries from bootorder. SeaBIOS uses zero for an item explicitly
selected in interactive_bootmenu().
Signed-off-by: David Woodhouse
---
v2: No code change
On Fri, 2019-06-21 at 10:40 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Our downstream patch for not initialising NVMe controllers if we aren't
> > going to boot from them, makes its decision based on the priority.
>
> What is the state of that patch btw?
It's on my "technical debt that I want to
On Thu, 2019-06-20 at 09:43 -0400, Kevin O'Connor wrote:
> On Thu, Jun 20, 2019 at 01:07:45PM +0100, David Woodhouse wrote:
> > For CSM, the highest priority for a boot entry is zero. SeaBIOS doesn't
> > use zero, and the highest priority is 1.
>
> FYI, SeaBIOS does trea
For CSM, the highest priority for a boot entry is zero. SeaBIOS doesn't
use zero, and the highest priority is 1.
Make the results of csm_bootprio_*() conform to that convention. Also
explicitly handle the BBS_DO_NOT_BOOT_FROM and BBS_IGNORE_ENTRY values.
Signed-off-by: David Woodhouse
---
v2
On Wed, 2019-06-19 at 12:27 +0100, David Woodhouse wrote:
> For CSM, the highest priority is zero. In SeaBIOS that means "don't", and
> the highest priority is 1.
>
> So we end up with the fun outcome that booting from NVMe worked only
> when it *wasn't* selected a
p() thread for an NVMe controller
if its boot prio is zero.
Signed-off-by: David Woodhouse
---
src/fw/csm.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/fw/csm.c b/src/fw/csm.c
index 3fcc252..7663d31 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -319
On Tue, 2019-06-18 at 18:48 -0400, Kevin O'Connor wrote:
> > The main project has an out-of-tree build, and currently *copies*
> > everything from the SeaBIOS submodule (except .git) into the build
> > directory and building it there. It creates a .version file with the
> > overall version number
On Thu, 2019-06-13 at 13:33 -0400, Kevin O'Connor wrote:
> Can you give some background on how this is intended to be used?
>
> We used to allow the version string to be overridden, but we found the
> results were a bit chaotic - different people chose different names
> and it was hard to
Signed-off-by: David Woodhouse
---
scripts/buildversion.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/buildversion.py b/scripts/buildversion.py
index 8875497..fc2decd 100755
--- a/scripts/buildversion.py
+++ b/scripts/buildversion.py
@@ -113,7 +113,9 @@ def
with being passed zero, which was happening for the
E820 table allocation from EDK2.
Signed-off-by: David Woodhouse
---
v2: Enforce MALLOC_MIN_ALIGN
src/fw/csm.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/fw/csm.c b/src/fw/csm.c
index 03b4bb8..3fcc
with being passed zero, which was happening for the
E820 table allocation from EDK2.
Signed-off-by: David Woodhouse
---
src/fw/csm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/fw/csm.c b/src/fw/csm.c
index 03b4bb8..bf7b8f5 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -264
On Tue, 2019-04-30 at 22:56 -0400, Kevin O'Connor wrote:
> Hi David,
>
> That call trace certainly looks odd. The SeaBIOS debugging info would
> help - try compiling SeaBIOS with debug level 8 and grab the log (as
> described at: https://www.seabios.org/Debugging#Diagnostic_information
> ).
When I kexec either Xen or Linux in real mode, from either Xen or
Linux, it fails.
The last thing I see looks like SeaBIOS trying to use SMM for call32:
IN:
0x000f70ec: mov%eax,%esi
0x000f70ef: mov$0xb5,%eax
0x000f70f5: mov$0x1234,%ecx
This is a gratuitous GCC-ism. For C code actually compiled with GCC we
should be using -m16 where it's available (GCC 4.9+).
And where the only thing marked with .code16gcc is explicit assembler
code, we should just use .code16 and avoid letting the compiler make any
of the assumptions that the
GCC 4.9 and clang 3.5 support the -m16 option on the command line which
supersedes the hackish .code16gcc assembler directive. Use it where
possible.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
There's no need to use .code16gcc where we are writing assembler code
explicitly. It only affects word-size-ambiguous instructions, and we
should just be explicit. And we are.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/romlayout.S | 14 +++---
1 file changed, 7
There's no need to use .code16gcc where we are writing assembler code
explicitly. It only affects word-size-ambiguous instructions, and we
should just be explicit. And we are.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
vgasrc/vgaentry.S | 2 +-
1 file changed, 1 insertion
There's no need to use .code16gcc where we are writing assembler code
explicitly. It only affects word-size-ambiguous instructions, and we
should just be explicit. And we are.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/fw/smm.c | 4 ++--
1 file changed, 2 insertions(+), 2
considered harmful.
Version 0.98 of the CSM spec adds the UmaAddress and UmaSize fields which
allow the CSM to specify a memory region that needs to be writeable, so
provide that information.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/fw/csm.c | 6 ++
src/std
On Wed, 2014-05-28 at 09:58 -0400, Kevin O'Connor wrote:
Is there an advantage to setting this at compile time vs only setting
these fields during runtime?
No.
Would this work instead?
u32 rommax = rom_get_max();
extern u8 final_readonly_start[];
csm_compat_table.UmaAddress =
On Wed, 2014-05-28 at 09:58 -0400, Kevin O'Connor wrote:
On Tue, May 20, 2014 at 02:22:16PM +0100, David Woodhouse wrote:
Unless CONFIG_MALLOC_UPPERMEMORY is turned off, we expect to use the
space between the top of option ROMs and the bottom of our own BIOS code
as a stack. OVMF
On Wed, 2014-05-28 at 15:36 -0400, Kevin O'Connor wrote:
On Mon, May 19, 2014 at 07:49:47PM +0100, David Woodhouse wrote:
On Mon, 2014-05-19 at 13:42 -0400, Kevin O'Connor wrote:
I don't see any reference to int 15h, ax=0xd042 as a standard. So,
maybe the author of the above text also
On Wed, 2014-05-28 at 15:36 -0400, Kevin O'Connor wrote:
On Mon, May 19, 2014 at 07:49:47PM +0100, David Woodhouse wrote:
On Mon, 2014-05-19 at 13:42 -0400, Kevin O'Connor wrote:
I don't see any reference to int 15h, ax=0xd042 as a standard. So,
maybe the author of the above text also
On Tue, 2014-05-20 at 14:22 +0100, David Woodhouse wrote:
However, this doesn't work if I have both CONFIG_MALLOC_UPPERMEMORY
*and* CONFIG_EXTRA_STACK enabled.
Hm, this appears to be because rom_get_max() is returning 0xef000,
causing us to ask UEFI to leave only the range 0xef000-0xf
the
symptoms and the fact that it doesn't fail when KVM is enabled.
I'll run it in qemu with insane levels of tracing, and see if I can work
out precisely where it goes wrong.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
it
actually issued a Legacy16Boot request. Prior to that, the entire
0xc-0x10 region was remaining locked.
I'll fix my EDK2 patch accordingly.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From d478ac82045a27f82f44ea9ce65f642197fe6078 Mon Sep 17 00:00:00 2001
From: David Woodhouse david.woodho...@intel.com
Date: Fri, 25 Jan 2013 19:39:07 -0600
Subject: [PATCH] Update EFI_COMPATIBILITY16_TABLE to match 0.98 spec update
Unless CONFIG_MALLOC_UPPERMEMORY is turned off, we expect to use
On Fri, 2013-11-29 at 12:44 -0500, Kevin O'Connor wrote:
Do you need debug output from 16bit mode or 32bit segmented mode? The
post and boot phases are all 32bit code so typical boot time debugging
shouldn't be impacted. Gerd's cbmem debugging code uses this
approach.
I don't need
On Mon, 2014-05-19 at 11:20 -0400, Kevin O'Connor wrote:
On Mon, May 19, 2014 at 02:27:38PM +0100, David Woodhouse wrote:
On Fri, 2013-11-29 at 12:44 -0500, Kevin O'Connor wrote:
Do you need debug output from 16bit mode or 32bit segmented mode? The
post and boot phases are all 32bit
On Fri, 2014-01-10 at 12:49 -0500, Kevin O'Connor wrote:
On Fri, Dec 06, 2013 at 11:56:22AM +, David Woodhouse wrote:
We expect to use the space between the top of option ROMs and the bottom
of our own BIOS code as a stack. OVMF was previously marking the whole
region from 0xC
On Mon, 2014-05-19 at 13:42 -0400, Kevin O'Connor wrote:
I don't see any reference to int 15h, ax=0xd042 as a standard. So,
maybe the author of the above text also wrote their own EFI module
which used that magic value?
Well, the INT 15h call would still be on the BIOS side; that doesn't
On Wed, 2014-04-16 at 12:37 -0400, Kevin O'Connor wrote:
On Mon, Apr 14, 2014 at 02:22:51PM +0200, Gerd Hoffmann wrote:
So you can try this:
qemu -vga std
-bios /usr/share/coreboot.git/coreboot-i440fx-seabios.rom
to see it live in action.
Two problems spotted so far:
(1)
On Fri, 2014-01-10 at 12:49 -0500, Kevin O'Connor wrote:
On Fri, Dec 06, 2013 at 11:56:22AM +, David Woodhouse wrote:
We expect to use the space between the top of option ROMs and the bottom
of our own BIOS code as a stack. OVMF was previously marking the whole
region from 0xC
On Thu, 2014-04-24 at 22:02 -0400, Kevin O'Connor wrote:
I've been considering a possible architectural change to SeaBIOS.
Currently, SeaBIOS contains a mix of 16bit code and 32bit code. All
of the initialization and bootup code is done in regular 32bit mode,
but runtime code (the callbacks
On Tue, 2014-05-13 at 12:45 -0400, Kevin O'Connor wrote:
That is interesting. Do you have a link to code or a spec handy? (I
looked through the Compatibility Support Module Specification again
and I see it talks about SMMs, but it seems to say that what is
implemented is IBV specific.)
with until the final
Legacy16Boot call. There's a LowPmmMemory given to use by UEFI to play
with, but that's right in the *middle* of low memory and using that for
persistent allocations would be painful. So just require
CONFIG_MALLOC_UPPERMEMORY when building a CSM.
Signed-off-by: David Woodhouse
This will make it easier to abstract out the MMIO serial access. Even if
that ends up in separate code which is a *copy* of this, at least they'll
match.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/hw/serialio.c | 19 +++
1 file changed, 11 insertions(+), 8
This includes generic support for MMIO serial which can be used for
other PCI (or non-PCI) serial ports too.
Only outputs to the serial port in 32-bit mode, unless we're lucky
enough that it's at an address below 1MiB.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/Kconfig
For a PCI serial port, we have to discover its location. Potentially on
every entry, since UEFI may shift it at some point during the boot process
from an early debug setup to a final location after real PCI enumeration.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/fw/csm.c
Why does it keep forgetting my config and reverting to defaults, every
time I touch src/Kconfig?
[dwmw2@shinybook seabios]$ make oldconfig
scripts/kconfig/conf --oldconfig /home/dwmw2/git/seabios/src/Kconfig
#
# configuration written to /home/dwmw2/git/seabios/.config
#
[dwmw2@shinybook
Just debugged the following:
ehci_setup() happens. Starts a thread to probe its ports...
ohci_setup() happens. Starts a thread to probe its ports...
OHCI probes port zero, decides there's nothing there.
EHCI probes port zero, decides there's a USB1 device there and gives it
away to OHCI...
On Thu, 2013-12-05 at 16:11 +0100, Gerd Hoffmann wrote:
I think not running configure_ehci() as thread should work too and is
a bit less agressive than wait_threads(). Waits only for the ehci
port probe threads finish (see usb_enumerate() func), not all threads.
Yeah. Is EHCI always
On Thu, 2013-12-05 at 11:59 -0500, Kevin O'Connor wrote:
I reviewed the code and booted my e350m1 board with an OHCI keyboard
and I can't reproduce your issue. Can you post the logs (with debug
level 8) of the failure you are seeing?
With some debugging of my own added. Note that
On Thu, 2013-12-05 at 21:26 +, David Woodhouse wrote:
I think this is because the EHCI device has a lower PCI function
(0:14.3) than its corresponding OHCI device (0:14.4)?
It is indeed. And reading the EHCI spec, I see that the companion
controllers *must* have a lower function number
On Thu, 2013-12-05 at 18:59 -0500, Kevin O'Connor wrote:
It occurred to me that we could actually simplify the code by
initializing all the ehci controllers and then init all the ohci/uhci
controllers. The current complex interactions between the PCI walking
and EHCI setup is really hard to
the UmaAddress and UmaSize fields, which
allow the CSM to specify a memory region that needs to be writable.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
The corresponding patch hasn't hit the OVMF/EDKII tree yet, but that
shouldn't stop us from applying it anyway. CSM support
This provides basic debug output on the Quark system, assuming that
*something* (i.e. coreboot or UEFI) has set it up in advance for us.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
I looked briefly at making this part of the CONFIG_DEBUG_SERIAL code,
and making that generic
On Fri, 2013-11-29 at 11:40 -0500, Kevin O'Connor wrote:
On Fri, Nov 29, 2013 at 02:02:02PM +, David Woodhouse wrote:
This provides basic debug output on the Quark system, assuming that
*something* (i.e. coreboot or UEFI) has set it up in advance for us.
Signed-off-by: David
On Fri, 2013-11-29 at 12:44 -0500, Kevin O'Connor wrote:
That should be okay, but would it ever actually be mapped below 1Meg?
Where would it be mapped to: 0xa-0xc?
Somewhere down there. Or 0xc even. There's no video here.
BTW, how does this Quark support compare with the PCI
On Mon, 2013-06-10 at 19:11 -0500, Anthony Liguori wrote:
If we did this right in QEMU, we'd have to introduce a QOM property
anyway
... and then we'd have to update each firmware implementation to know
about this new property, and the how it translates to the RESET_REG
field in the DSDT, etc.
On Mon, 2013-06-10 at 18:34 -0500, Anthony Liguori wrote:
Internally within QEMU, this initial discussion started by saying that
any ACPI generation within QEMU should happen strictly with QOM
methods. This was the crux of my argument, if QOM is the only
interface we need, everything is there
On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org
wrote:
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
Where is CorebootPkg available from?
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
On Wed, 2013-05-29 at 21:12 -0400, Kevin O'Connor wrote:
I remain doubtful that QOM has all the info needed to generate the
BIOS tables. Does QOM describe how the 5th pci device uses global
interrupt 11 when using global interrupts, legacy interrupt 5 when not
using global interrupts, and
On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
Certainly an option, but that is a long-term project.
Out of curiousity, are there other benefits to using coreboot as a core
firmware in QEMU?
Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
I like the
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
Where is CorebootPkg available from?
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
And it helps to dispel the stupid misconception in some quarters that
Coreboot *competes* with UEFI and thus cannot possibly be supported
because
On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote:
It depends. For ARM we insist that the user provides the
device tree that corresponds to the kernel they're going to
run, and then we just tweak it a bit.
Um... device trees describe hardware, and should not be at all
kernel-specific.
:
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
On Thu, 2013-03-21 at 13:49 +0100, Gerd Hoffmann wrote:
How about we don't bother to determine this at runtime at all?
Because it will be a PITA for testers + developers to figure the correct
.config switches of the day during the transition phase?
Why is it a PITA? Are you
On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
- for an earlier qemu, the option must be set,
- for a later qemu the option must be clear
(no -acpitable switch must be specified on the qemu cmldine ||
one -acpitable switch must load a MADT)
Hm, that sounds like it won't be
On Thu, 2013-03-21 at 15:12 +0200, Michael S. Tsirkin wrote:
On Thu, Mar 21, 2013 at 01:04:35PM +, David Woodhouse wrote:
On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
- for an earlier qemu, the option must be set,
- for a later qemu the option must be clear
be published at all.
I'd make it all-or-nothing. Except for a few historical qemu commits if
you're bisecting, why would qemu ever provide a *partial* set of tables?
--
Sent with MeeGo's ActiveSync support.
David WoodhouseOpen Source Technology Centre
On Fri, 2013-03-08 at 08:47 +0100, Paolo Bonzini wrote:
Wasn't that a fix for the SeaBIOS VGA BIOS? The one in qemu.git is
still built from the Bochs VGA BIOS.
No, it was for Bochs VGA BIOS.
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html
--
dwmw2
smime.p7s
Description:
On Mon, 2013-02-25 at 15:46 +0100, Gerd Hoffmann wrote:
2. Having (many!) hypervisor-specific special cases in SeaBIOS seems
wildly schizophrenic without bringing any significant benefits,
compared to factoring all of that out into a codebase which *already
does many of the needed
On Mon, 2013-02-25 at 15:46 +0100, Gerd Hoffmann wrote:
I'm not convinced using coreboot is a clear win, especially with EFI
coming. Can coreboot run tianocore as payload?
It's being worked on.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
On Sat, 2013-02-23 at 10:00 -0500, Kevin O'Connor wrote:
Patch 2 and 3 look okay to me - if there are no further comments I'll
push them.
I think we're fairly happy with them. Laszlo put together the OVMF side
(creating ACPI 2.0 tables instead of 1.0 and filling in the RESET_REG)
and I've
On Sat, 2013-02-23 at 11:38 -0500, Kevin O'Connor wrote:
On Sat, Feb 23, 2013 at 04:28:06PM +, David Woodhouse wrote:
On Sat, 2013-02-23 at 10:00 -0500, Kevin O'Connor wrote:
Patch 2 and 3 look okay to me - if there are no further comments I'll
push them.
I think we're fairly
On Fri, 2013-02-22 at 04:23 +0100, Laszlo Ersek wrote:
Patches 1 to 6 upgrade the FADT to ACPI 2.0 and present the PIIX3
Reset Control Register in it.
Hm. I can still trigger the soft reset loop in SeaBIOS, but perhaps not
in a circumstance that we care about...
I've fixed Qemu to do the
From: David Woodhouse david.woodho...@intel.com
I'm about to make it do more than just the pmtimer...
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/acpi.c | 10 --
src/acpi.h | 2 +-
src/coreboot.c | 4 ++--
src/csm.c | 4 ++--
src/xen.c | 4
From: David Woodhouse david.woodho...@intel.com
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/byteorder.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/byteorder.h b/src/byteorder.h
index 5a8a64a..7362aeb 100644
--- a/src/byteorder.h
+++ b/src
From: David Woodhouse david.woodho...@intel.com
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/acpi.c | 58 +++---
src/acpi.h | 14 ++
src/resume.c | 3 +++
3 files changed, 64 insertions(+), 11 deletions
From: David Woodhouse david.woodho...@intel.com
The so-called PCI reboot at 0xCF9 is supposed to be a hard reset, while
the keyboard controller is only a soft reset. So try pci_reboot() first.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
src/resume.c | 6 +++---
1 file changed
On Tue, 2013-02-19 at 20:09 -0500, Kevin O'Connor wrote:
Looks okay to me. I'd like to see the follow up patches that make use
of it before committing though.
Sent. With Qemu fixed to actually *do* a hard reset, and OVMF fixed to
pass in ACPI 2.0 tables with a RESET_REG filled in (thanks,
On Wed, 2013-02-20 at 16:34 +0100, Paolo Bonzini wrote:
Il 20/02/2013 16:18, Laszlo Ersek ha scritto:
I'm beginning to wish I'd just ignored the fact that
we need a properly working soft reset to get back from 286 protected
mode to real mode, and wired up the damn PAM reset
On Tue, 2013-02-19 at 01:38 -0500, Kevin O'Connor wrote:
This reduces some duplicate code between malloc_preinit() and
csm_malloc_preinit().
Signed-off-by: Kevin O'Connor ke...@koconnor.net
Nice. I was planning to reduce that duplication, and this seems ideal.
Thanks.
--
dwmw2
smime.p7s
On Mon, 2013-02-18 at 10:34 -0500, Kevin O'Connor wrote:
Some old DOS programs can also use f-segment space as Upper Memory
Blocks (UMB), so also report on what space is available in debug
messages.
Should we mark it as available in E820 too?
--
dwmw2
smime.p7s
Description: S/MIME
On Mon, 2013-02-18 at 23:08 +, David Woodhouse wrote:
Laszlo has hooked up the RCR on the PIIX3 already, so something like
this ought to make it reset the PAM setup *only* if reset via that...
+static void i440fx_reset(DeviceState *ds)
+{
+PCIDevice *dev = DO_UPCAST(PCIDevice, qdev
On Tue, 2013-02-19 at 10:20 +, Ian Campbell wrote:
I expect there will be some rough edges like the NV variable thing -- I
have a feeling these will have a lot in common with qemu/KVM, since they
would tend to interact with the platform (provided by qemu-dm under
Xen) rather than processor
On Mon, 2013-02-18 at 17:37 -0500, Kevin O'Connor wrote:
The ACPI v2 spec describes a hard reset register. SeaBIOS could
extract it from the FADT and then use it. Of course, we'd probably
want to update the QEMU ACPI tables to implement ACPI v2 then.
This sounded great until I actually came
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
Nothing actually sets it yet. We'll do that from the ACPI table parser
for CSM and Xen, and we can put it in our own tables for the native
case.
diff --git a/src/acpi.c b/src/acpi.c
index f7a2e55..97ade3f 100644
--- a/src/acpi.c
+++ b
On Tue, 2013-02-19 at 20:13 +0200, Gleb Natapov wrote:
I take it you mean copy 0xfffe to 0xe? That would not be
fun.
SeaBIOS would need to detect that it's in the state (it's definitely
not correct to do that on real-hardware or on working kvm
instances), then setup a
On Tue, 2013-02-19 at 20:41 +0200, Gleb Natapov wrote:
Ah, yes of course. So does CSM takes the whole 0xe-0xf segment or
it leaves OVMF code there somewhere. CSM reset code can jump into OVMF
code in 0xe-0xf range and let it do the copy.
There is no OVMF code there; OVMF
On Tue, 2013-02-19 at 21:01 +0200, Gleb Natapov wrote:
On Tue, Feb 19, 2013 at 06:48:41PM +, David Woodhouse wrote:
On Tue, 2013-02-19 at 20:41 +0200, Gleb Natapov wrote:
Ah, yes of course. So does CSM takes the whole 0xe-0xf segment or
it leaves OVMF code there somewhere. CSM
On Tue, 2013-02-19 at 21:49 +0100, Paolo Bonzini wrote:
And in fact it probably shouldn't use the hard-coded 0xcf9 reset; it
should use the one indicated by the ACPI RESET_REG field (which *is*
0xcf9... or should be).
We should implement this: http://mjg59.dreamwidth.org/3561.html
On Sat, 2013-02-16 at 02:37 +0100, Laszlo Ersek wrote:
I give up. Thanks for the help sorry about spamming three lists.
I've managed to reproduce this on a clean F18 system. This is the stock
qemu 1.2.2-6.fc18 on kernel 3.7.6-201.fc18.x86_64 with a newly-installed
Fedora 18 VM in the guest.
On Mon, 2013-02-18 at 10:40 +, David Woodhouse wrote:
On Sat, 2013-02-16 at 02:37 +0100, Laszlo Ersek wrote:
I give up. Thanks for the help sorry about spamming three lists.
I've managed to reproduce this on a clean F18 system. This is the stock
qemu 1.2.2-6.fc18 on kernel 3.7.6-201
be doing for *its* reset function too?
I'll submit this for upstream, but I consider it a workaround for the
real bug that Laszlo has been suffering from. So I'd rather wait until
we've solved that properly, or at least until we understand why we get
such different results on different CPUs.
--
David
On Mon, 2013-02-18 at 19:16 +0100, Laszlo Ersek wrote:
On 02/18/13 18:45, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
CS =f000 000f f300
^^^^
|base limitflags
selector
This is
On Mon, 2013-02-18 at 14:00 -0500, Kevin O'Connor wrote:
On Mon, Feb 18, 2013 at 08:31:01PM +0200, Gleb Natapov wrote:
Laszlo explained to me that the problem is that after reset we end up
in SeaBIOS reset code instead of OVMF one. This is because kvm starts
to execute from 0 instead of
On Mon, 2013-02-18 at 14:11 -0500, Kevin O'Connor wrote:
On Mon, Feb 18, 2013 at 07:04:08PM +, David Woodhouse wrote:
Well, what SeaBIOS already *does* is bash on the keyboard controller to
cause a reset. Which *ought* to work too; I have a patch to at least fix
*that*, by resetting
On Mon, 2013-02-18 at 21:27 +0100, Laszlo Ersek wrote:
could someone please review this one-liner?
Kevin already merged it.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
On Mon, 2013-02-18 at 17:37 -0500, Kevin O'Connor wrote:
On Mon, Feb 18, 2013 at 09:12:46PM +, David Woodhouse wrote:
The i440fx data sheet (ยง3.0) appears to say that the default values are
loaded on a *hard* reset, not a soft reset. And a reset invoked by the
keyboard controller
1 - 100 of 172 matches
Mail list logo
