Re: [Qemu-devel] Question/problems with Qemu and 64Bit Opensuse 10.2

[Jonathan Phenix]

Werner Dittmann wrote:
> Just forgot to give the info about my system:
>
> Qemu was built and runs on a Suse 10.1 64 bit system (AMD CPU). Also,
> while compiling Qemu I got quite some warning about casting pointers to
> integer of different size (64bit vs 32 bit). Is this ok?
>   
I'm using Fedora Core 5 x86_64 with qemu 0.8.2 and I have noticed these 
warnings as well. However, they do not seem to be a problem, at least 
for what I'm currently doing, developing a new system on top of qemu. 
They seem to be casts from "void *" to "int", which is OK on x86 but 
generate a warning on x86_64 since sizeof(void *) != sizeof(int) on that 
platform.

I other words, I doubt that these warnings are the source of the problem.

Regards,

Jonathan

> Regards,
> Werner
>
> Werner Dittmann wrote:
>   
> > All,
> >
> > currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu.
> >
> > Using a plain 0.82 didn't work out, after the Install screen Qemu goes
> > in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc).
> > I could not even stop Qemu but had to use kill -9 .
> > Because of some mail in the list that reported similar errors I
> > downloaded the latest CVS version and built it using a gcc 3.3.
> >
> > That didn't solve the problem: It seems to be in a loop but I can close
> > the qemu window and the window also grabs the mouse cursor (that was not
> > the case  with the 0.8.2 version).
> >
> > After loading the kernel I get the following message on the console
> > (only in VESA mode):
> >
> > "
> > Decompressing Linux ... done.
> > Booting the kernel.
> > "
> >
> > and at the bottom of the console screen the message (without the qutes):
> >
> > "kernel direct mapping tables up to 100000000 @ 8000-d000"
> >
> > I tried to switch on some -d but I don't know which one is relevant
> > here. I tried "-d int" but this produced about 90MB log data in just
> > some seconds.
> >
> > Which info do you need to get down to the problem? What can I try to
> > tackle the problem?
> >
> > Regards,
> > Werner
> >
> > PS: Because I'm somewhat experienced with security software I would ask
> > if there is any interest to have a TPM module (Software based TPM) for
> > Qemu that looks like a real HW TPM according the the TPM specs? If yes I
> > would start to look how to do it for Qemu. There is a software based TPM
> > avaliable with a GPL licence. The "only thing" to do would be to wrap it
> > with the HW interface functions (it's a memory mapped interface) so that
> > standard drivers would see it as standard TPM module.
> >
> > Werner
> >
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
> >     
>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>