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
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 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, Feb 18, 2013 at 07:16:25PM +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, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
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
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 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/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 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 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
15 matches
Mail list logo