Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
vgasrc/geodevga.c | 64 ++-
1 file changed, 35 insertions(+), 29 deletions(-)
diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index e96698c..50216b6 100644
---
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
vgasrc/geodevga.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index c2dabf5..ef840a4 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
@@ -140,7 +140,7 @@ static
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
vgasrc/geodevga.c | 2 +-
vgasrc/geodevga.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index 42e2eeb..e508cbd 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
vgasrc/geodevga.c | 2 +-
vgasrc/geodevga.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index 42e2eeb..e508cbd 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
vgasrc/geodevga.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index 50216b6..42e2eeb 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
@@ -33,6 +33,9 @@ static u64
On Thu, 2013-02-14 at 11:27 +, Ian Campbell wrote:
I've attached an hvmloader which I just built from the 4.2 stable branch
and have smoke tested, does it work for you?
FFS. Is it too early to start drinking yet? A 256KiB ROM image fails as
I have described, while a 128KiB image works fine.
On Thu, 2013-02-14 at 12:29 +, David Woodhouse wrote:
On Thu, 2013-02-14 at 11:27 +, Ian Campbell wrote:
I've attached an hvmloader which I just built from the 4.2 stable branch
and have smoke tested, does it work for you?
FFS. Is it too early to start drinking yet? A 256KiB ROM
On Thu, 2013-02-14 at 12:53 +, Ian Campbell wrote:
I had observed once upon a time that turning up the limit caused odd
failures, but I'd never associated it with the size. I spent ages
trying
to track down a NULL pointer in some level3 message and the like...
In hvmloader I see:
I oppose the name runningOnXen() !
I propose the name running_on_Xen()
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
I'll probably have a look at OVMF under Xen now, and making sure that my
CSM code works there. Then you shouldn't need to offer people the choice
between OVMF and SeaBIOS because you'll have one image that handles
everything (which is
On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
On Thu, 2013-02-14 at 12:53 +, Ian Campbell wrote:
I had observed once upon a time that turning up the limit caused odd
failures, but I'd never associated it with the size. I spent ages
trying
to track down a NULL pointer in
On Thu, 2013-02-14 at 13:52 +, David Woodhouse wrote:
On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
I'll probably have a look at OVMF under Xen now, and making sure that my
CSM code works there. Then you shouldn't need to offer people the choice
between OVMF and SeaBIOS
On Thu, 2013-02-14 at 14:08 +, Ian Campbell wrote:
The chap who did our OVMF stuff has moved on to pastures new but ISTR
him saying something about a build bug with GCC!=44, which had been
fixed in upstream OVMF but not yet sync'd into the Xen tree.
Yes, OVMF's toolchain handling is
On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
Anyway, I appear to have established that the qemu fw_cfg *doesn't*
exist in your domains — so how you pass bootorder to the guest, if you
successfully do so at all, I have no idea.
Asking around no one seems to have any idea how
On Thu, 2013-02-14 at 14:23 +, David Woodhouse wrote:
On Thu, 2013-02-14 at 14:08 +, Ian Campbell wrote:
The chap who did our OVMF stuff has moved on to pastures new but ISTR
him saying something about a build bug with GCC!=44, which had been
fixed in upstream OVMF but not yet
On Thu, 2013-02-14 at 16:41 +, Ian Campbell wrote:
On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
Anyway, I appear to have established that the qemu fw_cfg *doesn't*
exist in your domains — so how you pass bootorder to the guest, if
you
successfully do so at all, I have
On Thu, 2013-02-14 at 16:47 +, David Woodhouse wrote:
On Thu, 2013-02-14 at 16:41 +, Ian Campbell wrote:
On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
Anyway, I appear to have established that the qemu fw_cfg *doesn't*
exist in your domains — so how you pass
On Thu, 2013-02-14 at 16:46 +, Ian Campbell wrote:
On Thu, 2013-02-14 at 14:23 +, David Woodhouse wrote:
git.infradead.org/users/dwmw2/seabios.git
There's a README.CSM file in the SeaBIOS tree which describes how to
build OVMF with CSM support.
Do I understand correctly from
Fred . wrote:
I propose the name running_on_Xen()
The proper way to do that is to send a perfect patch, created using
git, with your commit on top of current seabios.git code.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
On Thu, 2013-02-14 at 17:11 +, Ian Campbell wrote:
On Thu, 2013-02-14 at 16:47 +, David Woodhouse wrote:
On Thu, 2013-02-14 at 16:41 +, Ian Campbell wrote:
On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
Anyway, I appear to have established that the qemu fw_cfg
On Thu, 2013-02-14 at 18:10 +, Ian Campbell wrote:
I tested:
HEAD is now at e62d172 Make Xen one of the top-level build target choices
with the attached config and I'm afraid it booted from the cdrom no
matter what I did in my config file.
I enabled CONFIG_QEMU_HARDWARE
Hi,
I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
reset requested by the guest doesn't work as expected. The behavior is
an infinite loop, with the following debug fragment repeated by the
CSM-ized SeaBIOS:
In resume (status=0)
In 32bit resume
Attempting a hard
On Thu, 2013-02-14 at 18:10 +, Ian Campbell wrote:
I tested:
HEAD is now at e62d172 Make Xen one of the top-level build target choices
with the attached config and I'm afraid it booted from the cdrom no
matter what I did in my config file.
The patch I sent earlier seems to have fixed
On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
Can we dumb down ^W^W generalize this code? :) Or maybe should qemu
introduce a reset handler for PAMs?
In the UEFI+CSM model, I believe the handling of PAM stuff is left
*entirely* to the UEFI side and the CSM is supposed to be
On Thu, 2013-02-14 at 12:54 -0800, H. Peter Anvin wrote:
This would be a bug, but it isn't quite true.
If you look at x86_cpu_reset() you will note that it sets the code
segment base to 0x, not 0xf as one could expect from the
above. This is also true of a physical x86.
As
On 02/14/13 21:54, H. Peter Anvin wrote:
On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
the exact address of... reset_vector() in SeaBIOS.
This would be a bug, but it isn't quite true.
If you look at x86_cpu_reset()
On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
the exact address of... reset_vector() in SeaBIOS.
This would be a bug, but it isn't quite true.
If you look at x86_cpu_reset() you will note that it sets the code
segment
On Thu, 2013-02-14 at 22:14 +0100, Laszlo Ersek wrote:
On 02/14/13 21:54, H. Peter Anvin wrote:
On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
the exact address of... reset_vector() in SeaBIOS.
This would be a
On 02/14/13 21:55, David Woodhouse wrote:
So, if real hardware would reset the PAMs on reset and avoid the need
for SeaBIOS to do so, I think we should be doing the same in qemu too.
That's what I couldn't figure out from the i440FX spec, but I believe
one could argue that reset should in fact
On 02/14/2013 01:27 PM, David Woodhouse wrote:
So it *is* jumping to 0xfff0 but the memory at that location isn't
what we expect? Do the PAM registers affect *that* too, or only the
region from 0xc-0xf? Surely the contents at 4GiB-δ should be
unchanged by *anything* we do with the
On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
reset requested by the guest doesn't work as expected. The behavior is
an infinite loop, with the following debug fragment repeated by the
CSM-ized SeaBIOS:
In
On 02/14/13 22:27, David Woodhouse wrote:
On Thu, 2013-02-14 at 22:14 +0100, Laszlo Ersek wrote:
On 02/14/13 21:54, H. Peter Anvin wrote:
On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
the exact address of... reset_vector()
On 02/14/13 21:55, David Woodhouse wrote:
Thanks for testing this, btw. Are you looking at suspend/resume too? :)
Entering S3 seemed OK (except the screen was not cleared; using Cirrus).
I woke up the guest with
# virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \
--hmp
On Fri, 2013-02-15 at 00:01 +0100, Laszlo Ersek wrote:
Entering S3 seemed OK (except the screen was not cleared; using
Cirrus).
I woke up the guest with
# virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \
--hmp --cmd system_wakeup
Trailing portion of the log:
On Feb 14, 2013, at 2:09 PM, H. Peter Anvin h...@zytor.com wrote:
On 02/14/2013 01:27 PM, David Woodhouse wrote:
So it *is* jumping to 0xfff0 but the memory at that location isn't
what we expect? Do the PAM registers affect *that* too, or only the
region from 0xc-0xf? Surely
在 2013-02-06三的 23:15 -0500，Kevin O'Connor写道：
On Mon, Feb 04, 2013 at 10:27:59AM +0800, liguang wrote:
Signed-off-by: liguang lig.f...@cn.fujitsu.com
Thanks. Some comments.
[...]
--- a/src/acpi.h
+++ b/src/acpi.h
[...]
+#include acpi-dsdt.hex
Moving the acpi structure defines to
Sorry for late reply
在 2013-02-06三的 23:18 -0500，Kevin O'Connor写道：
On Mon, Feb 04, 2013 at 10:28:00AM +0800, liguang wrote:
the old numa format got form fw_cfg is:
number of nodes
node id of cpu (array)
node memory size (array)
now, format it like array of:
apci_map,
memory_size,
On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote:
On 02/14/13 21:55, David Woodhouse wrote:
Thanks for testing this, btw. Are you looking at suspend/resume too? :)
Entering S3 seemed OK (except the screen was
On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote:
On 02/14/13 21:55, David Woodhouse wrote:
Thanks for testing this, btw. Are you looking at suspend/resume too? :)
Entering S3 seemed OK (except the screen was not cleared; using Cirrus).
I woke up the guest with
# virsh
39 matches
Mail list logo
