Re: [Qemu-devel] Emulation: Building solid files
Am 27.06.2007 um 00:22 schrieb NetAudi: Building virtual machines taking only one big binary file (merging Qemu engine and HD image file). It could be good for future portable aplications. I thought this because I'm triying to do the simplest-ultra-secure Internet navigatior. The idea is to generate a VM (with the lightest/ functional O.S. posibility and increase speed at top) to content a Firefox installation (with the most used complements into it). The main is to load all this VM into the RAM and when it will turn off, it never has to save the session changes, it allways must start at the beginning point. How does stuffing all virtual machine parts into one file help you to load a virtual machine entirely into RAM? Surely, one could manage to load multiple files into RAM. Additionally, I don't see how it helps security if you move the hard disk for the virtual machine into RAM. It should be fully sufficient to let the inital hard disk sitting in the file system and to record changes to the virtual hard disk, only. qemu supports such recordings (shadowed file systems) already and if it makes you happy, it shouldn't be too hard to keep the record of changes in RAM. This saves you a lot of startup time as well als hundreds of megabytes of RAM. For an approach without any changes to qemu, you could have a look into how (Linux) Live CDs work. Most of them work without a writeable hard disk, managing all the RAM-disk stuff themselves. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
[Qemu-devel] Qemu 0.9 segfault
Hi everybody. Could you please take a look at this post on the forum? No one was able to answer me on that topic... Has is been fixed in the CVS version by chance? http://qemu-forum.ipi.fi/viewtopic.php?t=3344 Thank you very much for this wonderful software anyway :) See ya. François.
Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts
On 6/26/07, Paul Brook [EMAIL PROTECTED] wrote: The story behind this is that ISO C89 requires that long be at least as big as a pointer (ie. void *). The actual requirement is that it be possible to store a pointer in a standard integer type, and long is the largest standard integer type. Unfortunately C99 relaxed this requirement, and allowed abominations like the win64 ABI. This means you have a choice: Write standard conforming code (long) that works on all known systems except win64, or use features that do't exist on many systems. IIRC C99 types like intptr_t are not supported on several fairly common unix systems. In that case I'll vote for unsigned long. I'd pass the issue to those doing a win64 port, if ever that happens.
[Qemu-devel] Re: sidt problem
hi!
just wanted to post that i found out what is really the problem...
obviously this is one of the restrictions in a virtual machine and thus
not a bug (as most of you probably know already).
it'd still be cool if it could be fixed somehow... though this seems
more of an academic thing than a programmer's job :-)
greets!
Clemens Kolbitsch wrote:
hi everyone!
i have a strange problem:
i use the following code on my linux 2.6.20 (kubuntu debian, i386) to
dynamically get the location of the system-call table (as can also be
found in /proc/kallsyms -- sys_call_table) as it is quite
interesting for new exploits ( :-) )
on a real cpu this works fine, however crashes in qemu... obviously
there is a bug somewhere. i have not found my way that deep into the
qemu source, so i cannot really help to find the bug.
well, here is the code:
struct
{
unsigned short limit;
unsigned int base;
} __attribute__ ((packed)) idtr;
struct
{
unsigned short off1;
unsigned short sel;
unsigned char none, flags;
unsigned short off2;
} __attribute__ ((packed)) *igd;
unsigned long *sys_call;
unsigned char *pc;
// find idt_table
__asm__(sidt %0 : :m(idtr));
// find system_call
igd = idtr.base + 8 * 0x80;
// !!!
// the next line crashes
// !!!
sys_call = (igd-off2 16) | igd-off1;
// find sys_call_table
// ff 14 85 XX XX XX XX call sys_call_table(,%eax,4)
sys_call_table = 0x0;
pc = (char*)sys_call;
// check the first 100 bytes in system_call
for (i = 0; i 100; ++i)
{
if ((*(long*)++pc 8) == 0x8514ff00)
{
sys_call_table = *(long*)(pc+3);
break;
}
}
maybe, someone has time to look at this problem (by the way, i use the
same system inside qemu as on my laptop)
greets!!
Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts
Unfortunately C99 relaxed this requirement, and allowed abominations like the win64 ABI. This means you have a choice: Write standard conforming code (long) that works on all known systems except win64, or use features that do't exist on many systems. IIRC C99 types like intptr_t are not supported on several fairly common unix systems. In that case I'll vote for unsigned long. I'd pass the issue to those doing a win64 port, if ever that happens. In Valgrind-world we use an alternative approach, which is to typedef a set of new integral types and use those exclusively, and not use the native 'int', 'long' etc. The new types have a single fixed meaning regardless of the host or guest and it is up to the configure script to set up suitable typedefs. At startup Valgrind checks the size and signedness of these types is as expected, so any configuration errors are caught. This has proved very helpful in porting to a number of platforms. J
Re: [Qemu-devel] sparc guest
Thiemo Seufer wrote: Blue Swirl wrote: On 6/25/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Nigel Horne wrote: Good news, sparc emulation with -nographic no longer core dumps. The bad news, networking still fails: FYI, I see a transmit error for ne2k_isa on mips r4k. Maybe that's related. On my test cases the network is still fine. What was the setup again? What I see is apparently not triggered by a change in Qemu. An older 2.6.16 kernel works with current Qemu, but 2.6.21 breaks networking. 2.6.16 and 2.6.21 are not involved here. My host is running 2.6.20, the guest is running 2.6.8. The setup is basically the big endian mips regression test initrd with a newer kernel. Sparc? Thiemo -- Nigel Horne. Arranger, Adjudicator, Band Trainer, Composer, Tutor, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 [EMAIL PROTECTED] http://www.bandsman.co.uk begin:vcard fn:Nigel Horne n:Horne;Nigel org:NJH Music email;internet:[EMAIL PROTECTED] tel;fax:+44 870 705 9334 note:Skype: nigelhorne x-mozilla-html:FALSE version:2.1 end:vcard
[Qemu-devel] [PATCH] Fix environ termination
Properly NULL-terminate the environment.
Andreas.
--- linux-user/main.c.~1.116.~ 2007-06-25 12:39:20.0 +0200
+++ linux-user/main.c 2007-06-27 12:51:43.0 +0200
@@ -1819,7 +1819,7 @@ int main(int argc, char **argv)
continue;
*(dst++) = strdup(*wrk);
}
-dst = NULL; /* NULL terminate target_environ */
+*dst = NULL; /* NULL terminate target_environ */
if (loader_exec(filename, argv+optind, target_environ, regs, info) != 0) {
printf(Error loading %s\n, filename);
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts
On Wed, 27 Jun 2007, Julian Seward wrote: In Valgrind-world we use an alternative approach, which is to typedef a set of new integral types and use those exclusively, and not use the native 'int', 'long' etc. The new types have a single fixed meaning regardless of the host or guest and it is up to the configure script to set up suitable typedefs. At startup Valgrind checks the size and signedness of these types is as expected, so any configuration errors are caught. This has proved very helpful in porting to a number of platforms. So in this particular case we have the types UWord and Word (unsigned and signed machine words) which it is guaranteed are the same size as void*, on all platforms. We also capitalise the first letter of all type names as that makes the code easier to read and makes it obvious when you are inadvertantly using the native 'int', 'long' etc. FWIW, any C code defining such types with a single fixed meaning should use very(!) distinct prefixes to keep those identifiers within their own namespace. From what I can tell having done quite a lot of porting and component integration of C code, capitalization is definitely not enough to ensure self-containedness of your code. :-) Regards Marius -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com Handelsregister: HRB Mainz 90 HRB 8066 Vorstand: Knut Degen, Robert Kaiser, Detlev Schaadt Aufsichtsratsvorsitzender: Dr. Thomas Hoch USt(VAT)-Id-Nr.: DE 149062328
Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts
Marius Groeger wrote: On Wed, 27 Jun 2007, Julian Seward wrote: In Valgrind-world we use an alternative approach, which is to typedef a set of new integral types and use those exclusively, and not use the native 'int', 'long' etc. The new types have a single fixed meaning regardless of the host or guest and it is up to the configure script to set up suitable typedefs. At startup Valgrind checks the size and signedness of these types is as expected, so any configuration errors are caught. This has proved very helpful in porting to a number of platforms. So in this particular case we have the types UWord and Word (unsigned and signed machine words) which it is guaranteed are the same size as void*, on all platforms. We also capitalise the first letter of all type names as that makes the code easier to read and makes it obvious when you are inadvertantly using the native 'int', 'long' etc. FWIW, any C code defining such types with a single fixed meaning should use very(!) distinct prefixes to keep those identifiers within their own namespace. From what I can tell having done quite a lot of porting and component integration of C code, capitalization is definitely not enough to ensure self-containedness of your code. :-) Indeed. We have already host_ and target_ prefixes in some places, which are IMHO a natural choice for a naming convention. Thiemo
[Qemu-devel] qemu/target-mips op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/27 19:01:46 Modified files: target-mips: op_helper.c Log message: Fix computation for ceil, floor and round instructions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.54r2=1.55
Re: [Qemu-devel] qemu vl.c (regression)
This patch results in a segmentation fault when i386-softmmu/qemu is called without arguments. strcmp is called with a null argument (optarg == NULL). Tested on Windows and Debian x86 host. Stefan Thiemo Seufer schrieb: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/06/23 16:01:57 Modified files: . : vl.c Log message: Return success for -M '?' query option. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.310r2=1.311
Re: [Qemu-devel] sparc guest
On 6/27/07, Nigel Horne [EMAIL PROTECTED] wrote: Thiemo Seufer wrote: Blue Swirl wrote: On 6/25/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Nigel Horne wrote: Good news, sparc emulation with -nographic no longer core dumps. The bad news, networking still fails: FYI, I see a transmit error for ne2k_isa on mips r4k. Maybe that's related. On my test cases the network is still fine. What was the setup again? What I see is apparently not triggered by a change in Qemu. An older 2.6.16 kernel works with current Qemu, but 2.6.21 breaks networking. 2.6.16 and 2.6.21 are not involved here. My host is running 2.6.20, the guest is running 2.6.8. I just updated guest from Debian 3.1r1 to 4.0. After reboot net still works fine (4Mbytes/s), though the kernel is still 2.4.29. I tried installing a 2.6 series kernel but something went wrong with the ram disk creation. Host is 2.6.18.
Re: [Qemu-devel] qemu/target-mips op_helper.c
IMHO, calling floatX_round_to_int before floatX_to_intY is not useful... Fabrice. Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/27 19:01:46 Modified files: target-mips: op_helper.c Log message: Fix computation for ceil, floor and round instructions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.54r2=1.55
Re: [Qemu-devel] qemu/target-mips op_helper.c
Fabrice Bellard wrote: IMHO, calling floatX_round_to_int before floatX_to_intY is not useful... I don't understand. floatX_round_to_int does round/ceil/floor but keeps the floating point representation. floatX_to_intY converts the adjusted value to integer representation. Doing this in two steps may have its own problems like spurious inexact signalling, but at least the calculated values appear to be correct. Thiemo
