[Qemu-devel] [PATCH] block: Prevent /dev/fd/X filename from being detected as floppy
From: Corey Bryant
Reported-by: Kevin Wolf
Signed-off-by: Corey Bryant
---
block/raw-posix.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index d8eff2f..68886cd 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -946,9 +946,11 @@ static int floppy_probe_device(const char *filename)
int prio = 0;
struct floppy_struct fdparam;
struct stat st;
+const char *p;
-if (strstart(filename, "/dev/fd", NULL))
+if (strstart(filename, "/dev/fd", &p) && p[0] != '/') {
prio = 50;
+}
fd = qemu_open(filename, O_RDONLY | O_NONBLOCK);
if (fd < 0) {
--
1.7.10.2
[Qemu-devel] [PATCH] target: hax: replace g_malloc with g_malloc0
From: Li Qiang
And also the g_malloc doesn't need check return value,
remove it.
Cc: qemu-triv...@nongnu.org
Signed-off-by: Li Qiang
---
target/i386/hax-all.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/target/i386/hax-all.c b/target/i386/hax-all.c
index d2e512856b..a460c605af 100644
--- a/target/i386/hax-all.c
+++ b/target/i386/hax-all.c
@@ -154,13 +154,7 @@ int hax_vcpu_create(int id)
return 0;
}
-vcpu = g_malloc(sizeof(struct hax_vcpu_state));
-if (!vcpu) {
-fprintf(stderr, "Failed to alloc vcpu state\n");
-return -ENOMEM;
-}
-
-memset(vcpu, 0, sizeof(struct hax_vcpu_state));
+vcpu = g_malloc0(sizeof(struct hax_vcpu_state));
ret = hax_host_create_vcpu(hax_global.vm->fd, id);
if (ret) {
@@ -250,11 +244,8 @@ struct hax_vm *hax_vm_create(struct hax_state *hax)
return hax->vm;
}
-vm = g_malloc(sizeof(struct hax_vm));
-if (!vm) {
-return NULL;
-}
-memset(vm, 0, sizeof(struct hax_vm));
+vm = g_malloc0(sizeof(struct hax_vm));
+
ret = hax_host_create_vm(hax, &vm_id);
if (ret) {
fprintf(stderr, "Failed to create vm %x\n", ret);
--
2.11.0
Re: [Qemu-devel] Switch to OpenBIOS for Sparc32/64?
Natalia Portillo wrote: > I propose the same for QEMU/PowerPC. It would be nice to some day be able to use QEMU to run classic Mac OS, now that Apple has discontinued the classic environment in OS X. Would switching to OpenBIOS negatively affect efforts in this direction? - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Switch to OpenBIOS for PowerPC? (was: Switch to OpenBIOS for Sparc32/64?)
Natalia Portillo wrote: > OpenBIOS is a far more complete OF implementation than Apple ones used > to load Mac OS <= 9. > Just it need to be able to read HFS partition, handle CUDA, ADB, other > devices, and, it will be able to run a Mac OS. OK, great. One small correction though: Mac OS since at least version 8.1 is perfectly happy without ADB as long as it has USB. I guess if we want to run older versions we still need ADB though. :) - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-i386 segfaults when running wine on a x86 CPU?
James Supancic wrote: > When I run > qemu-i386 /usr/bin/wine > I get > qemu: uncaught target signal 11 (Segmentation fault) - exiting > > I know I don't need qemu-i386 to run wine compiled for x86 CPUs on an > x86 CPU. I am trying to figure out how to make a version of wine that > will work with qemu-i386, after I figure this out I intend to move the > wine installation over to a sparc CPU. Qemu's user mode emulation only works for Linux -> Linux at the moment, i.e. programs compiled for Linux can be run on a Linux host. (The useful part is of course that programs compiled for a different CPU architecture than the host's can be run.) However, encouraging progress has been made on qemu-darwin-user, which will do what you want to do. See here: http://wiki.opendarwin.org/index.php/Darwine:qemu-darwin-user - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-i386 segfaults when running wine on a x86 CPU?
James Supancic wrote: > But, I am using a version of wine on Linux compiled for Linux? wine is a > Linux program is it not? Oops, I wasn't paying attention and thought your message was posted to darwine-devel. Sorry! - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] International Virtualization Conference
Jim C. Brown wrote: > On Sun, Oct 08, 2006 at 05:30:19AM -0700, Ottavio Caruso wrote: >> http://www.linuxworldexpo.de/linux_messe.php?ID=124&STEP=&lang=en >> >> I don't see Qemu mentioned at all. I wonder if any of the developers have >> been contacted at all. I thing it is a pity that once againg Qemu is ignored. >> > I suppose that qemu could get in by virtue of kqemu. That is closed source but > being closed source hasn't stopped VMware. Or Virtual PC. The conference looks rather like a marketing-fest. Every one of the sessions is pushing a particular company's products. - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] International Virtualization Conference
Rob Landley wrote: > On Sunday 08 October 2006 10:36 am, Jim C. Brown wrote: >> qemu is primarily a dynamic translator not a virtualizer. > > That's an implementation detail. The end result is running programs in a > virtual environment, and qemu's system emulation has lots of virtual hardware > it attaches to virtual busses, which it performs virtual I/O to, even > simulating the delivery of virtual interrupts to signal completion of virtual > DMA. Part of the generally accepted definition of virtualization is that the majority of guest instructions execute directly on the real CPU with no intervention by the VMM. QEMU + qvm86 does count as virtualization if the system spends most of its time in user mode; QEMU on its own does not (you run code that is very different to the original binary). - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Anyone knows why some mails get stuck at lists.gnu.org?
Oliver Gerlich wrote: > Hello, > > apparently today another load of delayed mails appeared on the > qemu-devel list... I have experienced this delay myself with some mails > I sent (OTOH the last mail I sent appeared after just 20 minutes). So I > wonder if anyone knows why some mails are delayed so much? Last I heard, Rusty was manually screening all posts from non-subscribers (to stop spam being posted). That could account for much of the delayed mail. - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Bounce message (was: loadvm and tap problem (perhaps a bug?!))
David Roberts wrote: > I'm getting exactly the same thing. I'm assuming this person no longer is > receving messages - perhaps they could be removed from the list (If any list > admins are reading this). > > On Tuesday 21 November 2006 10:04 pm, The Moon Seeker wrote: >> David Roberts a écrit : >>> Stop sending multiple messages - they are getting through. >> oups. >> >> i don't understand why I receive this message: (that's why I try to >> resent my mail...) >> >> This is an automatically generated Delivery Status Notification >> >> Delivery to the following recipient failed permanently: >> >> [EMAIL PROTECTED] >> [...] Looks to me like Google's mail server is misconfigured. These headers should ensure that bounces are delivered to the list software rather than the original sender: >> Sender: >> [EMAIL PROTECTED] >> Errors-To: >> [EMAIL PROTECTED] - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] X86_64 (AMD64) build segfaults
FWIW, there are similar problems with gcc 4 on ppc. Dyngen dies on _op_bsfl_T0_cc, because the blr is in the middle of the function. The only way I've found to get around this is to put -O0 in the CFLAGS in Makefile.target. I tried the various -fno-align-* options to no avail. In case anyone is curious, here is the code produced with -O2 and with -O0: [-O2] _op_bsfl_T0_cc: 252cor. r0,r24,r24 2530bne 0x2564 2534b 0x2558 2538srawi r0,r0,1 253caddir2,r2,0x1 2540andi. r9,r0,0x1 2544beq 0x2538 2548li r0,0x1 254cor r25,r2,r2 2550stw r0,0x2c(r27) 2554b 0x2560 2558li r0,_op_movl_A0_EAX 255cstw r0,0x2c(r27) 2560blr 2564andi. r2,r0,0x1 2568beq 0x2574 256cli r2,_op_movl_A0_EAX 2570b 0x2548 2574li r2,_op_movl_A0_EAX 2578b 0x2538 [-O0] _op_bsfl_T0_cc: 00012304stmwr30,0xfff8(r1) 00012308stwur1,0xffc0(r1) 0001230cor r30,r1,r1 00012310or r0,r24,r24 00012314stw r0,0x18(r30) 00012318lwz r0,0x18(r30) 0001231ccmpwi cr7,r0,_op_movl_A0_EAX 00012320beq cr7,0x12374 00012324li r0,_op_movl_A0_EAX 00012328stw r0,0x1c(r30) 0001232cb 0x12348 00012330lwz r2,0x1c(r30) 00012334addir0,r2,0x1 00012338stw r0,0x1c(r30) 0001233clwz r0,0x18(r30) 00012340srawi r0,r0,1 00012344stw r0,0x18(r30) 00012348lwz r0,0x18(r30) 0001234cxorir0,r0,0x1 00012350rlwinm r0,r0,0,31,31 00012354cmpwi cr7,r0,_op_movl_A0_EAX 00012358bne cr7,0x12330 0001235clwz r0,0x1c(r30) 00012360or r25,r0,r0 00012364or r2,r27,r27 00012368li r0,0x1 0001236cstw r0,0x2c(r2) 00012370b 0x12380 00012374or r2,r27,r27 00012378li r0,_op_movl_A0_EAX 0001237cstw r0,0x2c(r2) 00012380lwz r1,_op_movl_A0_EAX(r1) 00012384lmw r30,0xfff8(r1) 00012388blr Cheers, Josh On 22 apr 2005, at 17:41, [EMAIL PROTECTED] wrote: Hello Jonas, here is the output of the command you gave me for this function, does this help ? It helps in the sense that it confirms my suspicion, although I don't know why it creates such convoluted code. Maybe in order to have as small code as possible with at the same time as many aligned jump targets as possible. It's definitely not trivial to parse this, and even less trivial to rewrite it so it is usable for qemu's purposes (in this particular case, the retq could be replaced by a jmp, but you can't count on there being 4 padding bytes after each ret). You (or someone else) will have to find a way to force gcc 4.0 to put one ret (or jump) at the very end of the code it generates. If that's not possible, it will be quite hard to support gcc 4.0 in qemu... Jonas ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] news on the OS X cocoa port
On 21 Jul 2005, Natalia Portillo <[EMAIL PROTECTED]> wrote: El 21/07/2005, a las 18:33, Stealth Dave escribió: On Jul 21, 2005, at 6:46 AM, Hetz Ben Hamo wrote: On 7/21/05, Mike Kronenberg <[EMAIL PROTECTED]> wrote: Hetz Ben Hamo wrote: I'm thinking of a new way to store the images and saved VMs, too. Maybe we could make something like vpc: A package with the config, disk-images and saved VMs, located in ~/Documents/QEMU PCs/ Nice idea. I would recommend ~/Library/QEMU/PCs as an alternative. OS X tends to store all of its program specific configuration information in the Library folder, which separates it from actual Documents such as disk images, word processor files, images, etc. Just $0.02 from the Peanut Gallery! :) - Dave Yeah but the Library is a obscure place, and VirtualPC for example uses Documents with packages inside and I think that is an elegant way and also will help deal with old users. Also VPC uses XML for hardware description and should be easy to make a XML<->XML virtual machine converter, with along qemu-img will allow people to convert old VPC machines to QEMU ones (will be very useful for me). Besides which, you're not meant to go creating random folders at the top level of ~/Library/. If you have a single configuration file, it goes in ~/Library/Preferences/, or if you have a collection of things, you create a subfolder in ~/Library/Application Support/ and put them there. I would prefer ~/Documents/QEMU/ rather than ~/Library/Application Support/QEMU/ since the files stored there will not just be managed internally by the app; the user will know about them. Cheers, Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Re: no start on amd64 (was "Nothing happens")
At 17:25 +0200 2005-07-31, Rudi Lippert wrote: Looks like there really is an SDL problem. I'm not capable of writing a test program, but I tried sdlroids. It hangs in status S+ right after starting it. After I found out about this, I rebuilt libsdl (Gentoo package), but it didn't help. What's next? Perhaps you need to install a separate SDL development package to get the needed static libraries? I remember that being the solution to some Gentoo SDL problems which were discussed on this list in the past. - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Compile error on Mac OS X 10.3.9 (Panther) - CoreAudio
I'm trying to compile QEMU on Mac OS X 10.3.9, and I'm getting the following error message: /Users/stealthdave/Source/qemu/qemu/audio/coreaudio.c: In function `coreaudio_init_out': /Users/stealthdave/Source/qemu/qemu/audio/coreaudio.c:378: error: `freq' undeclared (first use in this function) Line 378 is coreaudio_logerr2 (status, typ, "Could not set samplerate %d\n", freq); I'm pretty sure it should say "as->freq" rather than just "freq". It compiled when I made that change anyway. ;) HTH, Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] support for Mac OS X default compiler
Does -fno-tree-ch works on PC ? Fabrice. Yes. According to the GCC docs[1], -ftree-ch is enabled by -O1 and above on all architectures. [1] http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Optimize-Options.html - Josh ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Adding device support in aarch64 virt board
Hi all,
I’d like to add I2C support for aarch64 virt board. So I modified hw/arm/virt.c
as follows.
1. Add [VIRT_I2C] = { 0x0910, 0x1000 } entry in base_memmap to
define a memory region
2. Use the following to emulate a I2C device
dev = sysbus_create_simple(TYPE_VERSATILE_I2C, vms->memmap[VIRT_I2C].base,
NULL);
i2c = (I2CBus *)qdev_get_child_bus(dev, "i2c");
i2c_slave_create_simple(i2c, "sii9022", 0x39);
1. Use the following to add device tree file entry
nodename = g_strdup_printf("/i2c@%" PRIx64, base);
qemu_fdt_add_subnode(vms->fdt, nodename);
qemu_fdt_setprop_string(vms->fdt, nodename, "compatible", "arm,versatile-i2c");
qemu_fdt_setprop_sized_cells(vms->fdt, nodename, "reg", 1, base, 1, size);
After modification, QEMU can compile successfully. However, when I run it
(qemu-system-aarch64 -M virt -m 2048 -cpu cortex-a53 -kernel ./Image -nographic
-hda rootfs.ext2 --append "root=/dev/vda"), I got the following error:
* qemu-system-aarch64: qemu-5.1.0/softmmu/memory.c:2388:
memory_region_add_subregion_common: Assertion `!subregion->container' failed
The assertion exists in qemu-5.1.0\softmmu\memory.c:
memory_region_add_subregion_common() and is triggered by dev =
sysbus_create_simple(TYPE_VERSATILE_I2C, vms->memmap[VIRT_I2C].base, NULL);. I
think it means I’m using a memory region that has been used. But I think the
memory region in base_memap I’ve chosen is available. Besides, the assertion
“subregion->container” is derived from dev = qdev_new(name) (located in
hw/core/sysbus.c), which I have no control over when calling
sysbus_create_simple(). Could someone tell me which part is wrong?
Any help is appreciated. Thanks in advance.
Regards,
Weiqi
Re: [Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups
Fair enough in itself, but if HPET is known to have problems with arguably the most popular OS family to use as a guest, why is it enabled by default? On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov wrote: > On Tue, Oct 01, 2013 at 09:34:06AM -, Ben A wrote: >> Apparently this bug's still alive and kicking. >> > And no plans to fix it. Do not use hpet with windows guests this buys > you nothing. > >> There's an obvious clock skew problem on Windows 7; in the Date & Time >> dialog, the clock jumps through seconds visibly too fast. >> >> I also found a case where HPET bugs are causing a real problem: Terraria >> (dedicated server) seems to be relying on (something that relies on) >> HPET, and QEMU doesn't get it right. The result is a goofy and >> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it >> makes killing anything tougher than a normal zombie basically >> impossible. >> >> -- >> You received this bug notification because you are a member of qemu- >> devel-ml, which is subscribed to QEMU. >> https://bugs.launchpad.net/bugs/599958 >> >> Title: >> Timedrift problems with Win7: hpet missing time drift fixups >> >> Status in QEMU: >> Confirmed >> >> Bug description: >> We've been finding timedrift issues witth Win7 under qemu-kvm on our >> daily testing >> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load FAIL1 Time >> drift too large after rest period: 38.63% >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL1 Time >> drift too large at iteration 1: 17.77 seconds >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration FAIL1 >> Time drift too large at iteration 2: 3.08 seconds >> >> Steps to reproduce: >> >> timedrift.with_load >> >> 1) Log into a guest. >> 2) Take a time reading from the guest and host. >> 3) Run load on the guest and host. >> 4) Take a second time reading. >> 5) Stop the load and rest for a while. >> 6) Take a third time reading. >> 7) If the drift immediately after load is higher than a user- >> specified value (in %), fail. >> If the drift after the rest period is higher than a user-specified >> value, >> fail. >> >> timedrift.with_migration >> >> 1) Log into a guest. >> 2) Take a time reading from the guest and host. >> 3) Migrate the guest. >> 4) Take a second time reading. >> 5) If the drift (in seconds) is higher than a user specified value, fail. >> >> timedrift.with_reboot >> >> 1) Log into a guest. >> 2) Take a time reading from the guest and host. >> 3) Reboot the guest. >> 4) Take a second time reading. >> 5) If the drift (in seconds) is higher than a user specified value, fail. >> >> This bug is to register those issues and keep an eye on them. >> >> Attached, some logs from the autotest tests executed on the guest >> >> To manage notifications about this bug go to: >> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions > > -- > Gleb.
Re: [Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups
Agh, I forgot reply all. Seems like something that should be changed, no? It would've saved me a lot of headache if there was a switch e.g. -optimize-for=[linux,winxp, win7,etc] that changed the defaults to be most accomodating to the specified OS as a guest. On Tue, Oct 1, 2013 at 11:33 AM, Gleb Natapov wrote: > On Tue, Oct 01, 2013 at 11:23:07AM -0500, Ben "Root" Anderson wrote: >> Fair enough in itself, but if HPET is known to have problems with >> arguably the most popular OS family to use as a guest, why is it >> enabled by default? >> > Arguably :) But QEMU defaults are arguably far from been optimal for any > guest. > >> On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov wrote: >> > On Tue, Oct 01, 2013 at 09:34:06AM -, Ben A wrote: >> >> Apparently this bug's still alive and kicking. >> >> >> > And no plans to fix it. Do not use hpet with windows guests this buys >> > you nothing. >> > >> >> There's an obvious clock skew problem on Windows 7; in the Date & Time >> >> dialog, the clock jumps through seconds visibly too fast. >> >> >> >> I also found a case where HPET bugs are causing a real problem: Terraria >> >> (dedicated server) seems to be relying on (something that relies on) >> >> HPET, and QEMU doesn't get it right. The result is a goofy and >> >> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it >> >> makes killing anything tougher than a normal zombie basically >> >> impossible. >> >> >> >> -- >> >> You received this bug notification because you are a member of qemu- >> >> devel-ml, which is subscribed to QEMU. >> >> https://bugs.launchpad.net/bugs/599958 >> >> >> >> Title: >> >> Timedrift problems with Win7: hpet missing time drift fixups >> >> >> >> Status in QEMU: >> >> Confirmed >> >> >> >> Bug description: >> >> We've been finding timedrift issues witth Win7 under qemu-kvm on our >> >> daily testing >> >> >> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load FAIL1 >> >> Time drift too large after rest period: 38.63% >> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL1 >> >> Time drift too large at iteration 1: 17.77 seconds >> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration FAIL1 >> >> Time drift too large at iteration 2: 3.08 seconds >> >> >> >> Steps to reproduce: >> >> >> >> timedrift.with_load >> >> >> >> 1) Log into a guest. >> >> 2) Take a time reading from the guest and host. >> >> 3) Run load on the guest and host. >> >> 4) Take a second time reading. >> >> 5) Stop the load and rest for a while. >> >> 6) Take a third time reading. >> >> 7) If the drift immediately after load is higher than a user- >> >> specified value (in %), fail. >> >> If the drift after the rest period is higher than a user-specified >> >> value, >> >> fail. >> >> >> >> timedrift.with_migration >> >> >> >> 1) Log into a guest. >> >> 2) Take a time reading from the guest and host. >> >> 3) Migrate the guest. >> >> 4) Take a second time reading. >> >> 5) If the drift (in seconds) is higher than a user specified value, >> >> fail. >> >> >> >> timedrift.with_reboot >> >> >> >> 1) Log into a guest. >> >> 2) Take a time reading from the guest and host. >> >> 3) Reboot the guest. >> >> 4) Take a second time reading. >> >> 5) If the drift (in seconds) is higher than a user specified value, >> >> fail. >> >> >> >> This bug is to register those issues and keep an eye on them. >> >> >> >> Attached, some logs from the autotest tests executed on the guest >> >> >> >> To manage notifications about this bug go to: >> >> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions >> > >> > -- >> > Gleb. > > -- > Gleb.
