1 Oct 2010 06:06
1 Oct 2010 09:15
Re: [PATCH v2 00/19] Monitor: split HMP and QMP dispatch tables
Markus Armbruster <armbru <at> redhat.com>
2010-10-01 07:15:45 GMT
2010-10-01 07:15:45 GMT
Luiz Capitulino <lcapitulino <at> redhat.com> writes: > This is a respin with the following small changes: > > v1 - v2: > o Renamed qemu-monitor-qmp.hx to qmp-commands.hx > o Added a new patch which renames qemu-monitor.hx to hmp-commands.hx > o Other minor changes ACK
1 Oct 2010 10:41
Re: QEMU throughput is down with SMP
Stefan Hajnoczi <stefanha <at> gmail.com>
2010-10-01 08:41:05 GMT
2010-10-01 08:41:05 GMT
On Thu, Sep 30, 2010 at 8:19 PM, Venkateswararao Jujjuri (JV) <jvrao <at> linux.vnet.ibm.com> wrote: > On 9/30/2010 2:13 AM, Stefan Hajnoczi wrote: >> >> On Thu, Sep 30, 2010 at 1:50 AM, Venkateswararao Jujjuri (JV) >> <jvrao <at> linux.vnet.ibm.com> wrote: >>> >>> Code: Mainline QEMU (git://git.qemu.org/qemu.git) >>> Machine: LS21 blade. >>> Disk: Local disk through VirtIO. >>> Did not select any cache option. Defaulting to writethrough. >>> >>> Command tested: >>> 3 parallel instances of : dd if=/dev/zero of=/pmnt/my_pw bs=4k >>> count=100000 >>> >>> QEMU with smp=1 >>> 19.3 MB/s + 19.2 MB/s + 18.6 MB/s = 57.1 MB/s >>> >>> QEMU with smp=4 >>> 15.3 MB/s + 14.1 MB/s + 13.6 MB/s = 43.0 MB/s >>> >>> Is this expected? >> >> Did you configure with --enable-io-thread? > > Yes I did. >> >> Also, try using dd oflag=direct to eliminate effects introduced by the >> guest page cache and really hit the disk.(Continue reading)
1 Oct 2010 15:31
Re: [PATCH 10/19] QMP: Introduce query commands dispatch table
Anthony Liguori <aliguori <at> linux.vnet.ibm.com>
2010-10-01 13:31:11 GMT
2010-10-01 13:31:11 GMT
On 09/30/2010 03:56 PM, Luiz Capitulino wrote: > The new table is a copy of HMP's table, containing only QObject > handlers. > > In the near future HMP will be making QMP calls and then we will > be able to drop QObject handlers from HMP's table. > > > From now on, QMP and HMP have different query command dispatch > tables. > I like this series a lot and I think it's ready to merge. But I wonder, why have a separate qmp_query_cmds table? Why not just fold the query commands into qmp_cmds? Regards, Anthony Liguori > Signed-off-by: Luiz Capitulino<lcapitulino <at> redhat.com> > --- > monitor.c | 130 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 128 insertions(+), 2 deletions(-) > > diff --git a/monitor.c b/monitor.c > index 8f58e18..7cb66df 100644 > --- a/monitor.c > +++ b/monitor.c > <at> <at> -190,6 +190,7 <at> <at> static const mon_cmd_t mon_cmds[];(Continue reading)
1 Oct 2010 15:38
Re: QEMU throughput is down with SMP
Ryan Harper <ryanh <at> us.ibm.com>
2010-10-01 13:38:55 GMT
2010-10-01 13:38:55 GMT
* Stefan Hajnoczi <stefanha <at> gmail.com> [2010-10-01 03:48]: > On Thu, Sep 30, 2010 at 8:19 PM, Venkateswararao Jujjuri (JV) > <jvrao <at> linux.vnet.ibm.com> wrote: > > On 9/30/2010 2:13 AM, Stefan Hajnoczi wrote: > >> > >> On Thu, Sep 30, 2010 at 1:50 AM, Venkateswararao Jujjuri (JV) > >> <jvrao <at> linux.vnet.ibm.com> wrote: > >>> > >>> Code: Mainline QEMU (git://git.qemu.org/qemu.git) > >>> Machine: LS21 blade. > >>> Disk: Local disk through VirtIO. > >>> Did not select any cache option. Defaulting to writethrough. > >>> > >>> Command tested: > >>> 3 parallel instances of : dd if=/dev/zero of=/pmnt/my_pw bs=4k > >>> count=100000 > >>> > >>> QEMU with smp=1 > >>> 19.3 MB/s + 19.2 MB/s + 18.6 MB/s = 57.1 MB/s > >>> > >>> QEMU with smp=4 > >>> 15.3 MB/s + 14.1 MB/s + 13.6 MB/s = 43.0 MB/s > >>> > >>> Is this expected? > >> > >> Did you configure with --enable-io-thread? > > > > Yes I did. > >> > >> Also, try using dd oflag=direct to eliminate effects introduced by the(Continue reading)
1 Oct 2010 15:49
Re: [PATCH 10/19] QMP: Introduce query commands dispatch table
Luiz Capitulino <lcapitulino <at> redhat.com>
2010-10-01 13:49:06 GMT
2010-10-01 13:49:06 GMT
On Fri, 01 Oct 2010 08:31:11 -0500 Anthony Liguori <aliguori <at> linux.vnet.ibm.com> wrote: > On 09/30/2010 03:56 PM, Luiz Capitulino wrote: > > The new table is a copy of HMP's table, containing only QObject > > handlers. > > > > In the near future HMP will be making QMP calls and then we will > > be able to drop QObject handlers from HMP's table. > > > > > From now on, QMP and HMP have different query command dispatch > > tables. > > > > I like this series a lot and I think it's ready to merge. > > But I wonder, why have a separate qmp_query_cmds table? Why not just > fold the query commands into qmp_cmds? Yes, that will be done shortly, but in a different series. I'm not doing it in this series because it's necessary to change the signature of all those functions which would make this series too large and harder to review. On a related note: I have more monitor patches in my queue. I'm building and testing them right now. I'm planning to send a pull request of all pending monitor patches later today. So, if you prefer, you can wait for that pull request instead of merging this series alone.(Continue reading)
1 Oct 2010 16:25
Re: [PATCH 10/19] QMP: Introduce query commands dispatch table
Anthony Liguori <aliguori <at> linux.vnet.ibm.com>
2010-10-01 14:25:51 GMT
2010-10-01 14:25:51 GMT
On 10/01/2010 08:49 AM, Luiz Capitulino wrote: > On Fri, 01 Oct 2010 08:31:11 -0500 > Anthony Liguori<aliguori <at> linux.vnet.ibm.com> wrote: > > >> On 09/30/2010 03:56 PM, Luiz Capitulino wrote: >> >>> The new table is a copy of HMP's table, containing only QObject >>> handlers. >>> >>> In the near future HMP will be making QMP calls and then we will >>> be able to drop QObject handlers from HMP's table. >>> >>> >>>> From now on, QMP and HMP have different query command dispatch >>>> >>> tables. >>> >>> >> I like this series a lot and I think it's ready to merge. >> >> But I wonder, why have a separate qmp_query_cmds table? Why not just >> fold the query commands into qmp_cmds? >> > Yes, that will be done shortly, but in a different series. > Perfect(Continue reading)> I'm not doing it in this series because it's necessary to change the
1 Oct 2010 16:33
[Bug 652293] Re: Linux for SPARC does not work
Roman Franchuk <652293 <at> bugs.launchpad.net>
2010-10-01 14:33:18 GMT
2010-10-01 14:33:18 GMT
> It looks like the version of OpenBIOS in Debian sqeeze is buggy. Thank you very much. I downloaded version from your link, and it works. -- Linux for SPARC does not work https://bugs.launchpad.net/bugs/652293 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to use debian for sparc. I downloaded Debain Lenny 5.06 sparc netinst (file name: debian-506-sparc-netinst.iso). I tried to boot it by command: qemu-system-sparc -cdrom debian-506-sparc-netinst.iso -boot d It printed some messages to screen. The last 2 was: entry point is 0x4000 Jumping to entry point... I tried to run it as sparc64 (debian.org sais that debian runs fine on sparc32, but i tried): qemu-system-sparc64 -cdrom debian-506-sparc-netinst.iso -boot d It loaded SILO. When i press enter or print kernel commandline, it starts booting, writes, that it loaded kernel 2.6.26, initrd, and after it i get black screen. System does not boot. I went to google and found that debian lenny can not run on sparc32 (it uses sparc64 kernel, but 32-bit userspace). People recomended me to try debian 4. I downloaded file debian-40r8-sparc-netinst.iso. But i got the same bug with qemu-system-sparc. With sparc64 i did not get black screen.It finished by string: Remapping the kernel... done. What is it?(Continue reading)
1 Oct 2010 17:04
Re: QEMU throughput is down with SMP
Venkateswararao Jujjuri (JV <jvrao <at> linux.vnet.ibm.com>
2010-10-01 15:04:40 GMT
2010-10-01 15:04:40 GMT
On 10/1/2010 6:38 AM, Ryan Harper wrote: > * Stefan Hajnoczi<stefanha <at> gmail.com> [2010-10-01 03:48]: >> On Thu, Sep 30, 2010 at 8:19 PM, Venkateswararao Jujjuri (JV) >> <jvrao <at> linux.vnet.ibm.com> wrote: >>> On 9/30/2010 2:13 AM, Stefan Hajnoczi wrote: >>>> >>>> On Thu, Sep 30, 2010 at 1:50 AM, Venkateswararao Jujjuri (JV) >>>> <jvrao <at> linux.vnet.ibm.com> wrote: >>>>> >>>>> Code: Mainline QEMU (git://git.qemu.org/qemu.git) >>>>> Machine: LS21 blade. >>>>> Disk: Local disk through VirtIO. >>>>> Did not select any cache option. Defaulting to writethrough. >>>>> >>>>> Command tested: >>>>> 3 parallel instances of : dd if=/dev/zero of=/pmnt/my_pw bs=4k >>>>> count=100000 >>>>> >>>>> QEMU with smp=1 >>>>> 19.3 MB/s + 19.2 MB/s + 18.6 MB/s = 57.1 MB/s >>>>> >>>>> QEMU with smp=4 >>>>> 15.3 MB/s + 14.1 MB/s + 13.6 MB/s = 43.0 MB/s >>>>> >>>>> Is this expected? >>>> >>>> Did you configure with --enable-io-thread? >>> >>> Yes I did. >>>>(Continue reading)
1 Oct 2010 17:09
Re: QEMU throughput is down with SMP
Stefan Hajnoczi <stefanha <at> gmail.com>
2010-10-01 15:09:00 GMT
2010-10-01 15:09:00 GMT
On Fri, Oct 1, 2010 at 4:04 PM, Venkateswararao Jujjuri (JV) <jvrao <at> linux.vnet.ibm.com> wrote: > On 10/1/2010 6:38 AM, Ryan Harper wrote: >> >> * Stefan Hajnoczi<stefanha <at> gmail.com> [2010-10-01 03:48]: >>> >>> On Thu, Sep 30, 2010 at 8:19 PM, Venkateswararao Jujjuri (JV) >>> <jvrao <at> linux.vnet.ibm.com> wrote: >>>> >>>> On 9/30/2010 2:13 AM, Stefan Hajnoczi wrote: >>>>> >>>>> On Thu, Sep 30, 2010 at 1:50 AM, Venkateswararao Jujjuri (JV) >>>>> <jvrao <at> linux.vnet.ibm.com> wrote: >>>>>> >>>>>> Code: Mainline QEMU (git://git.qemu.org/qemu.git) >>>>>> Machine: LS21 blade. >>>>>> Disk: Local disk through VirtIO. >>>>>> Did not select any cache option. Defaulting to writethrough. >>>>>> >>>>>> Command tested: >>>>>> 3 parallel instances of : dd if=/dev/zero of=/pmnt/my_pw bs=4k >>>>>> count=100000 >>>>>> >>>>>> QEMU with smp=1 >>>>>> 19.3 MB/s + 19.2 MB/s + 18.6 MB/s = 57.1 MB/s >>>>>> >>>>>> QEMU with smp=4 >>>>>> 15.3 MB/s + 14.1 MB/s + 13.6 MB/s = 43.0 MB/s >>>>>> >>>>>> Is this expected?(Continue reading)
RSS Feed