Sebastian Herbszt wrote:
Avi Kivity wrote:
The AP enters HALT state with IF=0. What can make it resume at the
following jmp 1b? NMI? SMI?
Yes, but also INIT.
Are you sure the AP will continue after the hlt instruction on INIT?
I think it will start to execute code from the reset vector
Avi Kivity wrote:
The AP enters HALT state with IF=0. What can make it resume at the
following jmp 1b? NMI? SMI?
Yes, but also INIT.
Are you sure the AP will continue after the hlt instruction on INIT?
I think it will start to execute code from the reset vector (0xfff0).
We might
Sebastian Herbszt wrote:
The AP enters HALT state with IF=0. What can make it resume at the
following jmp 1b? NMI? SMI?
Yes, but also INIT.
We might ignore IF=0 for hlt (which would be a bug).
I think i read something about a need for 4kb alignment for the
startup vector in the mp specs.
Yang, Sheng wrote:
Please refer to my another patch comment. Basicly, AP is running
HLT in 0x10038, but it can exit due to some reason, here QEmu
want to raise it up . But after AP exit from HLT, it can't return
to it because the code was overrided by grub and no HLT loop
there. Then AP
On Sunday 03 August 2008 03:30:41 Sebastian Herbszt wrote:
Yang, Sheng wrote:
Please refer to my another patch comment. Basicly, AP is running
HLT in 0x10038, but it can exit due to some reason, here QEmu
want to raise it up . But after AP exit from HLT, it can't return
to it because the
Yang, Sheng wrote:
Please refer to my another patch comment. Basicly, AP is running HLT
in 0x10038, but it can exit due to some reason, here QEmu want to
raise it up . But after AP exit from HLT, it can't return to it
because the code was overrided by grub and no HLT loop there. Then AP
had
Avi Kivity wrote:
IIRC the rombios32.c writes to the memory it is in, so it expects RAM,
not ROM.
kvm doesn't support ROM, so it would work. Qemu doesn't, so it would fail.
You can specify either RAM or ROM in Qemu, but you have to edit the C code.
If you need RAM in the low 640K, your
Yang, Sheng wrote:
On Thursday 31 July 2008 10:43:20 Yang, Sheng wrote:
From ba05b3c821400127074f65ee4d172fabbe3524cd Mon Sep 17 00:00:00
2001 From: Sheng Yang [EMAIL PROTECTED]
Date: Thu, 31 Jul 2008 10:39:24 +0800
Subject: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Rather than
] kvm: bios: Put AP boot up code to 0x1000
Rather than 0x1, which can be overrided by userspace program
like grub.
How about 0xex000? And avoid copying the bios to low memory?
Gleb tried it and it worked. We'd have to change qemu to mark the
memory as RAM, not ROM, but that's what real
:24 +0800
Subject: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Rather than 0x1, which can be overrided by userspace program
like grub.
How about 0xex000? And avoid copying the bios to low memory?
Gleb tried it and it worked. We'd have to change qemu to mark the
memory as RAM
Yang, Sheng wrote:
Rather than 0x1, which can be overrided by userspace program like
grub.
Could you please explain this problem?
If i don't misunderstand this smp_ap_boot_code_start from rombios32start.S
gets copied to AP_BOOT_CODE and then there is a broadcast INIT and SIPI.
After the
On Friday 01 August 2008 05:15:11 Sebastian Herbszt wrote:
Yang, Sheng wrote:
Rather than 0x1, which can be overrided by userspace program
like grub.
Could you please explain this problem?
If i don't misunderstand this smp_ap_boot_code_start from
rombios32start.S gets copied to
From ba05b3c821400127074f65ee4d172fabbe3524cd Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Thu, 31 Jul 2008 10:39:24 +0800
Subject: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Rather than 0x1, which can be overrided by userspace program like
grub.
Signed-off
13 matches
Mail list logo
