Re: [PATCH qemu v2] spapr: Kill SLOF

[David Gibson]

On Wed, Jan 08, 2020 at 04:53:06PM +1100, Alexey Kardashevskiy wrote:
> 
> 
> On 08/01/2020 15:20, Alexey Kardashevskiy wrote:
> > 
> > 
> > On 07/01/2020 16:54, David Gibson wrote:
> >> On Tue, Jan 07, 2020 at 03:44:35PM +1100, Alexey Kardashevskiy wrote:
> >>>
> >>>
> >>> On 06/01/2020 15:19, David Gibson wrote:
> >>>>> +
> >>>>> +static uint32_t client_package_to_path(const void *fdt, uint32_t 
> >>>>> phandle,
> >>>>> +                                       uint32_t buf, uint32_t len)
> >>>>> +{
> >>>>> +    char tmp[256];
> >>>>
> >>>> Fixed sized buffers are icky.  You could either dynamically allocate
> >>>> this based on the size the client gives, or you could use
> >>>> memory_region_get_ram_ptr() to read the data from the tree directly
> >>>> into guest memory.
> >>>
> >>> @len comes from the guest, I am really not comfortable with allocating
> >>> whatever (broken) guest requested. And if I limit @len by 1024 or
> >>> similar, then a fixed size buffer will do too, no?
> >>
> >> I see your point.  Does this call have a way to report failure?  In
> >> that case you could outright fail the call if it requests too long a
> >> length.
> > 
> > It returns length which can be 0 to signal an error.
> > 
> > but with this particular method the bigger problem is that I cannot know
> > in advance the actual path length from fdt_get_path(). I could double
> > the size until fdt_get_path() succeeded, just seems overkill here.
> > 
> > Property names seem to be limited by 32:
> 
> 
> >>> len("ibm,query-interrupt-source-number")
> 33
> 
> Awesome. Oh well :(

Yeah, as I suspected.  Also 'ibm,associativity-reference-points'.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature