headers
Alexander Graf | 1 Nov 2011 01:08
Picon

Re: GSoC mentor summit QEMU users session


On 31.10.2011, at 06:12, Peter Maydell <peter.maydell <at> linaro.org> wrote:

> On 29 October 2011 14:52, Alexander Graf <agraf <at> suse.de> wrote:
>> We should also show people unmaintained areas. The conclusion was a wiki
>> page with subsystems and status so people know what to expect. Maybe we
>> could generate this from the MAINTAINERS file?
> 
> Sounds like a good idea, although I think we might need to expand
> MAINTAINERS a bit -- I get the impression that there are a lot of
> "little bits" that fall into the gaps between the top-level areas
> marked out in MAINTAINERS.

True. We do however have file path matches, so we could easily find unmaintained files.

> 
>> Also, an easy way of counterfighting the feeling ignored part is
>> to tell people that they just hit an unmaintained area. There's
>> nothing more frustrating than sending a patch and get no reply.
>> Receiving a reply "Sorry, this area is unmaintained. Please find
>> someone to review it." would already be enough for most people.
> 
> The difficulty that strikes me with this is that I'm not sure any
> one person can reliably look at a patch and say "that's for an
> unmaintained area" (at least, I know what areas I can review but
> I have no idea about everybody else...) So you can only really
> tell by default, ie if the patch sits for a few weeks without
> any reply...

See above. I think we could script this :)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexander Graf | 1 Nov 2011 01:35
Picon

Re: [PATCH 3/3] monitor: add ability to dump SLB entries


On 31.10.2011, at 15:53, Nishanth Aravamudan wrote:

> On 31.10.2011 [15:14:12 +1100], David Gibson wrote:
>> Good points below.  I forgot to CC Nish, the original patch author on
>> my post, so I've added him to the list now.
>> 
>> Nish, can you correct these problems and resend the patch please?
> 
> Yep, I'll work on this shortly.
> 
>> On Mon, Oct 31, 2011 at 04:35:54AM +0100, Alexander Graf wrote:
>>> 
>>> On 31.10.2011, at 04:16, David Gibson wrote:
>>> 
>>>> From: Nishanth Aravamudan <nacc <at> us.ibm.com>
>>>> 
>>>> When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
>>>> qemu monitor reports "dump_mmu: unimplemented".  However, during
>>>> bringup work, it can be quite handy to have the SLB entries, which are
>>>> available in the CPUPPCState.  This patch adds an implementation of
>>>> info tlb for book3s, which dumps the SLB.
>>>> 
>>>> Signed-off-by: Nishanth Aravamudan <nacc <at> us.ibm.com>
>>>> Signed-off-by: David Gibson <david <at> gibson.dropbear.id.au>
>>>> ---
>>>> target-ppc/helper.c |   32 +++++++++++++++++++++++++++-----
>>>> 1 files changed, 27 insertions(+), 5 deletions(-)
>>>> 
>>>> diff --git a/target-ppc/helper.c b/target-ppc/helper.c
(Continue reading)

Permalink | Reply | 1 comment |
headers
matthias.bgg | 1 Nov 2011 02:36

[PATCH] block.c typo in comment fixed

From: Matthias Brugger <matthias.bgg <at> gmail.com>

Signed-off-by: Matthias Brugger <matthias.bgg <at> gmail.com>
---
 block.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/block.c b/block.c
