February 2023 - Linaro-open-discussions

Re: 回复：Re: 回复：Li =?utf-8?Q?naro-open-discussions_call_on_May___24th

by Shameerali Kolothum Thodi

> -----Original Message----- > From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi@gmail.com] > Sent: 25 July 2022 10:46 > To: Joyce Qi <joyce.qi(a)linaro.org> > Cc: Jonathan Cameron <jonathan.cameron(a)huawei.com>; Shameerali > Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>; Jonathon > Burcham <jon.burcham(a)linaro.org>; yangyicong > <yangyicong(a)huawei.com>; Hesham Almatary > <hesham.almatary(a)huawei.com>; shenyang (M) > <shenyang39(a)huawei.com>; tangchengchang > <tangchengchang(a)huawei.com>; Dietmar Eggemann > <Dietmar.Eggemann(a)arm.com>; linaro-open-discussions(a)op-lists.linaro.org; > Lorenzo Pieralisi <lorenzo.pieralisi(a)linaro.org> > Subject: Re: [Linaro-open-discussions] 回复：Re: 回复：Li > =?utf-8?Q?naro-open-discussions_call_on_May___24th > > On Thu, 21 Jul 2022 at 16:28, Joyce Qi <joyce.qi(a)linaro.org> wrote: > > > > Hi Jonatha,Lorenz,Shamee, > > > > Do you have any topics want to sync on July 26’s LOD meeting? > > [dropped my arm.com address and added @linaro.org one] > > I am just catching up after a 2 month hiatus but if there is anything urgent to > be discussed I am happy to join the call and run the meeting. Met too just back after holidays and don't have anything urgent for discussion from my end. Also, Jonathan is away this week. Thanks, Shameer > Lorenzo > > > > > Thanks:) > > Joyce > > > > > > > 在 2022年6月24日，下午10:38，Jonathan Cameron > <jonathan.cameron(a)huawei.com> > > > 写道： > > > > > > My availability that week is going to be hard to predict (at a workshop in > Germany) but SPDM topic can wait. > > > I just wanted to confirm general interest and email works fine for that. > > > > > > Good for others to have a sync meeting and if I can dial in for a bit I will > do so. > > > > > > Jonathan > > > > > > > > > > > > -----Original Message----- > > > From: Lorenzo Pieralisi <Lorenzo.Pieralisi(a)arm.com> > > > Sent: 24 June 2022 15:30 > > > To: Joyce Qi <joyce.qi(a)linaro.org> > > > Cc: Shameerali Kolothum Thodi > > > <shameerali.kolothum.thodi(a)huawei.com>; Jonathan Cameron > > > <jonathan.cameron(a)huawei.com>; Lorenzo Pieralisi > > > <lpieralisi(a)kernel.org>; Jonathon Burcham <jon.burcham(a)linaro.org>; > > > yangyicong <yangyicong(a)huawei.com>; Hesham Almatary > > > <hesham.almatary(a)huawei.com>; shenyang (M) > <shenyang39(a)huawei.com>; > > > tangchengchang <tangchengchang(a)huawei.com>; Dietmar Eggemann > > > <Dietmar.Eggemann(a)arm.com>; > > > linaro-open-discussions(a)op-lists.linaro.org; > > > lorenzo.pieralisi(a)gmail.com > > > Subject: Re: [Linaro-open-discussions] 回复：Re: 回复：Li > > > =?utf-8?Q?naro-open-discussions_call_on_May___24th > > > > > > Hi, > > > > > > Moving to July 5th is fine by me. > > > > > > For IORT RMR I'd encourage Shameer to ping the mailing list for SMMU > ACKs and not wait till July 5th, I believe I acked the relevant patches. > > > > > > I CC'ed my personal email since the email address I am sending from will > stop working tonight. > > > > > > Thanks, > > > Lorenzo > > > > > > > > > > > > ________________________________________ > > > From: Joyce Qi <joyce.qi(a)linaro.org> > > > Sent: 24 June 2022 15:25 > > > To: Lorenzo Pieralisi > > > Cc: Shameerali Kolothum Thodi; Jonathan Cameron; Lorenzo Pieralisi; > > > Jonathon Burcham; yangyicong; Hesham Almatary; shenyang (M); > > > tangchengchang; Dietmar Eggemann; > > > linaro-open-discussions(a)op-lists.linaro.org > > > Subject: Re: [Linaro-open-discussions] 回复：Re: 回复：Li > > > =?utf-8?Q?naro-open-discussions_call_on_May___24th > > > > > > Hi Lorenzo，Jonathan，Shameerali， > > > > > > Thanks for all your feedback，So can we move the LOD to July 5th for > > > the SPDM discussions？ > > > If that’s ok，I can reschedule the LDO meeting. > > > > > > Thanks:) > > > Joyce > > > > > > > > > > > >> 在 2022年6月24日，下午8:51，Lorenzo Pieralisi > <Lorenzo.Pieralisi(a)arm.com> > > >> 写道： > > >> > > >> Hi, > > >> > > >> I am traveling, I am interested on the SPDM discussions, I did not > > >> think there is much left to do wrt IORT RMR (other than merging it > > >> and decide who does that) but we can talk on thursday, just use > > >> lorenzo.pieralisi(a)gmail.com please to send the invite. > > >> > > >> If we can talk week starting July 4th honestly it would even be > > >> better. > > >> > > >> Thanks, > > >> Lorenzo > > >> > > >> ________________________________________ > > >> From: joyce.qi--- via Linaro-open-discussions > > >> <linaro-open-discussions(a)op-lists.linaro.org> > > >> Sent: 24 June 2022 11:33 > > >> To: Shameerali Kolothum Thodi; Jonathan Cameron; Lorenzo Pieralisi > > >> Cc: Jonathon Burcham; yangyicong; Hesham Almatary; shenyang (M); > > >> tangchengchang; Dietmar Eggemann; > > >> linaro-open-discussions(a)op-lists.linaro.org > > >> Subject: [Linaro-open-discussions] 回复：Re: 回复：Li > > >> =?utf-8?Q?naro-open-discussions_call_on_May___24th > > >> > > >> Hi Jonanthan，Shameerali， > > >> Thanks a lot for your input here：） > > >> @Lorenzo， > > >> Are you available on next Thuesday’s LOD meeting for checking the > > >> status on IORT RMR series Shameerali has brought up？ > > >> Thanks：） > > >> Joyce > > >> > > >> -------- 原始邮件 -------- > > >> 发件人： Shameerali Kolothum Thodi > > >> <shameerali.kolothum.thodi(a)huawei.com> > > >> 日期： 2022年6月24日周五傍晚5:24 > > >> 收件人： Jonathan Cameron <jonathan.cameron(a)huawei.com>, > > >> joyce.qi(a)linaro.org, Lorenzo Pieralisi <lpieralisi(a)kernel.org> > > >> 抄送： Jonathon Burcham <jon.burcham(a)linaro.org>, yangyicong > > >> <yangyicong(a)huawei.com>, Hesham Almatary > > >> <hesham.almatary(a)huawei.com>, "shenyang (M)" > > >> <shenyang39(a)huawei.com>, tangchengchang > > >> <tangchengchang(a)huawei.com>, Dietmar Eggemann > > >> <dietmar.eggemann(a)arm.com>, > > >> linaro-open-discussions(a)op-lists.linaro.org > > >> 主题： RE: [Linaro-open-discussions] Re: 回复：Li > > >> =?utf-8?Q?naro-open-discussions_call_on_May___24th > > >>> -----Original Message----- > > >>> From: Jonathan Cameron via Linaro-open-discussions > > >>> [mailto:linaro-open-discussions@op-lists.linaro.org] > > >>> Sent: 24 June 2022 10:13 > > >>> To: joyce.qi(a)linaro.org > > >>> Cc: Jonathan Cameron via Linaro-open-discussions > > >>> <linaro-open-discussions(a)op-lists.linaro.org>; Jonathon Burcham > > >>> <jon.burcham(a)linaro.org>; yangyicong <yangyicong(a)huawei.com>; > > >>> Hesham Almatary <hesham.almatary(a)huawei.com>; shenyang (M) > > >>> <shenyang39(a)huawei.com>; tangchengchang > > >>> <tangchengchang(a)huawei.com>; Dietmar Eggemann > > >>> <dietmar.eggemann(a)arm.com> > > >>> Subject: [Linaro-open-discussions] Re: 回复：Linaro-open-discussions > > >> call on > > >>> May 24th > > >>> > > >>> > > >>> Hi Joyce, > > >>> > > >>> Thanks for the reminder. I don’t think it is worth discussing at > > >> LOD as not > > >>> the right people on the call, but I would like to draw attention > > >>> to a > > >> thread > > >>> discussing whether to propose a SPDM BoF at Linux Plumbers: > > >>> > https://lore.kernel.org/linux-cxl/20220609124702.000037b0@Huawei.c > > >>> om/ > > >>> > > >>> At the moment I plan to speculatively put in a proposal, but may > > >> withdraw it > > >>> if not enough people would be involved to make useful progress. > > >>> The big ‘discussion’ point is how much to do in kernel vs in > > >> Userspace. > > >>> > > >>> I’ve just polled some of my colleagues for any other topics they > > >> would like to > > >>> raise on LOD, but for now I don’t have anything ready to talk about. > > >> If Lorenzo is around, would like to check the status on IORT RMR > > >> series. > > >> I have sent out the v13 here, > > >> > > >> https://lore.kernel.org/linux-acpi/20220615101044.1972-8-shameerali > > >> .kol > > >> othum.thodi(a)huawei.com/T/ > > >> Thanks, > > >> Shameer > > >>> Thanks, > > >>> > > >>> Jonathan > > >>> > > >>> > > >>> From: joyce.qi(a)linaro.org <joyce.qi(a)linaro.org> > > >>> Sent: 24 June 2022 10:06 > > >>> To: Jonathan Cameron <jonathan.cameron(a)huawei.com> > > >>> Cc: Jonathan Cameron via Linaro-open-discussions > > >>> <linaro-open-discussions(a)op-lists.linaro.org>; Lorenzo Pieralisi > > >>> <lorenzo.pieralisi(a)arm.com>; Jonathon Burcham > > >> <jon.burcham(a)linaro.org>; > > >>> yangyicong <yangyicong(a)huawei.com>; Hesham Almatary > > >>> <hesham.almatary(a)huawei.com>; shenyang (M) > > >>> <shenyang39(a)huawei.com>; tangchengchang > > >>> <tangchengchang(a)huawei.com>; Dietmar Eggemann > > >>> <dietmar.eggemann(a)arm.com> > > >>> Subject: 回复：[Linaro-open-discussions] Linaro-open-discussions call > > >>> on May 24th > > >>> > > >>> Hi Jonanthan，all > > >>> > > >>> Do you have anything to sync during next week's LOD meeting? > > >>> > > >>> Thanks > > >>> Joyce > > >>> > > >>> > > >>> -------- 原始邮件 -------- > > >>> 发件人： Joyce Qi <joyce.qi(a)linaro.org<mailto:joyce.qi@linaro.org>> > > >>> 日期： 2022年5月24日周二早上7:08 > > >>> 收件人： Jonathan Cameron > > >>> > <jonathan.cameron(a)huawei.com<mailto:jonathan.cameron@huawei.com>> > > >>> 抄送： Jonathan Cameron via Linaro-open-discussions > > >>> > > >> > > >> <linaro-open-discussions(a)op-lists.linaro.org<mailto:linaro-open-dis > > >> cuss > > >> ions > > >>> @op-lists.linaro.org>>, Lorenzo Pieralisi > > >>> <lorenzo.pieralisi(a)arm.com<mailto:lorenzo.pieralisi@arm.com>>, > > >> Jonathon > > >>> Burcham <jon.burcham(a)linaro.org<mailto:jon.burcham@linaro.org>>, > > >>> yangyicong > <yangyicong(a)huawei.com<mailto:yangyicong@huawei.com>>, > > >>> Hesham Almatary > > >>> > <hesham.almatary(a)huawei.com<mailto:hesham.almatary@huawei.com>>, > > >>> "shenyang (M)" > > >>> <shenyang39(a)huawei.com<mailto:shenyang39@huawei.com>>, > > >>> tangchengchang > > >>> > <tangchengchang(a)huawei.com<mailto:tangchengchang@huawei.com>>, > > >>> Dietmar Eggemann > > >>> <dietmar.eggemann(a)arm.com<mailto:dietmar.eggemann@arm.com>> > > >>> 主题： Re: [Linaro-open-discussions] Linaro-open-discussions call on > > >> May > > >>> 24th > > >>> Hi Jonathan,all > > >>> > > >>> Thanks for the confirm. > > >>> I will cancel today’s meeting since no topic:) > > >>> > > >>> Thanks:) > > >>> Joyce > > >>> > > >>> 在 2022年5月20日，下午7:10，Jonathan Cameron > > >>> > <jonathan.cameron(a)huawei.com<mailto:jonathan.cameron@huawei.com>> > > >>> 写道： > > >>> > > >>> Hi Joyce, > > >>> > > >>> Nothing to discuss from me. Anyone else have anything they want > > >>> to > > >> bring > > >>> up? > > >>> > > >>> Thanks, > > >>> > > >>> Jonathan > > >>> > > >>> > > >>> From: Joyce Qi <joyce.qi(a)linaro.org<mailto:joyce.qi@linaro.org>> > > >>> Sent: 18 May 2022 10:37 > > >>> To: Jonathan Cameron > > >>> > <jonathan.cameron(a)huawei.com<mailto:jonathan.cameron@huawei.com>> > > >>> Cc: Jonathan Cameron via Linaro-open-discussions > > >>> > > >> > > >> <linaro-open-discussions(a)op-lists.linaro.org<mailto:linaro-open-dis > > >> cuss > > >> ions > > >>> @op-lists.linaro.org>>; Lorenzo Pieralisi > > >>> <lorenzo.pieralisi(a)arm.com<mailto:lorenzo.pieralisi@arm.com>>; > > >> Jonathon > > >>> Burcham <jon.burcham(a)linaro.org<mailto:jon.burcham@linaro.org>>; > > >>> yangyicong > <yangyicong(a)huawei.com<mailto:yangyicong@huawei.com>>; > > >>> Hesham Almatary > > >>> > <hesham.almatary(a)huawei.com<mailto:hesham.almatary@huawei.com>>; > > >>> shenyang (M) > > >>> <shenyang39(a)huawei.com<mailto:shenyang39@huawei.com>>; > > >>> tangchengchang > > >>> > <tangchengchang(a)huawei.com<mailto:tangchengchang@huawei.com>>; > > >>> Dietmar Eggemann > > >>> <dietmar.eggemann(a)arm.com<mailto:dietmar.eggemann@arm.com>> > > >>> Subject: Re: [Linaro-open-discussions] Linaro-open-discussions > > >>> call > > >> on May > > >>> 24th > > >>> > > >>> Hi Jonathan, Lorenz ,all, > > >>> > > >>> Do you have any topic to discuss during the Linaro open > > >>> discussions > > >> next > > >>> Tuesday? > > >>> > > >>> Thanks:) > > >>> Joyce > > >>> > > >>> > > >>> > > >>> 在 2022年4月26日，上午1:45，Jonathan Cameron > > >>> > <Jonathan.Cameron(a)huawei.com<mailto:Jonathan.Cameron@huawei.com> > > > > >>> 写道： > > >>> > > >>> On Fri, 22 Apr 2022 14:00:06 +0100 Jonathan Cameron via > > >>> Linaro-open-discussions > > >>> > > >> > > >> <linaro-open-discussions(a)op-lists.linaro.org<mailto:linaro-open-dis > > >> cuss > > >> ions > > >>> @op-lists.linaro.org>> wrote: > > >>> > > >>> On Fri, 22 Apr 2022 11:33:29 +0100 Lorenzo Pieralisi > > >>> <lorenzo.pieralisi(a)arm.com<mailto:lorenzo.pieralisi@arm.com>> > wrote: > > >>> > > >>> On Fri, Apr 22, 2022 at 10:36:43AM +0100, Jonathan Cameron wrote: > > >>> On Thu, 21 Apr 2022 21:32:01 +0800 Joyce Qi via > > >>> Linaro-open-discussions > > >>> > > >> > > >> <linaro-open-discussions(a)op-lists.linaro.org<mailto:linaro-open-dis > > >> cuss > > >> ions > > >>> @op-lists.linaro.org>> wrote: > > >>> > > >>> Hi Jonathon锟斤拷Lorenzo锟斤拷 > > >>> > > >>> Do we have some topic to discuss for the Linaro-open-disscussions > > >> next > > >>> week? > > >>> > > >>> Thanks:) > > >>> Joyce > > >>> > > >>> Hi Joyce, > > >>> > > >>> Thanks for the reminder. So topics: > > >>> > > >>> RMR: Nothing from our side > > >>> > > >>> vCPUHP: we have a 'working' QEMU tree though it has some known > > >>> problems (doesn't work with SVE for some reason - so some > > >>> debugging > > >> to > > >>> do). Should be able to upload that shortly for anyone else who > > >>> wants to play with it. Any updates on progress of kernel patches > > >>> from ARM side would be good but email is fine for that. > > >>> > > >>> Could not work on them, I need to figure out a plan and quickly, > > >>> we can talk about that though, I should be able to have a clearer > > >>> picture by Tuesday. > > >>> > > >>> I am still using your SPDM stack and there are a couple of things > > >>> I don't get (eg CHALLENGE_AUTH signature verification, RSA path, > > >>> spdm_asym_rsassa_3072 path in spdm_verify_signature() - just > > >>> wanted to ask if you tested this path, I am struggling with > > >>> signature verification - just wanted to ask in particular about > > >>> the need for > > >>> ASN.1 encoding to use verify_signature()). > > >>> > > >>> Tested this again and it seems to be working (tm) > > >>> > > >>> Here are the logs... Just in case you fancy hand decoding the > > >> exchange. > > >>> > > >>> Sig should be the very last bit of the last message (ignoring the > > >>> 00 > > >> pad IIRC) > > >>> > > >>> Platform Port Transmit Command: 00 00 00 01 Platform Port Transmit > > >>> TransportType: 00 00 00 02 Platform Port Transmit Size: 00 00 00 > > >>> 0c Platform Port Transmit Buffer: 01 00 01 00 03 00 00 00 10 84 00 > > >>> 00 Platform Port Receive Command: 00 00 00 01 Platform Port > > >>> Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 00 14 > > >>> Platform Port Receive Buffer: 01 00 01 00 05 00 00 00 10 04 00 00 > > >>> 00 > > >> 03 00 > > >>> 10 00 11 00 12 > > >>> Platform Port Transmit Command: 00 00 00 01 Platform Port Transmit > > >>> TransportType: 00 00 00 02 Platform Port Transmit Size: 00 00 00 > > >>> 0c Platform Port Transmit Buffer: 01 00 01 00 03 00 00 00 10 84 00 > > >>> 00 Platform Port Receive Command: 00 00 00 01 Platform Port > > >>> Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 00 14 > > >>> Platform Port Receive Buffer: 01 00 01 00 05 00 00 00 10 04 00 00 > > >>> 00 > > >> 03 00 > > >>> 10 00 11 00 12 > > >>> Platform Port Transmit Command: 00 00 00 01 Platform Port Transmit > > >>> TransportType: 00 00 00 02 Platform Port Transmit Size: 00 00 00 > > >>> 14 Platform Port Transmit Buffer: 01 00 01 00 05 00 00 00 11 e1 > > >>> 00 00 > > >> 00 02 > > >>> 00 00 c6 f7 00 00 > > >>> Platform Port Receive Command: 00 00 00 01 Platform Port Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 00 14 > > >>> Platform Port Receive Buffer: 01 00 01 00 05 00 00 00 11 61 00 00 > > >>> 00 > > >> 00 00 > > >>> 00 f7 fb 00 00 > > >>> Platform Port Transmit Command: 00 00 00 01 Platform Port Transmit > > >>> TransportType: 00 00 00 02 Platform Port Transmit Size: 00 00 00 > > >>> 38 Platform Port Transmit Buffer: 01 00 01 00 0e 00 00 00 11 e3 > > >>> 04 00 > > >> 30 00 > > >>> 01 00 94 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > >>> 00 > > >> 00 > > >>> 00 00 02 20 1b 00 03 20 06 00 04 20 94 00 05 20 01 00 Platform > > >>> Port Receive Command: 00 00 00 01 Platform Port Receive > > >>> TransportType: 00 > > >>> 00 00 02 Platform Port Receive Size: 00 00 00 3c Platform Port > > >>> Receive Buffer: 01 00 01 00 0f 00 00 00 11 63 04 00 34 > > >> 00 > > >>> 01 00 08 00 00 00 04 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 > > >>> 00 > > >> 00 > > >>> 00 00 00 00 00 00 02 20 10 00 03 20 02 00 04 20 04 00 05 20 01 00 > > >>> Platform Port Transmit Command: 00 00 00 01 Platform Port Transmit > > >>> TransportType: 00 00 00 02 Platform Port Transmit Size: 00 00 00 > > >>> 0c Platform Port Transmit Buffer: 01 00 01 00 03 00 00 00 11 81 00 > > >>> 00 Platform Port Receive Command: 00 00 00 01 Platform Port > > >>> Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 00 9c > > >>> Platform Port Receive Buffer: 01 00 01 00 27 00 00 00 11 01 00 07 > > >>> 6b > > >> 3e 6a > > >>> 85 12 30 ed ec 1e 27 0e 6e 96 b0 95 68 eb b0 1f 9a 7a 63 f6 bd 04 > > >>> 0d > > >> 04 cc > > >>> 45 0a 03 b9 aa d6 e7 1b 7e 85 04 ae 18 55 8d 47 58 c4 cd 59 6b 3e > > >>> 6a > > >> 85 12 > > >>> 30 ed ec 1e 27 0e 6e 96 b0 95 68 eb b0 1f 9a 7a 63 f6 bd 04 0d 04 > > >>> cc > > >> 45 0a > > >>> 03 b9 aa d6 e7 1b 7e 85 04 ae 18 55 8d 47 58 c4 cd 59 6b 3e 6a 85 > > >>> 12 > > >> 30 ed > > >>> ec 1e 27 0e 6e 96 b0 95 68 eb b0 1f 9a 7a 63 f6 bd 04 0d 04 cc 45 > > >>> 0a > > >> 03 b9 > > >>> aa d6 e7 1b 7e 85 04 ae 18 55 8d 47 58 c4 cd 59 Platform Port > > >>> Transmit Command: 00 00 00 01 Platform Port Transmit TransportType: > > >>> 00 00 00 02 Platform Port Transmit Size: 00 00 00 10 Platform Port > > >>> Transmit Buffer: 01 00 01 00 04 00 00 00 11 82 00 00 00 > > >> 00 00 > > >>> 80 > > >>> Platform Port Receive Command: 00 00 00 01 Platform Port Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 04 10 > > >>> Platform Port Receive Buffer: 01 00 01 00 04 01 00 00 11 02 00 00 > > >>> 00 > > >> 04 64 > > >>> 0a 64 0e 00 00 99 e0 d4 22 35 22 e5 ba 58 24 e7 1e eb cf 9a 2c b5 > > >>> b5 > > >> 71 10 > > >>> ce aa 50 f5 64 83 78 d8 2d 9e 3b 99 53 74 db 98 d0 6f 63 cd 84 35 > > >>> c5 > > >> 10 cc > > >>> 21 f3 e0 30 82 05 19 30 82 03 01 a0 03 02 01 02 02 14 22 4d 06 18 > > >>> d5 > > >> d4 > > >>> a8 45 bf 5d f5 56 06 47 3f 90 a9 20 21 27 30 0d 06 09 2a 86 48 86 > > >>> f7 > > >> 0d 01 > > >>> 01 0c 05 00 30 1c 31 1a 30 18 06 03 55 04 03 0c 11 69 6e 74 65 6c > > >>> 20 > > >> 74 65 > > >>> 73 74 20 52 53 41 20 43 41 30 1e 17 0d 32 32 30 33 30 33 31 31 33 > > >>> 38 > > >> 34 > > >>> 32 5a 17 0d 33 32 30 32 32 39 31 31 33 38 34 32 5a 30 1c 31 1a 30 > > >>> 18 > > >> 06 > > >>> 03 55 04 03 0c 11 69 6e 74 65 6c 20 74 65 73 74 20 52 53 41 20 43 > > >>> 41 > > >> 30 > > >>> 82 02 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 02 0f > > >>> 00 > > >> 30 82 > > >>> 02 0a 02 82 02 01 00 b6 80 53 6e c7 66 9e 23 0f e9 2a d4 68 59 54 > > >>> ec > > >> bc cd > > >>> dd 1d 37 52 f9 fb 48 ed 9b 8e e5 20 77 a0 57 26 ba a4 e4 44 95 9c > > >>> 13 > > >> 30 36 > > >>> b8 03 39 33 58 4f 0f 19 5f 28 21 ee 52 f4 b0 4c 7b c1 86 94 ed 12 > > >>> cf > > >> 1b 24 > > >>> d2 20 d8 6a 7b 33 86 3e 84 b8 0e 57 06 14 fb ff a5 a7 05 ca 75 0c > > >>> b2 > > >> f0 d7 > > >>> 58 d0 b5 92 de ff a5 82 54 90 35 60 f3 c8 8f 2f 16 5f 89 91 5b 42 > > >>> 14 > > >> 04 23 > > >>> 44 04 54 2f 36 ab f7 29 91 9e 45 46 09 fc d9 45 29 a8 08 83 68 18 > > >>> 58 > > >> d3 7b > > >>> 9a b4 0e 3a b7 08 19 6f c2 7c 14 0f a3 3e fa ad 99 71 35 a5 fc ef > > >>> c1 > > >> 31 93 ae > > >>> db a7 5c 67 e1 e7 ef 53 8b ab 3e 48 6d d1 78 86 84 41 43 97 4d af > > >>> d4 > > >> 55 42 > > >>> 4b 3c 8a 5e c9 bb 10 8a 6e 62 2d bc d6 29 de cf ae 2b f8 66 e0 a8 > > >>> 0e > > >> 9a 86 > > >>> e5 dd fc 85 ae 9c a9 28 a0 7d e8 93 7f cf 1b e2 7a d0 d4 c0 3c 92 > > >>> 88 > > >> 06 ba > > >>> 3a d3 18 3c a1 98 f2 95 3a b5 0c 98 57 97 06 22 91 a7 86 c9 87 a3 > > >>> b1 > > >> da 71 > > >>> d6 14 79 a1 94 5b da fc d5 2e b3 4a 4f c2 8b 4a 99 44 4c da 3b 43 > > >>> 1c > > >> 35 4d > > >>> e1 a7 18 b9 d8 be fb 49 5f a7 51 20 08 e7 43 2b 81 ae da 7f 67 82 > > >>> 50 > > >> a7 4d > > >>> 4a d2 65 04 57 5a 4a 74 66 da f3 58 9a cd 12 49 8e af 3b d8 ee 5c > > >>> 56 > > >> 72 37 > > >>> 2d 8d ca 57 10 d4 b5 cc 35 95 18 76 aa 20 dc 5f 45 b8 19 98 9f b7 > > >>> 94 > > >> 8f 05 > > >>> 9e 3e f8 ee 51 7d 23 47 20 29 07 fa d4 d6 c2 28 4a 79 6a b3 3b ec > > >>> c3 > > >> 64 ee > > >>> 78 4c d2 72 95 74 5b 8c 90 25 d4 11 68 89 fe bc 8e e4 a3 fa d6 b4 > > >>> 6c > > >> 46 63 > > >>> 31 99 25 06 5a 30 85 4a 0e 22 38 b7 33 07 65 11 1b 12 88 0b 71 37 > > >>> 20 > > >> 2b > > >>> 54 00 43 30 24 e9 22 98 1b 6d 6c da 98 02 8d 36 6b 08 1f 03 90 e4 > > >>> bb > > >> dc 0b > > >>> c4 3d b0 00 93 ab d9 11 6f da 04 32 48 3c 61 d0 d6 7b 5d 72 f8 3c > > >>> 85 > > >> 65 9f > > >>> b6 c0 5f 0d a7 1e d6 ad d8 0a a1 70 1f b8 3a f8 8b 4b 99 02 03 01 > > >>> 00 > > >> 01 a3 > > >>> 53 30 51 30 1d 06 03 55 1d 0e 04 16 04 14 b3 c1 9a d7 32 bf 99 6b > > >>> 9f > > >> 77 8a > > >>> 11 f4 fc 24 92 43 f7 f7 ec 30 1f 06 03 55 1d 23 04 18 30 16 80 14 > > >>> b3 > > >> c1 9a > > >>> d7 32 bf 99 6b 9f 77 8a 11 f4 fc 24 92 43 f7 f7 ec 30 0f 06 03 55 > > >>> 1d > > >> 13 01 01 > > >>> ff 04 05 30 03 01 01 ff 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0c 05 > > >>> 00 > > >> 03 82 > > >>> 02 01 00 72 e2 8c aa 49 24 3f e9 53 a6 15 6d a0 da ed b8 ac d7 9b > > >>> fd > > >> 9b 19 > > >>> e3 e1 b4 27 36 79 24 63 03 0b f5 55 6c 22 cc 81 a7 1f 8c 90 d1 3e > > >>> f8 > > >> cd f1 > > >>> 79 8a ae 1f 4c aa 2b 6a 1b a5 4d cf fe 71 44 96 f6 f1 c6 d7 6d 38 > > >>> a5 > > >> fd 95 49 > > >>> fb cb 0f c9 c6 6a 5f d1 85 ff ba e5 cb ef f8 43 de 7e ac 92 2c b3 > > >>> 2c > > >> 57 a6 39 > > >>> f8 d2 ae c4 06 e8 3d 35 01 e7 30 51 74 e2 28 a2 6f 10 69 3d d8 96 > > >>> d8 > > >> 61 f5 > > >>> ff d3 29 86 26 e2 57 23 dc 8d 77 1a 31 f0 6f df a7 50 34 28 4a e3 > > >>> de > > >> 55 d0 > > >>> a2 6f 8a db a1 54 7a ac 9f d3 e8 c5 1f 55 2c 2e fc 37 c9 4c a1 22 > > >>> a4 > > >> e4 20 77 > > >>> Platform Port Transmit Command: 00 00 00 01 Platform Port Transmit > > >>> TransportType: 00 00 00 02 Platform Port Transmit Size: 00 00 00 > > >>> 10 Platform Port Transmit Buffer: 01 00 01 00 04 00 00 00 11 82 00 > > >>> 00 00 > > >> 04 64 > > >>> 0a > > >>> Platform Port Receive Command: 00 00 00 01 Platform Port Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 04 10 > > >>> Platform Port Receive Buffer: 01 00 01 00 04 01 00 00 11 02 00 00 > > >>> 00 > > >> 04 64 > > >>> 06 84 86 e0 3e 11 8b 72 c3 92 16 95 d5 32 0f 81 3d d1 0e d0 f8 3a > > >>> e6 > > >> 20 fe > > >>> d8 ae 5a c1 27 2c 18 1f 60 40 fa 89 10 05 33 f7 35 9d 5c 35 29 0d > > >>> b3 > > >> 26 94 > > >>> 48 eb 75 a3 d5 a8 74 22 80 56 40 cc 74 60 c1 03 d5 32 5d 3d 24 4c > > >>> b3 > > >> 5e b2 > > >>> f5 5b 61 f1 d7 fa 40 71 45 af 67 c5 fc 5a ee 32 10 5f eb 6c 68 be > > >>> 00 > > >> e1 0a e9 > > >>> 23 0d 06 6d fb b8 af 3a 9a 33 d1 b0 eb 89 5f c9 26 ba b8 91 ab cd > > >>> 55 > > >> 90 24 > > >>> 22 1b 3b 15 11 fe 61 22 de ae d7 19 45 b1 bf 09 09 2f c7 8f 57 b1 > > >>> 2b > > >> 37 b5 > > >>> 9d 4d f2 8b 2d ea 29 f5 17 bb 11 2f 5b 59 1b 43 65 d1 60 15 b9 ba > > >>> ca > > >> 0b a4 > > >>> bd 25 ec ba 5d 55 45 ab 02 2d fb 16 3e d6 82 01 a7 62 1a c7 77 77 > > >>> da > > >> 5f 4d > > >>> f2 a2 f5 14 24 e8 ab 63 16 a4 5d f0 ec 5e 1c 9a 72 a2 86 dd 2b ba > > >>> 88 > > >> d5 98 > > >>> 56 c7 1c 63 2e 59 eb 4a a7 df 55 7e 0c 77 ae de 9b 88 e2 93 47 27 > > >>> 62 > > >> c7 d4 > > >>> 0e 5d a4 16 05 ca 78 bd b9 67 d9 e7 c1 c8 41 23 94 de ae 5f e7 b6 > > >>> 50 > > >> 76 d5 > > >>> 4d d5 ce d6 b5 d4 78 53 c0 18 6d 7f c5 f0 34 29 ba 9a 14 ba f2 13 > > >>> 07 > > >> 4a 0f > > >>> e9 bd 1b fa 4e 20 4c 73 5e eb 9a 6d 3c bb 3b 61 e7 bf 71 cc c0 7a > > >>> d2 > > >> bf a7 > > >>> 26 b9 9a bc 2d a0 22 18 12 1d 04 87 30 82 04 a0 30 82 02 88 a0 03 > > >>> 02 > > >> 01 > > >>> 02 02 01 01 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0c 05 00 30 1c 31 > > >>> 1a > > >> 30 18 > > >>> 06 03 55 04 03 0c 11 69 6e 74 65 6c 20 74 65 73 74 20 52 53 41 20 > > >>> 43 > > >> 41 > > >>> 30 1e 17 0d 32 32 30 33 30 33 31 31 34 30 30 33 5a 17 0d 33 32 30 > > >>> 32 > > >> 32 > > >>> 39 31 31 34 30 30 33 5a 30 2b 31 29 30 27 06 03 55 04 03 0c 20 69 > > >>> 6e > > >> 74 > > >>> 65 6c 20 74 65 73 74 20 52 53 41 20 69 6e 74 65 72 6d 65 64 69 61 > > >>> 74 > > >> 65 > > >>> 20 63 65 72 74 30 82 01 a2 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 > > >>> 05 > > >> 00 > > >>> 03 82 01 8f 00 30 82 01 8a 02 82 01 81 00 ab 97 02 85 a7 a4 8c 17 > > >>> 29 > > >> 31 0c > > >>> b2 0d f6 e4 3d 76 00 ce e1 1b 19 9b e9 84 f5 36 10 1f d5 e6 60 fe > > >>> 8a > > >> e4 0a > > >>> 53 63 23 7c f8 57 8d 7f 2b a8 10 78 dd 40 ef a8 65 33 47 a4 fc b6 > > >>> f8 > > >> 23 b3 > > >>> 4b 28 8e c8 98 29 02 55 93 54 35 5d 2c fd d8 a4 5d 02 bb c5 06 61 > > >>> 72 > > >> cb 77 > > >>> a1 f6 ed 83 68 ec 4f a7 17 4b 29 89 52 40 9a f3 09 20 1e 4d e1 98 > > >>> 37 > > >> 70 de > > >>> 7c b9 77 2a 77 3d 41 e3 09 e4 d2 57 87 4b de 19 b9 c7 74 bc ec ac > > >>> 98 > > >> b0 0e > > >>> 2e 36 1e f7 8d 05 ab d4 a2 2b 0b fc a3 61 8d 08 bb ce 74 0a a1 d4 > > >>> b6 > > >> 38 80 > > >>> ab a8 be f3 d1 5d 5f 6e cd c7 4b af 85 2f a5 e1 5e 74 0c c8 be a2 > > >>> 67 > > >> 98 c7 > > >>> 61 45 d7 2a ee 88 93 4f d5 ef 83 11 dc 37 a0 38 20 97 c9 24 c3 3a > > >>> 26 > > >> 69 90 > > >>> 1e da 97 87 51 55 33 ef bc 13 b8 68 e8 da e0 68 53 90 11 03 83 43 > > >>> 85 > > >> f6 69 > > >>> 7c d7 07 d4 51 72 94 f5 44 02 7c cb bf 2e f0 1c d7 5b ac ab a7 ac > > >>> 35 > > >> b7 f4 > > >>> 19 cc 78 86 b6 ac 38 17 b3 37 09 5d b5 3f 65 e1 a8 7e 7b 42 0d cb > > >>> 24 > > >> e9 3d > > >>> fc d8 06 2e bc b3 1b 1c 2f 26 cf d2 24 f4 f7 7b 22 fd f1 6a 4e a9 > > >>> 73 > > >> 0a ea c5 > > >>> 11 b9 d3 07 57 f6 b7 d4 df 66 2a 84 7b ec 0b 77 93 69 d6 06 e1 96 > > >>> 97 > > >> 4c 7e > > >>> 72 51 be a4 d1 d6 41 33 d8 69 41 f8 3f 57 44 48 82 ad 34 26 e1 2f > > >>> f6 > > >> d4 fd > > >>> dd 6f a7 e1 55 69 5c 64 a6 a2 a1 70 aa 6f dd a0 cb 3c 9f ce 87 13 > > >>> 02 > > >> 03 01 > > >>> 00 01 a3 5e 30 5c 30 0c 06 03 55 1d 13 04 05 30 03 01 01 ff 30 0b > > >>> 06 > > >> 03 55 > > >>> 1d 0f 04 04 03 02 01 fe 30 1d 06 03 55 1d 0e 04 16 04 14 c1 3f 34 > > >>> 2e > > >> d9 40 > > >>> de 6a 8d b4 45 ed 8a a0 6b b6 73 03 2b e5 30 20 06 03 55 1d 25 01 > > >>> 01 > > >> ff 04 > > >>> 16 30 14 06 08 2b 06 01 05 05 07 03 01 06 08 2b 06 01 05 05 07 03 > > >>> 02 > > >> 30 > > >>> 0d 06 09 2a 86 48 86 f7 0d 01 01 0c 05 00 03 82 02 01 00 7d 96 9d > > >>> 42 > > >> 20 f4 > > >>> 5c 80 19 d9 31 > > >>> Platform Port Transmit Command: 00 00 00 01 Platform Port Transmit > > >>> TransportType: 00 00 00 02 Platform Port Transmit Size: 00 00 00 > > >>> 10 Platform Port Transmit Buffer: 01 00 01 00 04 00 00 00 11 82 00 > > >>> 00 00 > > >> 08 64 > > >>> 06 > > >>> Platform Port Receive Command: 00 00 00 01 Platform Port Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 04 10 > > >>> Platform Port Receive Buffer: 01 00 01 00 04 01 00 00 11 02 00 00 > > >>> 00 > > >> 04 64 > > >>> 02 d9 f4 22 2b c9 ea 52 0f 3e a8 e1 fb 87 b9 28 8a c6 70 32 5f a5 > > >>> 4e > > >> a9 a2 > > >>> 22 ed 38 36 69 38 20 07 81 f2 b0 80 b6 05 5f b3 26 8b 60 08 ac fa > > >>> db > > >> 78 08 > > >>> 20 c7 c5 3c 70 85 b8 e3 3c 81 45 3e 2b d9 6f e9 bf bf b9 d7 59 bd > > >>> 80 > > >> 46 87 > > >>> 08 f8 72 1e 44 b6 c4 17 2e 0e fe 51 28 d3 a5 d4 18 7e b6 64 ba 45 > > >>> 4f > > >> bc 51 > > >>> dd 38 70 e7 1f 0f 07 4d 75 b5 3e 2c 95 ca 11 0b a7 12 0f 25 8d ed > > >>> 0a > > >> 4b 6f > > >>> 96 e2 14 22 2d f7 96 64 6a c9 3a eb 09 71 89 ae 8d 82 2e 31 d6 46 > > >>> 58 > > >> 6c 85 > > >>> 3b dc 14 1f c3 5c b3 02 fe ef 26 f1 8a d3 70 50 88 45 bd c8 f7 57 > > >>> 24 > > >> 1b ef 01 > > >>> 8b 84 42 30 bb 1b 51 f4 e5 c2 02 6f ae 42 1d 4c a8 08 b2 75 c8 9b > > >>> 6c > > >> 6f 75 > > >>> e9 97 4a b3 f3 17 54 90 3b 1d c1 c7 e7 08 8a 88 5f 42 67 b5 04 4d > > >>> 4f > > >> b8 b9 > > >>> 5f 60 69 3a 1b 6a ee 39 3d 72 09 c4 80 5e 89 15 12 87 39 68 63 7c > > >>> 65 > > >> ed b4 > > >>> f1 12 d9 b9 82 30 74 0b aa 40 14 e0 33 f7 98 af 31 db e8 81 62 92 > > >>> e6 > > >> fc 9b > > >>> 6b 88 f9 cc c1 e4 6f 95 d2 86 f2 34 8f 48 c7 37 45 8e 25 07 26 f7 > > >>> 18 > > >> 75 04 > > >>> 12 e6 16 6f 50 09 26 c9 8e 36 3e 41 6d 90 d0 31 13 e9 47 3c c9 c4 > > >>> f3 > > >> c1 b0 > > >>> 1c 20 1c c8 95 4d 18 8d 46 83 35 fa 95 03 36 88 68 55 df a3 8d 79 > > >>> 9b > > >> eb 16 > > >>> bf 88 38 10 db 8c c2 f1 20 1b 36 a7 3b 44 26 bd c1 29 7f 02 98 a7 > > >>> 31 > > >> aa cd > > >>> 60 c7 ee 15 a4 b2 be 66 07 47 ea 89 95 5f 32 c6 bf 2e b5 66 46 5a > > >>> e1 > > >> 79 f2 > > >>> cd 4a 39 e0 9d f1 74 2f 00 6b e4 60 20 88 f0 53 83 26 6d ee ac a6 > > >>> f6 > > >> 54 47 > > >>> e2 7a 58 a6 29 1d c7 50 a9 91 0c 68 ff fd 7b 25 a2 f3 34 b2 15 bd > > >>> f4 > > >> 7d cf 9e > > >>> f1 4c 0d 86 39 b2 3e 80 e9 94 15 55 c8 af 8c d2 a9 6e 61 ce e5 23 > > >>> 22 > > >> dc 4e > > >>> b8 1c 41 68 7a b2 30 23 1c f2 6e 22 2e bd cc 6a 99 0b 1b eb 58 05 > > >>> 1c > > >> 04 c3 > > >>> 30 82 04 6b 30 82 02 d3 a0 03 02 01 02 02 01 03 30 0d 06 09 2a 86 > > >>> 48 > > >> 86 > > >>> f7 0d 01 01 0c 05 00 30 2b 31 29 30 27 06 03 55 04 03 0c 20 69 6e > > >>> 74 > > >> 65 6c > > >>> 20 74 65 73 74 20 52 53 41 20 69 6e 74 65 72 6d 65 64 69 61 74 65 > > >>> 20 > > >> 63 > > >>> 65 72 74 30 1e 17 0d 32 32 30 33 30 33 31 31 34 30 32 34 5a 17 0d > > >>> 33 > > >> 32 > > >>> 30 32 32 39 31 31 34 30 32 34 5a 30 28 31 26 30 24 06 03 55 04 03 > > >>> 0c > > >> 1d > > >>> 69 6e 74 65 6c 20 74 65 73 74 20 52 53 41 20 72 65 73 70 6f 6e 64 > > >>> 65 > > >> 72 20 > > >>> 63 65 72 74 30 82 01 a2 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 > > >>> 00 > > >> 03 > > >>> 82 01 8f 00 30 82 01 8a 02 82 01 81 00 a3 d7 6e f3 b7 4f 50 46 6c > > >>> 67 > > >> 7f 61 > > >>> 1a 30 85 a7 5a 8d b9 1f 29 76 86 57 5c cd 5c 20 fe b3 74 59 20 69 > > >>> 5e > > >> 8f de > > >>> 22 cb a8 e9 f0 fb 3a 1a 45 be ef 50 46 b3 fc fe 74 ea e5 9d 0e 8d > > >>> 3e > > >> b8 13 a5 > > >>> d2 7b 67 49 f6 6b 2d 7c 97 64 d1 24 ae c4 25 3f bf 67 9a 27 5d 72 > > >>> df > > >> 23 87 > > >>> d9 53 ba 8d de a7 3d cd e4 1c 9f 66 50 f4 e0 b7 96 97 36 2b 1a f6 > > >>> 38 > > >> d8 7e > > >>> 0e c4 70 bc 7c 00 4a 74 89 9b 62 a5 82 d9 6a 69 b7 23 aa 74 9e ef > > >>> 7c > > >> b9 59 > > >>> 12 4c 8f 4e a2 42 5c d1 32 54 39 ea ca 64 e0 33 50 6c df f5 12 8e > > >>> 1c > > >> 3d 51 > > >>> fe da b8 57 6e 7b 42 2d b6 ec 21 92 af 08 f2 89 c8 19 a4 d5 32 56 > > >>> 62 > > >> c2 a3 > > >>> f5 cc ec d4 eb 07 74 28 a5 5c 0b 1c 7a 4e 03 3a d5 c8 4e 39 25 4a > > >>> 9b > > >> ce 9a > > >>> 63 1a 15 2c 98 4b 64 04 2c 9b 7d 92 32 36 33 60 8b ec 2c a8 5d 95 > > >>> 74 > > >> 06 3f > > >>> 83 cb 62 12 84 b8 dd 68 eb 1c 18 6b 84 cc b6 ef 4f a8 3b e1 0f 0a > > >>> 09 > > >> 46 c6 > > >>> 0f fe 24 55 8c 85 a1 3d 37 b1 ff 29 55 5b 23 f1 91 df cc 9d 38 48 > > >>> 72 > > >> 0a 55 > > >>> b7 45 42 25 c3 05 67 b4 bc 17 cd fd a3 7b 1c e4 d8 b1 8b 42 b2 47 > > >>> 1b > > >> b7 99 > > >>> 4d 8a fd fe 52 80 94 58 e0 81 37 9a 91 61 93 e4 49 5e 69 16 32 4c > > >>> 03 > > >> 7c 42 > > >>> 2e d1 > > >>> Platform Port Transmit Command: 00 00 00 01 Platform Port Transmit > > >>> TransportType: 00 00 00 02 Platform Port Transmit Size: 00 00 00 > > >>> 10 Platform Port Transmit Buffer: 01 00 01 00 04 00 00 00 11 82 00 > > >>> 00 00 > > >> 0c 64 > > >>> 02 > > >>> Platform Port Receive Command: 00 00 00 01 Platform Port Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 02 74 > > >>> Platform Port Receive Buffer: 01 00 01 00 9d 00 00 00 11 02 00 00 > > >>> 64 > > >> 02 00 > > >>> 00 74 4f e8 47 58 28 7f 27 57 6b 66 80 29 5e cb b2 b2 a3 61 29 77 > > >>> 55 > > >> 2f 44 > > >>> 6e 47 c8 c5 93 ec 90 96 55 fc 6b 27 03 2a 9e ef 28 b5 49 05 02 03 > > >>> 01 > > >> 00 01 > > >>> a3 81 9c 30 81 99 30 0c 06 03 55 1d 13 01 01 ff 04 02 30 00 30 0b > > >>> 06 > > >> 03 55 > > >>> 1d 0f 04 04 03 02 05 e0 30 1d 06 03 55 1d 0e 04 16 04 14 86 f9 ed > > >>> fa > > >> 46 3d > > >>> 7b 2b 5c 16 29 72 c6 b2 4b af b9 b2 8b df 30 31 06 03 55 1d 11 04 > > >>> 2a > > >> 30 28 > > >>> a0 26 06 0a 2b 06 01 04 01 83 1c 82 12 01 a0 18 0c 16 41 43 4d 45 > > >>> 3a > > >> 57 > > >>> 49 44 47 45 54 3a 31 32 33 34 35 36 37 38 39 30 30 2a 06 03 55 1d > > >>> 25 > > >> 01 > > >>> 01 ff 04 20 30 1e 06 08 2b 06 01 05 05 07 03 01 06 08 2b 06 01 05 > > >>> 05 > > >> 07 03 > > >>> 02 06 08 2b 06 01 05 05 07 03 09 30 0d 06 09 2a 86 48 86 f7 0d 01 > > >>> 01 > > >> 0c > > >>> 05 00 03 82 01 81 00 81 69 45 3a 56 b5 12 ee 27 57 12 e1 bd 60 b6 > > >>> ca > > >> c6 a4 > > >>> d1 67 8c 8a e4 7c 9f e2 6f 9d b0 6e 6e e1 5d d8 b6 53 ac fb 68 d3 > > >>> ee > > >> 55 fc > > >>> 04 69 ba 33 8d a0 9b cd 2c 6e a4 fd 04 0e ac 5c d4 2f ce d1 89 d9 > > >>> 7e > > >> a1 e1 > > >>> b4 0c 7c 79 bd 2c 51 50 2a 01 7d 06 82 87 f0 1c f3 72 3b 14 6c 45 > > >>> e0 > > >> 6b 25 > > >>> 88 27 8e cb ec 21 98 c0 09 da 78 cc e7 39 10 0d d4 1a c2 0c 6d 31 > > >>> 2e > > >> 3a 5f > > >>> 34 f9 ea 5c 10 c1 90 3a a1 ff 46 7d 16 77 a6 7c b7 f5 ce bf 57 6a > > >>> 73 > > >> e0 bf f7 > > >>> 22 ba 57 d4 a0 b5 67 8c 1e 8c 9c 9b e6 ee 9a 0b 75 69 26 ce 78 de > > >>> 24 > > >> 21 85 > > >>> 99 22 95 c5 fd a3 8a 1d c8 96 80 6a 26 aa c3 59 d9 de a7 31 03 59 > > >>> 78 > > >> 58 db > > >>> c3 7d 0e 3f 97 50 b4 0f 53 41 0d 4b dd 66 8d bb 57 b6 f7 f7 fb 43 > > >>> 9e > > >> 25 3c > > >>> bc fa 20 84 bc 5d f8 71 3b af 6a e1 b1 84 41 d5 17 00 1d 9d 83 59 > > >>> b2 > > >> ce bd > > >>> 40 5a ba c6 52 45 2c 49 ff 10 d4 a1 e9 19 11 b5 3a 87 cc 74 76 f6 > > >>> 4d > > >> 07 92 > > >>> f1 98 53 07 96 89 9e 6c 70 cf 2e 2c 7d f1 dd d3 26 0a a8 39 23 1f > > >>> 5c > > >> 60 e7 > > >>> 32 13 61 04 94 f9 ff 21 2a 00 9c c8 e7 e7 53 ef e0 73 25 be f0 7d > > >>> f9 > > >> bd 49 > > >>> 08 dd c0 1b 68 67 87 a2 8f 8b ed 95 12 dd 01 fc ac 10 b7 d3 60 dc > > >>> 03 > > >> 2e 8d > > >>> ee 9b 85 1c 56 d5 a8 1d bb 0b 75 91 d7 b9 5d b5 f8 57 4f c5 4e 02 > > >>> 34 > > >> 76 a4 > > >>> cd b9 42 c4 58 de 57 dc 75 31 e3 6c 2e 65 d0 Platform Port > > >>> Transmit > > >>> Command: 00 00 00 01 Platform Port Transmit TransportType: 00 00 > > >>> 00 > > >>> 02 Platform Port Transmit Size: 00 00 00 2c > > >>> > > >>> //This is the challenge auth. > > >>> Platform Port Transmit Buffer: 01 00 01 00 0b 00 00 00 11 83 00 00 > > >>> af > > >> 2c d9 > > >>> aa cb 59 67 ce 3f 7b 8f a5 26 00 4e 1f 1c 4e c3 1e 31 06 be 0d 9e > > >>> 4f > > >> f8 b1 7c > > >>> 2a 39 89 > > >>> Platform Port Receive Command: 00 00 00 01 Platform Port Receive > > >>> TransportType: 00 00 00 02 Platform Port Receive Size: 00 00 01 e0 > > >>> Platform Port Receive Buffer: 01 00 01 00 78 00 00 00 11 03 80 01 > > >>> 6b > > >> 3e 6a > > >>> 85 12 30 ed ec 1e 27 0e 6e 96 b0 95 68 eb b0 1f 9a 7a 63 f6 bd 04 > > >>> 0d > > >> 04 cc > > >>> 45 0a 03 b9 aa d6 e7 1b 7e 85 04 ae 18 55 8d 47 58 c4 cd 59 61 17 > > >>> 8f > > >> cf a6 > > >>> 2d 0d e2 aa 90 91 06 7c 8e 3b 8b a7 64 7c 72 09 b2 9c 89 5b f1 30 > > >>> 47 > > >> e7 5b > > >>> 07 58 00 00 9c 43 d9 7b a3 ae c7 d4 bd 5e a8 db 74 b3 81 97 10 6e > > >>> 2f > > >> 22 5a > > >>> 26 c0 09 02 43 1d c1 3b dd cf e8 13 33 ff dc 02 39 15 2b 98 16 b5 > > >>> eb > > >> 8e 63 > > >>> 32 5a 3e 2a 6a 00 96 8e 42 5d 11 46 a6 7e d5 a8 76 11 94 2c a8 2c > > >>> c7 > > >> 6d 48 > > >>> 94 80 a0 fd 9a 7e 4a 84 59 c0 25 17 7d 0f d5 0d 93 75 02 1e 61 ef > > >>> 5e > > >> 5d 06 > > >>> 80 64 4d 6a 47 91 c7 b1 ca e3 d5 ab b3 6c 97 8a f0 56 39 e6 3d a0 > > >>> ad > > >> 96 20 > > >>> 14 43 fc 83 5d 21 08 78 e8 85 69 a0 d2 e6 9a c9 a9 f6 96 66 ee 80 > > >>> a6 > > >> 06 a6 > > >>> a6 ee cb 9b 7c e4 65 5f a5 0c 5a d9 5e de 50 d1 ab 73 8b c4 f7 3a > > >>> f2 > > >> 62 59 > > >>> 27 16 fa 42 1b e1 db 19 76 a8 40 06 25 d3 28 54 bf dd d4 75 1e 4f > > >>> 40 > > >> d0 c4 > > >>> 3e 1e 60 e7 4b 9b c9 c8 98 db a4 74 8f 86 39 ae 76 9c f9 c9 fe 63 > > >>> ef > > >> 34 ab > > >>> 4d 0b 14 22 d0 d6 9e a3 fd 12 ab c3 7c 61 fd ea 09 dc 2d ad 78 6e > > >>> ce > > >> 13 2b > > >>> 95 36 83 34 3a 1b ef d3 fd 07 de b2 df c7 7a 83 bd 6e ab 51 70 99 > > >>> 4e > > >> 28 07 > > >>> de 63 42 ab 81 96 79 7f 30 27 28 4a 3e a1 8f 42 5f 7d cd 8f ec 86 > > >>> e0 > > >> ea 2b > > >>> fb 05 c2 ce ce 69 ae 4e 5c dd 95 85 11 23 a3 80 85 40 65 e3 a1 92 > > >>> 18 > > >> 9a dc > > >>> 31 ac 13 24 a3 a9 b9 5c 95 f5 b5 b5 08 ee 7d d8 ff 44 42 77 c4 09 > > >>> 25 > > >> 35 7c > > >>> b4 0b 64 77 ea 74 19 b7 b0 c1 04 6d 42 7e ab 32 91 e5 b1 59 2d 60 > > >>> 31 > > >> 11 5f > > >>> 38 52 36 d0 ba c0 73 d5 fb 5c b6 82 a1 00 00 > > >>> > > >>> from spdm_emu last message is better formatted. > > >>> > > >>> SpdmReceiveRequest[0] (0x24): > > >>> 0000: 11 83 00 00 af 2c d9 aa cb 59 67 ce 3f 7b 8f a5 26 00 4e 1f > > >>> 1c > > >> 4e c3 > > >>> 1e 31 06 be 0d 9e 4f f8 b1 > > >>> 0020: 7c 2a 39 89 > > >>> SpdmSendResponse[0] ... > > >>> m1m2 hash - 6b c2 91 d6 c1 fe 1c 5e c9 bf 04 f6 fd 0f b1 58 9d 56 > > >>> d3 > > >> af 69 > > >>> 08 3b eb 06 ba 6d b0 d2 e2 33 46 8a d8 ff 4d 9a 44 13 d2 04 57 e9 > > >>> b9 > > >> ce b7 > > >>> b2 05 > > >>> SpdmSendResponse[0] (0x1d6): > > >>> 0000: 11 03 80 01 6b 3e 6a 85 12 30 ed ec 1e 27 0e 6e 96 b0 95 68 > > >>> eb > > >> b0 1f > > >>> 9a 7a 63 f6 bd 04 0d 04 cc > > >>> 0020: 45 0a 03 b9 aa d6 e7 1b 7e 85 04 ae 18 55 8d 47 58 c4 cd 59 > > >>> 61 > > >> 17 8f > > >>> cf a6 2d 0d e2 aa 90 91 06 > > >>> 0040: 7c 8e 3b 8b a7 64 7c 72 09 b2 9c 89 5b f1 30 47 e7 5b 07 58 > > >>> 00 > > >> 00 9c > > >>> 43 d9 7b a3 ae c7 d4 bd 5e > > >>> 0060: a8 db 74 b3 81 97 10 6e 2f 22 5a 26 c0 09 02 43 1d c1 3b dd > > >>> cf > > >> e8 13 > > >>> 33 ff dc 02 39 15 2b 98 16 > > >>> 0080: b5 eb 8e 63 32 5a 3e 2a 6a 00 96 8e 42 5d 11 46 a6 7e d5 a8 > > >>> 76 > > >> 11 94 > > >>> 2c a8 2c c7 6d 48 94 80 a0 > > >>> 00a0: fd 9a 7e 4a 84 59 c0 25 17 7d 0f d5 0d 93 75 02 1e 61 ef 5e > > >>> 5d > > >> 06 80 > > >>> 64 4d 6a 47 91 c7 b1 ca e3 > > >>> 00c0: d5 ab b3 6c 97 8a f0 56 39 e6 3d a0 ad 96 20 14 43 fc 83 5d > > >>> 21 > > >> 08 78 > > >>> e8 85 69 a0 d2 e6 9a c9 a9 > > >>> 00e0: f6 96 66 ee 80 a6 06 a6 a6 ee cb 9b 7c e4 65 5f a5 0c 5a d9 > > >>> 5e > > >> de 50 > > >>> d1 ab 73 8b c4 f7 3a f2 62 > > >>> 0100: 59 27 16 fa 42 1b e1 db 19 76 a8 40 06 25 d3 28 54 bf dd d4 > > >>> 75 > > >> 1e 4f > > >>> 40 d0 c4 3e 1e 60 e7 4b 9b > > >>> 0120: c9 c8 98 db a4 74 8f 86 39 ae 76 9c f9 c9 fe 63 ef 34 ab 4d > > >>> 0b > > >> 14 22 > > >>> d0 d6 9e a3 fd 12 ab c3 7c > > >>> 0140: 61 fd ea 09 dc 2d ad 78 6e ce 13 2b 95 36 83 34 3a 1b ef d3 > > >>> fd > > >> 07 de > > >>> b2 df c7 7a 83 bd 6e ab 51 > > >>> 0160: 70 99 4e 28 07 de 63 42 ab 81 96 79 7f 30 27 28 4a 3e a1 8f > > >>> 42 > > >> 5f 7d > > >>> cd 8f ec 86 e0 ea 2b fb 05 > > >>> 0180: c2 ce ce 69 ae 4e 5c dd 95 85 11 23 a3 80 85 40 65 e3 a1 92 > > >>> 18 > > >> 9a dc > > >>> 31 ac 13 24 a3 a9 b9 5c 95 > > >>> 01a0: f5 b5 b5 08 ee 7d d8 ff 44 42 77 c4 09 25 35 7c b4 0b 64 77 > > >>> ea > > >> 74 19 > > >>> b7 b0 c1 04 6d 42 7e ab 32 > > >>> 01c0: 91 e5 b1 59 2d 60 31 11 5f 38 52 36 d0 ba c0 73 d5 fb 5c b6 > > >>> 82 > > >> a1 > > >>> > > >>> I vaguely recall the running hash need for a challenge auth being > > >> rather hard > > >>> to get right but I had > > >>> the advantage of being able to compare how both sides built it up. > > >>> > > >>> Jonathan > > >>> > > >>> > > >>> Ah. Been a while, but IIRC correctly the spec doesn't make it > > >>> clear when signatures should be ASN.1. My basis for choosing > > >>> combinations in that code were what libSPDM did at the time. I > > >> remember > > >>> a bunch of trial and error and also hand decoding binary to try to > > >>> figure out what the encodings were. I also enjoyed those places > > >>> where various different ASN.1 encoded structures were concatenated > > >>> rather that encoded in one go - hence no cheap way to index to the > > >>> next one. > > >>> > > >>> I'm reviewing a nice short 972 page spec draft this week (which > > >>> will > > >> remain > > >>> unnamed :) but if I get time I'll see if I can test that path > > >>> before Tuesday. > > >>> > > >>> I think I ran basic tests on all the protocol types, but it was a > > >> long > > >>> time ago so possible I missed one. > > >>> > > >>> I meant to seek a spec clarification but haven't gotten around to > > >>> it > > >> yet. > > >>> Request from DMTF people was to file tickets against he spec for > > >> stuff > > >>> like that. > > >>> > > >>> Jonathan > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> Lorenzo > > >>> > > >>> New Potential topic. > > >>> > > >>> Scheduler Tuneables from NUMA topology. > > >>> > > >>> This is yangyicong's topic but I'll attempt to summarize: > > >>> > > >>> > > >> > > >> > https://lore.kernel.org/lkml/ef3b3e55-8be9-595f-6d54-886d13a7e2fd@h > > >> isi > > >> l > > >>> icon.com/ > > >>> > > >>> The scheduler contains a bunch of tunables including this one > > >>> which > > >> is > > >>> "migration cost" > > >>> This value is used to make decisions in load balancing + to > > >>> control > > >> the > > >>> frequency of load balancing > > >>> to avoid doing it too often. The default value has been fixed for > > >>> a > > >> long time > > >>> and systems have changed a lot in that time. > > >>> > > >>> Currently the value is tunable via debugfs, but in the above > > >>> thread > > >> the > > >>> proposal > > >>> to somehow base the value on the system topology was made. > > >>> > > >>> We haven't yet proceeded very far with this but if we can get > > >> appropriate > > >>> people for > > >>> the call it may be a good opportunity to do some brainstorming, > > >> particularly > > >>> as > > >>> we don't have ready access to that many machine topologies so > > >>> testing > > >> any > > >>> proposal > > >>> will be very challenging. Also I fear this space is only going to > > >>> get > > >> more > > >>> complex > > >>> as systems get larger over the next year or two. > > >>> > > >>> Next week may be too soon for such a discussion though given the > > >> short > > >>> notice! > > >>> > > >>> +CC Vincent and Dietmar, but please drag anyone else in who is > > >> relevant to > > >>> this > > >>> discussion. > > >>> > > >>> I might also mention this topic at the LDCG meeting this week to > > >>> see > > >> if we > > >>> can > > >>> interest from others who might be able to help with data + testing. > > >>> > > >>> Thanks, > > >>> > > >>> Jonathan > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> 锟斤拷 2022锟斤拷4锟斤拷14锟秸ｏ拷锟斤拷锟斤拷8:00锟斤 > 拷 > > >>> > > >> > > >> linaro-open-discussions-request(a)op-lists.linaro.org<mailto:linaro-o > > >> pen- > > >> disc > > >>> ussions-request(a)op-lists.linaro.org>写锟斤拷锟斤拷 > > >>> > > >>> Send Linaro-open-discussions mailing list submissions to > > >>> > > >> > > >> linaro-open-discussions(a)op-lists.linaro.org<mailto:linaro-open-disc > > >> ussi > > >> ons > > >>> @op-lists.linaro.org> > > >>> > > >>> To subscribe or unsubscribe via email, send a message with subject > > >>> or body 'help' to > > >>> > > >> > > >> linaro-open-discussions-request(a)op-lists.linaro.org<mailto:linaro-o > > >> pen- > > >> disc > > >>> ussions-request(a)op-lists.linaro.org> > > >>> > > >>> You can reach the person managing the list at > > >>> > > >> > > >> linaro-open-discussions-owner(a)op-lists.linaro.org<mailto:linaro-ope > > >> n-di > > >> scu > > >>> ssions-owner(a)op-lists.linaro.org> > > >>> > > >>> When replying, please edit your Subject line so it is more > > >>> specific than "Re: Contents of Linaro-open-discussions digest..." > > >>> > > >>> Today's Topics: > > >>> > > >>> 1. Re: LOD Call notes: 22 March 2022 - vCPU Hotplug Update > > >>> (Jonathan Cameron) > > >>> > > >>> > > >>> > > >> > > >> ------------------------------------------------------------------- > > >> --- > > >>> > > >>> Message: 1 > > >>> Date: Wed, 13 Apr 2022 19:17:32 +0100 > > >>> From: Jonathan Cameron > > >>> > <Jonathan.Cameron(a)Huawei.com<mailto:Jonathan.Cameron@Huawei.com > > >>>>> > > >>> Subject: [Linaro-open-discussions] Re: LOD Call notes: 22 March > > >>> 2022 > > >> - > > >>> vCPU Hotplug Update > > >>> To: Ilkka Koskinen > > >>> > <ilkka(a)os.amperecomputing.com<mailto:ilkka@os.amperecomputing.com> > > >>>> > > >>> Cc: > > >>> > > >> > > >> linaro-open-discussions(a)op-lists.linaro.org<mailto:linaro-open-disc > > >> ussi > > >> ons > > >>> @op-lists.linaro.org> > > >>> Message-ID: > > >>> > <20220413191732.00000e4e(a)Huawei.com<mailto:20220413191732.0000 > > >>> 0e4e(a)Huawei.com>> > > >>> Content-Type: text/plain; charset="US-ASCII" > > >>> > > >>> On Thu, 31 Mar 2022 11:47:26 -0700 (PDT) Ilkka Koskinen > > >>> > <ilkka(a)os.amperecomputing.com<mailto:ilkka@os.amperecomputing.com> > > >>> > > > >>> wrote: > > >>> > > >>> Hi everyone, > > >>> > > >>> On Tue, 22 Mar 2022, Jonathan Cameron via Linaro-open-discussions > > >> wrote: > > >>> Hi All, > > >>> > > >>> A quick set of notes on the discussion on vCPU hotplug. > > >>> > > >>> Great to have Ed join the discussion. If we are going to have > > >>> further calls on this topic we may want to move the time to be > > >>> more friendly for the US. > > >>> > > >>> Current status > > >>> * ACPI spec change via code first route approved. > > >>> * Kernel patches being reworked / rebased by ARM. Expected to be > > >>> sent out in 5.19 cycle. > > >>> * QEMU patches being updated by Huawei. Will do at least some > > >>> light testing and then push out a public git tree so that others > > >>> can test - will > > >> aim > > >>> to do this so it aligns with kernel code availability. > > >>> * Ed (Ampere) gave an update to say they are interested in pushing > > >> this > > >>> forwards ASAP and have customer / OS vendor engagement which will > > >>> be very useful in moving towards a complete solution, particularly > > >> ensuring > > >>> good test coverage etc. > > >>> > > >>> Noted that current QEMU patches may not cover all corner cases, > > >>> for example live migration of VMs that have vCPUs hotplugged. > > >>> Might 'just work' > > >>> but we haven't tested it yet so probably not. > > >>> > > >>> Given we didn't really add anything on DOE / SPDM over previous > > >> calls, > > >>> I don't plan to send out anything on that topic this time. > > >>> > > >>> Thanks to Joyce for hosting the call. If I noted down anything > > >> wrong, > > >>> or incomplete let the list know. > > >>> > > >>> Jonathan > > >>> -- > > >>> Linaro-open-discussions mailing list -- > > >>> > > >> > > >> linaro-open-discussions(a)op-lists.linaro.org<mailto:linaro-open-disc > > >> ussi > > >> ons > > >>> @op-lists.linaro.org> > > >>> > > >> > > >> https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+ > > >> Hom > > >> e > > >>> > > >>> Thanks for the great meeting and the update! As Ed mentioned (and > > >>> you wrote above), we're interested in joining the vCPU Hotplug > > >> development. > > >>> > > >>> Hi Ilkka > > >>> > > >>> Great to have you on board for this. > > >>> > > >>> Status wise, on QEMU side we have the new interface up and running > > >>> (it was a whole 2 lines of code once we'd dealt with some rebasing > > >> related > > >>> issues). > > >>> > > >>> Rather more changes were needed to make it work sensibly on top of > > >> Gavin > > >>> Shan's > > >>> QEMU topology configuration patch set. > > >>> > https://lore.kernel.org/qemu-devel/20220403145953.10522-1-gshan@re > > >>> dh > > >>> at.com/ > > >>> The code going through some light internal review before we put it > > >>> up somewhere public. Note it's definitely not production quality > > >>> code but it is > > >> somewhere > > >>> to start from. Given Easter related vacations I doubt we'll get > > >> enough > > >>> eyes on it until next week. > > >>> > > >>> We were thrown briefly by the fact there is a recently added > > >>> apcica/actbl2.h entry for MADT_ONLINE_CAPABLE but it's a different > > >> bit. > > >>> Seems x86 folk wanted something similar last year. We'll have to > > >>> do something ugly in ACPICA to mangle the name for the new bit to > > >>> avoid that > > >> collision. > > >>> Lorenzo, I'm assuming the ACPCIA one line patch to add that define > > >>> is something the ARM team will deal with? > > >>> > > >>> There are some known limitations though that we'll need to sort > > >>> out > > >> before > > >>> upstreaming the QEMU support. One of which is SVE currently breaks > > >> things. > > >>> Plenty of time though as kernel needs to be upstream first anyway. > > >>> > > >>> Testing wise we are using QEMU on top of QEMU so we can poke > > >>> corners > > >> of > > >>> the > > >>> architecture don't have hardware for (e.g. SVE :). Even on a > > >>> rubbish > > >> x86 > > >>> desktop it's not that slow :) > > >>> > > >>> Lorenzo, any update on kernel side of things or expected time > > >>> scale > > >> for > > >>> more information? > > >>> > > >>> Obviously we have some hacked patches based on Salil's original > > >> proposal > > >>> that sanity check the QEMU side of things but I suspect the final > > >> version > > >>> will look rather different :) > > >>> > > >>> One question on the spec change for Lorenzo. It's not entirely > > >>> clear but I think we should not be using _MAT when 'hotplugging' the > vCPUs? > > >>> For now the QEMU code provides the relevant entries anyway but it > > >>> would be nice to drop that if not necessary (it's not a huge > > >>> amount of code or complexity though so not a big thing either way). > > >>> > > >>> Thanks and an early happy Easter to those celebrating on Sunday. > > >>> > > >>> Jonathan > > >>> > > >>> > > >>> Br, Ilkka > > >>> > > >>> > > >>> ------------------------------ > > >>> > > >>> Subject: Digest Footer > > >>> > > >>> Linaro-open-discussions mailing list -- > > >>> > > >> > > >> linaro-open-discussions(a)op-lists.linaro.org<mailto:linaro-open-disc > > >> ussi > > >> ons > > >>> @op-lists.linaro.org> > > >>> To unsubscribe send an email to > > >>> > > >> > > >> linaro-open-discussions-leave(a)op-lists.linaro.org<mailto:linaro-ope > > >> n-di > > >> scus > > >>> sions-leave(a)op-lists.linaro.org> > > >>> > > >>> > > >>> ------------------------------ > > >>> > > >>> End of Linaro-open-discussions Digest, Vol 19, Issue 1 > > >>> ****************************************************** > > >>> > > >>> -- > > >>> Linaro-open-discussions mailing list -- > > >>> linaro-open-discussions(a)op-lists.linaro.org > > >>> > > >> > > >> https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+ > > >> Hom > > >> e > > >> -- > > >> Linaro-open-discussions mailing list -- > > >> linaro-open-discussions(a)op-lists.linaro.org > > >> https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+ > > >> Hom e IMPORTANT NOTICE: The contents of this email and any > > >> attachments are confidential and may also be privileged. If you are > > >> not the intended recipient, please notify the sender immediately and do > not disclose the contents to any other person, use it for any purpose, or store > or copy the information in any medium. Thank you. > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > >

1 year, 5 months

5
14
0 0

Qemu isn't responding with PSCI_DENIED when CPUs are forbidden.

by Salil Mehta

Hi James, > > Qemu isn't responding with PSCI_DENIED when CPUs are forbidden. ('SUCCESS' means you > > hit a 5 second timeout in the guest, on each CPU) I have tested the straight forward case and it works. Could you please elaborate on this so that I can look into the issue? Thanks Salil

1 year, 9 months

3
5
0 0

Re: Linaro-open-discussions Digest, Vol 29, Issue 6

by Joyce Qi

Hi all， Do we have any topic for next open discussion（Feb 28th）？ Thanks：） Joyce > 在 2023年2月24日，上午8:00，linaro-open-discussions-request@op-lists.linaro.org 写道： > > Send Linaro-open-discussions mailing list submissions to > linaro-open-discussions(a)op-lists.linaro.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > linaro-open-discussions-request(a)op-lists.linaro.org > > You can reach the person managing the list at > linaro-open-discussions-owner(a)op-lists.linaro.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Linaro-open-discussions digest..." > > Today's Topics: > > 1. Re: [RFC PATCH v0.1 22/25] ACPI: add support to register CPUs based on the _STA enabled bit > (Vishnu Pajjuri) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Feb 2023 11:40:43 +0530 > From: Vishnu Pajjuri <vishnu(a)amperemail.onmicrosoft.com> > Subject: [Linaro-open-discussions] Re: [RFC PATCH v0.1 22/25] ACPI: > add support to register CPUs based on the _STA enabled bit > To: James Morse <james.morse(a)arm.com>, > linaro-open-discussions(a)op-lists.linaro.org > Message-ID: > <6010811b-6c26-ad52-2a15-f5a55972c108(a)amperemail.onmicrosoft.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi James/Salil, > > On 31-08-2022 16:39, James Morse wrote: >> acpi_processor_get_info() registers all present CPUs. Registering a >> CPU is what creates the sysfs entries and triggers the udev >> notifications. >> >> arm64 virtual machines that support 'virtual cpu hotplug' use the >> enabled bit to indicate whether the CPU can be brought online, as >> the existing ACPI tables require all hardware to be described and >> present. >> >> If firmware describes a CPU as present, but disabled, skip the >> registration. Such CPUs are present, but can't be brought online for >> whatever reason. (e.g. firmware/hypervisor policy). >> >> Once firmware sets the enabled bit, the CPU can be registered and >> brought online by user-space. Online CPUs, or CPUs that are missing >> an _STA method must always be registered. >> >> Signed-off-by: James Morse <james.morse(a)arm.com> >> --- >> drivers/acpi/acpi_processor.c | 31 ++++++++++++++++++++++++++++++- >> 1 file changed, 30 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c >> index 1bd6e4b8ab66..42521d89c378 100644 >> --- a/drivers/acpi/acpi_processor.c >> +++ b/drivers/acpi/acpi_processor.c >> @@ -194,6 +194,32 @@ static int acpi_processor_make_present(struct acpi_processor *pr) >> return ret; >> } >> >> +static int acpi_processor_make_enabled(struct acpi_processor *pr) >> +{ >> + unsigned long long sta; >> + acpi_status status; >> + bool present, enabled; >> + >> + if (!acpi_has_method(pr->handle, "_STA")) >> + return arch_register_cpu(pr->id); >> + >> + status = acpi_evaluate_integer(pr->handle, "_STA", NULL, &sta); >> + if (ACPI_FAILURE(status)) >> + return -ENODEV; >> + >> + present = sta & ACPI_STA_DEVICE_PRESENT; >> + enabled = sta & ACPI_STA_DEVICE_ENABLED; >> + >> + if (cpu_online(pr->id) && (!present || !enabled)) { >> + pr_err_once(FW_BUG "CPU %u is online, but described as not present or disabled!\n", pr->id); >> + add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); >> + } else if (!present || !enabled) { >> + return -ENODEV; >> + } >> + >> + return arch_register_cpu(pr->id); >> +} >> + >> static int acpi_processor_get_info(struct acpi_device *device) >> { >> union acpi_object object = { 0 }; >> @@ -271,7 +297,7 @@ static int acpi_processor_get_info(struct acpi_device *device) >> } >> >> if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id)) { >> - int ret = arch_register_cpu(pr->id); >> + int ret = acpi_processor_make_enabled(pr); >> >> if (ret) >> return ret; >> @@ -479,6 +505,9 @@ static void acpi_processor_remove(struct acpi_device *device) >> acpi_processor_make_not_present(device); >> return; >> } >> + >> + if (cpu_present(pr->id) && !(sta & ACPI_STA_DEVICE_ENABLED)) >> + arch_unregister_cpu(pr->id); >> } >> >> #ifdef CONFIG_X86 > > Enumeration failure while trying to hot plug vcpus after guest reboot > > Following sequence of steps causes the issue > > 1. Boot VM with max 80 vcpus and current 72 vcpus(For example) > 2. hot plug 3 more vcpus > # virsh setvcpus vm2 75 --live > 3. hot unplug 3 vcpus ( which were added earlier ) > # virsh setvcpus vm2 72 --live > 4. reboot VM > # reboot > 5. Again try to hot plug 3 vcpus -- ERROR > # virsh setvcpus vm2 75 --live > [ 47.367823] acpi ACPI0007:48: Enumeration failure > [ 47.565173] acpi ACPI0007:49: Enumeration failure > [ 47.703423] acpi ACPI0007:4a: Enumeration failure > > > I have tested the above scenario with following git repos > > https://github.com/salil-mehta/qemu/tree/virt-cpuhp-armv8/rfc-v1-port290920… > > https://github.com/salil-mehta/linux/tree/virt-cpuhp-arm64/rfc-v2/jmorse-va… > https://gitlab.arm.com/linux-arm/linux-jm/-/tree/virtual_cpu_hotplug/rfc/v/… > > I observed the following sequence while doing hotplug and unplug > > When we do hotplug, making vcpu as *present*(_STA.Pres=1) and > *enabled*(_STA.Enabled=1) > When we do hot unplug, we just *disabled*(_STA.Enabled=0) vcpu but not > *removed*(_STA.Pres=1) > > In such a case CPU shall still be present at the firmware/VMM level and > could be kept disabled > i.e. _STA.Enable=0 and _STA.Present=1 > > After reboot, system is trying to enumerate vcpu(as *present*(_STA.Pres=1)) > and it is marking flags flags.initialized = true and flags.visited = true > > as the vcpu *disabled*(_STA.Enabled=0), vcpu has been made not present > and flags flags.initialized and flags.visited were not cleared > > > And following fix resolves the issue > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index 558664d169fc..e93b933cb8a4 100644 > --- a/drivers/acpi/scan.c > +++ b/drivers/acpi/scan.c > @@ -2158,6 +2158,9 @@ static int acpi_scan_attach_handler(struct > acpi_device *device) > break; > > device->handler = NULL; > + device->flags.initialized = false; > + acpi_device_clear_enumerated(device); > + device->flags.power_manageable = 0; > if (ret < 0) > break; > } > > _Regards_, > -Vishnu. > > ------------------------------ > > Subject: Digest Footer > > Linaro-open-discussions mailing list -- linaro-open-discussions(a)op-lists.linaro.org > To unsubscribe send an email to linaro-open-discussions-leave(a)op-lists.linaro.org > > > ------------------------------ > > End of Linaro-open-discussions Digest, Vol 29, Issue 6 > ******************************************************

1 year, 9 months

1
1
0 0

[RFC PATCH v0.1 00/25] ACPI/arm64: add support for virtual cpuhotplug

by James Morse

Hello! v0.1? Yeah, this is v0 from gitlab, rebased onto v6.0-rc3. This series has only been lightly tested.... --- Hello! This series adds what looks like cpuhotplug support to arm64 for use in virtual machines. It does this by moving the cpu_register() calls for architectures that support ACPI out of the arch code by using GENERIC_CPU_DEVICES, then into the ACPI processor driver. The kubernetes folk really want to be able to add CPUs to an existing VM, in exactly the same way they do on x86. The use-case is pre-booting guests with one CPU, then adding the number that were actually needed when the workload is provisioned. Wait? Doesn't arm64 support cpuhotplug already!? In the arm world, cpuhotplug gets used to mean removing the power from a CPU. The CPU is offline, and remains present. For x86, and ACPI, cpuhotplug has the additional step of physically removing the CPU, so that it isn't present anymore. Arm64 doesn't support this, and can't support it: CPUs are really a slice of the SoC, and there is not enough information in the existing ACPI tables to describe which bits of the slice also got removed. Without a reference machine adding this support to the spec is a wild goose chase. Critically: everything described in the firmware tables must remain present. For a virtual machine this is easy as all the other bits of 'virtual SoC' are emulated, so they can (and do) remain present when a vCPU is 'removed'. On a system that supports cpuhotplug the MADT has to describe every possible CPU at boot. Under KVM, the vGIC needs to know about every possible vCPU before the guest is started. With these constraints, virtual-cpuhotplug is really just a hypervisor/firmware policy about which CPUs can be brought online. This series adds support for virtual-cpuhotplug as exactly that: firmware policy. This may even work on a physical machine too; for a guest the part of firmware is played by the VMM. (typically Qemu). PSCI support is modified to return 'DENIED' if the CPU can't be brought online/enabled yet. The CPU object's _STA method's enabled bit is used to indicate firmware's current disposition. If the CPU has its enabled bit clear, it will not be registered with sysfs, and attempts to bring it online will fail. The notifications that _STA has changed its value then work in the same way, and firmware can cause the CPU to be registered some time later, allowing it to be brought online. This creates something that looks like cpuhotplug to user-space, as the sysfs files appear and disappear, and the udev notifications look the same. One notable difference is the CPU present mask, which is exposed via sysfs. Because the CPUs remain present throughout, they can still be seen in that mask. This value does get used by webbrowsers to estimate the number of CPUs as the CPU online mask is constantly changed on mobile phones. Linux is tolerant of PSCI returning errors, as its always been allowed to do that. To avoid confusing OS that can't tolerate this, we'd need an additional bit in the MADT GICC flags. This series copies ACPI_MADT_ONLINE_CAPABLE, which appears to be for this purpose, but calls it ACPI_MADT_GICC_CPU_CAPABLE as it has a different bit position in the GICC. I assume all x86 firmware vendors set the ENABLED bit in the CPU object's _STA method. This code is unconditionally enabled for all ACPI architectures. If there are problems with firmware tables on some devices, the CPUs will already be online by the time the acpi_processor_make_enabled() is called. A mismatch here causes a firmware-bug message and kernel taint. This should only affect people with broken firmware who also boot with maxcpus=1, and bring CPUs online later. I had a go at switching the remaining architectures over to GENERIC_CPU_DEVICES, so that the Kconfig symbol can be removed, but I got stuck with powerpc and s390. Thanks, James Morse (22): ACPI: Move ACPI_HOTPLUG_CPU to be enabled per architecture drivers: base: Use present CPUs in GENERIC_CPU_DEVICES drivers: base: Allow parts of GENERIC_CPU_DEVICES to be overridden drivers: base: Move node_dev_init() before cpu_dev_init() arm64: setup: Switch over to GENERIC_CPU_DEVICES using arch_register_cpu() ia64/topology: Switch over to GENERIC_CPU_DEVICES x86/topology: Switch over to GENERIC_CPU_DEVICES LoongArch: Switch over to GENERIC_CPU_DEVICES ACPI: processor: Register all CPUs from acpi_processor_get_info() ACPI: Rename ACPI_HOTPLUG_CPU to include 'present' ACPI: Rename acpi_processor_hotadd_init and remove pre-processor guards ACPI: Check _STA present bit before making CPUs not present ACPI: Warn when the present bit changes but the feature is not enabled drivers: base: Implement weak arch_unregister_cpu() LoongArch: Use the __weak version of arch_unregister_cpu() arm64: acpi: Move get_cpu_for_acpi_id() to a header ACPICA: Add new MADT GICC flags fields [code first?] arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helper irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs ACPI: add support to register CPUs based on the _STA enabled bit arm64: document virtual CPU hotplug's expectations Jean-Philippe Brucker (3): arm64: psci: Ignore DENIED CPUs KVM: arm64: Pass hypercalls to userspace KVM: arm64: Pass PSCI calls to userspace Documentation/arm64/cpu-hotplug.rst | 79 ++++++++++++++++++ Documentation/arm64/index.rst | 1 + Documentation/virt/kvm/api.rst | 31 ++++++- Documentation/virt/kvm/arm/hypercalls.rst | 1 + arch/arm64/Kconfig | 1 + arch/arm64/include/asm/acpi.h | 11 +++ arch/arm64/include/asm/cpu.h | 1 - arch/arm64/include/asm/kvm_host.h | 2 + arch/arm64/kernel/acpi_numa.c | 11 --- arch/arm64/kernel/psci.c | 2 +- arch/arm64/kernel/setup.c | 13 +-- arch/arm64/kernel/smp.c | 5 +- arch/arm64/kvm/arm.c | 15 +++- arch/arm64/kvm/hypercalls.c | 28 ++++++- arch/arm64/kvm/psci.c | 13 +++ arch/ia64/Kconfig | 2 + arch/ia64/include/asm/acpi.h | 2 +- arch/ia64/include/asm/cpu.h | 11 --- arch/ia64/kernel/acpi.c | 6 +- arch/ia64/kernel/setup.c | 2 +- arch/ia64/kernel/topology.c | 35 ++------ arch/loongarch/Kconfig | 2 + arch/loongarch/kernel/topology.c | 31 +------ arch/x86/Kconfig | 2 + arch/x86/include/asm/cpu.h | 6 -- arch/x86/kernel/acpi/boot.c | 4 +- arch/x86/kernel/topology.c | 19 +---- drivers/acpi/Kconfig | 5 +- drivers/acpi/acpi_processor.c | 99 ++++++++++++++++------- drivers/acpi/processor_core.c | 2 +- drivers/base/cpu.c | 21 +++-- drivers/base/init.c | 2 +- drivers/firmware/psci/psci.c | 2 + drivers/irqchip/irq-gic-v3.c | 38 +++++---- include/acpi/actbl2.h | 1 + include/kvm/arm_hypercalls.h | 1 + include/kvm/arm_psci.h | 4 + include/linux/acpi.h | 10 ++- include/linux/cpu.h | 6 ++ include/uapi/linux/kvm.h | 2 + 40 files changed, 339 insertions(+), 190 deletions(-) create mode 100644 Documentation/arm64/cpu-hotplug.rst -- 2.30.2

1 year, 9 months

5
43
1 0

online-policy/hotplug rebase for v6.3-rc1+

by James Morse

Hi Salil, I've rebased the online-policy/hotplug stuff onto Oliver's preferred way of doing PSCI in userspace. The whole tree is here: https://gitlab.arm.com/linux-arm/linux-jm/-/tree/virtual_cpu_hotplug/snapsh… I'll probably only post the in-guest parts, as the combined thing is getting too big. Is there any chance you could update the Qemu support for this, so that folk can play with it when its next posted? I've tested the KVM side of it with PSCI support for kvmtool, which is here: https://gitlab.arm.com/linux-arm/kvmtool-jm/-/tree/psci_in_userpsace/rfc/v1 The upshot is the CAP's disappear, and the device get/set attr has to be used against the VM fd to setup an SMC-CC filter for PSCI. Hopefully the kvmtool example makes your life easier. Any feedback on how easy this is for Qemu to use would be great. I've not looked into Vishnu's bug report yet. Thanks, James

1 year, 9 months

2
1
0 0

[PATCH V2 1/1] qemu_v8: add support to build and run secondary OP-TEE

by shiju.jose＠huawei.com

From: Shiju Jose <shiju.jose(a)huawei.com> Add changes to build secondary OP-TEE and run at S-EL1 for SPMC_AT_EL=2, where Hafnium is loaded at S-EL2. This is an experimental version to test loading and booting of more than one SP. Signed-off-by: Shiju Jose <shiju.jose(a)huawei.com> Changes: V1 -> V2 1. Changed patch subject and patch description. 2. Fix for the comments from Jens Wiklander by adding separate build flags and build path for the secondary OP-TEE. --- common.mk | 40 +++++++++++++++++++++ qemu_v8.mk | 41 ++++++++++++++++++++-- qemu_v8/secondary_optee_sp_manifest.dts | 46 +++++++++++++++++++++++++ qemu_v8/sp_layout.json | 4 +++ qemu_v8/spmc_el2_manifest.dts | 10 +++++- qemu_v8/tb_fw_config.dts | 4 +++ 6 files changed, 142 insertions(+), 3 deletions(-) create mode 100644 qemu_v8/secondary_optee_sp_manifest.dts diff --git a/common.mk b/common.mk index e5f2333..394688a 100644 --- a/common.mk +++ b/common.mk @@ -37,6 +37,9 @@ OPTEE_TEST_PATH ?= $(ROOT)/optee_test OPTEE_EXAMPLES_PATH ?= $(ROOT)/optee_examples OPTEE_RUST_PATH ?= $(ROOT)/optee_rust BUILDROOT_TARGET_ROOT ?= $(ROOT)/out-br/target +# The path for the secondary OP-TEE need update if the source +# is different from the primary OP-TEE OS. +SEC_OPTEE_OS_PATH ?= $(ROOT)/optee_os # default high verbosity. slow uarts shall specify lower if prefered CFG_TEE_CORE_LOG_LEVEL ?= 3 @@ -173,6 +176,9 @@ endif ifeq (,$(filter $(COMPILE_S_KERNEL),32 64)) $(error COMPILE_S_KERNEL=$(COMPILE_S_KERNEL) - Should be 32 or 64) endif +# Build path for the secondary OP-TEE could be out/arm/ +# if the source is different from the primary OP-TEE OS. +SEC_OPTEE_OS_COMMON_EXTRA_FLAGS ?= O=out/arm/secondary endif ifeq ($(COMPILE_S_KERNEL),32) @@ -208,8 +214,10 @@ endif ifeq ($(COMPILE_S_KERNEL),64) OPTEE_OS_COMMON_EXTRA_FLAGS += CFG_ARM64_core=y +SEC_OPTEE_OS_COMMON_EXTRA_FLAGS += CFG_ARM64_core=y else OPTEE_OS_COMMON_EXTRA_FLAGS += CFG_ARM64_core=n +SEC_OPTEE_OS_COMMON_EXTRA_FLAGS += CFG_ARM64_core=n endif @@ -543,6 +551,38 @@ optee-os-clean-common: $(MAKE) -C $(OPTEE_OS_PATH) $(OPTEE_OS_COMMON_FLAGS) clean ################################################################################ +# Secondary OP-TEE +################################################################################ +SEC_OPTEE_OS_COMMON_FLAGS ?= \ + $(SEC_OPTEE_OS_COMMON_EXTRA_FLAGS) \ + PLATFORM=$(OPTEE_OS_PLATFORM) \ + CROSS_COMPILE=$(CROSS_COMPILE_S_USER) \ + CROSS_COMPILE_core=$(CROSS_COMPILE_S_KERNEL) \ + CROSS_COMPILE_ta_arm64="$(CCACHE)$(AARCH64_CROSS_COMPILE)" \ + CROSS_COMPILE_ta_arm32="$(CCACHE)$(AARCH32_CROSS_COMPILE)" \ + CFG_TEE_CORE_LOG_LEVEL=$(CFG_TEE_CORE_LOG_LEVEL) \ + DEBUG=$(DEBUG) \ + CFG_TEE_BENCHMARK=$(CFG_TEE_BENCHMARK) \ + CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c + +SEC_OPTEE_OS_COMMON_FLAGS += CFG_CC_OPT_LEVEL=0 +SEC_OPTEE_OS_COMMON_FLAGS += CFG_WERROR=y +SEC_OPTEE_OS_COMMON_FLAGS += CFG_CORE_ASLR=n +SEC_OPTEE_OS_COMMON_FLAGS += CFG_DEBUG_INFO=y +SEC_OPTEE_OS_COMMON_FLAGS += CFG_UNWIND=y +SEC_OPTEE_OS_COMMON_FLAGS += CFG_TEE_CORE_DEBUG=y +SEC_OPTEE_OS_COMMON_FLAGS += CFG_NUM_THREADS=4 + +SEC_OPTEE_OS_PATH ?= $(BUILD_PATH)/sec_optee_os + +.PHONY: secondary-optee-os-common +secondary-optee-os-common: + $(MAKE) -C $(SEC_OPTEE_OS_PATH) $(SEC_OPTEE_OS_COMMON_FLAGS) + +.PHONY: secondary-optee-os-clean-common +secondary-optee-os-clean-common: + $(MAKE) -C $(SEC_OPTEE_OS_PATH) $(SEC_OPTEE_OS_COMMON_FLAGS) clean +################################################################################ # OP-TEE Rust ################################################################################ .PHONY: optee-rust diff --git a/qemu_v8.mk b/qemu_v8.mk index d6bf9a7..b57750a 100644 --- a/qemu_v8.mk +++ b/qemu_v8.mk @@ -100,7 +100,7 @@ ROOTFS_ENTRY ?= 0x44000000 ROOTFS_LOADADDR ?= 0x44000000 ifeq ($(SPMC_AT_EL),2) -BL32_DEPS ?= hafnium optee-os +BL32_DEPS ?= hafnium optee-os secondary-optee-os else BL32_DEPS ?= optee-os endif @@ -130,8 +130,14 @@ endif # Targets ################################################################################ TARGET_DEPS := arm-tf buildroot linux optee-os qemu +ifeq ($(SPMC_AT_EL),2) +TARGET_CLEAN := arm-tf-clean buildroot-clean linux-clean optee-os-clean \ + secondary-optee-os-clean qemu-clean check-clean +else TARGET_CLEAN := arm-tf-clean buildroot-clean linux-clean optee-os-clean \ qemu-clean check-clean +endif + TARGET_DEPS += $(BL33_DEPS) @@ -246,6 +252,7 @@ endif rm -f $(BINARIES_PATH)/bl32_extra2.bin rm -f $(BINARIES_PATH)/tos_fw_config.dtb rm -f $(BINARIES_PATH)/op-tee.pkg + rm -f $(BINARIES_PATH)/sec-op-tee.pkg ifeq ($(SPMC_AT_EL),1) ln -sf $(TF_A_OUT)/fdts/spmc_el1_manifest.dtb \ $(BINARIES_PATH)/tos_fw_config.dtb @@ -259,6 +266,7 @@ else ifeq ($(SPMC_AT_EL),2) $(BINARIES_PATH)/tb_fw_config.dtb ln -sf $(HAFNIUM_BIN) $(BINARIES_PATH)/bl32.bin ln -sf $(TF_A_OUT)/op-tee.pkg $(BINARIES_PATH)/op-tee.pkg + ln -sf $(TF_A_OUT)/sec-op-tee.pkg $(BINARIES_PATH)/sec-op-tee.pkg else ifeq ($(SPMC_AT_EL),3) ln -sf $(TF_A_OUT)/fdts/spmc_el3_manifest.dtb \ $(BINARIES_PATH)/tos_fw_config.dtb @@ -374,7 +382,7 @@ OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_ARM_GICV3=n CFG_CORE_HAFNIUM_INTC=y # [0e00.0000 0e2f.ffff] is reserved to early boot and SPMC # [0e30.0000 0e33.ffff] is reserved manifest etc (op-tee.pkg) OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_START=0x0e304000 -OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_SIZE=0x00cfc000 +OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_SIZE=0x006fc000 OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_CORE_WORKAROUND_NSITR_CACHE_PRIME=n OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_3 = CFG_CORE_EL3_SPMC=y OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_3 += CFG_DT_ADDR=0x40000000 @@ -398,6 +406,35 @@ optee-os: optee-os-common optee-os-clean: optee-os-clean-common +ifeq ($(SPMC_AT_EL),2) +################################################################################ +# Secondary OP-TEE +################################################################################ +SEC_OPTEE_OS_COMMON_FLAGS += DEBUG=$(DEBUG) CFG_ARM_GICV3=$(GICV3) +SEC_OPTEE_OS_COMMON_FLAGS += CFG_CORE_SEL2_SPMC=y +SEC_OPTEE_OS_COMMON_FLAGS += CFG_ARM_GICV3=n CFG_CORE_HAFNIUM_INTC=y +SEC_OPTEE_OS_COMMON_FLAGS += CFG_TZDRAM_START=0x0ea04000 +SEC_OPTEE_OS_COMMON_FLAGS += CFG_TZDRAM_SIZE=0x005fc000 +SEC_OPTEE_OS_COMMON_FLAGS += CFG_CORE_WORKAROUND_NSITR_CACHE_PRIME=n + +ifeq ($(XEN_BOOT),y) +SEC_OPTEE_OS_COMMON_FLAGS += CFG_VIRTUALIZATION=y +endif + +ifeq ($(PAUTH),y) +SEC_OPTEE_OS_COMMON_FLAGS += CFG_TA_PAUTH=y +SEC_OPTEE_OS_COMMON_FLAGS += CFG_CORE_PAUTH=y +endif +ifeq ($(MEMTAG),y) +SEC_OPTEE_OS_COMMON_FLAGS += CFG_MEMTAG=y +endif + +secondary-optee-os: secondary-optee-os-common + +secondary-optee-os-clean: secondary-optee-os-clean-common + +endif + ################################################################################ # Hafnium ################################################################################ diff --git a/qemu_v8/secondary_optee_sp_manifest.dts b/qemu_v8/secondary_optee_sp_manifest.dts new file mode 100644 index 0000000..0002351 --- /dev/null +++ b/qemu_v8/secondary_optee_sp_manifest.dts @@ -0,0 +1,46 @@ +/* + * Copyright (c) 2020, Arm Limited. All rights reserved. + * Copyright (c) 2022, Linaro Limited + * + * SPDX-License-Identifier: BSD-3-Clause + * + * This file is a Partition Manifest (PM) for a minimal Secure Partition (SP) + * that has additional optional properties defined. + * + */ + +/dts-v1/; + +/ { + compatible = "arm,ffa-manifest-1.0"; + + /* Properties */ + description = "sec-op-tee"; + ffa-version = <0x00010001>; /* 31:16 - Major, 15:0 - Minor */ + uuid = <0xe4b5f42f 0xed112faf 0x3351d7b9 0xe9cc99fc>; + id = <1>; + execution-ctx-count = <8>; + exception-level = <2>; /* S-EL1 */ + execution-state = <0>; /* AARCH64 */ + load-address = <0xea00000>; + entrypoint-offset = <0x4000>; + xlat-granule = <0>; /* 4KiB */ + boot-order = <0>; + messaging-method = <0x3>; /* Direct messaging only */ + ns-interrupts-action = <1>; /* NS_ACTION_ME */ + + /* Boot protocol */ + gp-register-num = <0x0>; + + device-regions { + compatible = "arm,ffa-manifest-device-regions"; + + uart1 { + base-address = <0x00000000 0x09040000>; + pages-count = <1>; + attributes = <0x3>; /* read-write */ + /* SPI, level-triggered, secure, priority=1 */ + interrupts = <0x28 0xb01>; + }; + }; +}; diff --git a/qemu_v8/sp_layout.json b/qemu_v8/sp_layout.json index c6a02a9..50d7695 100644 --- a/qemu_v8/sp_layout.json +++ b/qemu_v8/sp_layout.json @@ -2,5 +2,9 @@ "op-tee" : { "image": "../../optee_os/out/arm/core/tee-pager_v2.bin", "pm": "optee_sp_manifest.dts" + }, + "sec-op-tee" : { + "image": "../../optee_os/out/arm/secondary/core/tee-pager_v2.bin", + "pm": "secondary_optee_sp_manifest.dts" } } diff --git a/qemu_v8/spmc_el2_manifest.dts b/qemu_v8/spmc_el2_manifest.dts index 7acaa38..4e73df1 100644 --- a/qemu_v8/spmc_el2_manifest.dts +++ b/qemu_v8/spmc_el2_manifest.dts @@ -30,7 +30,15 @@ load_address = <0xe300000>; debug_name = "op-tee"; vcpu_count = <4>; - mem_size = <0xd00000>; + mem_size = <0x700000>; + }; + + vm2 { + is_ffa_partition; + load_address = <0xea00000>; + debug_name = "sec-op-tee"; + vcpu_count = <4>; + mem_size = <0x600000>; }; }; diff --git a/qemu_v8/tb_fw_config.dts b/qemu_v8/tb_fw_config.dts index 68f7b3b..ce3c26a 100644 --- a/qemu_v8/tb_fw_config.dts +++ b/qemu_v8/tb_fw_config.dts @@ -14,5 +14,9 @@ uuid = "486178e0-e7f8-11e3-bc5e-0002a5d5c51b"; load-address = <0xe300000>; }; + sec-op-tee { + uuid = "2ff4b5e4-af2f-11ed-b9d7-5133fc99cce9"; + load-address = <0xea00000>; + }; }; }; -- 2.25.1

1 year, 9 months

3
2
1 0

Linaro OP-TEE Contribution (LOC) monthly meeting February 28

by Jens Wiklander

Hi, It's soon time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I have recently seen interest in OP-TEE and S-EL2. As you may know, we have a working setup with OP-TEE and Hafnium with most of the needed patches upstream. Any other topics? Thanks, Jens

1 year, 10 months

2
1
0 0

[RFC PATCH 1/1] qemu_v8: add changes to run 2 SPs

by shiju.jose＠huawei.com

From: Shiju Jose <shiju.jose(a)huawei.com> Add changes to run 2 SPs at S-EL1 for SPMC_AT_EL=2, where Hafnium is loaded at S-EL2. This is an experimental version to test loading and booting of more than one SP. Notes and Observations: 1. Secondary SP is built from the optee-os code with different CFG_TZDRAM parameters. 2. optee-os to be build after building the secondary-optee-os, otherwise getting Stage-2 page fault when booting the primary SP. 3. When build together with optee-os the secondary-optee-os is build only when the corresponding target(secondary-optee-os-common) in the common.mk is used. Signed-off-by: Shiju Jose <shiju.jose(a)huawei.com> --- common.mk | 7 ++++ qemu_v8.mk | 36 ++++++++++++++++--- qemu_v8/secondary_optee_sp_manifest.dts | 46 +++++++++++++++++++++++++ qemu_v8/sp_layout.json | 4 +++ qemu_v8/spmc_el2_manifest.dts | 10 +++++- qemu_v8/tb_fw_config.dts | 4 +++ 6 files changed, 102 insertions(+), 5 deletions(-) create mode 100644 qemu_v8/secondary_optee_sp_manifest.dts diff --git a/common.mk b/common.mk index e5f2333..1de5426 100644 --- a/common.mk +++ b/common.mk @@ -542,6 +542,13 @@ optee-os-common: optee-os-clean-common: $(MAKE) -C $(OPTEE_OS_PATH) $(OPTEE_OS_COMMON_FLAGS) clean +.PHONY: secondary-optee-os-common +secondary-optee-os-common: + $(MAKE) -C $(OPTEE_OS_PATH) $(OPTEE_OS_COMMON_FLAGS) + +.PHONY: secondary-optee-os-clean-common +secondary-optee-os-clean-common: + $(MAKE) -C $(OPTEE_OS_PATH) $(OPTEE_OS_COMMON_FLAGS) clean ################################################################################ # OP-TEE Rust ################################################################################ diff --git a/qemu_v8.mk b/qemu_v8.mk index d6bf9a7..20b5b8b 100644 --- a/qemu_v8.mk +++ b/qemu_v8.mk @@ -100,7 +100,7 @@ ROOTFS_ENTRY ?= 0x44000000 ROOTFS_LOADADDR ?= 0x44000000 ifeq ($(SPMC_AT_EL),2) -BL32_DEPS ?= hafnium optee-os +BL32_DEPS ?= hafnium secondary-optee-os optee-os else BL32_DEPS ?= optee-os endif @@ -130,7 +130,7 @@ endif # Targets ################################################################################ TARGET_DEPS := arm-tf buildroot linux optee-os qemu -TARGET_CLEAN := arm-tf-clean buildroot-clean linux-clean optee-os-clean \ +TARGET_CLEAN := arm-tf-clean buildroot-clean linux-clean optee-os-clean secondary-optee-os-clean \ qemu-clean check-clean TARGET_DEPS += $(BL33_DEPS) @@ -246,6 +246,7 @@ endif rm -f $(BINARIES_PATH)/bl32_extra2.bin rm -f $(BINARIES_PATH)/tos_fw_config.dtb rm -f $(BINARIES_PATH)/op-tee.pkg + rm -f $(BINARIES_PATH)/sec-op-tee.pkg ifeq ($(SPMC_AT_EL),1) ln -sf $(TF_A_OUT)/fdts/spmc_el1_manifest.dtb \ $(BINARIES_PATH)/tos_fw_config.dtb @@ -259,6 +260,7 @@ else ifeq ($(SPMC_AT_EL),2) $(BINARIES_PATH)/tb_fw_config.dtb ln -sf $(HAFNIUM_BIN) $(BINARIES_PATH)/bl32.bin ln -sf $(TF_A_OUT)/op-tee.pkg $(BINARIES_PATH)/op-tee.pkg + ln -sf $(TF_A_OUT)/sec-op-tee.pkg $(BINARIES_PATH)/sec-op-tee.pkg else ifeq ($(SPMC_AT_EL),3) ln -sf $(TF_A_OUT)/fdts/spmc_el3_manifest.dtb \ $(BINARIES_PATH)/tos_fw_config.dtb @@ -373,13 +375,17 @@ OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 = CFG_CORE_SEL2_SPMC=y OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_ARM_GICV3=n CFG_CORE_HAFNIUM_INTC=y # [0e00.0000 0e2f.ffff] is reserved to early boot and SPMC # [0e30.0000 0e33.ffff] is reserved manifest etc (op-tee.pkg) -OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_START=0x0e304000 -OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_SIZE=0x00cfc000 OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_CORE_WORKAROUND_NSITR_CACHE_PRIME=n OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_3 = CFG_CORE_EL3_SPMC=y OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_3 += CFG_DT_ADDR=0x40000000 OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_3 += CFG_CORE_RESERVED_SHM=n +OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_2 = CFG_TZDRAM_START=0x0e304000 +OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_SIZE=0x006fc000 + +SECONDARY_OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_2 = CFG_TZDRAM_START=0x0ea04000 +SECONDARY_OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_SIZE=0x005fc000 + ifeq ($(XEN_BOOT),y) OPTEE_OS_COMMON_FLAGS += CFG_VIRTUALIZATION=y endif @@ -394,10 +400,32 @@ endif OPTEE_OS_COMMON_FLAGS += $(OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_$(SPMC_AT_EL)) +OP_TEE_OS_PATH ?= $(ROOT)/optee_os +OP_TEE_OS_BIN ?= $(OP_TEE_OS_PATH)/out/arm/core/tee-pager_v2.bin +SECONDARY_OP_TEE_OS_BIN ?= $(OP_TEE_OS_PATH)/out/arm/core/secondary-tee-pager_v2.bin + +.PHONY: optee-os +optee-os: optee-os-clean-common +optee-os: OPTEE_OS_COMMON_FLAGS := $(OPTEE_OS_COMMON_FLAGS) $(OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_$(SPMC_AT_EL)) optee-os: optee-os-common +################################################################################ +# secondary optee-os +################################################################################ + +.PHONY: secondary-optee-os +secondary-optee-os: secondary-optee-os-clean-common +secondary-optee-os: OPTEE_OS_COMMON_FLAGS := $(OPTEE_OS_COMMON_FLAGS) $(SECONDARY_OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_$(SPMC_AT_EL)) +secondary-optee-os: secondary-optee-os-common +secondary-optee-os: + cp $(OP_TEE_OS_BIN) $(SECONDARY_OP_TEE_OS_BIN) + +.PHONY: optee-os-clean optee-os-clean: optee-os-clean-common +.PHONY: secondary-optee-os-clean +secondary-optee-os-clean: rm $(SECONDARY_OPTEE_OS_BIN) + ################################################################################ # Hafnium ################################################################################ diff --git a/qemu_v8/secondary_optee_sp_manifest.dts b/qemu_v8/secondary_optee_sp_manifest.dts new file mode 100644 index 0000000..0002351 --- /dev/null +++ b/qemu_v8/secondary_optee_sp_manifest.dts @@ -0,0 +1,46 @@ +/* + * Copyright (c) 2020, Arm Limited. All rights reserved. + * Copyright (c) 2022, Linaro Limited + * + * SPDX-License-Identifier: BSD-3-Clause + * + * This file is a Partition Manifest (PM) for a minimal Secure Partition (SP) + * that has additional optional properties defined. + * + */ + +/dts-v1/; + +/ { + compatible = "arm,ffa-manifest-1.0"; + + /* Properties */ + description = "sec-op-tee"; + ffa-version = <0x00010001>; /* 31:16 - Major, 15:0 - Minor */ + uuid = <0xe4b5f42f 0xed112faf 0x3351d7b9 0xe9cc99fc>; + id = <1>; + execution-ctx-count = <8>; + exception-level = <2>; /* S-EL1 */ + execution-state = <0>; /* AARCH64 */ + load-address = <0xea00000>; + entrypoint-offset = <0x4000>; + xlat-granule = <0>; /* 4KiB */ + boot-order = <0>; + messaging-method = <0x3>; /* Direct messaging only */ + ns-interrupts-action = <1>; /* NS_ACTION_ME */ + + /* Boot protocol */ + gp-register-num = <0x0>; + + device-regions { + compatible = "arm,ffa-manifest-device-regions"; + + uart1 { + base-address = <0x00000000 0x09040000>; + pages-count = <1>; + attributes = <0x3>; /* read-write */ + /* SPI, level-triggered, secure, priority=1 */ + interrupts = <0x28 0xb01>; + }; + }; +}; diff --git a/qemu_v8/sp_layout.json b/qemu_v8/sp_layout.json index c6a02a9..2f9e5b9 100644 --- a/qemu_v8/sp_layout.json +++ b/qemu_v8/sp_layout.json @@ -2,5 +2,9 @@ "op-tee" : { "image": "../../optee_os/out/arm/core/tee-pager_v2.bin", "pm": "optee_sp_manifest.dts" + }, + "sec-op-tee" : { + "image": "../../optee_os/out/arm/core/secondary-tee-pager_v2.bin", + "pm": "secondary_optee_sp_manifest.dts" } } diff --git a/qemu_v8/spmc_el2_manifest.dts b/qemu_v8/spmc_el2_manifest.dts index 7acaa38..4e73df1 100644 --- a/qemu_v8/spmc_el2_manifest.dts +++ b/qemu_v8/spmc_el2_manifest.dts @@ -30,7 +30,15 @@ load_address = <0xe300000>; debug_name = "op-tee"; vcpu_count = <4>; - mem_size = <0xd00000>; + mem_size = <0x700000>; + }; + + vm2 { + is_ffa_partition; + load_address = <0xea00000>; + debug_name = "sec-op-tee"; + vcpu_count = <4>; + mem_size = <0x600000>; }; }; diff --git a/qemu_v8/tb_fw_config.dts b/qemu_v8/tb_fw_config.dts index 68f7b3b..ce3c26a 100644 --- a/qemu_v8/tb_fw_config.dts +++ b/qemu_v8/tb_fw_config.dts @@ -14,5 +14,9 @@ uuid = "486178e0-e7f8-11e3-bc5e-0002a5d5c51b"; load-address = <0xe300000>; }; + sec-op-tee { + uuid = "2ff4b5e4-af2f-11ed-b9d7-5133fc99cce9"; + load-address = <0xea00000>; + }; }; }; -- 2.25.1

1 year, 10 months

3
2
0 0

Qemu TCG support for virtual-cpuhotplug/online-policy

by James Morse

Hi Miguel got in touch with a suggested fix for the Qemu TCG support for virtual-cpuhotplug/online-policy. I recall we talked about this last week, and didn't intend to support TCG. It didn't work for me on x86 when I tried it, Jonathan suggested we don't know what its needed for. Miguel - over to you! Thanks, James

1 year, 10 months

2
1
0 0

About the test_bit() check in the kvm_hvc_user() part of hypercall.c

by Salil Mehta

Hi james, Below is the check [1] I was referring to in today's LOD call and it looks you have already fixed it in your latest patches [2] posted > > [2] https://git.gitlab.arm.com/linux-arm/linux-jm.git virtual_cpu_hotplug/rfc/v0.2 > > > > #Hunk > > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c > > index fcab358de228..3c2136cd7a3f 100644 > > --- a/arch/arm64/kvm/hypercalls.c > > +++ b/arch/arm64/kvm/hypercalls.c > > @@ -126,7 +126,7 @@ int kvm_hvc_user(struct kvm_vcpu *vcpu) > > int i; > > struct kvm_run *run = vcpu->run; > > > > - if (test_bit(KVM_ARCH_FLAG_HVC_TO_USER, &vcpu->kvm->arch.flags)) { > > + if (!test_bit(KVM_ARCH_FLAG_HVC_TO_USER, &vcpu->kvm->arch.flags)) { > > smccc_set_retval(vcpu, SMCCC_RET_NOT_SUPPORTED, 0, 0, 0); > > return 1; > > } > > Makes sense - thanks! I couldn't test this without the Qemu changes. > [1] https://op-lists.linaro.org/archives/list/linaro-open-discussions@op-lists.… [2] https://lore.kernel.org/linux-arm-kernel/20230203135043.409192-30-james.mor…

1 year, 10 months

1
0
0 0

2024

2023

2022

2021

2020

Linaro-open-discussions February 2023