[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v8 06/16] microcode: introduce a global cache of ucode patch


  • To: Chao Gao <chao.gao@xxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Mon, 5 Aug 2019 09:31:28 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=suse.com;dmarc=pass action=none header.from=suse.com;dkim=pass header.d=suse.com;arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0jsTOYN7fKSsfLQfl0jYY3TRYoiEYaSoOoaXAm05XAM=; b=XMnB9tA8ePfh1OdHpAxGLxrkx6qiXY7qGhn6kJmzzooyLPM7LJwhALQfJH4qjrnFoyhtprBqRyPDWx+GRR7DfH5zzf0D2L1SysfFM3n3w9oFWp89LcfrXhPfHAyvsz1Vu01mY7fZZVAZiGynm9PfhvrYGXAnZa9/6FfEGUt5Fn8VMD4kpnL0Ed2eWn7VgrrO3qwjP1yqVhH1HO+0bkywXNouTcF/BntKW9s9aeLqckpl0wDIg6FmmymRgWkbYNwv94wRBtzhk9097jG5kIRcZDvf5ayu+QzMbOkY9zGMpJmbXVWe1YhOqdf1cgrS1uYz7lOSEKlYRRvDYsE2zwpw7A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hwkyQyvzxGgq2UcY2LlpvfvluEYz6p5gJRe244T2XDHKbrN+yqW8kv1YQbP75xsR/Rw6G4HJelfQ8wscPq9HDNoYdyQphXfxnSAK5HfqRhPiE2mLR/b9+qjI+S1UUUj4mXTMAwFSV5lQnR/S5ucz0o/iaXf9kQgn0dcjQ7bjlcR29s7oEImZbrGaz4JsVZEGHl/IOHzDIZWrv9mWPJU/FpHXP0gpZK6m/TzH0qIEyodlNWsPH5mR97SDA3TNDdjG/+XmJHS9lFT30W4QXfwZ3n7cIUx9acAPd616u6gkUrvfv5oNxMGAD1pV8J2qkzUWFdxmXnQTQHqDGB8PTS1Kew==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ashok Raj <ashok.raj@xxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 05 Aug 2019 09:33:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVSFKbg6V+T8KOdE+RBvqghdKkCKbn8Z0AgAQ3fz+AACdbgA==
  • Thread-topic: [PATCH v8 06/16] microcode: introduce a global cache of ucode patch

On 05.08.2019 09:02, Chao Gao wrote:
> On Fri, Aug 02, 2019 at 02:46:58PM +0000, Jan Beulich wrote:
>> On 01.08.2019 12:22, Chao Gao wrote:
>>> +bool microcode_update_cache(struct microcode_patch *patch)
>>> +{
>>> +
>>> +    ASSERT(spin_is_locked(&microcode_mutex));
>>> +
>>> +    if ( !microcode_cache )
>>> +        microcode_cache = patch;
>>> +    else if ( microcode_ops->compare_patch(patch, microcode_cache) ==
>>> +                  NEW_UCODE )
>>
>> Indentation is wrong here.
>>
>>> +static struct microcode_patch *alloc_microcode_patch(
>>> +    const struct microcode_amd *mc_amd)
>>> +{
>>> +    struct microcode_patch *microcode_patch = xmalloc(struct 
>>> microcode_patch);
>>> +    struct microcode_amd *cache = xmalloc(struct microcode_amd);
>>> +    void *mpb = xmalloc_bytes(mc_amd->mpb_size);
>>> +    struct equiv_cpu_entry *equiv_cpu_table =
>>> +                                
>>> xmalloc_bytes(mc_amd->equiv_cpu_table_size);
>>> +
>>> +    if ( !microcode_patch || !cache || !mpb || !equiv_cpu_table )
>>> +    {
>>> +        xfree(microcode_patch);
>>> +        xfree(cache);
>>> +        xfree(mpb);
>>> +        xfree(equiv_cpu_table);
>>> +        return ERR_PTR(-ENOMEM);
>>> +    }
>>> +
>>> +    memcpy(mpb, mc_amd->mpb, mc_amd->mpb_size);
>>> +    cache->mpb = mpb;
>>> +    cache->mpb_size = mc_amd->mpb_size;
>>> +    memcpy(equiv_cpu_table, mc_amd->equiv_cpu_table,
>>> +           mc_amd->equiv_cpu_table_size);
>>> +    cache->equiv_cpu_table = equiv_cpu_table;
>>> +    cache->equiv_cpu_table_size = mc_amd->equiv_cpu_table_size;
>>> +    microcode_patch->mc_amd = cache;
>>> +
>>> +    return microcode_patch;
>>> +}
>>
>> Why is it that everything needs to be copied here, rather than
>> simply shuffling one (or a few) pointer(s)? Can't the caller
>> simply install the argument it passes here as the new cache blob?
> 
> The old per-cpu cache would use the pointers. And the old cache struct
> is removed in "microcode: remove struct ucode_cpu_info". I can add a
> patch after that one to reuse the pointers. Otherwise, I may have to
> merge following two patches into this one.

If this is just a transitory step, then it's fine, but you should
say so in the description (and the patch to re-use the already
allocated space would then be nice to be part of this series).

>>> +static enum microcode_match_result compare_patch(
>>> +    const struct microcode_patch *new, const struct microcode_patch *old)
>>> +{
>>> +    const struct microcode_header_intel *old_header = &old->mc_intel->hdr;
>>> +
>>> +    return microcode_update_match(&new->mc_intel->hdr, old_header->sig,
>>> +                                  old_header->pf, old_header->rev);
>>
>> So this is exactly what I said on the earlier patch the function
>> cannot be used for. The way "pf" works precludes this, as said in
>> reply to an earlier version, and no-one corrected me (i.e. I'm in
>> no way excluding I'm misunderstanding something here).
> 
> How about just check 'rev' here and leave a comment here to explain
> why?
> 
> We drops all mismatched patches (including that only has 'pf'
> mismatched) compared with current CPU signature. Given that, it is
> fine to only check the revision number.

Ah, yes, that's apparently another option. But it'll require re-working
microcode_update_match(), or not using it here, afaics.

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.