index 9bb236c..480aae2 100644
--- a/block.c
+++ b/block.c
 <at>  <at>  -497,7 +497,7  <at>  <at>  static int bdrv_open_common(BlockDriverState *bs, const char *filename,
     open_flags = flags & ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING);

     /*
-     * Snapshots should be writable.
+     * Snapshots should be writeable.
      */
     if (bs->is_temporary) {
         open_flags |= BDRV_O_RDWR;
--

-- 
1.7.1
Permalink | Reply | 3 comments |
headers
David Gibson | 1 Nov 2011 01:54
Picon

Re: [PULL 0/3] 128-bit support for the memory API

On Mon, Oct 31, 2011 at 11:05:47AM -0500, Anthony Liguori wrote:
> On 10/30/2011 09:02 AM, Avi Kivity wrote:
> >This somewhat controversial patchset converts internal arithmetic in the
> >memory API to 128 bits.
> 
> Given the level of controversy, what do you think about deferring
> this to 1.1?

If it's deferred then one of my rearrangements for the arithmetic must
go in instead.  These patches fix real bugs, that bite us on pseries.
It's not the only way to fix those bugs, and probably not even my
personally preferred way to fix them, but they need to be fixed
_somehow_ for 1.0.

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >It has been argued that with careful coding we can make 64-bit work as
> >well.  I don't think this is true in general - a memory router can adjust
> >addresses either forwards or backwards, and some buses (PCIe) need the
> >full 64-bit space - though it's probably the case for all the configurations
> >we support today.  Regardless, the need for careful coding means subtle bugs,
> >which I don't want in a core API that is driven by guest supplied values.
> >
> >Avi Kivity (3):
> >   Add support for 128-bit arithmetic
> >   memory: use 128-bit integers for sizes and intermediates
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nishanth Aravamudan | 1 Nov 2011 02:18
Picon
Favicon

Re: [PATCH 3/3] monitor: add ability to dump SLB entries

On 31.10.2011 [17:35:13 -0700], Alexander Graf wrote:
> 
> On 31.10.2011, at 15:53, Nishanth Aravamudan wrote:
> 
> > On 31.10.2011 [15:14:12 +1100], David Gibson wrote:
> >> Good points below.  I forgot to CC Nish, the original patch author on
> >> my post, so I've added him to the list now.
> >> 
> >> Nish, can you correct these problems and resend the patch please?
> > 
> > Yep, I'll work on this shortly.
> > 
> >> On Mon, Oct 31, 2011 at 04:35:54AM +0100, Alexander Graf wrote:
> >>> 
> >>> On 31.10.2011, at 04:16, David Gibson wrote:
> >>> 
> >>>> From: Nishanth Aravamudan <nacc <at> us.ibm.com>
> >>>> 
> >>>> When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
> >>>> qemu monitor reports "dump_mmu: unimplemented".  However, during
> >>>> bringup work, it can be quite handy to have the SLB entries, which are
> >>>> available in the CPUPPCState.  This patch adds an implementation of
> >>>> info tlb for book3s, which dumps the SLB.
> >>>> 
> >>>> Signed-off-by: Nishanth Aravamudan <nacc <at> us.ibm.com>
> >>>> Signed-off-by: David Gibson <david <at> gibson.dropbear.id.au>
> >>>> ---
> >>>> target-ppc/helper.c |   32 +++++++++++++++++++++++++++-----
> >>>> 1 files changed, 27 insertions(+), 5 deletions(-)
> >>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Maydell | 1 Nov 2011 02:35
Favicon
Gravatar

Re: GSoC mentor summit QEMU users session

On 1 November 2011 00:08, Alexander Graf <agraf <at> suse.de> wrote:
> On 31.10.2011, at 06:12, Peter Maydell <peter.maydell <at> linaro.org> wrote:
>> On 29 October 2011 14:52, Alexander Graf <agraf <at> suse.de> wrote:
>>> We should also show people unmaintained areas. The conclusion was a wiki
>>> page with subsystems and status so people know what to expect. Maybe we
>>> could generate this from the MAINTAINERS file?
>>
>> Sounds like a good idea, although I think we might need to expand
>> MAINTAINERS a bit -- I get the impression that there are a lot of
>> "little bits" that fall into the gaps between the top-level areas
>> marked out in MAINTAINERS.
>
> True. We do however have file path matches, so we could easily find unmaintained files.

We'd need to expand MAINTAINERS to be a lot more comprehensive and
detailed than it is now (not necessarily a bad plan). It also doesn't
deal with the "this area is maintained but the maintainer seems to
have been busy for the last three months" issue.

I guess we could try it and see how it worked.

> See above. I think we could script this :)

I think you also want to have some sort of scripting of whether
and what you were still leaving behind -- ie try to identify the
patches which your script thought were maintained but which
still didn't get any response.

