Re: [Qemu-devel] peter-bochs with QEMU
Hi Peter, 2012/11/11 Peter Cheung > > Dear All Developers > My name is Peter Cheung, from Hong Kong, my debugger > http://peter-bochs.googlecode.com is riding on bochs, i tried to use it to > debug the linux kernel, but bochs runs too slowly. So I want to modify the > qemu-kvm (not qemu) to work with peter-bochs, so that I can debug linux > kernel using qemu-kvm. > I want to know the code-commit-process. If i developed/modified something > on qemu, how can i commit my code? Do I need to pass through some approval > process? or some UAT process? > > May I know which guys are response for this for qemu-kvm? Anyone can sbumit patches. After you have finished your patches, run "scripts/get_maintainer.pl your_patch_file" to get maintainers who should review your patches, then use git -send-email to send your patches to qemu-devel mailing list, with cc'ing to maintainers mentioned above. You should take a look at this guide: http://wiki.qemu.org/Contribute/SubmitAPatch > > > Thanks > from Peter (mcheun...@hotmail.com) -- Best Regards, Dunrong Huang
Re: [Qemu-devel] peter-bochs with QEMU
Thank youfrom Peter > Date: Sun, 11 Nov 2012 16:26:05 +0800 > From: riegama...@gmail.com > To: mcheun...@hotmail.com > CC: qemu-devel@nongnu.org > Subject: Re: [Qemu-devel] peter-bochs with QEMU > > Hi Peter, > > 2012/11/11 Peter Cheung > > > > Dear All Developers > > My name is Peter Cheung, from Hong Kong, my debugger > > http://peter-bochs.googlecode.com is riding on bochs, i tried to use it to > > debug the linux kernel, but bochs runs too slowly. So I want to modify the > > qemu-kvm (not qemu) to work with peter-bochs, so that I can debug linux > > kernel using qemu-kvm. > > I want to know the code-commit-process. If i developed/modified > > something on qemu, how can i commit my code? Do I need to pass through some > > approval process? or some UAT process? > > > > May I know which guys are response for this for qemu-kvm? > > Anyone can sbumit patches. > > After you have finished your patches, run "scripts/get_maintainer.pl > your_patch_file" to get > maintainers who should review your patches, then use git -send-email > to send your patches to > qemu-devel mailing list, with cc'ing to maintainers mentioned above. > > You should take a look at this guide: > http://wiki.qemu.org/Contribute/SubmitAPatch > > > > > > > Thanks > > from Peter (mcheun...@hotmail.com) > > > > > -- > Best Regards, > > Dunrong Huang >
Re: [Qemu-devel] [PATCH] MAINTAINERS: add Stefan Hajnoczi as block and virtio-blk co-maintainer
On Sat, Nov 10, 2012 at 12:24 AM, Paolo Bonzini wrote: > Il 09/11/2012 14:29, Stefan Hajnoczi ha scritto: >> Kevin has requested co-maintainership to give him more time to write >> code. We will alternate patch review duties on a weekly basis. >> >> Signed-off-by: Stefan Hajnoczi >> --- >> MAINTAINERS | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 8f5681f..2ede20d 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -553,6 +553,7 @@ T: git git://github.com/kvaneesh/QEMU.git >> >> virtio-blk >> M: Kevin Wolf >> +M: Stefan Hajnoczi >> S: Supported >> F: hw/virtio-blk* >> >> @@ -583,6 +584,7 @@ F: audio/ >> >> Block >> M: Kevin Wolf >> +M: Stefan Hajnoczi >> S: Supported >> F: block* >> F: block/ >> > > Congratulations! I think that should have been reply To: Kevin, "Congratulations on finding a sucker to help review block patches" ;-). Thanks though! Stefan
Re: [Qemu-devel] [PATCH] target-mips: Fix seg fault for LUI when MIPS_DEBUG_DISAS==1.
On Fri, Nov 09, 2012 at 07:40:51PM -0800, Eric Johnson wrote:
> The call to gen_logic_imm for OPC_LUI passes -1 for rs. This
> causes the MIPS_DEBUG statement to seg fault due to the deference
> of regnames[rs]. This patch fixes that.
>
> Signed-off-by: Eric Johnson
> ---
> target-mips/translate.c | 18 +++---
> 1 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/target-mips/translate.c b/target-mips/translate.c
> index 8175da0..aba6327 100644
> --- a/target-mips/translate.c
> +++ b/target-mips/translate.c
> @@ -2013,7 +2013,6 @@ static void gen_logic_imm(CPUMIPSState *env,
> DisasContext *ctx, uint32_t opc,
>int rt, int rs, int16_t imm)
> {
> target_ulong uimm;
> -const char *opn = "imm logic";
>
> if (rt == 0) {
> /* If no destination, treat it as a NOP. */
> @@ -2027,29 +2026,34 @@ static void gen_logic_imm(CPUMIPSState *env,
> DisasContext *ctx, uint32_t opc,
> tcg_gen_andi_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
> else
> tcg_gen_movi_tl(cpu_gpr[rt], 0);
> -opn = "andi";
> +MIPS_DEBUG("%s %s, %s, " TARGET_FMT_lx, "andi", regnames[rt],
> +regnames[rs], uimm);
> break;
> case OPC_ORI:
> if (rs != 0)
> tcg_gen_ori_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
> else
> tcg_gen_movi_tl(cpu_gpr[rt], uimm);
> -opn = "ori";
> +MIPS_DEBUG("%s %s, %s, " TARGET_FMT_lx, "ori", regnames[rt],
> +regnames[rs], uimm);
> break;
> case OPC_XORI:
> if (likely(rs != 0))
> tcg_gen_xori_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
> else
> tcg_gen_movi_tl(cpu_gpr[rt], uimm);
> -opn = "xori";
> +MIPS_DEBUG("%s %s, %s, " TARGET_FMT_lx, "xori", regnames[rt],
> +regnames[rs], uimm);
> break;
> case OPC_LUI:
> tcg_gen_movi_tl(cpu_gpr[rt], imm << 16);
> -opn = "lui";
> +MIPS_DEBUG("lui %s, " TARGET_FMT_lx, regnames[rt], uimm);
> +break;
> +
> +default:
> +MIPS_DEBUG("Unknown logical immediate opcode %08x", opc);
> break;
> }
> -(void)opn; /* avoid a compiler warning */
> -MIPS_DEBUG("%s %s, %s, " TARGET_FMT_lx, opn, regnames[rt], regnames[rs],
> uimm);
> }
>
> /* Set on less than with immediate operand */
Thanks, I applied this patch, with minor tweak: instead of using printf
%s to format the opcode name, I moved it to the string like it was
%already the case for LUI.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] 64-on-32 TCG broken
On Wed, Nov 07, 2012 at 05:26:58PM +0400, Kirill Batuzov wrote:
> > diff --git a/tcg/tcg.c b/tcg/tcg.c
> > index c3a7f19..1133438 100644
> > --- a/tcg/tcg.c
> > +++ b/tcg/tcg.c
> > @@ -1329,8 +1329,8 @@ static void tcg_liveness_analysis(TCGContext *s)
> > the low part. The result can be optimized to a simple
> > add or sub. This happens often for x86_64 guest when the
> > cpu mode is set to 32 bit. */
> > -if (dead_temps[args[1]]) {
> > -if (dead_temps[args[0]]) {
> > +if (dead_temps[args[1]] && !mem_temps[1]) {
> > +if (dead_temps[args[0]] && !mem_temps[0]) {
>
> This should be mem_temps[args[1]] and mem_temps[args[0]] I believe.
>
> > goto do_remove;
> > }
> > /* Create the single operation plus nop. */
> > @@ -1355,8 +1355,8 @@ static void tcg_liveness_analysis(TCGContext *s)
> > nb_iargs = 2;
> > nb_oargs = 2;
> > /* Likewise, test for the high part of the operation dead. */
> > -if (dead_temps[args[1]]) {
> > -if (dead_temps[args[0]]) {
> > +if (dead_temps[args[1]] && !mem_temps[1]) {
> > +if (dead_temps[args[0]] && !mem_temps[0]) {
>
> Same here.
>
> > goto do_remove;
> > }
> > gen_opc_buf[op_index] = op = INDEX_op_mul_i32;
>
> Looks like for x86_64 guest temp 0 is the env (always mem_temp), temp 1 -
> cc_op. As a result it can accidentally remove high part of operation
> when it is actually alive but will never optimize out whole operation
> even if its output is really dead.
>
> I've attached a small patch to fix this issue.
>
> I was not able to boot gentoo install CD (amd64) with current trunk.
> Boot process hangs soon after framebuffer initialization. With the patch
> it boots successfully. Command line to reproduce:
>
> qemu-system-x86_64 -cdrom install-amd64-minimal-20121013.iso
>
> --
> Kirill Batuzov
> From 33e1fc03934cebea8d32c98ea34961c80f05d94a Mon Sep 17 00:00:00 2001
> From: Kirill Batuzov
> Date: Wed, 7 Nov 2012 15:26:38 +0400
> Subject: [PATCH] tcg: properly check that op's output needs to be synced to
> memory
>
> Fix typo introduced in b3a1be87bac3a6aaa59bb88c1410f170dc9b22d5.
>
> Reported-by: Ruslan Savchenko
> Signed-off-by: Kirill Batuzov
> ---
> tcg/tcg.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tcg/tcg.c b/tcg/tcg.c
> index 42052db..35fba50 100644
> --- a/tcg/tcg.c
> +++ b/tcg/tcg.c
> @@ -1337,8 +1337,8 @@ static void tcg_liveness_analysis(TCGContext *s)
> the low part. The result can be optimized to a simple
> add or sub. This happens often for x86_64 guest when the
> cpu mode is set to 32 bit. */
> -if (dead_temps[args[1]] && !mem_temps[1]) {
> -if (dead_temps[args[0]] && !mem_temps[0]) {
> +if (dead_temps[args[1]] && !mem_temps[args[1]]) {
> +if (dead_temps[args[0]] && !mem_temps[args[0]]) {
> goto do_remove;
> }
> /* Create the single operation plus nop. */
> @@ -1363,8 +1363,8 @@ static void tcg_liveness_analysis(TCGContext *s)
> nb_iargs = 2;
> nb_oargs = 2;
> /* Likewise, test for the high part of the operation dead. */
> -if (dead_temps[args[1]] && !mem_temps[1]) {
> -if (dead_temps[args[0]] && !mem_temps[0]) {
> +if (dead_temps[args[1]] && !mem_temps[args[1]]) {
> +if (dead_temps[args[0]] && !mem_temps[args[0]]) {
> goto do_remove;
> }
> gen_opc_buf[op_index] = op = INDEX_op_mul_i32;
Thanks, applied.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] LSI boot hangs
Hello, I'm having a boot hanger with LSI 53C895 adapter with latest qemu (not KVM): hangs in "Searching bootorder for: /pci@i0cf8/*@3/*@0/*@0,0" b90600eed3c0efe5f3260853c873caf51c0677b1 is the first bad commit commit b90600eed3c0efe5f3260853c873caf51c0677b1 Author: Avi Kivity Date: Wed Oct 3 16:42:37 2012 +0200 dma: make dma access its own address space Instead of accessing the cpu address space, use an address space configured by the caller. Eventually all dma functionality will be folded into AddressSpace, but we have to start from something. Reviewed-by: Anthony Liguori Signed-off-by: Avi Kivity :100644 100644 433d8b21b344d7eaa8ffee840d2bc62eefb269fc 3f09dcb072c794d09a4dd0ce753307f121f67609 M dma-helpers.c :100644 100644 1a33603f2260cd2bbc5224790816c8fb037959e4 1bd6f4a65154d1bdcf5bd45cc8a797c89b6c2ca5 M dma.h :04 04 2690964eeda924b5738538e6725ac35a91ac56f7 07577f817d21a21d17645bda96c40b73fbccef87 M hw Any ideas how to fix it? Thank you. Ciao, Gerhard
[Qemu-devel] q35, usb-ehci1, and Mac OS X boot problems
Hi, I'm testing OS X on the q35 tree, and it seems to work quite nicely so far. However, with the addition of "usb-ehci1" in the latest round of updates, I've started experiencing hangs during OS X boot. First, what works: With the following command line (usb items on the last line): bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo \ -M q35 -L q35-seabios/out -monitor stdio \ -device isa-applesmc,osk="our..Inc" \ -kernel ./Chameleon_RC5_Trunk_Binaries_r668/i386/boot \ -netdev user,id=hub0port0 -device e1000,netdev=hub0port0,id=eth0 \ -device ide-drive,bus=ide.0,drive=MacHDD \ -drive id=MacHDD,if=none,snapshot=on,file=./mac_10.6.img \ -device ich9-usb-uhci1 -device usb-kbd -device usb-mouse I get a working OS X guest, with the following USB related bits in 'info qtree': ... dev: gmch-pcihost, id "" MCFG = 2952790016 irq 0 bus: pcie.0 type PCI dev: ich9-usb-uhci1, id "" masterbus = firstport = 0 bandwidth = 1280 addr = 03.0 romfile = rombar = 1 multifunction = off command_serr_enable = on class USB controller, addr 00:03.0, pci id 8086:2934 (sub 1af4:1100) bar 4: i/o at 0xc040 [0xc05f] bus: usb-bus.0 type usb-bus dev: usb-hub, id "" port = full-path = on addr 0.3, port 2, speed 12, name QEMU USB Hub, attached dev: usb-mouse, id "" port = full-path = on addr 0.4, port 2.1, speed 12, name QEMU USB Mouse, attached dev: usb-kbd, id "" port = full-path = on addr 0.2, port 1, speed 12, name QEMU USB Keyboard, attached ... If I replace: -device ich9-usb-uhci1 -device usb-kbd -device usb-mouse with the generic default: -usb -device usb-kbd -device usb-mouse I get a hang at boot time. OS X (SnowLeopard) prints the following USB-related warning/error to its console: USBF: 2.557 AppleUSBEHCI[0xff80056c5000]::CheckSleepCapability - controller will be unloaded across sleep The following USB bits show up in 'info qtree': ... dev: gmch-pcihost, id "" MCFG = 2952790016 irq 0 bus: pcie.0 type PCI ... dev: ich9-usb-uhci3, id "" masterbus = "usb-bus.0" firstport = 4 bandwidth = 1280 addr = 1d.2 romfile = rombar = 1 multifunction = on command_serr_enable = on class USB controller, addr 00:1d.2, pci id 8086:2936 (sub 1af4:1100) bar 4: i/o at 0xc080 [0xc09f] dev: ich9-usb-uhci2, id "" masterbus = "usb-bus.0" firstport = 2 bandwidth = 1280 addr = 1d.1 romfile = rombar = 1 multifunction = on command_serr_enable = on class USB controller, addr 00:1d.1, pci id 8086:2935 (sub 1af4:1100) bar 4: i/o at 0xc060 [0xc07f] dev: ich9-usb-uhci1, id "" masterbus = "usb-bus.0" firstport = 0 bandwidth = 1280 addr = 1d.0 romfile = rombar = 1 multifunction = on command_serr_enable = on class USB controller, addr 00:1d.0, pci id 8086:2934 (sub 1af4:1100) bar 4: i/o at 0xc040 [0xc05f] dev: ich9-usb-ehci1, id "" maxframes = 128 addr = 1d.7 romfile = rombar = 1 multifunction = on command_serr_enable = on class USB controller, addr 00:1d.7, pci id 8086:293a (sub 1af4:1100) bar 0: mem at 0xfebf1000 [0xfebf1fff] bus: usb-bus.0 type usb-bus dev: usb-mouse, id "" port = full-path = on addr 0.0, port 2, speed 12, name QEMU USB Mouse, attached dev: usb-kbd, id "" port = full-path = on addr 0.0, port 1, speed 12, name QEMU USB Keyboard, attached Note how both the keyboard and mouse are now under 'ehci1', rather than under one of the 'uhci' entries, e.g. uhci1 like in the working example earlier on. When I try to start with ehci1 only, with the following USB command line items: -device ich9-usb-ehci1 -device usb-kbd -device usb-mouse I get an error from qemu: speed mismatch trying to attach usb device QEMU USB Keyboard to bus usb-bus.0 The simple presence of EHCI1 as configured by "-device ich9-usb-ehci1" will prevent OS X from booting (with the above-mentioned "controller will be unloaded across sleep" warning). If added all by itself, it looks like this in qtree: ... dev: gmch-pcihost, id "" MCFG = 2952790016 irq 0 bus: pcie.0 type PCI dev: ich9-usb-ehci1, id "" maxframes = 128 addr = 03.0 romfile = rombar = 1 multifunction = off command_serr_enable = on class USB controller, addr 00:03.0, pci id 8086:293a (sub 1af4:1100) bar 0: mem at 0xfebf1000 [0xfebf1fff] bus: usb-bus.0
Re: [Qemu-devel] [PATCH 1/2] qemu-ga: execute script to quiesce the guest on fsfreeze-freeze/thaw
Hi Eric, thanks for your review.
On 2012/11/09 3:38, Eric Blake wrote:
> On 11/08/2012 05:05 AM, Tomoki Sekiyama wrote:
>
> [Recoding to UTF-8, as ISO-2022-JP is not universally installed these
> days - you may want to reconsider your mailer's defaults]
Now this should be UTF-8, sorry.
>> To use the online disk snapshot for online-backup, application-level
>> consistency of the snapshot image is required. However, currently the
>> guest agent can provide only filesystem-level consistency, and the
>> snapshot may contain dirty data, for example, incomplete transactions.
>> This patch provides the opportunity to quiesce applications before
>> snapshot is taken.
>>
>> When the qemu-ga receives fsfreeze-freeze command, the script specified
>> in --fsfreeze-script option is executed with "freeze" argument before the
>> filesystem is frozen. For fsfreeze-thaw command, the script is executed
>> with "thaw" argument after the filesystem is thawed.
>>
>> Signed-off-by: Tomoki Sekiyama
>> ---
>
>> @@ -396,6 +397,34 @@ GuestFsfreezeStatus qmp_guest_fsfreeze_status(Error
>> **err)
>> return GUEST_FSFREEZE_STATUS_THAWED;
>> }
>>
>> +int execute_fsfreeze_script(const char *arg)
>> +{
>> +int ret = -1;
>> +const char *fsfreeze_script;
>> +char *cmdline;
>> +struct stat st;
>> +
>> +fsfreeze_script = ga_fsfreeze_script(ga_state);
>> +if (fsfreeze_script && stat(fsfreeze_script, &st) == 0) {
>> +if (S_ISREG(st.st_mode) && (st.st_mode & S_IXUSR)) {
>
> Is it any simpler to use access(fsfreeze_script, X_OK) to check if the
> script exists and is executable?
OK, I will use access() here.
>> +ret = system(cmdline);
>
> ...system() is not required to be thread-safe, but we should assume that
> qemu-ga is multi-threaded, and therefore we should not use system.
> Besides executing things via an extra layer of shell opens doors for
> further problems; for example, if the user starts qemu-ga with
> --fsfreeze-script '/path/with spaces/script', your command line is
> horribly broken when passed through the shell. It would be much better
> to directly fork() and exec() the script ourselves instead of relying on
> system().
I will use fork()/exec() method instead of system(), as in shutdown,
so I can remove malloc/free.
>> +if (ret > 0) {
>> +g_warning("fsfreeze script failed with status=%d", ret);
>
> This is a potentially misleading message; you should be using macros
> such as WEXITSTATUS when interpreting the result of system(), since not
> all systems return exit status 1 in the same bit position.
OK. I will refine error messages.
> The idea of having the freeze and thaw actions hook out to
> user-specified actions for additional steps seems nice, but this patch
> series needs a lot more work.
Regards,
--
Tomoki Sekiyama
Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
Re: [Qemu-devel] [PATCH 2/2] qemu-ga: sample fsfreeze-script
On 2012/11/09 3:25, Eric Blake wrote:
> On 11/08/2012 05:36 AM, Tomoki Sekiyama wrote:
>> Adds sample scripts for --fsfreeze-script option of qemu-ga.
>> -fsfreeze.sh: iterates and execute scripts in fsfreeze.d/
>> -fsfreeze.d/mysql-flush.sh: quiesce MySQL before snapshot
>>
>> Signed-off-by: Tomoki Sekiyama
>> ---
>> +++ b/docs/qemu-guest-agent/fsfreeze-script-sample/fsfreeze.d/mysql-flush.sh
>> @@ -0,0 +1,41 @@
>> +#!/bin/bash
>
> Any particular reason you have to use a bash-ism, or would it be
> appropriate to use /bin/sh here?
No, I will just replace this to /bin/sh.
>> +MYSQL="mysql -uroot" #"-prootpassword"
>> +FIFO=/tmp/mysql-flush.fifo
>> +
>> +flush_and_wait() {
>> +echo 'FLUSH TABLES WITH READ LOCK \G'
>> +read < $FIFO
>> +echo 'UNLOCK TABLES \G'
>> +}
>> +
>> +if [ "$1" = "freeze" ]; then
>> +
>> +mkfifo $FIFO
>
> No error checking?
I will add the check.
>> +flush_and_wait | $MYSQL &
>> +# wait until every block is flushed
>> +while [ "`echo 'SHOW STATUS LIKE "Key_blocks_not_flushed"' |\
>
> I prefer $() over ``
OK, will replace `` by $().
>> +$MYSQL | tail -1 | cut -f 2`" -gt 0 ]; do
>> +sleep 1
>> +done
>> +# for InnoDB, wait until every log is flushed
>> +while :; do
>> +INNODB_STATUS=/tmp/mysql-innodb.status
>
> This name is highly predictable, and therefore highly insecure. I hope
> I'm never caught installing something this insecure on my system.
Usually this doesn't contain critical data, but I will use mktemp to
randomize the filename and to make this only accessible from the qemu-ga user.
>> +echo 'SHOW ENGINE INNODB STATUS \G' | $MYSQL > $INNODB_STATUS
>> +LOG_CURRENT=`grep 'Log sequence number' $INNODB_STATUS |\
>> +tr -s " " | cut -d' ' -f4`
>> +LOG_FLUSHED=`grep 'Log flushed up to' $INNODB_STATUS |\
>> +tr -s " " | cut -d' ' -f5`
>
> More instances where $() is nicer than ``
OK.
>> +rm $INNODB_STATUS
>> +[ $LOG_CURRENT = $LOG_FLUSHED ] && break
>
> Are you sure that $LOG_CURRENT and $LOG_FLUSHED will always be non-empty
> and contain no whitespace? If not, you are missing quoting here.
I will add quotes, just to make it robust.
>> diff --git a/docs/qemu-guest-agent/fsfreeze-script-sample/fsfreeze.sh
>> b/docs/qemu-guest-agent/fsfreeze-script-sample/fsfreeze.sh
>> new file mode 100755
>> index 000..b402107
>> --- /dev/null
>> +++ b/docs/qemu-guest-agent/fsfreeze-script-sample/fsfreeze.sh
>> @@ -0,0 +1,17 @@
>> +#!/bin/bash
>
> Again, I see no bash-isms, why not use /bin/sh.
I will use /bin/sh here too.
>> +cd `dirname $0`
>> +cd fsfreeze.d
>
> Unsafe if $0 contains spaces or starts with '-'. Although you could
> argue that either of those situations represents installation error, it
> never hurts to be robust. Also, why bother with two cd when one would
> do, and where is your error checking?
OK, I will add quotes and -- to be make it safer and use full path below.
>> +for x in *; do
>> +[ -x ./$x ] && ./$x $1
>
> Should you be filtering out files such as *~ or *.bak or ~.rpmsave, and
> so forth? This is insecure if $x contains spaces. And rather than
> unquoted $1, it is better to pass "$@", as in:
>
> [ -x "$x" ] && "./$x" "$@"
I will add quotes and checking for files to be ignored.
>> +done
Again, thank you for your detailed review.
I will fix the issues and send new patchset soon.
Regards,
--
Tomoki Sekiyama
Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
Re: [Qemu-devel] [RFC v1 2/3] ramlist: apply fine grain lock for ram_list
On Sat, Nov 10, 2012 at 9:54 AM, Paolo Bonzini wrote:
> Il 09/11/2012 04:14, Liu Ping Fan ha scritto:
>> From: Liu Ping Fan
>>
>> Signed-off-by: Liu Ping Fan
>> ---
>> cpu-all.h |1 +
>> exec.c| 46 +++---
>> 2 files changed, 40 insertions(+), 7 deletions(-)
>
> The problem here is that the ram_list is a pretty critical bit for TCG.
>
This patch does not touch the MRU, so you mean the expense of lock? If
it is, I think, we can define empty lock ops for TCG, and later, when
we adopt urcu, we can come back to fix the TCG problem.
> The migration thread series has patches that split the list in two: a
> MRU-accessed list that uses the BQL, and another that uses a separate lock.
>
I read the thread, but I think we can not protect RAMBlock w/o a
unified lock. When ram device's refcnt->0, and call
qemu_ram_free_from_ptr(), it can be with/without QBL. So we need to
sync the two lists: ->blocks and ->blocks_mru on the same lock,
otherwise, a destroyed RAMBlock will be exposed.
Thanks and regards,
Pingfan
> address_space_map could use the latter list. In order to improve
> performance further, we could sort the list from the biggest to the
> smallest region, like KVM does in the kernel.
>
> Paolo
>
>> diff --git a/cpu-all.h b/cpu-all.h
>> index 6aa7e58..d3ead99 100644
>> --- a/cpu-all.h
>> +++ b/cpu-all.h
>> @@ -498,6 +498,7 @@ typedef struct RAMBlock {
>> } RAMBlock;
>>
>> typedef struct RAMList {
>> +QemuMutex lock;
>> uint8_t *phys_dirty;
>> QLIST_HEAD(, RAMBlock) blocks;
>> } RAMList;
>> diff --git a/exec.c b/exec.c
>> index fe84718..e5f1c0f 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -2444,6 +2444,7 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
>> if (QLIST_EMPTY(&ram_list.blocks))
>> return 0;
>>
>> +qemu_mutex_lock(&ram_list.lock);
>> QLIST_FOREACH(block, &ram_list.blocks, next) {
>> ram_addr_t end, next = RAM_ADDR_MAX;
>>
>> @@ -2459,6 +2460,7 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
>> mingap = next - end;
>> }
>> }
>> +qemu_mutex_unlock(&ram_list.lock);
>>
>> if (offset == RAM_ADDR_MAX) {
>> fprintf(stderr, "Failed to find gap of requested size: %" PRIu64
>> "\n",
>> @@ -2474,8 +2476,10 @@ ram_addr_t last_ram_offset(void)
>> RAMBlock *block;
>> ram_addr_t last = 0;
>>
>> +qemu_mutex_lock(&ram_list.lock);
>> QLIST_FOREACH(block, &ram_list.blocks, next)
>> last = MAX(last, block->offset + block->length);
>> +qemu_mutex_unlock(&ram_list.lock);
>>
>> return last;
>> }
>> @@ -2503,6 +2507,7 @@ void qemu_ram_set_idstr(ram_addr_t addr, const char
>> *name, DeviceState *dev)
>> RAMBlock *new_block, *block;
>>
>> new_block = NULL;
>> +qemu_mutex_lock(&ram_list.lock);
>> QLIST_FOREACH(block, &ram_list.blocks, next) {
>> if (block->offset == addr) {
>> new_block = block;
>> @@ -2528,6 +2533,7 @@ void qemu_ram_set_idstr(ram_addr_t addr, const char
>> *name, DeviceState *dev)
>> abort();
>> }
>> }
>> +qemu_mutex_unlock(&ram_list.lock);
>> }
>>
>> static int memory_try_enable_merging(void *addr, size_t len)
>> @@ -2582,12 +2588,6 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
>> void *host,
>> }
>> new_block->length = size;
>>
>> -QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next);
>> -
>> -ram_list.phys_dirty = g_realloc(ram_list.phys_dirty,
>> - last_ram_offset() >>
>> TARGET_PAGE_BITS);
>> -memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
>> - 0, size >> TARGET_PAGE_BITS);
>> cpu_physical_memory_set_dirty_range(new_block->offset, size, 0xff);
>>
>> qemu_ram_setup_dump(new_block->host, size);
>> @@ -2596,6 +2596,15 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
>> void *host,
>> if (kvm_enabled())
>> kvm_setup_guest_memory(new_block->host, size);
>>
>> +qemu_mutex_lock(&ram_list.lock);
>> +QLIST_INSERT_HEAD(&ram_list.blocks, new_block, next);
>> +
>> +ram_list.phys_dirty = g_realloc(ram_list.phys_dirty,
>> + last_ram_offset() >>
>> TARGET_PAGE_BITS);
>> +memset(ram_list.phys_dirty + (new_block->offset >> TARGET_PAGE_BITS),
>> + 0, size >> TARGET_PAGE_BITS);
>> +qemu_mutex_unlock(&ram_list.lock);
>> +
>> return new_block->offset;
>> }
>>
>> @@ -2608,19 +2617,23 @@ void qemu_ram_free_from_ptr(ram_addr_t addr)
>> {
>> RAMBlock *block;
>>
>> +qemu_mutex_lock(&ram_list.lock);
>> QLIST_FOREACH(block, &ram_list.blocks, next) {
>> if (addr == block->offset) {
>> QLIST_REMOVE(block, next);
>> g_free(block);
>> +qemu_mutex_unlock(&ram_list.lock);
>> return;
>> }
>> }
>> +qemu_mutex_unlock(&ram_list.lock);
>> }
>>
>> void qemu_ram_free(ram_addr
Re: [Qemu-devel] [RFC v1 1/3] bouce buffer has fine grain lock
On Sat, Nov 10, 2012 at 9:49 AM, Paolo Bonzini wrote:
> Il 09/11/2012 04:14, Liu Ping Fan ha scritto:
>> From: Liu Ping Fan
>>
>> Signed-off-by: Liu Ping Fan
>> ---
>> exec.c | 21 +
>> 1 files changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/exec.c b/exec.c
>> index 73d5242..fe84718 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -3296,6 +3296,15 @@ void address_space_destroy_dispatch(AddressSpace *as)
>> as->dispatch = NULL;
>> }
>>
>> +typedef struct {
>> +QemuMutex lock;
>> +void *buffer;
>> +target_phys_addr_t addr;
>> +target_phys_addr_t len;
>> +} BounceBuffer;
>> +
>> +static BounceBuffer bounce;
>> +
>> static void memory_map_init(void)
>> {
>> system_memory = g_malloc(sizeof(*system_memory));
>> @@ -3308,6 +3317,8 @@ static void memory_map_init(void)
>> address_space_init(&address_space_io, system_io);
>> address_space_io.name = "I/O";
>>
>> +qemu_mutex_init(&bounce.lock);
>> +
>> memory_listener_register(&core_memory_listener, &address_space_memory);
>> memory_listener_register(&io_memory_listener, &address_space_io);
>> memory_listener_register(&tcg_memory_listener, &address_space_memory);
>> @@ -3671,14 +3682,6 @@ void cpu_physical_memory_write_rom(target_phys_addr_t
>> addr,
>> }
>> }
>>
>> -typedef struct {
>> -void *buffer;
>> -target_phys_addr_t addr;
>> -target_phys_addr_t len;
>> -} BounceBuffer;
>> -
>> -static BounceBuffer bounce;
>> -
>> typedef struct MapClient {
>> void *opaque;
>> void (*callback)(void *opaque);
>> @@ -3747,6 +3750,7 @@ void *address_space_map(AddressSpace *as,
>> section = &mr_obj;
>>
>> if (!(memory_region_is_ram(section->mr) && !section->readonly)) {
>> +qemu_mutex_lock(&bounce.lock);
>> if (todo || bounce.buffer) {
>> break;
>> }
>
> "todo" must be checked before the if.
>
Applied, thanks.
> Also, you do not need to keep the lock after address_space_map exits.
> In fact, it can be released as soon as bounce.buffer is written to.
> After that point, bounce will not be touched (the lock only serves to
> serialize writes to bounce.buffer). That is,
>
But w/o the lock, the content in bounce.buffer for threadA, can be
flushed with thread B.
> if (todo) {
> break;
> }
> qemu_mutex_lock(&bounce.lock);
> if (bounce.buffer) {
> qemu_mutex_unlock(&bounce.lock);
> break;
> }
> bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, TARGET_PAGE_SIZE);
> qemu_mutex_unlock(&bounce.lock);
>
As above.
Regards,
Pingfan
>
> Of course, this must be documented.
>
> Paolo
>
>> @@ -3807,6 +3811,7 @@ void address_space_unmap(AddressSpace *as, void
>> *buffer, target_phys_addr_t len,
>> }
>> qemu_vfree(bounce.buffer);
>> bounce.buffer = NULL;
>> +qemu_mutex_unlock(&bounce.lock);
>> cpu_notify_map_clients();
>> }
>>
>>
>
[Qemu-devel] [PATCH] tap: reset vnet header size on open
For tap, we currently assume the vnet header size is 10
(the default value) but that might not be the case
if tap is persistent and has been used by qemu previously.
To fix, set vnet header size correctly on open.
Signed-off-by: Michael S. Tsirkin
---
This fixes the issue reported by Alexander Graf on the kvm forum.
Alexander, could you confirm please?
Thanks,
net/tap-linux.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/tap-linux.c b/net/tap-linux.c
index c6521be..3eaedc4 100644
--- a/net/tap-linux.c
+++ b/net/tap-linux.c
@@ -39,6 +39,7 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
int vnet_hdr_required
{
struct ifreq ifr;
int fd, ret;
+int len = sizeof(struct virtio_net_hdr);
TFR(fd = open(PATH_NET_TUN, O_RDWR));
if (fd < 0) {
@@ -65,6 +66,13 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
int vnet_hdr_required
close(fd);
return -1;
}
+/*
+ * Make sure vnet header size has the default value: for a persistent
+ * tap it might have been modified e.g. by another instance of qemu.
+ * Ignore errors since old kernels do not support this ioctl: in this
+ * case the header size implicitly has the correct value.
+ */
+ioctl(fd, TUNSETVNETHDRSZ, &len);
}
if (ifname[0] != '\0')
--
MST
[Qemu-devel] [Bug 1033727] Re: USB passthrough doesn't work anymore with qemu-kvm 1.1.1
Just an FYI for people that come across this bug: not all USB devices are affected. USB passthrough is working for me with a Logitech C920 webcam in Ubuntu 12.10 (qemu-kvm 1.2.0), albeit with some video freezing. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1033727 Title: USB passthrough doesn't work anymore with qemu-kvm 1.1.1 Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: New Status in “qemu-kvm” package in Debian: Confirmed Bug description: Hi, I have a "Bus 006 Device 002: ID 0d46:3003 Kobil Systems GmbH mIDentity Light / KAAN SIM III" (kind of smart card) in an USB port which I make available to a Windows XP guest. This worked fine with every older qemu-kvm version I've used so far. But since 1.1.0 it doesn't work anymore. The device shows up in the guest, but the software can't access it anymore (and the guest is pretty unresponsive). On the host I get every 2 seconds this message: [ 7719.239528] usb 6-1: reset full-speed USB device number 2 using uhci_hcd Command line options are: /usr/bin/kvm ... -device usb-host,vendorid=0x0d46,productid=0x3003,bus=usb.0,port=3 ... When I switch back to qemu-kvm 1.0.1 everything works fine again. Any idea what the problem could be? Thanks Klaus To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1033727/+subscriptions
[Qemu-devel] [Bug 1077708] Re: Video capture from webcam with USB passthrough freezes
Does not seem to repro when using the webcam natively in the host with Google+ Hangouts. Does not seem to repro when using the webcam natively on a Windows Vista 32-bit machine with Google+ Hangouts. I'd be happy to do some debugging. Are there extra log messages that I should enable? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1077708 Title: Video capture from webcam with USB passthrough freezes Status in QEMU: New Bug description: QEMU version: 1.2.0 Graphics: Spice Guest: Windows 7 32-bit Host: Ubuntu 12.10 amd64 (using distro package qemu-kvm-spice) I am using USB 2.0 passthrough of a Logitech C920 webcam. The guest is running the proprietary Logitech drivers. When video chatting with either Google+ Hangouts or Skype 3.8.0.115, video capture from the webcam is initially fine but eventually freezes. It remains frozen for up to several minutes and then resumes on its own. The process then repeats. Audio recorded from the webcam's mic works continuously. The problem also affects video recording in Logitech's bundled software. Strangely though, the live preview is _not_ affected. The freezing is only present in the recorded video file. I can tell that the problem is not introduced by Spice during playback, because the user on the other end of Hangouts/Skype sees the same problem, and the freezes in a recorded video file are seen at the same point every time the file is played. Command line: /usr/bin/kvm-spice -name Windows7 -S -M pc-1.0 -enable-kvm -m 2048 -smp 3,sockets=3,cores=1,threads=1 -uuid cfcc7e85-7873-1c32-0a00-d1c35f3eb073 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb- uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb- uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9 -usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/data/libvirt/images/Windows7.img,if=none,id=drive- ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive- ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive- ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive =drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:0b:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda- duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb- host,hostbus=2,hostaddr=8,id=hostdev0 -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1077708/+subscriptions
[Qemu-devel] [Bug 1077708] [NEW] Video capture from webcam with USB passthrough freezes
Public bug reported: QEMU version: 1.2.0 Graphics: Spice Guest: Windows 7 32-bit Host: Ubuntu 12.10 amd64 (using distro package qemu-kvm-spice) I am using USB 2.0 passthrough of a Logitech C920 webcam. The guest is running the proprietary Logitech drivers. When video chatting with either Google+ Hangouts or Skype 3.8.0.115, video capture from the webcam is initially fine but eventually freezes. It remains frozen for up to several minutes and then resumes on its own. The process then repeats. Audio recorded from the webcam's mic works continuously. The problem also affects video recording in Logitech's bundled software. Strangely though, the live preview is _not_ affected. The freezing is only present in the recorded video file. I can tell that the problem is not introduced by Spice during playback, because the user on the other end of Hangouts/Skype sees the same problem, and the freezes in a recorded video file are seen at the same point every time the file is played. Command line: /usr/bin/kvm-spice -name Windows7 -S -M pc-1.0 -enable-kvm -m 2048 -smp 3,sockets=3,cores=1,threads=1 -uuid cfcc7e85-7873-1c32-0a00-d1c35f3eb073 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb- uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb- uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9 -usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/data/libvirt/images/Windows7.img,if=none,id=drive- ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive- ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive- ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive =drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:0b:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda- duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb- host,hostbus=2,hostaddr=8,id=hostdev0 -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x5 ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1077708 Title: Video capture from webcam with USB passthrough freezes Status in QEMU: New Bug description: QEMU version: 1.2.0 Graphics: Spice Guest: Windows 7 32-bit Host: Ubuntu 12.10 amd64 (using distro package qemu-kvm-spice) I am using USB 2.0 passthrough of a Logitech C920 webcam. The guest is running the proprietary Logitech drivers. When video chatting with either Google+ Hangouts or Skype 3.8.0.115, video capture from the webcam is initially fine but eventually freezes. It remains frozen for up to several minutes and then resumes on its own. The process then repeats. Audio recorded from the webcam's mic works continuously. The problem also affects video recording in Logitech's bundled software. Strangely though, the live preview is _not_ affected. The freezing is only present in the recorded video file. I can tell that the problem is not introduced by Spice during playback, because the user on the other end of Hangouts/Skype sees the same problem, and the freezes in a recorded video file are seen at the same point every time the file is played. Command line: /usr/bin/kvm-spice -name Windows7 -S -M pc-1.0 -enable-kvm -m 2048 -smp 3,sockets=3,cores=1,threads=1 -uuid cfcc7e85-7873-1c32-0a00-d1c35f3eb073 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb- uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb- uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9 -usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/data/libvirt/images/Windows7.img,if=none,id=drive- ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive- ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive- ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive =drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:0b:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga std
[Qemu-devel] [Bug 1077708] Re: Video capture from webcam with USB passthrough freezes
The problem also occurs with the generic Microsoft webcam drivers. Note that, during webcam use, these messages are output from QEMU sporadically: USBDEVFS_DISCARDURB: Invalid argument USBDEVFS_DISCARDURB: Invalid argument husb: leaking iso urbs because of discard failure USBDEVFS_DISCARDURB: Invalid argument USBDEVFS_DISCARDURB: Invalid argument husb: leaking iso urbs because of discard failure USBDEVFS_DISCARDURB: Invalid argument USBDEVFS_DISCARDURB: Invalid argument husb: leaking iso urbs because of discard failure USBDEVFS_DISCARDURB: Invalid argument USBDEVFS_DISCARDURB: Invalid argument USBDEVFS_DISCARDURB: Invalid argument husb: leaking iso urbs because of discard failure However, the timing of the messages is completely uncorrelated with the video freezes, so I am uncertain as to whether they are related or not. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1077708 Title: Video capture from webcam with USB passthrough freezes Status in QEMU: New Bug description: QEMU version: 1.2.0 Graphics: Spice Guest: Windows 7 32-bit Host: Ubuntu 12.10 amd64 (using distro package qemu-kvm-spice) I am using USB 2.0 passthrough of a Logitech C920 webcam. The guest is running the proprietary Logitech drivers. When video chatting with either Google+ Hangouts or Skype 3.8.0.115, video capture from the webcam is initially fine but eventually freezes. It remains frozen for up to several minutes and then resumes on its own. The process then repeats. Audio recorded from the webcam's mic works continuously. The problem also affects video recording in Logitech's bundled software. Strangely though, the live preview is _not_ affected. The freezing is only present in the recorded video file. I can tell that the problem is not introduced by Spice during playback, because the user on the other end of Hangouts/Skype sees the same problem, and the freezes in a recorded video file are seen at the same point every time the file is played. Command line: /usr/bin/kvm-spice -name Windows7 -S -M pc-1.0 -enable-kvm -m 2048 -smp 3,sockets=3,cores=1,threads=1 -uuid cfcc7e85-7873-1c32-0a00-d1c35f3eb073 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb- uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb- uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9 -usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/data/libvirt/images/Windows7.img,if=none,id=drive- ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive- ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive- ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive =drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:0b:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda- duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb- host,hostbus=2,hostaddr=8,id=hostdev0 -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1077708/+subscriptions
[Qemu-devel] [PATCH] slirp: Don't crash on packets from 0.0.0.0/8.
LWIP can generate packets with a source of 0.0.0.0, which triggers an
assertion failure in arp_table_add(). Instead of crashing, simply return
to avoid adding an invalid ARP table entry.
Signed-off-by: Nickolai Zeldovich
---
slirp/arp_table.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/slirp/arp_table.c b/slirp/arp_table.c
index 5d7b8ac..3318ce9 100644
--- a/slirp/arp_table.c
+++ b/slirp/arp_table.c
@@ -38,7 +38,8 @@ void arp_table_add(Slirp *slirp, uint32_t ip_addr, uint8_t
ethaddr[ETH_ALEN])
ethaddr[3], ethaddr[4], ethaddr[5]));
/* Check 0.0.0.0/8 invalid source-only addresses */
-assert((ip_addr & htonl(~(0xf << 28))) != 0);
+if ((ip_addr & htonl(~(0xf << 28))) == 0)
+return;
if (ip_addr == 0x || ip_addr == broadcast_addr) {
/* Do not register broadcast addresses */
--
1.7.10.4
[Qemu-devel] [Bug 1077806] [NEW] Integrate Virtualbox/Qemu Guest booting as a desktop environment listing (request)
Public bug reported: I had seen this new way to install Chromium OS and "boot" it using LightDM's session select menu, and it made me think of an idea: What if you were able to boot virtual machines in the same manner? It would simplify the Ubuntu user's life GREATLY if they had easy access to a Windows VM that can synchronize their files to and fro (Guest additions) and not require a reboot to use it. Modern computers have more than enough power to do something like this, and it should be even easier if the system is using a dedicated virtual machine environment rather than a full blown desktop. This can transform LightDM from being just another login screen to a full-blown glorified host for all of your operating systems and remote logins. I think this would make using Ubuntu a LOT less of a hassle for the new user who came from Windows :) ** Affects: lightdm Importance: Undecided Status: New ** Affects: pantheon-greeter Importance: Undecided Status: New ** Affects: qemu Importance: Undecided Status: New ** Tags: feature request ** Also affects: pantheon-greeter Importance: Undecided Status: New ** Description changed: I had seen this new way to install Chromium OS and "boot" it using LightDM's session select menu, and it made me think of an idea: What if you were able to boot virtual machines in the same manner? It would simplify the Ubuntu user's life GREATLY if they had easy access to a Windows VM that can synchronize their files to and fro (Guest additions) and not require a reboot to use it. Modern computers have more than enough power to do something like this, and it should be even easier if the system is using a dedicated virtual machine environment rather than a full blown desktop. + This can transform LightDM from being just another login screen to a + full-blown glorified host for all of your operating systems and remote + logins. + I think this would make using Ubuntu a LOT less of a hassle for the new user who came from Windows :) ** Summary changed: - Integrate Virtualbox/Qemu Guest booting as a login (request) + Integrate Virtualbox/Qemu Guest booting as a desktop environment listing (request) ** Also affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1077806 Title: Integrate Virtualbox/Qemu Guest booting as a desktop environment listing (request) Status in Light Display Manager: New Status in Pantheon Login Screen: New Status in QEMU: New Bug description: I had seen this new way to install Chromium OS and "boot" it using LightDM's session select menu, and it made me think of an idea: What if you were able to boot virtual machines in the same manner? It would simplify the Ubuntu user's life GREATLY if they had easy access to a Windows VM that can synchronize their files to and fro (Guest additions) and not require a reboot to use it. Modern computers have more than enough power to do something like this, and it should be even easier if the system is using a dedicated virtual machine environment rather than a full blown desktop. This can transform LightDM from being just another login screen to a full-blown glorified host for all of your operating systems and remote logins. I think this would make using Ubuntu a LOT less of a hassle for the new user who came from Windows :) To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1077806/+subscriptions
Re: [Qemu-devel] [PATCH v5 5/7] TCG: Use gen_opc_buf from context instead of global variable.
On 11/10/2012 04:39 PM, Blue Swirl wrote:
On Tue, Nov 6, 2012 at 4:41 AM, Evgeny Voevodin wrote:
Signed-off-by: Evgeny Voevodin
Reviewed-by: Richard Henderson
---
target-alpha/translate.c |6 ++--
target-arm/translate.c|6 ++--
target-cris/translate.c |9 +++---
target-i386/translate.c |6 ++--
target-lm32/translate.c |9 +++---
target-m68k/translate.c |6 ++--
target-microblaze/translate.c |9 +++---
target-mips/translate.c |6 ++--
target-openrisc/translate.c |9 +++---
target-ppc/translate.c|6 ++--
target-s390x/translate.c |6 ++--
target-sh4/translate.c|6 ++--
target-sparc/translate.c |6 ++--
target-unicore32/translate.c |6 ++--
target-xtensa/translate.c |4 +--
tcg/optimize.c| 62 -
tcg/tcg.c | 30 ++--
17 files changed, 98 insertions(+), 94 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 6676cbf..91c761a 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -3373,7 +3373,7 @@ static inline void
gen_intermediate_code_internal(CPUAlphaState *env,
int max_insns;
pc_start = tb->pc;
-gen_opc_end = gen_opc_buf + OPC_MAX_SIZE;
+gen_opc_end = tcg_ctx.gen_opc_buf + OPC_MAX_SIZE;
ctx.tb = tb;
ctx.env = env;
@@ -3406,7 +3406,7 @@ static inline void
gen_intermediate_code_internal(CPUAlphaState *env,
}
}
if (search_pc) {
-j = tcg_ctx.gen_opc_ptr - gen_opc_buf;
+j = tcg_ctx.gen_opc_ptr - tcg_ctx.gen_opc_buf;
if (lj < j) {
lj++;
while (lj < j)
@@ -3465,7 +3465,7 @@ static inline void
gen_intermediate_code_internal(CPUAlphaState *env,
gen_icount_end(tb, num_insns);
*tcg_ctx.gen_opc_ptr = INDEX_op_end;
if (search_pc) {
-j = tcg_ctx.gen_opc_ptr - gen_opc_buf;
+j = tcg_ctx.gen_opc_ptr - tcg_ctx.gen_opc_buf;
lj++;
while (lj <= j)
gen_opc_instr_start[lj++] = 0;
diff --git a/target-arm/translate.c b/target-arm/translate.c
index ff5d294..0602b31 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -9727,7 +9727,7 @@ static inline void
gen_intermediate_code_internal(CPUARMState *env,
dc->tb = tb;
-gen_opc_end = gen_opc_buf + OPC_MAX_SIZE;
+gen_opc_end = tcg_ctx.gen_opc_buf + OPC_MAX_SIZE;
dc->is_jmp = DISAS_NEXT;
dc->pc = pc_start;
@@ -9834,7 +9834,7 @@ static inline void
gen_intermediate_code_internal(CPUARMState *env,
}
}
if (search_pc) {
-j = tcg_ctx.gen_opc_ptr - gen_opc_buf;
+j = tcg_ctx.gen_opc_ptr - tcg_ctx.gen_opc_buf;
if (lj < j) {
lj++;
while (lj < j)
@@ -9974,7 +9974,7 @@ done_generating:
}
#endif
if (search_pc) {
-j = tcg_ctx.gen_opc_ptr - gen_opc_buf;
+j = tcg_ctx.gen_opc_ptr - tcg_ctx.gen_opc_buf;
lj++;
while (lj <= j)
gen_opc_instr_start[lj++] = 0;
diff --git a/target-cris/translate.c b/target-cris/translate.c
index e34288e..0adc07b 100644
--- a/target-cris/translate.c
+++ b/target-cris/translate.c
@@ -3232,7 +3232,7 @@ gen_intermediate_code_internal(CPUCRISState *env,
TranslationBlock *tb,
dc->env = env;
dc->tb = tb;
-gen_opc_end = gen_opc_buf + OPC_MAX_SIZE;
+gen_opc_end = tcg_ctx.gen_opc_buf + OPC_MAX_SIZE;
dc->is_jmp = DISAS_NEXT;
dc->ppc = pc_start;
@@ -3297,7 +3297,7 @@ gen_intermediate_code_internal(CPUCRISState *env,
TranslationBlock *tb,
check_breakpoint(env, dc);
if (search_pc) {
-j = tcg_ctx.gen_opc_ptr - gen_opc_buf;
+j = tcg_ctx.gen_opc_ptr - tcg_ctx.gen_opc_buf;
if (lj < j) {
lj++;
while (lj < j) {
@@ -3436,7 +3436,7 @@ gen_intermediate_code_internal(CPUCRISState *env,
TranslationBlock *tb,
gen_icount_end(tb, num_insns);
*tcg_ctx.gen_opc_ptr = INDEX_op_end;
if (search_pc) {
-j = tcg_ctx.gen_opc_ptr - gen_opc_buf;
+j = tcg_ctx.gen_opc_ptr - tcg_ctx.gen_opc_buf;
lj++;
while (lj <= j) {
gen_opc_instr_start[lj++] = 0;
@@ -3452,7 +3452,8 @@ gen_intermediate_code_internal(CPUCRISState *env,
TranslationBlock *tb,
log_target_disas(pc_start, dc->pc - pc_start,
dc->env->pregs[PR_VR]);
qemu_log("\nisize=%d osize=%td\n",
-dc->pc - pc_start, gtcg_ctx.en_opc_ptr - gen_opc_buf);
+dc->pc - pc_start, gtcg_ctx.en_opc_ptr - tcg_ctx.gen_opc_buf);
+tcg_ctx.gen_opc_buf);
Broken patch:
/src/qemu/target-cris/translate.c:3456: error: statement with no effect
/src/qemu/target-cris/translate.c:3456: e
