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 Fri, 2013-02-15 at 12:09 +, David Woodhouse wrote:
On Thu, 2013-02-14 at 16:46 +, Ian Campbell wrote:
Right, we really need to find someone with hours to finish properly
integrating OVMF.
Hm, that 'someone' may end up being me¹.
That would be awesome!
I was actually wondering
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
On 02/19/13 16:29, David Woodhouse wrote:
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.
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
+++
On Mon, Feb 18, 2013 at 02:33:23PM -0500, Kevin O'Connor wrote:
On Mon, Feb 18, 2013 at 09:17:05PM +0200, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 02:00:52PM -0500, Kevin O'Connor wrote:
Why not fix KVM so that it runs at fff0 after reset?
Because KVM uses VMX extension and VMX
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, Feb 19, 2013 at 06:35:03PM +, David Woodhouse wrote:
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 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, 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 reset code can jump into OVMF
code in 0xe-0xf
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
Il 19/02/2013 20:39, David Woodhouse ha scritto:
We'd need to fix SeaBIOS to use the 0xcf9 reset too; currently it'll sit
in an endless loop of keyboard-induced *soft* resets anyway, because it
tries that before 0xcf9.
And in fact it probably shouldn't use the hard-coded 0xcf9 reset; it
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 Tue, Feb 19, 2013 at 06:08:31PM +, David Woodhouse wrote:
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.
Looks okay to me.
David Woodhouse wrote:
is it just that all PC BIOSes are written by crack-smoking hobos
that they drag in off the street, and this is just an artefact of
the rule anything they *can* get wrong and still boot Windows,
they *will* get wrong?
I wouldn't be surprised.
//Peter
Calculate a LegacyRamSize directly from the e820 map for use by
handle_1588() and handle_15e801() (the only two external interfaces
that require RamSize). All other users of the existing RamSize (and
RamSizeOver4G) variables are specific to QEMU, so move the
declarations to paravirt.c.
Since the final location of the varlow variables are known at build
time, link the final locations into the binary during the build. The
16bit code was already done at link time - update the build so the
32bit code is also done at link time.
Signed-off-by: Kevin O'Connor ke...@koconnor.net
---
The BiosTableSpace variable was used to ensure there was sufficient
space in the f-segment for malloc_fseg() calls. However, it added 2K
to the final image size to reserve that space.
Update the build to determine where to put the f-segment allocations.
In most cases (when code relocation is
21 matches
Mail list logo
