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 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
Il 18/02/2013 13:53, David Woodhouse ha scritto:
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 6c77e49..6dcf1c5 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -171,6 +171,23 @@ static int i440fx_load_old(QEMUFile* f, void *opaque,
int version_id)
return 0;
}
+static void
On Mon, 2013-02-18 at 15:46 +0100, Paolo Bonzini wrote:
If you want to submit this patch for upstream QEMU (I agree it is a
good idea), please set dc-reset instead in i440fx_class_init.
Thanks.
I just copied the way that PIIX3 does it... is that something that
piix3_class_init() should be
Il 18/02/2013 16:00, David Woodhouse ha scritto:
On Mon, 2013-02-18 at 15:46 +0100, Paolo Bonzini wrote:
If you want to submit this patch for upstream QEMU (I agree it is a
good idea), please set dc-reset instead in i440fx_class_init.
Thanks.
I just copied the way that PIIX3 does it... is
On Mon, 2013-02-18 at 16:38 +0100, Paolo Bonzini wrote:
Indeed the difference between CPUs is puzzling.
Very much so. So far I have established that it works OK here:
cpu family : 6
model : 44
model name : Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz
stepping: 2
On 02/18/13 13:53, David Woodhouse wrote:
Nevertheless, on my workstation as on yours, we do seem to end up
executing from the CSM in RAM when we reset. But on my laptop, it
executes the *ROM* as it should.
This patch 'fixes' it, and I think it might even be correct in itself,
but I don't
On 02/18/13 17:48, David Woodhouse wrote:
On Mon, 2013-02-18 at 16:38 +0100, Paolo Bonzini wrote:
Indeed the difference between CPUs is puzzling.
Very much so. So far I have established that it works OK here:
cpu family: 6
model : 44
model name: Intel(R) Core(TM) i7 CPU
On 02/18/13 18:28, Laszlo Ersek wrote:
On 02/18/13 17:48, David Woodhouse wrote:
On Mon, 2013-02-18 at 16:38 +0100, Paolo Bonzini wrote:
Indeed the difference between CPUs is puzzling.
Very much so. So far I have established that it works OK here:
cpu family : 6
model: 44
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 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 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:
14 matches
Mail list logo
