[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 09/11] x86/ucode/amd: Remove gratuitous memory allocations from cpu_request_microcode()
On 31/03/2020 16:13, Jan Beulich wrote: > On 31.03.2020 16:55, Andrew Cooper wrote: >> On 31/03/2020 15:51, Jan Beulich wrote: >>> On 31.03.2020 12:05, Andrew Cooper wrote: >>>> @@ -497,57 +456,54 @@ static struct microcode_patch >>>> *cpu_request_microcode(const void *buf, size_t siz >>>> * It's possible the data file has multiple matching ucode, >>>> * lets keep searching till the latest version >>>> */ >>>> - while ( (error = get_ucode_from_buffer_amd(mc_amd, buf, size, >>>> - &offset)) == 0 ) >>>> + buf += offset; >>>> + size -= offset; >>>> { >>>> - /* >>>> - * If the new ucode covers current CPU, compare ucodes and store >>>> the >>>> - * one with higher revision. >>>> - */ >>>> - if ( (microcode_fits(mc_amd->mpb) != MIS_UCODE) && >>>> - (!saved || (compare_header(mc_amd->mpb, saved) == >>>> NEW_UCODE)) ) >>>> + while ( size ) >>>> { >>>> - xfree(saved); >>>> - saved = mc_amd->mpb; >>>> - } >>>> - else >>>> - { >>>> - xfree(mc_amd->mpb); >>>> - mc_amd->mpb = NULL; >>>> - } >>>> + const struct container_microcode *mc; >>>> + >>>> + if ( size < sizeof(*mc) || >>>> + (mc = buf)->type != UCODE_UCODE_TYPE || >>>> + size - sizeof(*mc) < mc->len || >>>> + !verify_patch_size(mc->len) ) >>>> + { >>>> + printk(XENLOG_ERR "microcode: Bad microcode data\n"); >>>> + error = -EINVAL; >>>> + break; >>>> + } >>>> >>>> - if ( offset >= size ) >>>> - break; >>>> + /* >>>> + * If the new ucode covers current CPU, compare ucodes and >>>> store the >>>> + * one with higher revision. >>>> + */ >>>> + if ( (microcode_fits(mc->patch) != MIS_UCODE) && >>>> + (!saved || (compare_header(mc->patch, saved) == >>>> NEW_UCODE)) ) >>>> + { >>>> + saved = mc->patch; >>>> + saved_size = mc->len; >>>> + } >>>> >>>> - /* >>>> - * 1. Given a situation where multiple containers exist and >>>> correct >>>> - * patch lives on a container that is not the last container. >>>> - * 2. We match equivalent ids using find_equiv_cpu_id() from the >>>> - * earlier while() (On this case, matches on earlier container >>>> - * file and we break) >>>> - * 3. Proceed to while ( (error = >>>> get_ucode_from_buffer_amd(mc_amd, >>>> - * buf, size, &offset)) == 0 ) >>>> - * 4. Find correct patch using microcode_fits() and apply the >>>> patch >>>> - * (Assume: apply_microcode() is successful) >>>> - * 5. The while() loop from (3) continues to parse the binary as >>>> - * there is a subsequent container file, but... >>>> - * 6. ...a correct patch can only be on one container and not on >>>> any >>>> - * subsequent ones. (Refer docs for more info) Therefore, we >>>> - * don't have to parse a subsequent container. So, we can abort >>>> - * the process here. >>>> - * 7. This ensures that we retain a success value (= 0) to 'error' >>>> - * before if ( mpbuf->type != UCODE_UCODE_TYPE ) evaluates to >>>> - * false and returns -EINVAL. >>>> - */ >>>> - if ( offset + SECTION_HDR_SIZE <= size && >>>> - *(const uint32_t *)(buf + offset) == UCODE_MAGIC ) >>>> - break; >>>> + /* Move over the microcode blob. */ >>>> + buf += sizeof(*mc) + mc->len; >>>> + size -= sizeof(*mc) + mc->len; >>>> + >>>> + /* >>>> + * Peek ahead. If we see the start of another container, >>>> we've >>>> + * exhaused all microcode blobs in this container. Exit >>>> cleanly. >>>> + */ >>>> + if ( size >= 4 && *(const uint32_t *)buf == UCODE_MAGIC ) >>>> + break; >>> While, as already indicated, I agree with shrinking the big comment, >>> I think point 6 is what wants retaining in some form - it's not >>> obvious at all why a subsequent container couldn't contain a higher >>> rev ucode than what we've found. That comment refers us to docs, but >>> I couldn't find anything to this effect in PM Vol 2. Assuming this >>> indeed documented and true, with the comment extended accordingly >>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> >> I think it is referring to the internal PPR, which isn't even the one we >> have access to. >> >> As to the multiple containers aspect, I've deliberately "fixed" that in >> patch 11 so we do scan all the way to the end. > Right, meanwhile I've seen this. But shouldn't patch 11 then adjust at > least the "Exit cleanly" part of the comment? You're merely breaking > the inner loop then ... I'd still argue that "exit cleanly" is fine in context. Without it, the end of buffer case happens fine as size becomes 0 and terminates both loops, but in the case that there is a following container, without it we fail because of the "!= UCODE_UCODE_TYPE" check. ~Andrew
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |