Hi James,
Do we have any plan when we want to push the non-RFC Virtual CPU Hotplug patch-set
for the kernel side to the community. I guess people will be more interested in reviewing
if it is floated with a non-RFC tag.
If time is a problem at your side then do you need my help in carrying it forward for you?
Please let me know
Thanks
Salil.
Hi,
On Tuesday, November 28 it's time for another LOC monthly meeting. For
time and connection details see the calendar at
https://www.trustedfirmware.org/meetings/
There's an ongoing effort to add RPMB emulation in QEMU. This should
allow RPMB testing in our CI.
Any other topics?
Thanks,
Jens
Jianyong Wu would like to recall the message, "[Linaro-open-discussions] Re: [Request] Regarding non-RFC patch-set of Virtual CPU Hotplug kernel support".
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.
Hello,
We have been trying to verify the "system suspend/Restore" with vCPU Hotplug patches recently and
found this functionality does not work on ARM64 with VMs even without our patches i.e. using latest kernel and qemu repository.
estuary:/$ cat /sys/power/mem_sleep
[s2idle]
estuary:/$
estuary:/$ cat /sys/power/state
freeze mem disk
estuary:/$
estuary:/$
estuary:/$ echo mem > /sys/power/state
[ 60.458445] PM: suspend entry (s2idle)
[ 60.458840] Filesystems sync: 0.000 seconds
[ 60.459649] Freezing user space processes
[ 60.461149] Freezing user space processes completed (elapsed 0.001 seconds)
[ 60.461830] OOM killer disabled.
[ 60.462144] Freezing remaining freezable tasks
[ 60.463188] Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
[ 60.463920] printk: Suspending console(s) (use no_console_suspend to debug)
(qemu)
(qemu) sys
system_powerdown system_reset system_wakeup
(qemu) system_wakeup
Error: wake-up from suspend is not supported by this guest
(qemu)
Or using # systemctl suspend
What is the expected behavior or are we missing something?
Thanks
Salil
Hi,all
May I, representing our members, bring forth an issue for discussion?
The impact of this issue is big: Without resolving this issue, the scenario
where the GPU is passed through to the virtual machine cannot be used. And
it exists on Arm only, x86 is good. (I know workarounds exist, but we want
to fix that in the mainline).
After reading through so many community emails (see below), I believe it’s
unlikely that a single patch can quickly gain everyone's support. A broad
discussion involving the ARM ecosystem and the KVM community is essential.
Only with consensus can a submitted patch receive sufficient support,
eventually resolving this issue in the mainline version.
History:
-
This issue was first submitted to the public on 2021-07-01, refer to
this [URL] (
https://gitee.com/openeuler/kernel/issues/I3YRDP?from=project-issue ).
-
A patch was submitted to the kernel maillist on 2022-04-01, authored by
kylinos.com, but it was refused. No follow-up was found after that.
[Link to the Patch] (
https://lore.kernel.org/lkml/20220401090828.614167-1-xieming@kylinos.cn/T/
)
-
Another discussion went on in this email chain on 2022-05-09:, authored
by nvidia.com, but no conclusion.
https://lore.kernel.org/all/20210429162906.32742-1-sdonthineni@nvidia.com/
-
As of this writing 2023-10-09, the issue still can be reproduced in
kernel 6.1.x with Nvidia / AMD GPUs, on Arm arch.
Problem Description:
A GPU is passed through to a virtual machine via a PCIE node. When
installing the GPU driver within a virtual machine that runs on Openeuler
22.03 LTS SP2 (aarch64) system (linux kernel 5.10 based), the following
error occurs:
“Unsupported FSC: EC=0x24 xFSC=0x21 ESR_EL2=0x92000061”
PS: the same issue can also be reproduced in kernel 6.1.x with Nvidia / AMD
GPUs.
Upon consulting the official ARM documentation, the meanings of some of the
error codes are as follows:
EC=0x24
The binary code is 0b100100, which corresponds to a data abort. A possible
cause of this problem could be alignment errors.
xFSC=0x21
The binary code is 0b100001. Upon inquiry, this code represents an
alignment error.
There is a lack of online solutions to this error. KylinOS engineers once
proposed a patch for this error, but it was rejected by the community.
Moreover, their modification was based on the old 4.x kernel version.
Link: [Link to the Patch](
https://lore.kernel.org/lkml/20220401090828.614167-1-xieming@kylinos.cn/T/)
This patch suggests that it is unreasonable to set the I/O memory
attributes of the virtual machine to Device_nGnRE type.
According to ARM's official Whitepaper: Understanding Write Combining on Arm,
Device-GRE is a type of relaxed-order memory that allows for gathering
operations, but it does not allow for read speculation and imposes strict
alignment constraints. You may refer to the table below or the following
link for more information.
[Link to ARM Community](
https://community.arm.com/arm-research/m/resources/1012 )
Preliminary Deduction:
The GPU might be using Device-GRE type memory but without proper alignment,
leading to the generation of this error.
Thanks.
Best regards,
Guodong Xu
Linaro
Hi Jonathan,James,Salil,all
Any topics we want to sync during next LOD meeting?
Thanks:)
Joyce
> 在 2023年7月13日,上午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: FYI: KVMForum2023 Conference Talk slides - "Virtual CPU Hotplug Support on ARM64"
> (Joyce Qi)
> 2. Re: Linaro-open-discussions Digest, Vol 33, Issue 19 (Yicong Yang)
> 3. FYI: KVMForum2023 Conference Talk slides - "Virtual CPU Hotplug Support on ARM64"
> (Salil Mehta)
> 4. Re: [PATCH V3 1/1] qemu_v8: add support to run secondary OP-TEE
> (Shiju Jose)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 12 Jul 2023 10:06:24 +0800
> From: Joyce Qi <joyce.qi(a)linaro.org>
> Subject: [Linaro-open-discussions] Re: FYI: KVMForum2023 Conference
> Talk slides - "Virtual CPU Hotplug Support on ARM64"
> To: Salil Mehta <salil.mehta(a)huawei.com>
> Cc: "linaro-open-discussions(a)op-lists.linaro.org"
> <linaro-open-discussions(a)op-lists.linaro.org>, "james.morse(a)arm.com"
> <james.morse(a)arm.com>, Jean-Philippe Brucker
> <jean-philippe.brucker(a)arm.com>, "lorenzo.pieralisi(a)linaro.org"
> <lorenzo.pieralisi(a)linaro.org>, Lorenzo Pieralisi
> <lpieralisi(a)kernel.org>, zhukeqian <zhukeqian1(a)huawei.com>,
> "wangxiongfeng (C)" <wangxiongfeng2(a)huawei.com>, Miguel Luis
> <miguel.luis(a)oracle.com>, Vishnu Pajjuri
> <vishnu(a)amperemail.onmicrosoft.com>,
> "darren(a)amperemail.onmicrosoft.com"
> <darren(a)amperemail.onmicrosoft.com>,
> "ilkka(a)amperemail.onmicrosoft.com" <ilkka(a)amperemail.onmicrosoft.com>,
> Catalin Marinas <catalin.marinas(a)arm.com>, Marc Zyngier
> <maz(a)kernel.org>, Will Deacon <will(a)kernel.org>, Karl Heubaum
> <karl.heubaum(a)oracle.com>, Russell King <linux(a)armlinux.org.uk>,
> "salil.mehta(a)opnsrc.net" <salil.mehta(a)opnsrc.net>, Peter Maydell
> <peter.maydell(a)linaro.org>, Sudeep Holla <sudeep.holla(a)arm.com>,
> Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Message-ID: <AB9B6479-BAA8-4976-B670-757B461A3B7E(a)linaro.org>
> Content-Type: text/plain; charset=gb2312
>
> Hi Salil,
>
> Thanks for sharing, uploaded to the meeting minutes on June 7.
>
> https://linaro.atlassian.net/wiki/spaces/LOD/pages/28933292085/2023-06-07+M…
>
>
>
>> 在 2023年7月12日,上午2:22,Salil Mehta <salil.mehta(a)huawei.com> 写道:
>>
>> Hello,
>> Slides (Qemu + Kernel) and video related to our "Virtual CPU Hotplug presentation" recently concluded
>> at KVMForum2023 Conference are now available at the below link:
>>
>> Link: https://kvm-forum.qemu.org/2023/talk/9SMPDQ/
>>
>>
>> Many thanks to everyone who has contributed to the project so far!
>>
>>
>> Best regards
>> Salil
>>
>>
>>
>>
>>
>>
>>
>> <KVMForum2023-virtual-cpu-hotplug-kernel-slides.pdf><KVMForum2023-virtual-cpu-hotplug-qemu-slides.pdf>
>
> Thanks:)
> Joyce
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 11 Jul 2023 20:28:19 +0800
> From: Yicong Yang <yangyicong(a)huawei.com>
> Subject: [Linaro-open-discussions] Re: Linaro-open-discussions Digest,
> Vol 33, Issue 19
> To: Joyce Qi <joyce.qi(a)linaro.org>, Lorenzo Pieralisi
> <lorenzo.pieralisi(a)linaro.org>
> Cc: yangyicong(a)hisilicon.com, James Morse <james.morse(a)arm.com>, James
> Morse via Linaro-open-discussions
> <linaro-open-discussions(a)op-lists.linaro.org>,
> "wangkefeng.wang(a)huawei.com" <wangkefeng.wang(a)huawei.com>, tanxiaofei
> <tanxiaofei(a)huawei.com>, tongtiangen(a)huawei.com
> Message-ID: <b00be3fe-968f-5116-2711-ad77a4ea7f71(a)huawei.com>
> Content-Type: text/plain; charset="gbk"
>
> Hi,
>
> Thanks for organizing the meeting and thanks for the discussion. Attached the material talked
> on the meeting as well as the meeting minutes at the last.
>
> Thanks,
> Yicong
>
> On 2023/7/10 23:03, Joyce Qi wrote:
>> Hi Lorenzo,
>>
>> Thanks for attending and invite James to join.
>> Just resend the calendar.
>>
>> Also invited Yicong to join.
>>
>> Thanks:)
>> Joyce
>>
>>
>>> 在 2023年7月10日,下午10:34,Lorenzo Pieralisi <lorenzo.pieralisi(a)linaro.org> 写道:
>>>
>>> On Mon, 10 Jul 2023 at 16:32, Lorenzo Pieralisi
>>> <lorenzo.pieralisi(a)linaro.org> wrote:
>>>>
>>>> On Mon, 10 Jul 2023 at 16:24, Joyce Qi via Linaro-open-discussions
>>>> <linaro-open-discussions(a)op-lists.linaro.org> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Just reminder that we will have the Open Discussion on July 11th on the memory and RAS related topics.
>>>>>
>>>>> @James, Lorenz,
>>>>>
>>>>> Will you be able to join?
>>>
>>> Is it possible please to resend a calendar invite ?
>>>
>>> Thanks,
>>> Lorenzo
>>>
>>>>
>>>> Yes, I will - I CC'ed James, hopefully also the Huawei folks will be there
>>>> otherwise there is no point since they raised the topics.
>>>>
>>>> Please let us know,
>>>> Lorenzo
>>
>> .
>>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 11 Jul 2023 18:22:04 +0000
> From: Salil Mehta <salil.mehta(a)huawei.com>
> Subject: [Linaro-open-discussions] FYI: KVMForum2023 Conference Talk
> slides - "Virtual CPU Hotplug Support on ARM64"
> To: "linaro-open-discussions(a)op-lists.linaro.org"
> <linaro-open-discussions(a)op-lists.linaro.org>, Joyce Qi
> <joyce.qi(a)linaro.org>
> Cc: "james.morse(a)arm.com" <james.morse(a)arm.com>, Jean-Philippe Brucker
> <jean-philippe.brucker(a)arm.com>, "lorenzo.pieralisi(a)linaro.org"
> <lorenzo.pieralisi(a)linaro.org>, Lorenzo Pieralisi
> <lpieralisi(a)kernel.org>, zhukeqian <zhukeqian1(a)huawei.com>,
> "wangxiongfeng (C)" <wangxiongfeng2(a)huawei.com>, Miguel Luis
> <miguel.luis(a)oracle.com>, Vishnu Pajjuri
> <vishnu(a)amperemail.onmicrosoft.com>,
> "darren(a)amperemail.onmicrosoft.com"
> <darren(a)amperemail.onmicrosoft.com>,
> "ilkka(a)amperemail.onmicrosoft.com" <ilkka(a)amperemail.onmicrosoft.com>,
> Catalin Marinas <catalin.marinas(a)arm.com>, Marc Zyngier
> <maz(a)kernel.org>, Will Deacon <will(a)kernel.org>, Karl Heubaum
> <karl.heubaum(a)oracle.com>, Russell King <linux(a)armlinux.org.uk>,
> "salil.mehta(a)opnsrc.net" <salil.mehta(a)opnsrc.net>, Peter Maydell
> <peter.maydell(a)linaro.org>, Sudeep Holla <sudeep.holla(a)arm.com>,
> Suzuki K Poulose <suzuki.poulose(a)arm.com>
> Message-ID: <42340fd4b86747809a955c81fe6be8b5(a)huawei.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello,
> Slides (Qemu + Kernel) and video related to our "Virtual CPU Hotplug presentation" recently concluded
> at KVMForum2023 Conference are now available at the below link:
>
> Link: https://kvm-forum.qemu.org/2023/talk/9SMPDQ/
>
>
> Many thanks to everyone who has contributed to the project so far!
>
>
> Best regards
> Salil
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 12 Jul 2023 10:17:11 +0000
> From: Shiju Jose <shiju.jose(a)huawei.com>
> Subject: [Linaro-open-discussions] Re: [PATCH V3 1/1] qemu_v8: add
> support to run secondary OP-TEE
> To: Jens Wiklander <jens.wiklander(a)linaro.org>
> Cc: "linaro-open-discussions(a)op-lists.linaro.org"
> <linaro-open-discussions(a)op-lists.linaro.org>,
> "Olivier.Deprez(a)arm.com" <Olivier.Deprez(a)arm.com>, Linuxarm
> <linuxarm(a)huawei.com>, "zhouguangwei (C)" <zhouguangwei5(a)huawei.com>
> Message-ID: <d550a78261ec447f8b2d8c62e92ab584(a)huawei.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Jens,
>
>> -----Original Message-----
>> From: Jens Wiklander <jens.wiklander(a)linaro.org>
>> Sent: 11 July 2023 10:02
>> To: Shiju Jose <shiju.jose(a)huawei.com>
>> Cc: linaro-open-discussions(a)op-lists.linaro.org; Olivier.Deprez(a)arm.com;
>> Linuxarm <linuxarm(a)huawei.com>; Jonathan Cameron
>> <jonathan.cameron(a)huawei.com>; Zengtao (B) <prime.zeng(a)hisilicon.com>;
>> zhouguangwei (C) <zhouguangwei5(a)huawei.com>
>> Subject: Re: [PATCH V3 1/1] qemu_v8: add support to run secondary OP-TEE
>>
>> Hi,
>>
>> On Mon, Jun 26, 2023 at 1:13 PM <shiju.jose(a)huawei.com> wrote:
>>>
>>> From: Shiju Jose <shiju.jose(a)huawei.com>
>>>
>>> Add changes to run a secondary OP-TEE at S-EL1 for SPMC_AT_EL=2, where
>>> Hafnium is loaded at S-EL2.
>>>
>>> Signed-off-by: Shiju Jose <shiju.jose(a)huawei.com>
>>
>> With https://github.com/OP-TEE/build/pull/663 I'm trying to upstream the
>> Hafnium setup. Once that's merged please create a pull request against
>> https://github.com/OP-TEE/build and we can continue reviewing this patch
>> there.
>
> Sure.
>
> Thanks,
> Shiju
>>
>> Thanks,
>> Jens
>>
>>>
> ...
>>> 2.25.1
>>>
>
> ------------------------------
>
> 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 34, Issue 3
> ******************************************************
Hi
Today Tuesday, September 26 it's time for another LOC monthly meeting.
Sorry for the short notice. For
time and connection details see the calendar at
https://www.trustedfirmware.org/meetings/
I have a few items for the agenda:
- Firmware handoff in OP-TEE https://github.com/OP-TEE/optee_os/pull/6308
- We've started to upstream a few PRs that will require bumping the
major version to 4
Any other topics?
Thanks,
Jens
[+] Adding back LOD mailing list
Hi Leo,
> From: Leonardo Augusto Guimarães Garcia <leonardo.garcia(a)linaro.org>
> Sent: Wednesday, August 30, 2023 1:59 PM
> To: Marcin Juszkiewicz <marcin.juszkiewicz(a)linaro.org>; Jonathan Cameron
> <jonathan.cameron(a)huawei.com>; Salil Mehta <salil.mehta(a)huawei.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi(a)linaro.org>; Joyce Qi
> <joyce.qi(a)linaro.org>; James Morse <james.morse(a)arm.com>; Salil Mehta
> <salil.mehta(a)opnsrc.net>; Radoslaw Biernacki <rad(a)semihalf.com>; Leif
> Lindholm <quic_llindhol(a)quicinc.com>; Peter Maydell <peter.maydell(a)linaro.org>
> Subject: Re: [Linaro-open-discussions] Re: About the LOD next week (Aug 22th)
>
>
> On 2023/08/30 09:11, Marcin Juszkiewicz wrote:
> > W dniu 30.08.2023 o 13:59, Jonathan Cameron pisze:
> >> Salil Mehta <salil.mehta(a)huawei.com> wrote:
> >
> >>> But I am not sure about qemu-sbsa. Maybe someone can help throw
> >>> light on the goals of qemu-sbsa and who wants it?
> >>
> >> Architecture verification - not use as a VM except for that purpose.
> >> It's not a replacement for virt - purpose is completely different.
> >>
> >> Of the current machines in QEMU the only one that I can see vCPU HP
> >> mattering for is virt as that's the one targeting cloud VMs etc.
> >
> > Clouds use 'virt' as it was made for that purpose. And vCPU hotplug
> > may have sense there.
> >
> > SBSA Reference Platform (sbsa-ref in QEMU) is emulation of physical
> > computer (similar to 'q35' in x86-64 world). It does not use any of
> > virtio expansions but emulate expansion cards so you get
> > 'bochs-display' instead of 'virtio-gpu', 'ahci' instead of
> > 'virtio-blk/scsi' etc.
> >
> > The goal is to have virtual system which can be used to check how
> > operating systems behave on SBSA hardware.
> >
> > We are going for SBSA level 3 compliance and we are getting closer.
> >
> > Does vCPU hotplug make sense for sbsa-ref? Probably not as you do not
> > hotplug cpus into your physical box, right?
>
>
> This is correct. Today we don't have Arm physical machines that support
> CPUs hot plug/unplug.
>
> Given that, I agree with Jonathan that the cVPU hot plug/unplug code
> don't need to worry about SBSA QEMU implementation. There shouldn't be
> any use case for that in the foreseeable future.
Agreed for the reasons mentioned above. Thanks again for the confirmation.
Thanks
Salil.
>
> Cheers,
>
> Leo
[+] Adding the LOD list for the obvious reasons
Hi Marcin,
> From: Marcin Juszkiewicz <marcin.juszkiewicz(a)linaro.org>
> Sent: Wednesday, August 30, 2023 1:12 PM
> To: Jonathan Cameron <jonathan.cameron(a)huawei.com>; Salil Mehta
> <salil.mehta(a)huawei.com>
> Cc: Leonardo Augusto Guimarães Garcia <leonardo.garcia(a)linaro.org>; Lorenzo
> Pieralisi <lorenzo.pieralisi(a)linaro.org>; Joyce Qi <joyce.qi(a)linaro.org>;
> James Morse <james.morse(a)arm.com>; Salil Mehta <salil.mehta(a)opnsrc.net>;
> Radoslaw Biernacki <rad(a)semihalf.com>; Leif Lindholm
> <quic_llindhol(a)quicinc.com>; Peter Maydell <peter.maydell(a)linaro.org>
> Subject: Re: [Linaro-open-discussions] Re: About the LOD next week (Aug
> 22th)
>
> W dniu 30.08.2023 o 13:59, Jonathan Cameron pisze:
> > Salil Mehta <salil.mehta(a)huawei.com> wrote:
>
> >> But I am not sure about qemu-sbsa. Maybe someone can help throw
> >> light on the goals of qemu-sbsa and who wants it?
> >
> > Architecture verification - not use as a VM except for that purpose.
> > It's not a replacement for virt - purpose is completely different.
> >
> > Of the current machines in QEMU the only one that I can see vCPU HP
> > mattering for is virt as that's the one targeting cloud VMs etc.
>
> Clouds use 'virt' as it was made for that purpose. And vCPU hotplug may
> have sense there.
>
> SBSA Reference Platform (sbsa-ref in QEMU) is emulation of physical
> computer (similar to 'q35' in x86-64 world). It does not use any of
> virtio expansions but emulate expansion cards so you get 'bochs-display'
> instead of 'virtio-gpu', 'ahci' instead of 'virtio-blk/scsi' etc.
>
> The goal is to have virtual system which can be used to check how
> operating systems behave on SBSA hardware.
>
> We are going for SBSA level 3 compliance and we are getting closer.
Thanks for confirming this and sharing this useful information.
>
> Does vCPU hotplug make sense for sbsa-ref? Probably not as you do not
> hotplug cpus into your physical box, right?
Agreed, for the reference verification platform it does not.
Thanks
Salil.