[Qemu-devel] [PATCH v3 0/7] qapi/range/memory-device: fixes and cleanups

David Hildenbrand posted 7 patches 7 years ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20181023152306.3123-1-david@redhat.com
Test docker-clang@ubuntu passed
Test checkpatch passed
Test asan passed
Test docker-mingw@fedora passed
Test docker-quick@centos7 passed
There is a newer version of this series
hw/mem/memory-device.c      | 60 ++++++++++++++++++--------------
include/qemu/range.h        | 68 +++++++++++++++++++++++++++++++++++--
qapi/string-input-visitor.c | 34 ++++++++-----------
3 files changed, 114 insertions(+), 48 deletions(-)
[Qemu-devel] [PATCH v3 0/7] qapi/range/memory-device: fixes and cleanups
Posted by David Hildenbrand 7 years ago
While working on memory device code, I noticed that specifiying an uint64_t
on command line does not work in all cases as we always parse an int64_t.
So I fix that and also cleanup the old int64_t parser.

To be able to fix some overflows in memory-device code in a clean way,
I am reusing the range implementation of qemu, for which I need some
more helpers.

This series is based on
    "[PATCH v5 00/16] memory-device: complete refactoring"
which should get pulled soon.

v2 -> v3:
- "qapi: correctly parse uint64_t values from strings"
-- don't parse range
-- don't rename "parse_str"

v1 -> v2:
- "range: add some more functions"
-- Reduce number of functions
-- make range_init() return an error in case of overflow
-- provide range_init_nofail()
- "memory-device: rewrite address assignment using ranges"
-- Use new functions range_init/range_init_nofail
-- Use range_contains_range instead of starts_before/ends_after


David Hildenbrand (7):
  qapi: use qemu_strtoi64() in parse_str
  qapi: correctly parse uint64_t values from strings
  range: pass const pointer where possible
  range: add some more functions
  memory-device: use QEMU_IS_ALIGNED
  memory-device: avoid overflows on very huge devices
  memory-device: rewrite address assignment using ranges

 hw/mem/memory-device.c      | 60 ++++++++++++++++++--------------
 include/qemu/range.h        | 68 +++++++++++++++++++++++++++++++++++--
 qapi/string-input-visitor.c | 34 ++++++++-----------
 3 files changed, 114 insertions(+), 48 deletions(-)

-- 
2.17.1


Re: [Qemu-devel] [PATCH v3 0/7] qapi/range/memory-device: fixes and cleanups
Posted by David Hildenbrand 7 years ago
On 23.10.18 17:22, David Hildenbrand wrote:
> While working on memory device code, I noticed that specifiying an uint64_t
> on command line does not work in all cases as we always parse an int64_t.
> So I fix that and also cleanup the old int64_t parser.
> 
> To be able to fix some overflows in memory-device code in a clean way,
> I am reusing the range implementation of qemu, for which I need some
> more helpers.
> 
> This series is based on
>     "[PATCH v5 00/16] memory-device: complete refactoring"
> which should get pulled soon.
> 
> v2 -> v3:
> - "qapi: correctly parse uint64_t values from strings"
> -- don't parse range
> -- don't rename "parse_str"
> 
> v1 -> v2:
> - "range: add some more functions"
> -- Reduce number of functions
> -- make range_init() return an error in case of overflow
> -- provide range_init_nofail()
> - "memory-device: rewrite address assignment using ranges"
> -- Use new functions range_init/range_init_nofail
> -- Use range_contains_range instead of starts_before/ends_after
> 
> 
> David Hildenbrand (7):
>   qapi: use qemu_strtoi64() in parse_str
>   qapi: correctly parse uint64_t values from strings
>   range: pass const pointer where possible
>   range: add some more functions
>   memory-device: use QEMU_IS_ALIGNED
>   memory-device: avoid overflows on very huge devices
>   memory-device: rewrite address assignment using ranges
> 
>  hw/mem/memory-device.c      | 60 ++++++++++++++++++--------------
>  include/qemu/range.h        | 68 +++++++++++++++++++++++++++++++++++--
>  qapi/string-input-visitor.c | 34 ++++++++-----------
>  3 files changed, 114 insertions(+), 48 deletions(-)
> 

Any more comments? If not, I think this is good to go.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v3 0/7] qapi/range/memory-device: fixes and cleanups
Posted by Eduardo Habkost 7 years ago
On Wed, Oct 31, 2018 at 11:14:48AM +0100, David Hildenbrand wrote:
> On 23.10.18 17:22, David Hildenbrand wrote:
> > While working on memory device code, I noticed that specifiying an uint64_t
> > on command line does not work in all cases as we always parse an int64_t.
> > So I fix that and also cleanup the old int64_t parser.
> > 
> > To be able to fix some overflows in memory-device code in a clean way,
> > I am reusing the range implementation of qemu, for which I need some
> > more helpers.
> > 
> > This series is based on
> >     "[PATCH v5 00/16] memory-device: complete refactoring"
> > which should get pulled soon.
> > 
> > v2 -> v3:
> > - "qapi: correctly parse uint64_t values from strings"
> > -- don't parse range
> > -- don't rename "parse_str"
> > 
> > v1 -> v2:
> > - "range: add some more functions"
> > -- Reduce number of functions
> > -- make range_init() return an error in case of overflow
> > -- provide range_init_nofail()
> > - "memory-device: rewrite address assignment using ranges"
> > -- Use new functions range_init/range_init_nofail
> > -- Use range_contains_range instead of starts_before/ends_after
> > 
> > 
> > David Hildenbrand (7):
> >   qapi: use qemu_strtoi64() in parse_str
> >   qapi: correctly parse uint64_t values from strings
> >   range: pass const pointer where possible
> >   range: add some more functions
> >   memory-device: use QEMU_IS_ALIGNED
> >   memory-device: avoid overflows on very huge devices
> >   memory-device: rewrite address assignment using ranges
> > 
> >  hw/mem/memory-device.c      | 60 ++++++++++++++++++--------------
> >  include/qemu/range.h        | 68 +++++++++++++++++++++++++++++++++++--
> >  qapi/string-input-visitor.c | 34 ++++++++-----------
> >  3 files changed, 114 insertions(+), 48 deletions(-)
> > 
> 
> Any more comments? If not, I think this is good to go.

I'm assuming you want to drop patches 1 and 2, that's correct?

I'm queueing patches 3/7, 5/7, and 6/7 on machine-next.

Patch 4/7 still needs a reviewer.

Patch 7/7 seems to depend on patch 4, so I'm not queueing it yet.

-- 
Eduardo