Re: Re: [Qemu-devel] Windows Laptop Idea
<[EMAIL PROTECTED]> wrote: > > > The rescue disks aren't an OEM copy of WinXP Home, they > > are a set of 6 CD's containing a very fixed version of > > Partition Quest's partition restorer. I went down into > > Ahh... > > Yeah, you got screwed. > > I thought those kinds of practices went out with Win98. > > But yeah, I guess some manufacturers aren't honest. Well, it keeps you from reusing the media on a machine that it's licensed for, but what I'm trying to do is setup my XP on my laptop in a QEMU session. I've looked through the batch files, and it uses a partition quest binary to do the actual restore, as long as it passes the bios id check. > At least be glad you got the cd's. They could have put it on a protected > hidden partition on your drive. (The IDE drive specs allow for password > protected hidden drive sections.) So if your hard drive failed, so would > your copy of XP Yeah, I've already had another HP laptop disk crash. > > the bat files that manipulate this thing, and there is > > a bios checker to make sure that the bios of the laptop > > I'm pretty sure the 'bios checker' is probably checking for the digital > signature in the BIOS. Nope. Just the bios id. > With XP, Microsoft went pretty strong with digital signatures, putting them > into about every file. > > They probably made OEM's do the same with the bios. > > That way if you patched it or used some warez bios with some extra feature of > some sort, the digital signature wouldn't be correct, and the activation > would fail. Possibly. But it would be interesting to try to install it *if* I could set the bios ID on the command line in qemu. > > I have heard of several cases of people upgrading the bios (in some cases to > an official one, and in others to a hacked one) and the product activation > failing. well, again, I'm not terribly thrilled about Microsoft, but I would like see if it's possible. If M$ did something else to prevent it from running, then that I can't do anything about. It is pretty fragile. When I tried to remove the hibernate partition, XP stopped booting. > > So I doubt it's a simple check. Not like looking for "HP OEM" string or some > such. Something that simple would pretty much defeat the whole point of > product activation. You'd see warez sites with lots of patched bios's with > the OEM signature checks in, allowing everybody to run a Dell or other OEM > version of XP without any activation. The bios id is part of the directory struture that HP uses. > Microsoft wouldn't tolerate that. They are too greedy. It'd almost have to > be a full cryptographic digital signature. Something that couldn't be easily > forged by the warez crowd. I suppose I could remaster the CD's to use QEMU/Bochs's bios signature, but it'd be easier if I didn't have to do that. > > That's why I said you'd have to emulate the hardware too. So you could use > the original bios. yep. > > >> I'm a firm believer that a person has a right to the original unmodified > >> files (without unneeded OEM specific junk), so if it was me, I'd make an > >> effort to get the md5's of the regular OEM version of XP (whatever > >> version) and see what is truely different. > > > > This would be pretty impossible. > > Maybe not > > I remember with Win98 that even many customized rescue cd's, you could often > manage to extract the correct files and create an install disk. That may be worth pursuing, just so I can have a recovery disk in case things really go boom > > With XP it would probably be more difficult. More trouble than it'd be > worth. You could probably uninstall a lot of stuff, and comparing files to a > regular XP, and so on, and almost get a clean copy. But probably not all the > way. And it'd be a lot of trouble. > > I've never investigated going from an installed copy and trying to make a cd > from it. > > As Hetz said... You might want to look around for a warez copy of xp. Maybe > borrow a copy from a friend, that way you'd know it'd be legit. (Be careful > about warez programs... they aren't all trustworthy, if you know what I mean!) I have a copy of XPHome, but I would like to see if I can get all the extras that are on the the rescue disks. I can reinstall them from there, on to the XPHome, but that's a lot extra work. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.
On Sunday 01 May 2005 21:15, Flavio Visentin wrote: > > This is not correct. > > If the blr is not at the end of the function, things will break. > > [SNIP] > > > This basically only ever worked because gcc could be coerced into > > generating relatively simple code. GCC4 contains much more aggressive > > high level optimizers, so this is no longer possible. > > I don't know almost anything about gcc, so I'm asking two questions: > > 1) Isn't there any kind of compiler directive to force no optimization > only for a portion of the code? Optimiziation is controlled on a per-file bases. > 2) If there aren't such directives is it possible to link together > optimized obj with not optimized obj? In this case you could group > functions that require no optimization and link them with the other > optimized code. Linking together objects compiled with and without optimization isn't a problem, however... Disabling optimization isn't really an option because (a) it causes other problems, and (b) the code generate is awfully slow. The real solution is to teach qemu how to generate native code from and remove dyngen altogether, but that's a lot of work. Look in the list archives for more details. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.
On Sunday 01 May 2005 21:29, Jonas Maebe wrote: > On 01 May 2005, at 19:04, Paul Brook wrote: > > This is not correct. > > If the blr is not at the end of the function, things will break. > > dyngen assumes the last instruction is the only return instruction in > > the > > function. This allows it to remove the blr insn and concatenate > > multiple > > functions together. > > Can't we on PPC just replace all blr's with plain branches to the > instruction after end of the function? (since all instructions are 32 > bit long) Yes, that should be work for ppc. Obviously this doesn't help on x86/amd64 where a jump is longer than a ret. you would have to copy the preceeding instruction[s] to make room for the branch. You'd then need to redirect any jumps directly to the ret instruction, and make them point at the copy. Sparc may have similar problems because of jump delay slots (a jump is effectively two instructions long. Arm needs a bit of logic to follow jumps and figure out where the end of the function is (ie. where the constant pool starts), but other that than the same trick should work. Overall it sounds like a tractable problem. It shouldn't matter if this analysis takes a while because it's don'e while building qemu, not at runtime. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.
On 01 May 2005, at 19:04, Paul Brook wrote: This is not correct. If the blr is not at the end of the function, things will break. dyngen assumes the last instruction is the only return instruction in the function. This allows it to remove the blr insn and concatenate multiple functions together. Can't we on PPC just replace all blr's with plain branches to the instruction after end of the function? (since all instructions are 32 bit long) Jonas ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > This is not correct. > If the blr is not at the end of the function, things will break. [SNIP] > This basically only ever worked because gcc could be coerced into generating > relatively simple code. GCC4 contains much more aggressive high level > optimizers, so this is no longer possible. I don't know almost anything about gcc, so I'm asking two questions: 1) Isn't there any kind of compiler directive to force no optimization only for a portion of the code? 2) If there aren't such directives is it possible to link together optimized obj with not optimized obj? In this case you could group functions that require no optimization and link them with the other optimized code. Maybe I asked 2 dumb questions, but I'm courious and I'd like to learn something new :-) TNX P.S. I apologize for my bad English :-) - -- Flavio Visentin | \|||/ |@/0.0\@ | \ - / +--oOOo---oOOo-- There are only 10 types of people in this world: those who understand binary, and those who don't. GPG Key: http://www.zipman.it/gpgkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCdTj0usUmHkh1cnoRAs3hAJ48/9uEbjEqNTsa24mKm6Ol62774ACdGpnF N+EC/lngLa6oytEfDVUO3eA= =lVHN -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Laptop Idea
On 4/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Ben; > Unfortunately, there aren't too many disk imaging programs I'd recommend. > Both Norton Ghost (the old version) and DriveImage (the old version) have > problems. And I certainly wouldn't recommend the new versions. None of the > opensource stuff I've seen know how to burn to cd/dvd. I agree here. Norton really seems like technology from the past (DOS, 16bit mode etc). But I can recommend two programs. The first ist OSS: partimage. It certainly has its limitations (e.g. it does not know anything about Windows specials, such as the security ID), but it works from any live Linux systems, which makes it indefinately more powerful than the competitors. The second one is BootItNG from http://www.terabyteunlimited.com/. It is a partition tool, bootloader and image manipulation program. A time limited test version is available, which should be enough for a one off partition manipulation. It does not run on top of an OS, but it still has a number of nice features, including burning to CD (DVD?). HTH Thomas ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] 2 Questions
I'm workin on the GUI for cocoa.m... I'm able to save/stop/start WMs from the GUI - if i stop qemu, am I able to change vars like memory/images/network and start qemu with a different VM without terminating qemu? I'm able to change images for cdrom/floppy from the GUI - is it possible to load a image for the cdrom/floppy, if i had none at startup (right now it's not working in my code) Greetings Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re: [Qemu-devel] Windows Laptop Idea
Ben; > The rescue disks aren't an OEM copy of WinXP Home, they > are a set of 6 CD's containing a very fixed version of > Partition Quest's partition restorer. I went down into Ahh... Yeah, you got screwed. I thought those kinds of practices went out with Win98. But yeah, I guess some manufacturers aren't honest. At least be glad you got the cd's. They could have put it on a protected hidden partition on your drive. (The IDE drive specs allow for password protected hidden drive sections.) So if your hard drive failed, so would your copy of XP > the bat files that manipulate this thing, and there is > a bios checker to make sure that the bios of the laptop I'm pretty sure the 'bios checker' is probably checking for the digital signature in the BIOS. With XP, Microsoft went pretty strong with digital signatures, putting them into about every file. They probably made OEM's do the same with the bios. That way if you patched it or used some warez bios with some extra feature of some sort, the digital signature wouldn't be correct, and the activation would fail. I have heard of several cases of people upgrading the bios (in some cases to an official one, and in others to a hacked one) and the product activation failing. So I doubt it's a simple check. Not like looking for "HP OEM" string or some such. Something that simple would pretty much defeat the whole point of product activation. You'd see warez sites with lots of patched bios's with the OEM signature checks in, allowing everybody to run a Dell or other OEM version of XP without any activation. Microsoft wouldn't tolerate that. They are too greedy. It'd almost have to be a full cryptographic digital signature. Something that couldn't be easily forged by the warez crowd. That's why I said you'd have to emulate the hardware too. So you could use the original bios. >> I'm a firm believer that a person has a right to the original unmodified >> files (without unneeded OEM specific junk), so if it was me, I'd make an >> effort to get the md5's of the regular OEM version of XP (whatever version) >> and see what is truely different. > > This would be pretty impossible. Maybe not I remember with Win98 that even many customized rescue cd's, you could often manage to extract the correct files and create an install disk. With XP it would probably be more difficult. More trouble than it'd be worth. You could probably uninstall a lot of stuff, and comparing files to a regular XP, and so on, and almost get a clean copy. But probably not all the way. And it'd be a lot of trouble. I've never investigated going from an installed copy and trying to make a cd from it. As Hetz said... You might want to look around for a warez copy of xp. Maybe borrow a copy from a friend, that way you'd know it'd be legit. (Be careful about warez programs... they aren't all trustworthy, if you know what I mean!) As long as you are just testing qemu by trying to install it, I don't think anybody would really care. >> I'm definetly not a fan of Microsoft's policies and practices. I do use >> Windows, but I don't like the company. > > Agreed. Having a windows license on my laptop should not > preclude me from running the configuration only *their* > way. In this case, it's HP that's screwing you. With Microsoft's blessing. There is still one chance, though... You might be able to complain enough to HP to get the xp install cd. I have heard of a few cases (with unknown oem's) where either people didn't get a cd at all, or something or other, and they complained long enough to their seller and they gave them the oem version of xp. Can't say that'd actually work though... Or, you could always check ebay! You might be able to pick up a Dell xp cd pretty cheap. (Or other oem cd.) The Dell versions I've seen are pretty close to a plain OEM cd. So you might be able to clean up that cd, copy the few OEM specific files from your HP and make a new cd. If you do it right, it'd still be pre-activated for your system. You'd just be free of the HP extra stuff. Anyway, for you, to test qemu with xp you are pretty much out of luck. Sorry. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] savemv/loadvm keyboard weirdness
I'm starting a Knoppix 3.8 instance from a CD iso image using: qemu -cdrom /export/src/iso/KNOPPIX_V3.8.1-2005-04-08-EN.iso -user-net -enable-audio -boot d knoppix.img -k en-us with the intention of getting it up and running so I can use a savevm/loadvm feature. What I did was boot Knoppix, open a terminal window, and then do a savevm and quit. I then restarted the Knoppix session with the previous command line adding "-loadvm knoppix-save.img". This works and I have the knoppix image up and running in a matter of 10 seconds. However, the keyboard mapping for the terminal is very screwed up. It's almost like it's doing all control keys. Now, sometimes, I can kill the kconsole and restart another one and it all works the way it should. Anyone have an idea about this? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Interaction between snapshot and savevm/loadvm
Does anyone know the interaction between using snapshot and a savevm'd state. I'd like to do some testing without having to lug around several copies of an image file, so I'm thinking that i'd like to use a snapshot with a savevm state file to restart an image. This way, if something blows up badly, I don't lose my original image. Thoughts? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] Remove requirement for -hda with -kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fabrice Bellard wrote:
>
> I like the idea, but your patch may not compile for win32. Maybe
> creating a generic "dummy:[size]" block device would be interesting
> instead ?
>
> Fabrice.
>
How about this? With this patch you can specify e.g. '-hda dummy:256M'
to create a 256 Mb hard disc on the fly, backed by a file in the temp
directory which is deleted on exit. This patch uses this general
mechanism to create the bogus 1-sector hard disc needed for booting a
Linux kernel. This patch works on Linux and has been compile-tested on
Mingw.
Ross
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCcq1+9bR4xmappRARAtqgAKDkDHQjfIYeaPnn/wD3F+G44vvxsgCfUoDX
gONMKl2/KFPHJjzJRHwC2yk=
=6vTC
-END PGP SIGNATURE-
Index: Makefile
===
RCS file: /cvsroot/qemu/qemu/Makefile,v
retrieving revision 1.87
diff -u -p -r1.87 Makefile
--- Makefile 28 Apr 2005 21:15:08 - 1.87
+++ Makefile 29 Apr 2005 21:22:02 -
@@ -25,7 +25,7 @@ else
endif
endif
-qemu-img$(EXESUF): qemu-img.c block.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c
+qemu-img$(EXESUF): qemu-img.c block.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c block-dummy.c
$(CC) -DQEMU_TOOL $(CFLAGS) $(LDFLAGS) $(DEFINES) -o $@ $^ -lz $(LIBS)
dyngen$(EXESUF): dyngen.c
Index: Makefile.target
===
RCS file: /cvsroot/qemu/qemu/Makefile.target,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile.target
--- Makefile.target 28 Apr 2005 21:15:08 - 1.69
+++ Makefile.target 29 Apr 2005 21:22:03 -
@@ -314,7 +314,7 @@ endif
# must use static linking to avoid leaving stuff in virtual address space
VL_OBJS=vl.o osdep.o block.o readline.o monitor.o pci.o console.o
-VL_OBJS+=block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o
+VL_OBJS+=block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o block-dummy.o
SOUND_HW = sb16.o
AUDIODRV = audio.o noaudio.o wavaudio.o
Index: block.c
===
RCS file: /cvsroot/qemu/qemu/block.c,v
retrieving revision 1.22
diff -u -p -r1.22 block.c
--- block.c 28 Apr 2005 21:09:32 - 1.22
+++ block.c 29 Apr 2005 21:22:05 -
@@ -657,4 +657,5 @@ void bdrv_init(void)
bdrv_register(&bdrv_bochs);
bdrv_register(&bdrv_vpc);
bdrv_register(&bdrv_vvfat);
+bdrv_register(&bdrv_dummy);
}
Index: vl.h
===
RCS file: /cvsroot/qemu/qemu/vl.h,v
retrieving revision 1.73
diff -u -p -r1.73 vl.h
--- vl.h 28 Apr 2005 21:15:08 - 1.73
+++ vl.h 29 Apr 2005 21:22:08 -
@@ -385,6 +385,7 @@ extern BlockDriver bdrv_dmg;
extern BlockDriver bdrv_bochs;
extern BlockDriver bdrv_vpc;
extern BlockDriver bdrv_vvfat;
+extern BlockDriver bdrv_dummy;
void bdrv_init(void);
BlockDriver *bdrv_find_format(const char *format_name);
Index: hw/pc.c
===
RCS file: /cvsroot/qemu/qemu/hw/pc.c,v
retrieving revision 1.35
diff -u -p -r1.35 pc.c
--- hw/pc.c 15 Jan 2005 12:02:56 - 1.35
+++ hw/pc.c 29 Apr 2005 21:22:08 -
@@ -446,8 +446,14 @@ void pc_init(int ram_size, int vga_ram_s
uint8_t old_bootsect[512];
if (bs_table[0] == NULL) {
-fprintf(stderr, "A disk image must be given for 'hda' when booting a Linux kernel\n");
-exit(1);
+fprintf(stderr, "qemu: Disk image not given for 'hda' when booting"
+" a Linux kernel; inventing one\n");
+bs_table[0] = bdrv_new("hda");
+if (bdrv_open(bs_table[0], "dummy:512", 0) < 0) {
+fprintf(stderr, "qemu: could not create temporary diskimage\n");
+exit(1);
+}
+boot_device = 'c';
}
snprintf(buf, sizeof(buf), "%s/%s", bios_dir, LINUX_BOOT_FILENAME);
ret = load_image(buf, bootsect);
--- /dev/null 2005-04-29 15:39:30.0 +0100
+++ block-dummy.c 2005-04-29 21:48:18.0 +0100
@@ -0,0 +1,148 @@
+/*
+ * QEMU dummy block device driver
+ *
+ * Copyright (C) 2005 Ross Kendall Axe <[EMAIL PROTECTED]>
+ * Portions copyright (c) 2003 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software
Re: [Qemu-devel] Windows Laptop Idea
Ben; >> > the bat files that manipulate this thing, and there is >> > a bios checker to make sure that the bios of the laptop >> >> I'm pretty sure the 'bios checker' is probably checking for the digital >> signature in the BIOS. > > It just looks for a string. You wanna see the bat files? > I booted it under qemu, then copied all the bat files > off a floppy image. I have a pair of HP laptops and > there's not much differnece between the set of bat files. I think I now understand what you are saying... The *restore process* just checks for a simple bios string. That's what HP chose to do. WinXP itself (to verify the activation) checks more than that. In that case, once you've done the restore proccess itself, you could use your own backup program and make a copy that isn't protected. Unfortunately, there aren't too many disk imaging programs I'd recommend. Both Norton Ghost (the old version) and DriveImage (the old version) have problems. And I certainly wouldn't recommend the new versions. None of the opensource stuff I've seen know how to burn to cd/dvd. *IF* you want it, you can get the dos part of Norton Ghost for free. It's included in one of their updates from the web site. You put that onto a basic dos boot floppy and run it that way. I use Ghost that way, and I know a few others that do. But none of us really trust Ghost because sometimes it has problems. You might try a regular copy of DriveImage. You'd still have to deal with XP activation and the hp specific drivers etc., but you'd have your own image that you could restore to any drive, including to a image. (I once did that with vmware. It didn't work too well since the hardware is so different. You can work around that, but you need an xp cd.) Anyway, here's the URL for the update to old Norton Ghost. http://liveupdate.symantec.com/ng2003b793_en.x86 rename it to .zip and extract ghost.exe (I don't think there is a newer version.) Put that onto a very basic dos floppy. (Just dos and an optional mouse driver.) If you allow it, ghost will 'brand' the drive you are using on track 0. You can tell it no. But be warned that trying to copy a working image to another computer (or qemu etc.) isn't likely to work easily. It can be done, but it's not easy. It's kind of like doing a mobo swap. If you can do it before the swap, then you can make certain preperations to get XP to redectect the hardware etc. on the next boot. If the mobo went out and you've already replaced, then you do need a regular xp cd to install xp over itself to repair things. Just like doing it with Win98. >> Microsoft wouldn't tolerate that. They are too greedy. It'd almost have to >> be a full cryptographic digital signature. Something that couldn't be >> easily forged by the warez crowd. > > Yeah, but who'd really do that. The damn HP rescue disks > install just one way. All or nothing. Everything on Right. But once it is installed, you could make a copy and try to take it to another machine. That's where XP's activation and BIOS check come in at. That's the part I thought you were talking about. As for just changing the bios signature to enable the restore process that would depend on where the signature is at. If the space isn't used in the Bochs / qemu bios, you could change it and then rerun the bios checksum program. Here are a couple of links you might be interested in. Talks about making an xp from an installed version of xp... Don't know if it works. It's just an old link I had. (Although it might work, I still think it'd be better to get a real oem cd (even dell), and copy the few HP oem files onto it and make a real OEM xp install cd. That way you never have to worry about all the other junk that HP installs.) http://www.easydesksoftware.com/recovery.htm#XP How to swap a mobo without having to reinstall XP. Similar to moving an image over to qemu or vmware. http://episteme.arstechnica.com/eve/ubb.x?q=Y&a=tpc&s=50009562&f=77909774&m=1400925745&p=1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.
On Saturday 30 April 2005 12:10, David Woodhouse wrote:
> GCC 4 occasionally generates functions with the 'blr' somewhere in the
> middle and a branch at the end.
>
> --- qemu-0.7.0/dyngen.c.orig 2005-04-30 11:59:05.0 +0100
> +++ qemu-0.7.0/dyngen.c 2005-04-30 12:00:11.0 +0100
> @@ -1396,11 +1395,13 @@ void gen_code(const char *name, host_ulo
> #elif defined(HOST_PPC)
> {
> uint8_t *p;
> +uint32_t insn;
> p = (void *)(p_end - 4);
> if (p == p_start)
> error("empty code for %s", name);
> -if (get32((uint32_t *)p) != 0x4e800020)
> -error("blr expected at the end of %s", name);
> +insn = get32((uint32_t *)p);
> +if (insn != 0x4e800020 && (insn & 0xfc02) != 0x4800)
> +error("blr or b expected at the end of %s", name);
> copy_size = p - p_start;
> }
> #elif defined(HOST_S390)
This is not correct.
If the blr is not at the end of the function, things will break.
dyngen assumes the last instruction is the only return instruction in the
function. This allows it to remove the blr insn and concatenate multiple
functions together.
This basically only ever worked because gcc could be coerced into generating
relatively simple code. GCC4 contains much more aggressive high level
optimizers, so this is no longer possible.
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [patch] VMDK create support
Filip Navara <[EMAIL PROTECTED]>
Support for creating VMDK images.
Index: block-vmdk.c
===
RCS file: /cvsroot/qemu/qemu/block-vmdk.c,v
retrieving revision 1.5
diff -u -p -r1.5 block-vmdk.c
--- block-vmdk.c 26 Apr 2005 21:08:00 - 1.5
+++ block-vmdk.c 30 Apr 2005 04:07:54 -
@@ -315,6 +315,109 @@ static int vmdk_write(BlockDriverState *
return 0;
}
+static int vmdk_create(const char *filename, int64_t total_size,
+ const char *backing_file, int flags)
+{
+int fd, i;
+VMDK4Header header;
+uint32_t tmp, magic, grains, gd_size, gt_size, gt_count;
+char *desc_template =
+"# Disk DescriptorFile\n"
+"version=1\n"
+"CID=%x\n"
+"parentCID=\n"
+"createType=\"monolithicSparse\"\n"
+"\n"
+"# Extent description\n"
+"RW %lu SPARSE \"%s\"\n"
+"\n"
+"# The Disk Data Base \n"
+"#DDB\n"
+"\n"
+"ddb.virtualHWVersion = \"3\"\n"
+"ddb.geometry.cylinders = \"%lu\"\n"
+"ddb.geometry.heads = \"16\"\n"
+"ddb.geometry.sectors = \"63\"\n"
+"ddb.adapterType = \"ide\"\n";
+char desc[1024];
+const char *real_filename, *temp_str;
+
+/* XXX: add support for backing file */
+
+fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY | O_LARGEFILE,
+ 0644);
+if (fd < 0)
+return -1;
+magic = cpu_to_be32(VMDK4_MAGIC);
+memset(&header, 0, sizeof(header));
+header.version = cpu_to_le32(1);
+header.flags = cpu_to_le32(3); /* ?? */
+header.capacity = cpu_to_le64(total_size);
+header.granularity = cpu_to_le64(128);
+header.num_gtes_per_gte = cpu_to_le32(512);
+
+grains = (total_size + header.granularity - 1) / header.granularity;
+gt_size = ((header.num_gtes_per_gte * sizeof(uint32_t)) + 511) >> 9;
+gt_count = (grains + header.num_gtes_per_gte - 1) / header.num_gtes_per_gte;
+gd_size = (gt_count * sizeof(uint32_t) + 511) >> 9;
+
+header.desc_offset = 1;
+header.desc_size = 20;
+header.rgd_offset = header.desc_offset + header.desc_size;
+header.gd_offset = header.rgd_offset + gd_size + (gt_size * gt_count);
+header.grain_offset =
+ ((header.gd_offset + gd_size + (gt_size * gt_count) +
+ header.granularity - 1) / header.granularity) *
+header.granularity;
+
+header.desc_offset = cpu_to_le64(header.desc_offset);
+header.desc_size = cpu_to_le64(header.desc_size);
+header.rgd_offset = cpu_to_le64(header.rgd_offset);
+header.gd_offset = cpu_to_le64(header.gd_offset);
+header.grain_offset = cpu_to_le64(header.grain_offset);
+
+header.check_bytes[0] = 0xa;
+header.check_bytes[1] = 0x20;
+header.check_bytes[2] = 0xd;
+header.check_bytes[3] = 0xa;
+
+/* write all the data */
+write(fd, &magic, sizeof(magic));
+write(fd, &header, sizeof(header));
+
+ftruncate(fd, header.grain_offset << 9);
+
+/* write grain directory */
+lseek(fd, le64_to_cpu(header.rgd_offset) << 9, SEEK_SET);
+for (i = 0, tmp = header.rgd_offset + gd_size;
+ i < gt_count; i++, tmp += gt_size)
+write(fd, &tmp, sizeof(tmp));
+
+/* write backup grain directory */
+lseek(fd, le64_to_cpu(header.gd_offset) << 9, SEEK_SET);
+for (i = 0, tmp = header.gd_offset + gd_size;
+ i < gt_count; i++, tmp += gt_size)
+write(fd, &tmp, sizeof(tmp));
+
+/* compose the descriptor */
+real_filename = filename;
+if ((temp_str = strrchr(real_filename, '\\')) != NULL)
+real_filename = temp_str + 1;
+if ((temp_str = strrchr(real_filename, '/')) != NULL)
+real_filename = temp_str + 1;
+if ((temp_str = strrchr(real_filename, ':')) != NULL)
+real_filename = temp_str + 1;
+sprintf(desc, desc_template, time(NULL), (unsigned long)total_size,
+real_filename, total_size / (63 * 16));
+
+/* write the descriptor */
+lseek(fd, le64_to_cpu(header.desc_offset) << 9, SEEK_SET);
+write(fd, desc, strlen(desc));
+
+close(fd);
+return 0;
+}
+
static void vmdk_close(BlockDriverState *bs)
{
BDRVVmdkState *s = bs->opaque;
@@ -331,6 +434,6 @@ BlockDriver bdrv_vmdk = {
vmdk_read,
vmdk_write,
vmdk_close,
-NULL, /* no create yet */
+vmdk_create,
vmdk_is_allocated,
};
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [patch] arm semihosting open bug
The arm semihosting open syscall does not pass the "mode" argument when creating a file. The patch below fixes this. Paul Index: arm-semi.c === RCS file: /cvsroot/qemu/qemu/linux-user/arm-semi.c,v retrieving revision 1.2 diff -u -p -r1.2 arm-semi.c --- arm-semi.c 26 Apr 2005 20:44:10 - 1.2 +++ arm-semi.c 30 Apr 2005 15:13:43 - @@ -99,7 +99,7 @@ uint32_t do_arm_semihosting(CPUState *en else return STDOUT_FILENO; } -return set_swi_errno(ts, open(s, open_modeflags[ARG(1)])); +return set_swi_errno(ts, open(s, open_modeflags[ARG(1)], 0644)); case SYS_CLOSE: return set_swi_errno(ts, close(ARG(0))); case SYS_WRITEC: ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix dyngen failure on PPC.
GCC 4 occasionally generates functions with the 'blr' somewhere in the
middle and a branch at the end.
--- qemu-0.7.0/dyngen.c.orig2005-04-30 11:59:05.0 +0100
+++ qemu-0.7.0/dyngen.c 2005-04-30 12:00:11.0 +0100
@@ -1396,11 +1395,13 @@ void gen_code(const char *name, host_ulo
#elif defined(HOST_PPC)
{
uint8_t *p;
+uint32_t insn;
p = (void *)(p_end - 4);
if (p == p_start)
error("empty code for %s", name);
-if (get32((uint32_t *)p) != 0x4e800020)
-error("blr expected at the end of %s", name);
+insn = get32((uint32_t *)p);
+if (insn != 0x4e800020 && (insn & 0xfc02) != 0x4800)
+error("blr or b expected at the end of %s", name);
copy_size = p - p_start;
}
#elif defined(HOST_S390)
--
dwmw2
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [patchlet] typo in documentation
Hi,
Typo in the documentation: s/peripherial/peripheral/g
diff -X excl -rduNp qemu.oorig/qemu-doc.texi qemu/qemu-doc.texi
--- qemu.oorig/qemu-doc.texi2005-03-13 10:43:05.0 +0100
+++ qemu/qemu-doc.texi 2005-04-30 14:46:24.762300960 +0200
@@ -22,7 +22,7 @@ QEMU has two operating modes:
@item
Full system emulation. In this mode, QEMU emulates a full system (for
-example a PC), including a processor and various peripherials. It can
+example a PC), including a processor and various peripherals. It can
be used to launch different Operating Systems without rebooting the
PC or to debug system code.
@@ -73,7 +73,7 @@ Download the experimental binary install
@c man begin DESCRIPTION
The QEMU System emulator simulates the
-following PC peripherials:
+following PC peripherals:
@itemize @minus
@item
@@ -930,7 +930,7 @@ problem.
Use the executable @file{qemu-system-ppc} to simulate a complete PREP
or PowerMac PowerPC system.
-QEMU emulates the following PowerMac peripherials:
+QEMU emulates the following PowerMac peripherals:
@itemize @minus
@item
@@ -947,7 +947,7 @@ Non Volatile RAM
VIA-CUDA with ADB keyboard and mouse.
@end itemize
-QEMU emulates the following PREP peripherials:
+QEMU emulates the following PREP peripherals:
@itemize @minus
@item
@@ -1000,7 +1000,7 @@ More information is available at
Use the executable @file{qemu-system-sparc} to simulate a JavaStation
(sun4m architecture). The emulation is far from complete.
-QEMU emulates the following sun4m peripherials:
+QEMU emulates the following sun4m peripherals:
@itemize @minus
@item
diff -X excl -rduNp qemu.oorig/qemu-tech.texi qemu/qemu-tech.texi
--- qemu.oorig/qemu-tech.texi 2004-12-20 00:18:01.0 +0100
+++ qemu/qemu-tech.texi 2005-04-30 14:46:59.755981112 +0200
@@ -22,7 +22,7 @@ QEMU has two operating modes:
@item
Full system emulation. In this mode, QEMU emulates a full system
-(usually a PC), including a processor and various peripherials. It can
+(usually a PC), including a processor and various peripherals. It can
be used to launch an different Operating System without rebooting the
PC or to debug system code.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu ./Changelog ./vl.c ./vl.h hw/ide.c
CVSROOT:/cvsroot/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 05/04/30 16:10:35 Modified files: . : Changelog vl.c vl.h hw : ide.c Log message: Windows 2000 install disk full hack (original idea from Vladimir N. Oleynik) CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/Changelog.diff?tr1=1.89&tr2=1.90&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/vl.c.diff?tr1=1.126&tr2=1.127&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/vl.h.diff?tr1=1.73&tr2=1.74&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/hw/ide.c.diff?tr1=1.33&tr2=1.34&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Windows 2000 disk full problem during install...
Hi, I commited a patch to correct the Windows 2000 disk full problem based on Vladimir N. Oleynik idea. Use the option '-win2k-hack' when installing Windows 2000. The disk write speed will be slower but the disk full problem should disapear. Do not use this option after Windows is installed. Tell me if you see improvements. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi qemu-tech.texi
CVSROOT:/cvsroot/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 05/04/30 15:08:33 Modified files: . : qemu-doc.texi qemu-tech.texi Log message: typos CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.59&tr2=1.60&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/qemu-tech.texi.diff?tr1=1.5&tr2=1.6&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] target...
> if i want to use qemu to run, os2, beos, windows... under linux, i can't > use i386-user? No, you need i386-softmmu to run a whole virtual machine. If you use the CVS version of QEmu, you can also use the KQemu accelerator module to speed this up. If you wanted to (for instance) run i386 binaries on a PPC Linux host, you'd use i386-user to emulate the x86 Linux userspace without having to run a whole virtual i386 machine. Cheers, Mark ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: qemu for Solaris 10 / networking question
Hi, Bernd Schemmer wrote: http://user.it.uu.se/~jerker/qemu/MB1Xqemu0_6_0__i386_solaris9_usr_local.pkg.gz and installed it on Solaris 10 x86 - works very well except the network emulation. From the comments on http://www.solariscentral.org/article.php/20040907100827529 I'm not sure if network emulation is already included in that build. Is it? And if yes, how can I use it? on Solaris x86 2.8/2.9/2.10 based hosts, networking is functional now (many thanks to Juergen Keil !). Please wait just a few days: An updated QEMU package for Solaris hosts (x86 and SPARC [many thanks to Ph.D. student Dipl.Math Johannes Schindelin!]) is almost ready to be released as "CSWqemu" on www.blastwave.org . However - on SPARC hosts neworking won't work right now. -- Best regards, Martin Bochnig ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] target...
Le 1 Mai 2005 06:31, Paul Brook a écrit : > On Sunday 01 May 2005 05:58, Marc Collin wrote: > > hi > > > > when we do a ./configure for qemu > > > > there is: > > > > target list i386-user arm-user armeb-user sparc-user ppc-user > > i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu > > > > for a x86 machine, what is the best for performance? > > i386-user or i386-softmmu > > i386-user. > > These are two different things the -user emulation only emulates a linux > userspace. The -softmmu emulation emulates a complete system. > > Paul > > if i want to use qemu to run, os2, beos, windows... under linux, i can't use i386-user? -- www.laboiteaprog.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Some problems with QEmu on Windows
I got some help here a couple a days ago (thread "qemu.exe, qemumenu.bat and qemu-forum doesn't work"), and I promised to make some more testing and report the bugs I found. This is my report. The first and major problem when running qemu on windows is that you get no output at all. No error messages or helps at all. Everything just dies silently. Jernej Simonèiè's program help me patch qemu, so it work as it should do (older version didn't have this problem). I really hopes someone could fix this. A second problem is that GetNetworkParams is not supported in NT4. I think this is acceptable, but sense qemu didn't explain to me why nothing worked (cause of problem 1 :-) I got quite confused. Older versions of qemu hadn't that problem (0.5 I think). Using -nics 0 helped me. I have tested qemu 0.7 on Windows XP and Windows 98, and qemu 0.61 on Windows NT. Except from this I'm very thankful for qemu. It helps me testing my own programs on different Window version without tweaking my own computer. PEK ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [patch] Bug in arm saturating instructions
The patch below fixes a but in the arm saturating add/subtract instructions. We were writing the result back to the wrong register. Paul Index: target-arm/translate.c === RCS file: /cvsroot/qemu/qemu/target-arm/translate.c,v retrieving revision 1.24 diff -u -p -r1.24 translate.c --- target-arm/translate.c 27 Apr 2005 20:25:20 - 1.24 +++ target-arm/translate.c 1 May 2005 10:28:46 - @@ -1032,7 +1032,7 @@ static void disas_arm_insn(CPUState * en gen_op_subl_T0_T1_saturate(); else gen_op_addl_T0_T1_saturate(); -gen_movl_reg_T0(s, rn); +gen_movl_reg_T0(s, rd); break; case 0x8: /* signed multiply */ case 0xa: ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] target...
On Sunday 01 May 2005 05:58, Marc Collin wrote: > hi > > when we do a ./configure for qemu > > there is: > > target list i386-user arm-user armeb-user sparc-user ppc-user > i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu > > for a x86 machine, what is the best for performance? > i386-user or i386-softmmu i386-user. These are two different things the -user emulation only emulates a linux userspace. The -softmmu emulation emulates a complete system. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows XP Home on qemu 0.6.0 and Mac OS X 10.3.8
On 1 mai 05, at 06:24, Karl Magdsick wrote: http://fabrice.bellard.free.fr/qemu/kqemu-doc.html indicates kqemu is only for x86 Linux 2.4.x and Linux 2.6.x, not PPC Xnu 7.9.x. Qemu 0.6.0 might also be too old to take advantage of kqemu. If he used the installer from Free OS Zoo, this would seem to indicate he doesn't know which compile options were used. In any case, I would hope that if the kqemu options cause large overhad, they weren't turned on for a compilation targeted at both an architecture and kernel for which kqemu did not exist at the time of compiliation. Are you suggesting that his emulator is running slowly because it is repeatedly attempting and failing to use the accelerated kernel interface? The version martin uses is 0.6.0 Pierre ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
