On Mon, Nov 30, 2009 at 08:54:42PM +0200, Avi Kivity wrote:
> Strange - qemu -kernel has zero interaction with the host kernel. It's
> a totally normal boot process.
Well, it's entirely reproducable. Any idea how to make progress on
this? It really keeps me from making progress on doing any qe
On 11/30/2009 08:50 PM, Christoph Hellwig wrote:
Sounds like your guest kernel is trying to access an x86_64 register?
You can of cause try insmod'ing kvm.ko with ignore_msrs=1. You hopefully
don't need syscalls until you get into user space.
The option doesn't exist yet in 2.6.31 which
On Thu, Nov 26, 2009 at 01:24:22PM +0100, Alexander Graf wrote:
> Hm - maybe worth a try to give it a -L to the source pc-bios directory
> anyways.
Doesn't change a thing.
> Sounds like your guest kernel is trying to access an x86_64 register?
>
> You can of cause try insmod'ing kvm.ko with igno
Christoph Hellwig wrote:
> On Thu, Nov 26, 2009 at 01:00:25PM +0100, Alexander Graf wrote:
>
>> Hm - are you using -L pc-bios?
>>
>
> No. I use an installed qemu (./configure --prefix=/opt/qemu) and
> there's no pc-bios directorie in my kernel source tree where I start it
> from.
>
Hm
On Thu, Nov 26, 2009 at 01:00:25PM +0100, Alexander Graf wrote:
> Hm - are you using -L pc-bios?
No. I use an installed qemu (./configure --prefix=/opt/qemu) and
there's no pc-bios directorie in my kernel source tree where I start it
from.
> Also, maybe there's something in dmesg
> telling you a
Christoph Hellwig wrote:
> On Wed, Nov 25, 2009 at 10:58:45AM +0100, Alexander Graf wrote:
>
>> Ok I just tried to reproduce this using my netbook (32 bits only) and
>> your kernel:
>>
>
> Still seeing it using latests qemu.git. Any idea about other information that
> might help sorting it
On Wed, Nov 25, 2009 at 10:58:45AM +0100, Alexander Graf wrote:
> Ok I just tried to reproduce this using my netbook (32 bits only) and
> your kernel:
Still seeing it using latests qemu.git. Any idea about other information that
might help sorting it out?
I'm running Linux 2.6.31 on the host, bt
Christoph Hellwig wrote:
> On Mon, Nov 23, 2009 at 10:28:44PM +0100, Alexander Graf wrote:
>
>>> Is this on an x86_64 box or i386? I can boot the same kernel with
>>> upstream qemu on another box with an x86_64 kernel and qemu.
>>>
>> I only test things on x86_64. so you're saying it bre
On Mon, Nov 23, 2009 at 10:28:44PM +0100, Alexander Graf wrote:
> >Is this on an x86_64 box or i386? I can boot the same kernel with
> >upstream qemu on another box with an x86_64 kernel and qemu.
>
> I only test things on x86_64. so you're saying it breaks on an i586
> host?
Yes, both guest a
Am 23.11.2009 um 21:21 schrieb Christoph Hellwig :
On Fri, Nov 20, 2009 at 12:34:29PM +0100, Alexander Graf wrote:
ag...@busu:~/work/qemu-late-int19/qemu> ./x86_64-softmmu/qemu-system-
x86_64 -nographic -kernel ../bzImage -append console=ttyS0 -L pc-
bios -
enable-kvm
[0.00] Linux ve
On Fri, Nov 20, 2009 at 12:34:29PM +0100, Alexander Graf wrote:
> ag...@busu:~/work/qemu-late-int19/qemu> ./x86_64-softmmu/qemu-system-
> x86_64 -nographic -kernel ../bzImage -append console=ttyS0 -L pc-bios -
> enable-kvm
> [0.00] Linux version 2.6.32-rc7 (h...@brick) (gcc version 4.3.4
Alexander Graf wrote:
Btw, it seems like seabios takes quite a bit longer than pc bios to load
the kernel, mostly while the gPXE line is displayed.
Yeah, I really wish we could disable gPXE for default boots. Usually
nobody wants to -boot n anyways, and if they do they can specify that
IMHO.
On 20.11.2009, at 12:31, Christoph Hellwig wrote:
On Fri, Nov 20, 2009 at 11:53:41AM +0100, Alexander Graf wrote:
Works great here:
./x86_64-softmmu/qemu-system-x86_64 -nographic -kernel ../bzImage -
append console=ttyS0 -L pc-bios
Are you sure you also have the follow-up linuxboot patch app
On Fri, Nov 20, 2009 at 11:53:41AM +0100, Alexander Graf wrote:
> Works great here:
>
> ./x86_64-softmmu/qemu-system-x86_64 -nographic -kernel ../bzImage -
> append console=ttyS0 -L pc-bios
>
> Are you sure you also have the follow-up linuxboot patch applied? The
> one "fixing BOCHS bios suppo
On 20.11.2009, at 10:12, Christoph Hellwig wrote:
On Wed, Nov 18, 2009 at 04:06:34PM -0600, Anthony Liguori wrote:
I assume you set prefix with your configure as opposed to make
install
DESTDIR?
Yes. It's configured the following way:
./configure \
--target-list=x86_64-softmmu \
On Wed, Nov 18, 2009 at 04:06:34PM -0600, Anthony Liguori wrote:
> I assume you set prefix with your configure as opposed to make install
> DESTDIR?
Yes. It's configured the following way:
./configure \
--target-list=x86_64-softmmu \
--kerneldir=/home/hch/work/linux-2.6 \
Christoph Hellwig wrote:
On Wed, Nov 18, 2009 at 01:55:48PM -0600, Anthony Liguori wrote:
Did you rebuild qemu and make sure the new BIOS/roms were installed?
and it simply hangs with a black screen once the SDL window opens
I had this problem because I had not rebuilt qemu.
On Wed, Nov 18, 2009 at 01:55:48PM -0600, Anthony Liguori wrote:
> Did you rebuild qemu and make sure the new BIOS/roms were installed?
>
> >and it simply hangs with a black screen once the SDL window opens
> >
>
> I had this problem because I had not rebuilt qemu.
I did a make clean; ./config
Christoph Hellwig wrote:
It seems like this series is now in qemu.git, but I still can't boot
using -kernel.
I'm starting qemu as:
/opt/qemu/bin/qemu-system-x86_64 \
-m 1500 -enable-kvm \
-kernel arch/x86/boot/bzImage \
-drive
file=/dev/vg00/qemu-root,if=virtio,media=di
It seems like this series is now in qemu.git, but I still can't boot
using -kernel.
I'm starting qemu as:
/opt/qemu/bin/qemu-system-x86_64 \
-m 1500 -enable-kvm \
-kernel arch/x86/boot/bzImage \
-drive
file=/dev/vg00/qemu-root,if=virtio,media=disk,cache=none,aio=threads
SeaBIOS clears RAM between we write our -kernel image to RAM and the int19
handler gets triggered.
So in order to work around that, I sat down and implemented Avi's suggestion
of "downloading" all blobs in runtime from the fw_cfg interface
Thanks to glommer who talked me into doing it ;-).
v1 ->
Am 12.11.2009 um 15:53 schrieb Christoph Hellwig :
Thanks Alexander,
I hope this goes into qemu.git ASAP - without it it's totally unusable
for my test setup, and it of course bit my silently when preparing a
demo for a confernence where only reverting back to and older qemu
helped..
Yeah,
Thanks Alexander,
I hope this goes into qemu.git ASAP - without it it's totally unusable
for my test setup, and it of course bit my silently when preparing a
demo for a confernence where only reverting back to and older qemu
helped..
SeaBIOS clears RAM between we write our -kernel image to RAM and the int19
handler gets triggered.
So in order to work around that, I sat down and implemented Avi's suggestion
of "downloading" all blobs in runtime from the fw_cfg interface
Thanks to glommer who talked me into doing it ;-).
Alexa
24 matches
Mail list logo