(A mildly enhanced version of patchwork might do for that.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Zhi Yong Wu | 1 Nov 2011 02:54
Picon

Re: [PATCH] qed: adjust the way to get nb_sectors

On Mon, Oct 31, 2011 at 02:11:00PM +0000, Stefan Hajnoczi wrote:
>From: Stefan Hajnoczi <stefanha <at> gmail.com>
>To: Zhi Yong Wu <zwu.kernel <at> gmail.com>
>Cc: Kevin Wolf <kwolf <at> redhat.com>, Zhi Yong Wu <wuzhy <at> linux.vnet.ibm.com>,
> qemu-devel <at> nongnu.org, stefanha <at> linux.vnet.ibm.com
>Content-Type: text/plain; charset=ISO-8859-1
>x-cbid: 11103114-6148-0000-0000-000000CC1760
>X-IBM-ISS-SpamDetectors: Score=0; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0;
> SC=0; ST=0; TS=0; UL=0; ISC=
>X-IBM-ISS-DetailInfo: BY=3.00000227; HX=3.00000175; KW=3.00000007;
> PH=3.00000001; SC=3.00000001; SDB=6.00083535; UDB=6.00022970;
> UTC=2011-10-31 14:11:03
>X-Xagent-From: stefanha <at> gmail.com
>X-Xagent-To: wuzhy <at> linux.vnet.ibm.com
>X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGENTU6 at VMSDVMA)
>
>On Mon, Oct 31, 2011 at 8:25 AM, Zhi Yong Wu <zwu.kernel <at> gmail.com> wrote:
>> On Mon, Oct 31, 2011 at 4:10 PM, Kevin Wolf <kwolf <at> redhat.com> wrote:
>>> Am 31.10.2011 04:01, schrieb Zhi Yong Wu:
>>>> It is better to use qiov.size in qed-table.c to get nb_sectors than iov.iov_len.
>>>>
>>>> Signed-off-by: Zhi Yong Wu <wuzhy <at> linux.vnet.ibm.com>
>>>
>>> The commit message should probably say why it's better. Not saying
>>> otherwise, but I can't see the different at the first sight.
>> They are equal, but if the number of iov isn't ONE, they will be not
>> equal. qiov.size contains the sum of all iov's size while iov.iov_len
>> is only the size of one iov. Although in current scenario, they are
>> equal, but i think that it is better if qiov.size is used.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Wu | 1 Nov 2011 03:12
Picon

Re: [PATCH v2] trace: Add wildcard trace event support

On 10/31/2011 10:05 PM, Stefan Hajnoczi wrote:
> >    net/queue.c      |    1 +
Oops!
Thanks. Very sorry for that! I will be more cautious.
Permalink | Reply | 0 comments |
headers
Jun Koi | 1 Nov 2011 04:35
Picon

[patch] explicitly initialize tcg_cpu_thread

This patch explicitly initializes tcg_cpu_thread to NULL in cpus.c
(One code patch in qemu_tcg_init_vcpu() relies on the value of
tcg_cpu_thread to create env->thread and so on )

Signed-off-by: Jun Koi <junkoi2004 <at> gmail.com>

diff --git a/cpus.c b/cpus.c
index f768683..47feb58 100644
--- a/cpus.c
+++ b/cpus.c
 <at>  <at>  -606,7 +606,7  <at>  <at>  static bool iothread_requesting_mutex;

 static QemuThread io_thread;

-static QemuThread *tcg_cpu_thread;
+static QemuThread *tcg_cpu_thread = NULL;
 static QemuCond *tcg_halt_cond;

 /* cpu creation */
Permalink | Reply | 3 comments |
headers
Alexander Graf | 1 Nov 2011 05:29
Picon

Re: GSoC mentor summit QEMU users session


On 31.10.2011, at 18:35, Peter Maydell wrote:

> On 1 November 2011 00:08, Alexander Graf <agraf <at> suse.de> wrote:
>> On 31.10.2011, at 06:12, Peter Maydell <peter.maydell <at> linaro.org> wrote:
>>> On 29 October 2011 14:52, Alexander Graf <agraf <at> suse.de> wrote:
>>>> We should also show people unmaintained areas. The conclusion was a wiki
>>>> page with subsystems and status so people know what to expect. Maybe we
>>>> could generate this from the MAINTAINERS file?
>>> 
>>> Sounds like a good idea, although I think we might need to expand
>>> MAINTAINERS a bit -- I get the impression that there are a lot of
>>> "little bits" that fall into the gaps between the top-level areas
>>> marked out in MAINTAINERS.
>> 
>> True. We do however have file path matches, so we could easily find unmaintained files.
> 
> We'd need to expand MAINTAINERS to be a lot more comprehensive and
> detailed than it is now (not necessarily a bad plan). It also doesn't
> deal with the "this area is maintained but the maintainer seems to
> have been busy for the last three months" issue.
> 
> I guess we could try it and see how it worked.
> 
>> See above. I think we could script this :)
> 
> I think you also want to have some sort of scripting of whether
> and what you were still leaving behind -- ie try to identify the
> patches which your script thought were maintained but which
> still didn't get any response.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane