public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "wang xiaofeng" <winggundum82@163.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: CapsuleApp behavior for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule
Date: Mon, 13 Feb 2017 10:09:51 +0800 (CST)	[thread overview]
Message-ID: <327c5917.21cd.15a353bbb4c.Coremail.winggundum82@163.com> (raw)
In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A8ECA16@shsmsx102.ccr.corp.intel.com>

Hi Jiewen,
     Sorry, I forgot that I modified Capsuleapp before, Trunk Caspuleapp behavior is like you said" If a capsule has CAPSULE_FLAGS_PERSIST_ACROSS_RESET, capsule app will trigger reset". The logic doesn;t have errors.
But the behavior is a little different from my understanding . Could you think if we can change the behavior to " If a capsule has CAPSULE_FLAGS_PERSIST_ACROSS_RESET, capsule app will NOT trigger reset,let user trigger the reset later"?
The reasons are as the followings:
1) user cannot distinguish whether the reset is triggered by bios code or application code , there is no difference for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule and CAPSULE_FLAGS_PERSIST_ACROSS_RESET + CAPSULE_FLAGS_INITIATE_RESET capsule in current design
2) user may have to update bios capsule , ME capsule ,BMC capsule together,otherwise system cannot work in next reboot. So after bios capsule update done , a reset is not expected. User want to update it later after all capsule are updated.


Anyhow , this is a new feature request and you can decide whether need to add this feature.










At 2017-02-10 19:24:55, "Yao, Jiewen" <jiewen.yao@intel.com> wrote:
>That is an interesting question.
>
>A general rule for Capsule App is:
>
>1)       If a capsule has CAPSULE_FLAGS_INITIATE_RESET, the CapsuleService will issue reset. No need to handler in CapsuleApp. (The free memory logic will not run)
>
>2)       If a capsule has CAPSULE_FLAGS_PERSIST_ACROSS_RESET, the CapsuleService will not issue reset, because CapsuleService will let caller decide when to reset. So here CapsuleApp does reset. (The free memory logic will not run)
>
>3)       If a capsule has no CAPSULE_FLAGS_PERSIST_ACROSS_RESET flag, the CapsuleService processes the image immediately. Then CapsuleApp can free the buffer finally, because it is already processed.
>
>May I know where you think we have logic error?
>
>Thank you
>Yao Jiewen
>
>From: wang xiaofeng [mailto:winggundum82@163.com]
>Sent: Friday, February 10, 2017 1:27 AM
>To: Yao, Jiewen <jiewen.yao@intel.com>; edk2-devel@lists.01.org
>Subject: CapsuleApp behavior for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule
>
>Hi Jiewen,
>       I think it might be a logic error for CapsuleApp  with CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule. If a capsule only have CAPSULE_FLAGS_PERSIST_ACROSS_RESET flag, my understanding it will not trigger reset automatially. User will trigger reset&#65533;&#65533;S3) in OS or application like CapsuleApp.
>     CapsuleApp will not trigger reset if CAPSULE_FLAGS_INITIATE_RESET is not set, the problem is it will free the capsule buffer also!
>
>Done:
>  for (Index = 0; Index < CapsuleNum; Index++) {
>    if (CapsuleBuffer[Index] != NULL) {
>      FreePool (CapsuleBuffer[Index]);
>    }
>  }
>
>  CleanGatherList(BlockDescriptors, CapsuleNum);
>
>   I trited to remove the above free buffer logic and capsuleApp can work with CAPSULE_FLAGS_INITIATE_RESET only attribute. The capsule data should be kept in this case
>
>
>
>
>
>_______________________________________________
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel

  reply	other threads:[~2017-02-13  2:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07  6:33 [PATCH] SignedCapsulePkg/EdkiiSystemCapsuleLib: Fix logic error Jiewen Yao
2017-02-07  8:58 ` wang xiaofeng
2017-02-10  9:27   ` CapsuleApp behavior for CAPSULE_FLAGS_PERSIST_ACROSS_RESET only capsule wang xiaofeng
2017-02-10 11:24     ` Yao, Jiewen
2017-02-13  2:09       ` wang xiaofeng [this message]
2017-02-13  3:52         ` Yao, Jiewen
2017-02-13  4:46           ` wang xiaofeng
2017-02-17  1:23             ` Yao, Jiewen
2017-02-17  1:38               ` wang xiaofeng
2017-02-20  1:27               ` wang xiaofeng
2017-02-23 11:21               ` Tcg2Pei.efi assert after sync to latest trunk wang xiaofeng
2017-02-23 13:01                 ` Gao, Liming
2017-02-24  5:08                   ` wang xiaofeng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=327c5917.21cd.15a353bbb4c.Coremail.winggundum82@163.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox