Hi Jonathan,Lorenzo,all,
Do we have any topic to sync on our LOD meeting next week?
Thanks:) Joyce
在 2022年10月18日，上午8:00，linaro-open-discussions-request@op-lists.linaro.org 写道：
Send Linaro-open-discussions mailing list submissions to linaro-open-discussions@op-lists.linaro.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to linaro-open-discussions-request@op-lists.linaro.org
You can reach the person managing the list at linaro-open-discussions-owner@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:
- Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) (Salil Mehta)
Message: 1 Date: Mon, 17 Oct 2022 16:12:26 +0000 From: Salil Mehta salil.mehta@huawei.com Subject: [Linaro-open-discussions] Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) To: "joyce.qi@linaro.org" joyce.qi@linaro.org, "james.morse@arm.com" james.morse@arm.com Cc: "linaro-open-discussions@op-lists.linaro.org" linaro-open-discussions@op-lists.linaro.org, "lorenzo.pieralisi@linaro.org" lorenzo.pieralisi@linaro.org, "ilkka@os.amperecomputing.com" ilkka@os.amperecomputing.com, Jean-Philippe Brucker jean-philippe.brucker@arm.com, "salil.mehta@opnsrc.net" salil.mehta@opnsrc.net Message-ID: 12408d4c06604dd4bd8e017adf7e5fe6@huawei.com Content-Type: text/plain; charset="utf-8"
Hi James, As discussed in the meeting below are the repositories which you might want to have a look.
[1] Forward ported QEMU with some fixes was shared (by Salil) https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v1-port29092022
[2] James Approach with online-capable and present==possible (some fixes) https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-pres-eq-poss-cpu
[3] Variant of James approach with online-capable and conditionally present cpus https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-variant-with-cond-present-cpu
I have also shared the LOD presentation with Joyce for uploading to the site.
Attachment: [1] Linaro Open Discussion Meeting Update - 05102022 - Salil_Mehta-fixed.pdf
Many thanks Salil
-----Original Message----- From: Google Calendar [mailto:calendar-notification@google.com] On Behalf Of Joyce Qi via Linaro-open-discussions Sent: Wednesday, October 5, 2022 9:31 AM To: linaro-open-discussions@op-lists.linaro.org; james.morse@arm.com; Jonathan Cameron jonathan.cameron@huawei.com; lorenzo.pieralisi@linaro.org; ilkka@os.amperecomputing.com Subject: [Linaro-open-discussions] Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)
Linaro Open Discussions monthly meeting Wednesday 5 Oct 2022 ⋅ 19:00 – 20:00 Hong Kong Standard Time
Location https://linaro-org.zoom.us/j/95682500341 https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250 0341&sa=D&source=calendar&usd=2&usg=AOvVaw2JDK9LgOcXl2WanQ86Y-6h
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议 https://linaro-org.zoom.us/j/95682500341
会议号：956 8250 0341 手机一键拨号 +16699009128,,95682500341# 美国 (San Jose) +13462487799,,95682500341# 美国 (Houston)
根据您的位置拨号 +1 669 900 9128 美国 (San Jose) +1 346 248 7799 美国 (Houston) +1 253 215 8782 美国 (Tacoma) +1 646 558 8656 美国 (New York) +1 301 715 8592 美国 (Washington DC) +1 312 626 6799 美国 (Chicago) 888 788 0099 美国 免费 877 853 5247 美国 免费 会议号：956 8250 0341 查找本地号码：https://linaro-org.zoom.us/u/ady2J9Zn7t
Guests linaro-open-discussions@op-lists.linaro.org james.morse@arm.com jonathan.cameron@huawei.com lorenzo.pieralisi@linaro.org ilkka@os.amperecomputing.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM... cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0
Reply for linaro-open-discussions@op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM... cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0 Your attendance is optional.
~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event. To stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
Subject: Digest Footer
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org To unsubscribe send an email to linaro-open-discussions-leave@op-lists.linaro.org
End of Linaro-open-discussions Digest, Vol 25, Issue 3
Nothing from me at the moment. Though others may well speak up from our side!
Jonathan
-----Original Message----- From: Joyce Qi joyce.qi@linaro.org Sent: 20 October 2022 13:47 To: Jonathan Cameron jonathan.cameron@huawei.com; Salil Mehta salil.mehta@huawei.com; Lorenzo Pieralisi lorenzo.pieralisi@linaro.org; James Morse james.morse@arm.com Cc: Jonathan Cameron via Linaro-open-discussions linaro-open-discussions@op-lists.linaro.org; linux@armlinux.org.uk Subject: Re: Linaro-open-discussions Digest, Vol 25, Issue 3
Hi Jonathan,Lorenzo,all,
Do we have any topic to sync on our LOD meeting next week?
Thanks:) Joyce
在 2022年10月18日，上午8:00，linaro-open-discussions-request@op-lists.linaro.org 写道：
Send Linaro-open-discussions mailing list submissions to linaro-open-discussions@op-lists.linaro.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to linaro-open-discussions-request@op-lists.linaro.org
You can reach the person managing the list at linaro-open-discussions-owner@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:
- Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) (Salil Mehta)
Message: 1 Date: Mon, 17 Oct 2022 16:12:26 +0000 From: Salil Mehta salil.mehta@huawei.com Subject: [Linaro-open-discussions] Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) To: "joyce.qi@linaro.org" joyce.qi@linaro.org, "james.morse@arm.com" james.morse@arm.com Cc: "linaro-open-discussions@op-lists.linaro.org" linaro-open-discussions@op-lists.linaro.org, "lorenzo.pieralisi@linaro.org" lorenzo.pieralisi@linaro.org, "ilkka@os.amperecomputing.com" ilkka@os.amperecomputing.com, Jean-Philippe Brucker jean-philippe.brucker@arm.com, "salil.mehta@opnsrc.net" salil.mehta@opnsrc.net Message-ID: 12408d4c06604dd4bd8e017adf7e5fe6@huawei.com Content-Type: text/plain; charset="utf-8"
Hi James, As discussed in the meeting below are the repositories which you might want to have a look.
[1] Forward ported QEMU with some fixes was shared (by Salil) https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v1-port29092022
[2] James Approach with online-capable and present==possible (some fixes) https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-pres-eq-poss-cpu
[3] Variant of James approach with online-capable and conditionally present cpus https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-variant-with-cond-present-cpu
I have also shared the LOD presentation with Joyce for uploading to the site.
Attachment: [1] Linaro Open Discussion Meeting Update - 05102022 - Salil_Mehta-fixed.pdf
Many thanks Salil
-----Original Message----- From: Google Calendar [mailto:calendar-notification@google.com] On Behalf Of Joyce Qi via Linaro-open-discussions Sent: Wednesday, October 5, 2022 9:31 AM To: linaro-open-discussions@op-lists.linaro.org; james.morse@arm.com; Jonathan Cameron jonathan.cameron@huawei.com; lorenzo.pieralisi@linaro.org; ilkka@os.amperecomputing.com Subject: [Linaro-open-discussions] Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)
Linaro Open Discussions monthly meeting Wednesday 5 Oct 2022 ⋅ 19:00 – 20:00 Hong Kong Standard Time
Location https://linaro-org.zoom.us/j/95682500341 https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9 568250 0341&sa=D&source=calendar&usd=2&usg=AOvVaw2JDK9LgOcXl2WanQ86Y-6h
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议 https://linaro-org.zoom.us/j/95682500341
会议号：956 8250 0341 手机一键拨号 +16699009128,,95682500341# 美国 (San Jose) 13462487799,,95682500341# 美国 +(Houston)
根据您的位置拨号 +1 669 900 9128 美国 (San Jose) +1 346 248 7799 美国 (Houston) +1 253 215 8782 美国 (Tacoma) +1 646 558 8656 美国 (New York) +1 301 715 8592 美国 (Washington DC) +1 312 626 6799 美国 (Chicago) 888 788 0099 美国 免费 877 853 5247 美国 免费 会议号：956 8250 0341 查找本地号码：https://linaro-org.zoom.us/u/ady2J9Zn7t
Guests linaro-open-discussions@op-lists.linaro.org james.morse@arm.com jonathan.cameron@huawei.com lorenzo.pieralisi@linaro.org ilkka@os.amperecomputing.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNW tiMWxv cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNza W9uc0B vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI 3c0Bnc m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOT YxMjNi ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0
Reply for linaro-open-discussions@op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNW tiMWxv cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNza W9uc0B vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI 3c0Bnc m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOT YxMjNi ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0 Your attendance is optional.
~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event. To stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding -- Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Ho me
Subject: Digest Footer
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org To unsubscribe send an email to linaro-open-discussions-leave@op-lists.linaro.org
End of Linaro-open-discussions Digest, Vol 25, Issue 3
Hello,
I have two small topics that are relevant to CXL: * maintaining the UEFI memory map with hotplug memory (series in development, no ACPI changes needed) * Cache invalidate for NVdimm unlock and erase (spec proposal which will need a customer)
These would only take about thirty minutes, unless we want to go into all the gory details of the first one. I don't think its worth having the meeting just for these.
I've not got to rebase the virtual cpu hotplug stuff - I've been busy turning the MPAM stuff around this week. (and I'm out next monday)
Thanks,
James
On 20/10/2022 13:47, Joyce Qi wrote:
Hi Jonathan,Lorenzo,all,
Do we have any topic to sync on our LOD meeting next week?
Thanks:) Joyce
在 2022年10月18日，上午8:00，linaro-open-discussions-request@op-lists.linaro.org 写道：
Send Linaro-open-discussions mailing list submissions to linaro-open-discussions@op-lists.linaro.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to linaro-open-discussions-request@op-lists.linaro.org
You can reach the person managing the list at linaro-open-discussions-owner@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:
- Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) (Salil Mehta)
Message: 1 Date: Mon, 17 Oct 2022 16:12:26 +0000 From: Salil Mehta salil.mehta@huawei.com Subject: [Linaro-open-discussions] Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) To: "joyce.qi@linaro.org" joyce.qi@linaro.org, "james.morse@arm.com" james.morse@arm.com Cc: "linaro-open-discussions@op-lists.linaro.org" linaro-open-discussions@op-lists.linaro.org, "lorenzo.pieralisi@linaro.org" lorenzo.pieralisi@linaro.org, "ilkka@os.amperecomputing.com" ilkka@os.amperecomputing.com, Jean-Philippe Brucker jean-philippe.brucker@arm.com, "salil.mehta@opnsrc.net" salil.mehta@opnsrc.net Message-ID: 12408d4c06604dd4bd8e017adf7e5fe6@huawei.com Content-Type: text/plain; charset="utf-8"
Hi James, As discussed in the meeting below are the repositories which you might want to have a look.
[1] Forward ported QEMU with some fixes was shared (by Salil) https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v1-port29092022
[2] James Approach with online-capable and present==possible (some fixes) https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-pres-eq-poss-cpu
[3] Variant of James approach with online-capable and conditionally present cpus https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-variant-with-cond-present-cpu
I have also shared the LOD presentation with Joyce for uploading to the site.
Attachment: [1] Linaro Open Discussion Meeting Update - 05102022 - Salil_Mehta-fixed.pdf
Many thanks Salil
-----Original Message----- From: Google Calendar [mailto:calendar-notification@google.com] On Behalf Of Joyce Qi via Linaro-open-discussions Sent: Wednesday, October 5, 2022 9:31 AM To: linaro-open-discussions@op-lists.linaro.org; james.morse@arm.com; Jonathan Cameron jonathan.cameron@huawei.com; lorenzo.pieralisi@linaro.org; ilkka@os.amperecomputing.com Subject: [Linaro-open-discussions] Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)
Linaro Open Discussions monthly meeting Wednesday 5 Oct 2022 ⋅ 19:00 – 20:00 Hong Kong Standard Time
Location https://linaro-org.zoom.us/j/95682500341 https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250 0341&sa=D&source=calendar&usd=2&usg=AOvVaw2JDK9LgOcXl2WanQ86Y-6h
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议 https://linaro-org.zoom.us/j/95682500341
会议号：956 8250 0341 手机一键拨号 +16699009128,,95682500341# 美国 (San Jose) +13462487799,,95682500341# 美国 (Houston)
根据您的位置拨号 +1 669 900 9128 美国 (San Jose) +1 346 248 7799 美国 (Houston) +1 253 215 8782 美国 (Tacoma) +1 646 558 8656 美国 (New York) +1 301 715 8592 美国 (Washington DC) +1 312 626 6799 美国 (Chicago) 888 788 0099 美国 免费 877 853 5247 美国 免费 会议号：956 8250 0341 查找本地号码：https://linaro-org.zoom.us/u/ady2J9Zn7t
Guests linaro-open-discussions@op-lists.linaro.org james.morse@arm.com jonathan.cameron@huawei.com lorenzo.pieralisi@linaro.org ilkka@os.amperecomputing.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM... cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0
Reply for linaro-open-discussions@op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM... cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0 Your attendance is optional.
~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event. To stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
Subject: Digest Footer
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org To unsubscribe send an email to linaro-open-discussions-leave@op-lists.linaro.org
End of Linaro-open-discussions Digest, Vol 25, Issue 3
Hi James，
ok，we can have the discussion next Tuesday. Will any US frirends like to join the discussion? 11:00 BST or 14:00 BST time?
Thanks:) Joyce
在 2022年10月20日，下午11:06，James Morse james.morse@arm.com 写道：
Hello,
I have two small topics that are relevant to CXL:
- maintaining the UEFI memory map with hotplug memory (series in development, no ACPI changes needed)
- Cache invalidate for NVdimm unlock and erase (spec proposal which will need a customer)
These would only take about thirty minutes, unless we want to go into all the gory details of the first one. I don't think its worth having the meeting just for these.
I've not got to rebase the virtual cpu hotplug stuff - I've been busy turning the MPAM stuff around this week. (and I'm out next monday)
On Thu, Oct 20, 2022 at 04:06:05PM +0100, James Morse wrote:
I've not got to rebase the virtual cpu hotplug stuff - I've been busy turning the MPAM stuff around this week. (and I'm out next monday)
This item is of particular interest.
Hi all
Having received some feedbacks about the time and some US colleagues would like to attend the meeting , can we postpone the meeting to 14:00pm BST time,Nov 1st?
Thanks:) Joyce
在 2022年10月21日，上午12:19，Russell King (Oracle) linux@armlinux.org.uk 写道：
On Thu, Oct 20, 2022 at 04:06:05PM +0100, James Morse wrote:
I've not got to rebase the virtual cpu hotplug stuff - I've been busy turning the MPAM stuff around this week. (and I'm out next monday)
This item is of particular interest.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Fri, Oct 21, 2022 at 07:04:58AM +0800, Joyce Qi wrote:
Hi all
Having received some feedbacks about the time and some US colleagues would like to attend the meeting , can we postpone the meeting to 14:00pm BST time,Nov 1st?
No problem for me, thanks.
Hi Joyce, I am perfectly okay with this.
Hope it is not too late for you as BST(British Summer Time) will end on 30th Oct 2022. Hence, clocks will go back by 1 hour and UK will start to follow GMT. The time difference between UK and china CST will now increase to 8 hours instead of current 7 hours.
Although, I can see you have adjusted the time back from 3:00PM -> 2:00 PM but not sure if this was a proactive adjustment to account for BST->GMT change? If in case intention was to start the meeting a bit earlier at 9:00PM CST this time then perhaps we might have to pull the meeting little bit more by 1 hour?
I would request everyone (including US folks) to take into account this BST->GMT change before making sure their availability.
Many thanks Salil
-----Original Message----- From: Joyce Qi [mailto:joyce.qi@linaro.org] Sent: Friday, October 21, 2022 12:05 AM To: Russell King (Oracle) linux@armlinux.org.uk; Ilkka Koskinen ilkka@os.amperecomputing.com Cc: James Morse james.morse@arm.com; Jonathan Cameron jonathan.cameron@huawei.com; Salil Mehta salil.mehta@huawei.com; Lorenzo Pieralisi lorenzo.pieralisi@linaro.org; Jonathan Cameron via Linaro-open-discussions linaro-open-discussions@op-lists.linaro.org Subject: Re: Linaro-open-discussions Digest, Vol 25, Issue 3
Hi all
Having received some feedbacks about the time and some US colleagues would like to attend the meeting , can we postpone the meeting to 14:00pm BST time,Nov 1st?
Thanks:) Joyce
在 2022年10月21日，上午12:19，Russell King (Oracle) linux@armlinux.org.uk
写道：
On Thu, Oct 20, 2022 at 04:06:05PM +0100, James Morse wrote:
I've not got to rebase the virtual cpu hotplug stuff - I've been busy turning
the MPAM
stuff around this week. (and I'm out next monday)
This item is of particular interest.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Hi James, It totally skipped my mind earlier to mention that apart from what I have already shared through the below repositories, and as discussed in early September on LOD, I have also been experimenting with another approach (nothing new but something similar and based on yours and JPBs suggestion) for VCPU Hotplug. It is a non-ACPI version and banks upon trapping KVM Host PSCI to user space (i.e. CPU_ON, CPU_OFF etc.) to let QEMU make the decisions i.e. whether CPUs could be made online or not. Most of the kernel patches i.e. at both guest and KVM level are already in place in your repository. I have changed the QEMU part (mostly inspired from JPBs work he shared earlier in June 2021).
This approach of course is not different than what you have already shared recently just that it can work without any ACPI exchanges (which as you mentioned could be frowned upon by the community) but still banks upon the QMP interface to hot-{add|remove} the vcpus at VMM/QEMU level. It goes without the mention that, even for this approach, we still would need to solve the present==possible related issues at the guest level which have been discussed earlier.
Would soon be sharing repository for this change as well soon (before next LOD meeting of 1st Nov?) so that we have everything on table to compare.
Hi Joyce, As I am still recovering from surgery and I am only able to occasionally access the laptop. Hence, for any communication on LOD including me please also CC on the below addresses as well:
salil.mehta@opnsrc.net/mehta.salil.lnk@gmail.com
Thanks for understanding!
Best regards Salil
-----Original Message----- From: James Morse [mailto:james.morse@arm.com] Sent: Thursday, October 20, 2022 4:06 PM To: Joyce Qi joyce.qi@linaro.org; Jonathan Cameron jonathan.cameron@huawei.com; Salil Mehta salil.mehta@huawei.com; Lorenzo Pieralisi lorenzo.pieralisi@linaro.org Cc: Jonathan Cameron via Linaro-open-discussions linaro-open-discussions@op-lists.linaro.org; linux@armlinux.org.uk Subject: Re: Linaro-open-discussions Digest, Vol 25, Issue 3
Hello,
I have two small topics that are relevant to CXL:
- maintaining the UEFI memory map with hotplug memory (series in development,
no ACPI changes needed)
- Cache invalidate for NVdimm unlock and erase (spec proposal which will need
a customer)
These would only take about thirty minutes, unless we want to go into all the gory details of the first one. I don't think its worth having the meeting just for these.
I've not got to rebase the virtual cpu hotplug stuff - I've been busy turning the MPAM stuff around this week. (and I'm out next monday)
Thanks,
James
On 20/10/2022 13:47, Joyce Qi wrote:
Hi Jonathan,Lorenzo,all,
Do we have any topic to sync on our LOD meeting next week?
Thanks:) Joyce
在 2022年10月18日，上午8:00，
linaro-open-discussions-request@op-lists.linaro.org 写道：
Send Linaro-open-discussions mailing list submissions to linaro-open-discussions@op-lists.linaro.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to linaro-open-discussions-request@op-lists.linaro.org
You can reach the person managing the list at linaro-open-discussions-owner@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:
- Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022
19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)
(Salil Mehta)
Message: 1 Date: Mon, 17 Oct 2022 16:12:26 +0000 From: Salil Mehta salil.mehta@huawei.com Subject: [Linaro-open-discussions] Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) To: "joyce.qi@linaro.org" joyce.qi@linaro.org, "james.morse@arm.com" james.morse@arm.com Cc: "linaro-open-discussions@op-lists.linaro.org" linaro-open-discussions@op-lists.linaro.org, "lorenzo.pieralisi@linaro.org" lorenzo.pieralisi@linaro.org, "ilkka@os.amperecomputing.com" ilkka@os.amperecomputing.com, Jean-Philippe Brucker jean-philippe.brucker@arm.com, "salil.mehta@opnsrc.net" salil.mehta@opnsrc.net Message-ID: 12408d4c06604dd4bd8e017adf7e5fe6@huawei.com Content-Type: text/plain; charset="utf-8"
Hi James, As discussed in the meeting below are the repositories which you might want
to have a look.
[1] Forward ported QEMU with some fixes was shared (by Salil) https://github.com/salil-mehta/qemu.git
virt-cpuhp-armv8/rfc-v1-port29092022
[2] James Approach with online-capable and present==possible (some fixes) https://github.com/salil-mehta/linux.git
virt-cpuhp-arm64/rfc-v2/jmorse-pres-eq-poss-cpu
[3] Variant of James approach with online-capable and conditionally present
cpus
https://github.com/salil-mehta/linux.gitvirt-cpuhp-arm64/rfc-v2/jmorse-variant-with-cond-present-cpu
I have also shared the LOD presentation with Joyce for uploading to the site.
Attachment: [1] Linaro Open Discussion Meeting Update - 05102022 - Salil_Mehta-fixed.pdf
Many thanks Salil
-----Original Message----- From: Google Calendar [mailto:calendar-notification@google.com] On Behalf
Of
Joyce Qi via Linaro-open-discussions Sent: Wednesday, October 5, 2022 9:31 AM To: linaro-open-discussions@op-lists.linaro.org; james.morse@arm.com; Jonathan Cameron jonathan.cameron@huawei.com;
lorenzo.pieralisi@linaro.org;
ilkka@os.amperecomputing.com Subject: [Linaro-open-discussions] Invitation: Linaro Open Discussions
monthly
meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)
Linaro Open Discussions monthly meeting Wednesday 5 Oct 2022 ⋅ 19:00 – 20:00 Hong Kong Standard Time
https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250
0341&sa=D&source=calendar&usd=2&usg=AOvVaw2JDK9LgOcXl2WanQ86Y-6h
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议 https://linaro-org.zoom.us/j/95682500341
会议号：956 8250 0341 手机一键拨号 +16699009128,,95682500341# 美国 (San Jose) +13462487799,,95682500341# 美国 (Houston)
根据您的位置拨号 +1 669 900 9128 美国 (San Jose) +1 346 248 7799 美国 (Houston) +1 253 215 8782 美国 (Tacoma) +1 646 558 8656 美国 (New York) +1 301 715 8592 美国 (Washington DC) +1 312 626 6799 美国 (Chicago) 888 788 0099 美国 免费 877 853 5247 美国 免费 会议号：956 8250 0341 查找本地号码：https://linaro-org.zoom.us/u/ady2J9Zn7t
Guests linaro-open-discussions@op-lists.linaro.org james.morse@arm.com jonathan.cameron@huawei.com lorenzo.pieralisi@linaro.org ilkka@os.amperecomputing.com View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM...
cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B
vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc
m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi
ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0
Reply for linaro-open-discussions@op-lists.linaro.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM...
cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B
vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc
m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi
ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0 Your attendance is optional.
~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event. To stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
Subject: Digest Footer
Linaro-open-discussions mailing list --
linaro-open-discussions@op-lists.linaro.org
To unsubscribe send an email to
linaro-open-discussions-leave@op-lists.linaro.org
End of Linaro-open-discussions Digest, Vol 25, Issue 3
Hi,
On Fri, Oct 21, 2022 at 12:28:23AM +0000, Salil Mehta wrote:
Hi James, It totally skipped my mind earlier to mention that apart from what I have already shared through the below repositories, and as discussed in early September on LOD, I have also been experimenting with another approach (nothing new but something similar and based on yours and JPBs suggestion) for VCPU Hotplug. It is a non-ACPI version and banks upon trapping KVM Host PSCI to user space (i.e. CPU_ON, CPU_OFF etc.) to let QEMU make the decisions i.e. whether CPUs could be made online or not.
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
Thanks.
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
On Fri, Oct 21, 2022 at 12:28:23AM +0000, Salil Mehta wrote:
Hi James, It totally skipped my mind earlier to mention that apart from what I have already shared through the below repositories, and as discussed in early September on LOD, I have also been experimenting with another approach (nothing new but something similar and based on yours and JPBs suggestion) for VCPU Hotplug. It is a non-ACPI version and banks upon trapping KVM Host PSCI to user space (i.e. CPU_ON, CPU_OFF etc.) to let QEMU make the decisions i.e. whether CPUs could be made online or not.
Er, ... this is how it is expected to work. CPU_ON had 'Denied' added to allow firmware to apply some policy to which CPUs can be brought online.
There are two aspects to the ACPI changes. One is to tell the OS that the policy has changed, and it should try to bring CPUs online. This is required to make the use-case work. If the udev triggers don't occur when the policy change, this whole exercise is futile. The other is the online-capable bit in the MADT. This is because other operating systems may not be tolerant to PSCI returning errors. (although: it has always been able to do this).
I don't think you can remove the ACPI bits.
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
CPU_ON shouldn't block, but can (now) return DENIED if the firmware policy means the CPU is "pretend not-present". The cover-letter for the early-RFC series has more details: https://op-lists.linaro.org/archives/list/linaro-open-discussions@op-lists.l...
I'm fine with 2pm UK time on the first of November. If I get the MPAM series out today, I'll have time to work on this thing next week. (I think I've found a volunteer to test the Kubernetes stuff with it)
Thanks,
James
On Fri, Oct 21, 2022 at 10:45:48AM +0100, James Morse wrote:
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
CPU_ON shouldn't block, but can (now) return DENIED if the firmware policy means the CPU is "pretend not-present".
That is what I meant. Not "block" as in "wait until something".
Hi Russell,
On 21/10/2022 12:37, Russell King (Oracle) wrote:
On Fri, Oct 21, 2022 at 10:45:48AM +0100, James Morse wrote:
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
CPU_ON shouldn't block, but can (now) return DENIED if the firmware policy means the CPU is "pretend not-present".
That is what I meant. Not "block" as in "wait until something".
Sorry - I read that wrong! (I've been in lockdep hell all morning).
ACPI already has mechanisms for this. The _STA value/policy can only change when the CPU is offline. If firmware wants request a CPU is taken offline, it can issue a eject-request notification. If the OS will then take the CPU offline, and call _EJ0 to say its done, as well as updating _OST with its progress.
There is no mechanism to forcibly offline a running CPU.
Thanks,
James
On Fri, Oct 21, 2022 at 02:01:20PM +0100, James Morse wrote:
Hi Russell,
On 21/10/2022 12:37, Russell King (Oracle) wrote:
On Fri, Oct 21, 2022 at 10:45:48AM +0100, James Morse wrote:
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
CPU_ON shouldn't block, but can (now) return DENIED if the firmware policy means the CPU is "pretend not-present".
That is what I meant. Not "block" as in "wait until something".
Sorry - I read that wrong! (I've been in lockdep hell all morning).
ACPI already has mechanisms for this. The _STA value/policy can only change when the CPU is offline. If firmware wants request a CPU is taken offline, it can issue a eject-request notification. If the OS will then take the CPU offline, and call _EJ0 to say its done, as well as updating _OST with its progress.
As far as I'm aware, this isn't yet implemented in mainline kernels for aarch64, but the mechanism you describe is used for x86.
Hi All，
I have booked the LOD meeting at 14:00PM BST time, Nov 1st.
@Salil, thanks for noticing the summer time changes from Nov:)
Thanks:) Joyce
在 2022年10月21日，下午9:17，Russell King (Oracle) linux@armlinux.org.uk 写道：
On Fri, Oct 21, 2022 at 02:01:20PM +0100, James Morse wrote:
Hi Russell,
On 21/10/2022 12:37, Russell King (Oracle) wrote:
On Fri, Oct 21, 2022 at 10:45:48AM +0100, James Morse wrote:
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
CPU_ON shouldn't block, but can (now) return DENIED if the firmware policy means the CPU is "pretend not-present".
That is what I meant. Not "block" as in "wait until something".
Sorry - I read that wrong! (I've been in lockdep hell all morning).
ACPI already has mechanisms for this. The _STA value/policy can only change when the CPU is offline. If firmware wants request a CPU is taken offline, it can issue a eject-request notification. If the OS will then take the CPU offline, and call _EJ0 to say its done, as well as updating _OST with its progress.
As far as I'm aware, this isn't yet implemented in mainline kernels for aarch64, but the mechanism you describe is used for x86.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Fri, Oct 21, 2022 at 10:18:39PM +0800, Joyce Qi wrote:
Hi All，
I have booked the LOD meeting at 14:00PM BST time, Nov 1st.
That's a bank holiday in Italy. I feel a bit guilty for asking to change the day just because of me, if we can't change the day I will try to attend anyway on Nov 1st.
Thanks, Lorenzo
@Salil, thanks for noticing the summer time changes from Nov:)
Thanks:) Joyce
在 2022年10月21日，下午9:17，Russell King (Oracle) linux@armlinux.org.uk 写道：
On Fri, Oct 21, 2022 at 02:01:20PM +0100, James Morse wrote:
Hi Russell,
On 21/10/2022 12:37, Russell King (Oracle) wrote:
On Fri, Oct 21, 2022 at 10:45:48AM +0100, James Morse wrote:
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
CPU_ON shouldn't block, but can (now) return DENIED if the firmware policy means the CPU is "pretend not-present".
That is what I meant. Not "block" as in "wait until something".
Sorry - I read that wrong! (I've been in lockdep hell all morning).
ACPI already has mechanisms for this. The _STA value/policy can only change when the CPU is offline. If firmware wants request a CPU is taken offline, it can issue a eject-request notification. If the OS will then take the CPU offline, and call _EJ0 to say its done, as well as updating _OST with its progress.
As far as I'm aware, this isn't yet implemented in mainline kernels for aarch64, but the mechanism you describe is used for x86.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Hi Russel,
From: Russell King [mailto:linux@armlinux.org.uk] Sent: Friday, October 21, 2022 2:17 PM To: James Morse james.morse@arm.com Cc: Salil Mehta salil.mehta@huawei.com; Joyce Qi joyce.qi@linaro.org; Jonathan Cameron jonathan.cameron@huawei.com; Lorenzo Pieralisi lorenzo.pieralisi@linaro.org; Jean-Philippe Brucker jean-philippe@linaro.org; Jean-Philippe Brucker jean-philippe.brucker@arm.com; linaro-open-discussions@op-lists.linaro.org; salil.mehta@opnsrc.net; mehta.salil.lnk@gmail.com Subject: Re: Linaro-open-discussions Digest, Vol 25, Issue 3
On Fri, Oct 21, 2022 at 02:01:20PM +0100, James Morse wrote:
Hi Russell,
On 21/10/2022 12:37, Russell King (Oracle) wrote:
On Fri, Oct 21, 2022 at 10:45:48AM +0100, James Morse wrote:
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
CPU_ON shouldn't block, but can (now) return DENIED if the firmware policy
means the CPU
is "pretend not-present".
That is what I meant. Not "block" as in "wait until something".
Sorry - I read that wrong! (I've been in lockdep hell all morning).
ACPI already has mechanisms for this. The _STA value/policy can only change
when the CPU
is offline. If firmware wants request a CPU is taken offline, it can issue
a eject-request
notification. If the OS will then take the CPU offline, and call _EJ0 to say
its done, as
well as updating _OST with its progress.
As far as I'm aware, this isn't yet implemented in mainline kernels for aarch64, but the mechanism you describe is used for x86.
ACPI Handshake code is common to all the architectures and yes there are some arch specific hooks (__weak functions like acpi_{un}map_cpu) which must be overridden if "Physical CPU Hotplug" has to be supported like in x86 but this is not our intention. ARM64 does not have physical Hotplug support and we are only targeting virtual CPU Hotplug here. We are just leveraging the ACPI handshake code, meant for the physical vCPU Hotplug hot-{add, remove}, to make vCPUs as {not-}present (well kind of, in actual they are always present) in the Linux kernel while being hot-{added, removed} through those ACPI events from the firmware/VMM.
James has done most of the hard bits and suggested kernel changes to support this in August 2022:
[1] https://gitlab.arm.com/linux-arm/linux-jm/-/commits/virtual_cpu_hotplug/rfc/...
[Meaning of making {not-}present in above patches means {not-}making the CPU device available by {un-}registering_cpu() according to the ACPI events]
You might want to check, a variant of James approach which also conditionally {un-}sets the present cpu mask.
[2] https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-variant-with-cond-present-cpu
[Meaning of making {not-}present in above patches means {not-}making the CPU device available by {un}register_cpu() AND also {un-}set'ing the CPU bit in the present_cpu_mask according to the ACPI events]
Above can be tested using these QEMU changes: [3] https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v1-port29092022
Thanks Salil
From: James Morse [mailto:james.morse@arm.com] Sent: Friday, October 21, 2022 2:01 PM To: Russell King (Oracle) linux@armlinux.org.uk Cc: Salil Mehta salil.mehta@huawei.com; Joyce Qi joyce.qi@linaro.org; Jonathan Cameron jonathan.cameron@huawei.com; Lorenzo Pieralisi lorenzo.pieralisi@linaro.org; Jean-Philippe Brucker jean-philippe@linaro.org; Jean-Philippe Brucker jean-philippe.brucker@arm.com; linaro-open-discussions@op-lists.linaro.org; salil.mehta@opnsrc.net; mehta.salil.lnk@gmail.com Subject: Re: Linaro-open-discussions Digest, Vol 25, Issue 3
Hi Russell,
On 21/10/2022 12:37, Russell King (Oracle) wrote:
On Fri, Oct 21, 2022 at 10:45:48AM +0100, James Morse wrote:
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU. How would that aspect be addressed with your approach?
CPU_ON shouldn't block, but can (now) return DENIED if the firmware policy
means the CPU
is "pretend not-present".
That is what I meant. Not "block" as in "wait until something".
Sorry - I read that wrong! (I've been in lockdep hell all morning).
ACPI already has mechanisms for this. The _STA value/policy can only change when the CPU is offline. If firmware wants request a CPU is taken offline, it can issue a eject-request notification. If the OS will then take the CPU offline, and call _EJ0 to say its done, as well as updating _OST with its progress.
There is no mechanism to forcibly offline a running CPU.
Hi Russel,
You might want to see "slide 5 - Quick Overview Virtual CPU Hot-(un)plug Event Sequence" for the detailed interactions of what James just explained:
Reference: https://kvmforum2020.sched.com/event/eE4m/challenges-in-supporting-virtual-c...
Code Reference, File: linux/drivers/acpi/scan.c
acpi_scan_hot_remove(struct acpi_device *device) { [...] acpi_scan_try_to_offline(device); [...] status = acpi_evaluate_ej0(handle); [...] }
Thanks Salil
Hello,
From: James Morse [mailto:james.morse@arm.com] Sent: Friday, October 21, 2022 10:46 AM To: Russell King (Oracle) linux@armlinux.org.uk; Salil Mehta salil.mehta@huawei.com Cc: Joyce Qi joyce.qi@linaro.org; Jonathan Cameron jonathan.cameron@huawei.com; Lorenzo Pieralisi lorenzo.pieralisi@linaro.org; Jean-Philippe Brucker jean-philippe@linaro.org; Jean-Philippe Brucker jean-philippe.brucker@arm.com; linaro-open-discussions@op-lists.linaro.org; salil.mehta@opnsrc.net; mehta.salil.lnk@gmail.com Subject: Re: Linaro-open-discussions Digest, Vol 25, Issue 3
Hi Russell, Salil,
On 21/10/2022 08:38, Russell King (Oracle) wrote:
On Fri, Oct 21, 2022 at 12:28:23AM +0000, Salil Mehta wrote:
Hi James, It totally skipped my mind earlier to mention that apart from what I have
already
shared through the below repositories, and as discussed in early September
on LOD,
I have also been experimenting with another approach (nothing new but something similar and based on yours and JPBs suggestion) for VCPU Hotplug. It is a
non-ACPI
version and banks upon trapping KVM Host PSCI to user space (i.e. CPU_ON, CPU_OFF etc.) to let QEMU make the decisions i.e. whether CPUs could be made
online
or not.
Er, ... this is how it is expected to work. CPU_ON had 'Denied' added to allow firmware to apply some policy to which CPUs can be brought online.
sure, but we had not talked about using this on non-ACPI version (which of course does not looks like we can achieve)
There are two aspects to the ACPI changes. One is to tell the OS that the policy has changed, and it should try to bring CPUs online. This is required to make the use-case work. If the udev triggers don't occur when the policy change, this whole exercise is futile. The other is the online-capable bit in the MADT. This is because other operating systems may not be tolerant to PSCI returning errors. (although: it has always been able to do this).
I don't think you can remove the ACPI bits.
Agreed. Does not looks like without using any out-of-band notification like gRPC etc. but then we have already discussed the problems associated with this approach.
Hi Russel,
From: Russell King [mailto:linux@armlinux.org.uk] Sent: Friday, October 21, 2022 8:39 AM To: Salil Mehta salil.mehta@huawei.com Cc: James Morse james.morse@arm.com; Joyce Qi joyce.qi@linaro.org; Jonathan Cameron jonathan.cameron@huawei.com; Lorenzo Pieralisi lorenzo.pieralisi@linaro.org; Jean-Philippe Brucker jean-philippe@linaro.org; Jean-Philippe Brucker jean-philippe.brucker@arm.com; linaro-open-discussions@op-lists.linaro.org; salil.mehta@opnsrc.net; mehta.salil.lnk@gmail.com Subject: Re: Linaro-open-discussions Digest, Vol 25, Issue 3
Hi,
On Fri, Oct 21, 2022 at 12:28:23AM +0000, Salil Mehta wrote:
Hi James, It totally skipped my mind earlier to mention that apart from what I have already shared through the below repositories, and as discussed in early September
on LOD,
I have also been experimenting with another approach (nothing new but something similar and based on yours and JPBs suggestion) for VCPU Hotplug. It is a non-ACPI version and banks upon trapping KVM Host PSCI to user space (i.e. CPU_ON, CPU_OFF etc.) to let QEMU make the decisions i.e. whether CPUs could be made
online
or not.
This is fine if the guest hasn't already brought the vCPU online, but if it has, blocking CPU_ON doesn't prevent the guest continuing to use the vCPU.
[Sorry for the delayed reply and I did not make myself very clear while I wrote above. This is not my approach. In fact, originally this primitive approach[1] was used as a workaround of not having ACPI support for vCPU Hotplug on ARM64]
That is correct. That is a problem if we do not use ACPI and has been discussed earlier. To address this in non-ACPI, people have been using out-of-the-band notification using gRPC[1] to the guest to bring down the vCPUs which itself is plagued with many problems.
Now, because James added code to trap the PSCI-to-userspace calls, I just thought to give it another go but I must admit I could not find a cleaner way to address the problem you mentioned.
[1] Reference: https://github.com/kata-containers/runtime/issues/1262
Thanks Salil
I've not got to rebase the virtual cpu hotplug stuff - I've been busy turning the MPAM stuff around this week. (and I'm out next monday)
Below repo has been rebased to latest kernel. Please check:
James Approach with online-capable and present==possible (some fixes) https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-pres-eq-poss-cpu
Thanks,
James
On 20/10/2022 13:47, Joyce Qi wrote:
Hi Jonathan,Lorenzo,all,
Do we have any topic to sync on our LOD meeting next week?
Thanks:) Joyce
在 2022年10月18日，上午8:00，
linaro-open-discussions-request@op-lists.linaro.org 写道：
Send Linaro-open-discussions mailing list submissions to linaro-open-discussions@op-lists.linaro.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to linaro-open-discussions-request@op-lists.linaro.org
You can reach the person managing the list at linaro-open-discussions-owner@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:
- Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022
19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)
(Salil Mehta)
Message: 1 Date: Mon, 17 Oct 2022 16:12:26 +0000 From: Salil Mehta salil.mehta@huawei.com Subject: [Linaro-open-discussions] Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) To: "joyce.qi@linaro.org" joyce.qi@linaro.org, "james.morse@arm.com" james.morse@arm.com Cc: "linaro-open-discussions@op-lists.linaro.org" linaro-open-discussions@op-lists.linaro.org, "lorenzo.pieralisi@linaro.org" lorenzo.pieralisi@linaro.org, "ilkka@os.amperecomputing.com" ilkka@os.amperecomputing.com, Jean-Philippe Brucker jean-philippe.brucker@arm.com, "salil.mehta@opnsrc.net" salil.mehta@opnsrc.net Message-ID: 12408d4c06604dd4bd8e017adf7e5fe6@huawei.com Content-Type: text/plain; charset="utf-8"
Hi James, As discussed in the meeting below are the repositories which you might want
to have a look.
[1] Forward ported QEMU with some fixes was shared (by Salil) https://github.com/salil-mehta/qemu.git
virt-cpuhp-armv8/rfc-v1-port29092022
[2] James Approach with online-capable and present==possible (some fixes) https://github.com/salil-mehta/linux.git
virt-cpuhp-arm64/rfc-v2/jmorse-pres-eq-poss-cpu
[3] Variant of James approach with online-capable and conditionally present
cpus
https://github.com/salil-mehta/linux.gitvirt-cpuhp-arm64/rfc-v2/jmorse-variant-with-cond-present-cpu
I have also shared the LOD presentation with Joyce for uploading to the site.
Attachment: [1] Linaro Open Discussion Meeting Update - 05102022 - Salil_Mehta-fixed.pdf
Many thanks Salil
-----Original Message----- From: Google Calendar [mailto:calendar-notification@google.com] On Behalf
Of
Joyce Qi via Linaro-open-discussions Sent: Wednesday, October 5, 2022 9:31 AM To: linaro-open-discussions@op-lists.linaro.org; james.morse@arm.com; Jonathan Cameron jonathan.cameron@huawei.com;
lorenzo.pieralisi@linaro.org;
ilkka@os.amperecomputing.com Subject: [Linaro-open-discussions] Invitation: Linaro Open Discussions
monthly
meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)
Linaro Open Discussions monthly meeting Wednesday 5 Oct 2022 ⋅ 19:00 – 20:00 Hong Kong Standard Time
https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250
0341&sa=D&source=calendar&usd=2&usg=AOvVaw2JDK9LgOcXl2WanQ86Y-6h
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议 https://linaro-org.zoom.us/j/95682500341
会议号：956 8250 0341 手机一键拨号 +16699009128,,95682500341# 美国 (San Jose) +13462487799,,95682500341# 美国 (Houston)
根据您的位置拨号 +1 669 900 9128 美国 (San Jose) +1 346 248 7799 美国 (Houston) +1 253 215 8782 美国 (Tacoma) +1 646 558 8656 美国 (New York) +1 301 715 8592 美国 (Washington DC) +1 312 626 6799 美国 (Chicago) 888 788 0099 美国 免费 877 853 5247 美国 免费 会议号：956 8250 0341 查找本地号码：https://linaro-org.zoom.us/u/ady2J9Zn7t
Guests linaro-open-discussions@op-lists.linaro.org james.morse@arm.com jonathan.cameron@huawei.com lorenzo.pieralisi@linaro.org ilkka@os.amperecomputing.com View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM...
cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B
vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc
m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi
ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0
Reply for linaro-open-discussions@op-lists.linaro.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM...
cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B
vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc
m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi
ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0 Your attendance is optional.
~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event. To stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
Subject: Digest Footer
Linaro-open-discussions mailing list --
linaro-open-discussions@op-lists.linaro.org
To unsubscribe send an email to
linaro-open-discussions-leave@op-lists.linaro.org
End of Linaro-open-discussions Digest, Vol 25, Issue 3
On Thu, 20 Oct 2022 16:06:05 +0100 James Morse james.morse@arm.com wrote:
Hello,
I have two small topics that are relevant to CXL:
- maintaining the UEFI memory map with hotplug memory (series in development, no ACPI changes needed)
- Cache invalidate for NVdimm unlock and erase (spec proposal which will need a customer)
Hi James,
Dan raised an "interesting" point... https://lore.kernel.org/all/6387ed1b67fb7_c957294dd@dwillia2-mobl3.amr.corp....
Dan is arguing that we are obliged to flush all caches on any changing of address decoders. So basically any case where the OS is setting up any CXL memory for access. That applies to hotplug of volatile memory, or any OS managed bring up (including all persistent memory as there isn't currently a good way to bring that up in firmware even if it is there at he beginning).
It's plausible that he is right though I've not thought about it in enough depth yet + need to talk it through with our architecture experts to make sure I'm not missing something. If he is, that cache invalidate proposal just became much higher priority.
Jonathan
These would only take about thirty minutes, unless we want to go into all the gory details of the first one. I don't think its worth having the meeting just for these.
I've not got to rebase the virtual cpu hotplug stuff - I've been busy turning the MPAM stuff around this week. (and I'm out next monday)
Thanks,
James
On 20/10/2022 13:47, Joyce Qi wrote:
Hi Jonathan,Lorenzo,all,
Do we have any topic to sync on our LOD meeting next week?
Thanks:) Joyce
在 2022年10月18日，上午8:00，linaro-open-discussions-request@op-lists.linaro.org 写道：
Send Linaro-open-discussions mailing list submissions to linaro-open-discussions@op-lists.linaro.org
To subscribe or unsubscribe via email, send a message with subject or body 'help' to linaro-open-discussions-request@op-lists.linaro.org
You can reach the person managing the list at linaro-open-discussions-owner@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:
- Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) (Salil Mehta)
Message: 1 Date: Mon, 17 Oct 2022 16:12:26 +0000 From: Salil Mehta salil.mehta@huawei.com Subject: [Linaro-open-discussions] Re: Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org) To: "joyce.qi@linaro.org" joyce.qi@linaro.org, "james.morse@arm.com" james.morse@arm.com Cc: "linaro-open-discussions@op-lists.linaro.org" linaro-open-discussions@op-lists.linaro.org, "lorenzo.pieralisi@linaro.org" lorenzo.pieralisi@linaro.org, "ilkka@os.amperecomputing.com" ilkka@os.amperecomputing.com, Jean-Philippe Brucker jean-philippe.brucker@arm.com, "salil.mehta@opnsrc.net" salil.mehta@opnsrc.net Message-ID: 12408d4c06604dd4bd8e017adf7e5fe6@huawei.com Content-Type: text/plain; charset="utf-8"
Hi James, As discussed in the meeting below are the repositories which you might want to have a look.
[1] Forward ported QEMU with some fixes was shared (by Salil) https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v1-port29092022
[2] James Approach with online-capable and present==possible (some fixes) https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-pres-eq-poss-cpu
[3] Variant of James approach with online-capable and conditionally present cpus https://github.com/salil-mehta/linux.git virt-cpuhp-arm64/rfc-v2/jmorse-variant-with-cond-present-cpu
I have also shared the LOD presentation with Joyce for uploading to the site.
Attachment: [1] Linaro Open Discussion Meeting Update - 05102022 - Salil_Mehta-fixed.pdf
Many thanks Salil
-----Original Message----- From: Google Calendar [mailto:calendar-notification@google.com] On Behalf Of Joyce Qi via Linaro-open-discussions Sent: Wednesday, October 5, 2022 9:31 AM To: linaro-open-discussions@op-lists.linaro.org; james.morse@arm.com; Jonathan Cameron jonathan.cameron@huawei.com; lorenzo.pieralisi@linaro.org; ilkka@os.amperecomputing.com Subject: [Linaro-open-discussions] Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)
Linaro Open Discussions monthly meeting Wednesday 5 Oct 2022 ⋅ 19:00 – 20:00 Hong Kong Standard Time
Location https://linaro-org.zoom.us/j/95682500341 https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250 0341&sa=D&source=calendar&usd=2&usg=AOvVaw2JDK9LgOcXl2WanQ86Y-6h
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议 https://linaro-org.zoom.us/j/95682500341
会议号：956 8250 0341 手机一键拨号 +16699009128,,95682500341# 美国 (San Jose) +13462487799,,95682500341# 美国 (Houston)
根据您的位置拨号 +1 669 900 9128 美国 (San Jose) +1 346 248 7799 美国 (Houston) +1 253 215 8782 美国 (Tacoma) +1 646 558 8656 美国 (New York) +1 301 715 8592 美国 (Washington DC) +1 312 626 6799 美国 (Chicago) 888 788 0099 美国 免费 877 853 5247 美国 免费 会议号：956 8250 0341 查找本地号码：https://linaro-org.zoom.us/u/ady2J9Zn7t
Guests linaro-open-discussions@op-lists.linaro.org james.morse@arm.com jonathan.cameron@huawei.com lorenzo.pieralisi@linaro.org ilkka@os.amperecomputing.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM... cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0
Reply for linaro-open-discussions@op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiM... cGlsYW8zb2hwa3E5cWFfMjAyMjA5MjdUMTEwMDAwWiBsaW5hcm8tb3Blbi1kaXNjdXNzaW9uc0B vcC1saXN0cy5saW5hcm8ub3Jn&tok=NTQjY184anE0dGh2ZTNuN3NlaThhMGpmazlwdXI3c0Bnc m91cC5jYWxlbmRhci5nb29nbGUuY29tY2JlMDNmZTk3ZTYzMGMyN2ExZDE2N2QyYjcwOTYxMjNi ODIwMjA0ZQ&ctz=Asia%2FHong_Kong&hl=en_GB&es=0 Your attendance is optional.
~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event. To stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
Subject: Digest Footer
Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org To unsubscribe send an email to linaro-open-discussions-leave@op-lists.linaro.org
End of Linaro-open-discussions Digest, Vol 25, Issue 3
Hi Jonathan,
On 01/12/2022 11:02, Jonathan Cameron wrote:
On Thu, 20 Oct 2022 16:06:05 +0100 Dan raised an "interesting" point... https://lore.kernel.org/all/6387ed1b67fb7_c957294dd@dwillia2-mobl3.amr.corp....
Dan is arguing that we are obliged to flush all caches on any changing of address decoders. So basically any case where the OS is setting up any CXL memory for access. That applies to hotplug of volatile memory, or any OS managed bring up (including all persistent memory as there isn't currently a good way to bring that up in firmware even if it is there at he beginning).
It's plausible that he is right though I've not thought about it in enough depth yet
- need to talk it through with our architecture experts to make sure I'm not missing something.
If he is, that cache invalidate proposal just became much higher priority.
Great, I've given a gentle nudge to the folk who were looking at this.
If you're looking at a particular platform for this sort of thing, it would be interesting to know what kind of ballpark the latencies are in for the maintenance. I'm in two minds as to whether something about the latency needs advertising, or we need to make it interruptible/restartable. Over a certain amount we need to tell RCU to calm down, even longer I'd start to worry about interrupt latency.
I don't completely follow the CXL discussion. Is it possible this needs doing for a subset of a window? For the NVDIMM use-cases the granularity was implicitly the device. The constraints on firmware may be different if a cache only needs partially invalidating.
Thanks,
James
Hi, Lorenzo
When we debug vsva, sva on guest with 2-stage translation, we found tlb miss impact performance a lot, with Jean's help.
Currently we are using huge page feature in glibc to overcome this issue. With huge page, vsva in guest can achieve comparable performance as sva in host.
More details: https://docs.qq.com/doc/DRXlpQmpTSlBZTGZZ Will do some
Basically we are using two optimization methods/ host sva: using memset fist to overcome io page fault, since cpu alloc physical memory is much faster than smmu. guest vsva: using huge page to overcome tlbmiss.
The customer are asking whether (next version) silicon (smmu) can do some help to concur tlb miss issue or io page fault issue. If so, software can be simpler. Any suggestions?
Thanks
On 2022/10/20 下午8:47, Joyce Qi via Linaro-open-discussions wrote:
Hi Jonathan,Lorenzo,all,
Do we have any topic to sync on our LOD meeting next week?
Thanks:) Joyce
On Thu, Oct 27, 2022 at 12:06:59PM +0800, Zhangfei Gao wrote:
Hi, Lorenzo
When we debug vsva, sva on guest with 2-stage translation, we found tlb miss impact performance a lot, with Jean's help.
Currently we are using huge page feature in glibc to overcome this issue. With huge page, vsva in guest can achieve comparable performance as sva in host.
More details: https://docs.qq.com/doc/DRXlpQmpTSlBZTGZZ Will do some
Basically we are using two optimization methods/ host sva: using memset fist to overcome io page fault, since cpu alloc physical memory is much faster than smmu. guest vsva: using huge page to overcome tlbmiss.
The customer are asking whether (next version) silicon (smmu) can do some help to concur tlb miss issue or io page fault issue.
I can bring this up with the SMMU architect - thank you for taking time to describe the use cases and SW you are deploying.
If so, software can be simpler. Any suggestions?
Talking to SMMU architects - there is not much SW can do other than what you are doing already.
Thanks, Lorenzo
Thanks
On 2022/10/20 下午8:47, Joyce Qi via Linaro-open-discussions wrote:
Hi Jonathan,Lorenzo,all,
Do we have any topic to sync on our LOD meeting next week?
Thanks:) Joyce
On Sat, 17 Dec 2022 at 00:14, Lorenzo Pieralisi lorenzo.pieralisi@linaro.org wrote:
On Thu, Oct 27, 2022 at 12:06:59PM +0800, Zhangfei Gao wrote:
Hi, Lorenzo
When we debug vsva, sva on guest with 2-stage translation, we found tlb miss impact performance a lot, with Jean's help.
Currently we are using huge page feature in glibc to overcome this issue. With huge page, vsva in guest can achieve comparable performance as sva in host.
More details: https://docs.qq.com/doc/DRXlpQmpTSlBZTGZZ Will do some
Basically we are using two optimization methods/ host sva: using memset fist to overcome io page fault, since cpu alloc physical memory is much faster than smmu. guest vsva: using huge page to overcome tlbmiss.
The customer are asking whether (next version) silicon (smmu) can do some help to concur tlb miss issue or io page fault issue.
I can bring this up with the SMMU architect - thank you for taking time to describe the use cases and SW you are deploying.
If so, software can be simpler. Any suggestions?
Talking to SMMU architects - there is not much SW can do other than what you are doing already.
Thanks Lorenzo for still tracking this, very appreciated.
Thanks
linaro-open-discussions@op-lists.linaro.org
-
James Morse -
Jonathan Cameron -
Jonathan Cameron
-
Joyce Qi -
Lorenzo Pieralisi -
Russell King (Oracle) -
Salil Mehta -
Zhangfei Gao