- Linaro-open-discussions - op-lists.linaro.org

Invitation: Linaro Open Discussions monthly meeting @ Wed 5 Oct 2022 19:00 - 20:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)

by joyce.qi＠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… 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(a)op-lists.linaro.org james.morse(a)arm.com jonathan.cameron(a)huawei.com lorenzo.pieralisi(a)linaro.org ilkka(a)os.amperecomputing.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiMWxv… Reply for linaro-open-discussions(a)op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiMWxv… 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

3 years, 1 month

6
13
0 0

Re: Linaro-open-discussions Digest, Vol 25, Issue 9

by Joyce Qi

Hi Lorenzo, I have noticed you are in holiday on Nov,1st. I can switch the meeting to Nov 2nd if other people are free. @Lorenzo,James, Can we arrange Zhangfei’s questions( TLB missing impact the performance in vsva/ sva) as below in next meeting. Or can you help involve any other experts focus on this? Appreciated so much for your help here. Thanks:) Joyce 在 2022年10月28日，上午8:00，linaro-open-discussions-request@op-lists.linaro.o rg 写道： 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: Linaro-open-discussions Digest, Vol 25, Issue 3 (Zhangfei Gao) -------------------------------------------------------------------- -- Message: 1 Date: Thu, 27 Oct 2022 12:06:59 +0800 From: Zhangfei Gao <zhangfei.gao(a)linaro.org> Subject: [Linaro-open-discussions] Re: Linaro-open-discussions Digest, Vol 25, Issue 3 To: Joyce Qi <joyce.qi(a)linaro.org>, Lorenzo Pieralisi <lorenzo.pieralisi(a)linaro.org>, jean-philippe <jean-philippe(a)linaro.org> Cc: linaro-open-discussions(a)op-lists.linaro.org, linux(a)armlinux.org.uk Message-ID: <2fba7536-1475-4755-9084-a920addecc42(a)linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed 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 ------------------------------ 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 25, Issue 9 ******************************************************

3 years, 1 month

1
0
0 0

Re: Linaro-open-discussions Digest, Vol 25, Issue 9

by Joyce Qi

Hi Lorenzo, I have noticed you are in holiday on Nov,1st. I can switch the meeting to Nov 2nd if other people are free. @Lorenzo,James, Can we arrange Zhangfei’s questions( TLB missing impact the performance in vsva/ sva) as below in next meeting. Or can you help involve any other experts focus on this? Appreciated so much for your help here. Thanks:) Joyce > 在 2022年10月28日，上午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: Linaro-open-discussions Digest, Vol 25, Issue 3 (Zhangfei Gao) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 27 Oct 2022 12:06:59 +0800 > From: Zhangfei Gao <zhangfei.gao(a)linaro.org> > Subject: [Linaro-open-discussions] Re: Linaro-open-discussions Digest, > Vol 25, Issue 3 > To: Joyce Qi <joyce.qi(a)linaro.org>, Lorenzo Pieralisi > <lorenzo.pieralisi(a)linaro.org>, jean-philippe > <jean-philippe(a)linaro.org> > Cc: linaro-open-discussions(a)op-lists.linaro.org, linux(a)armlinux.org.uk > Message-ID: <2fba7536-1475-4755-9084-a920addecc42(a)linaro.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 >> >> >> > > > ------------------------------ > > 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 25, Issue 9 > ******************************************************

3 years, 1 month

1
0
0 0

Invitation: Linaro Open Discussions monthly meeting @ Tue 1 Nov 2022 22:00 - 23:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)

by joyce.qi＠linaro.org

Linaro Open Discussions monthly meeting Tuesday 1 Nov 2022 ⋅ 22:00 – 23: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… 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(a)op-lists.linaro.org james.morse(a)arm.com salil.mehta(a)huawei.com Zhangfei Gao linux(a)armlinux.org.uk ilkka(a)os.amperecomputing.com lorenzo.pieralisi(a)linaro.org jonathan.cameron(a)huawei.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiMWxv… Reply for linaro-open-discussions(a)op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiMWxv… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on 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 organizer, 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

3 years, 1 month

1
0
0 0

Linaro OP-TEE Contribution (LOC) monthly meeting October

by Jens Wiklander

Hi, OP-TEE Contributions (LOC) monthly meeting is planned for Tuesday, Oct 25 at 10.00 (UTC). Note, new time! If you have any topics you'd like to discuss, please let us know and we can schedule them. Meeting details: Date/time: October 25 at 10.00 (UTC) Meeting notes: http://bit.ly/loc-notes Project page: https://www.linaro.org/projects/#LOC Connection details =============== Join Zoom: https://linaro-org.zoom.us/j/93697277554?pwd=MGdFRU4xZjdDS2VSMzVMbGZIdnkwZz… Thanks, Jens on behalf of the Linaro OP-TEE team

3 years, 1 month

1
0
0 0

Linaro OP-TEE Contributions (LOC) monthly meeting

by Jens Wiklander

Hi, We don't have any topics for the meeting today, so let's cancel it. The time slot we've allocated for this meeting is either bad or worse for me so I'd like to try and find a new time slot. Please use the doodle link [1] below to record your preferences. The doodle poll is public so feel free to email me directly instead in case you're more comfortable with that. This is my first time creating a doodle poll, so apologies if I've made a mess of it. As noted in the poll we're looking for a day and time in the fourth week of the month. We're using the CET time zone as many of us are in the time zone. If you can't find any time that works for you please send me a mail with more suitable times and I'll try to work out something. Let's give this a week or so to possibly settle on a new time slot. [1] https://doodle.com/meeting/participate/id/dJqR4Eyb Thanks, Jens

3 years, 2 months

1
2
0 0

Re: Linaro-open-discussions Digest, Vol 24, Issue 4

by Joyce Qi

Hi Jonathan,Lorenzo,all, Do we have any topic to sync next week? Thanks:) Joyce > 在 2022年9月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: [RFC PATCH v0.1 22/25] ACPI: add support to register CPUs based on the _STA enabled bit > (Salil Mehta) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 12 Sep 2022 18:09:34 +0000 > From: Salil Mehta <salil.mehta(a)huawei.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" > <linaro-open-discussions(a)op-lists.linaro.org> > Cc: "lorenzo.pieralisi(a)linaro.org" <lorenzo.pieralisi(a)linaro.org> > Message-ID: <65c52e8ba75e4cc59ec4b88a44c8a13b(a)huawei.com> > Content-Type: text/plain; charset="utf-8" > > Hi James > >> From: James Morse [mailto:james.morse@arm.com] >> Sent: Friday, September 9, 2022 5:53 PM >> To: Salil Mehta <salil.mehta(a)huawei.com>; >> linaro-open-discussions(a)op-lists.linaro.org >> Cc: lorenzo.pieralisi(a)linaro.org; Jean-Philippe Brucker >> <jean-philippe(a)linaro.org>; Jonathan Cameron <jonathan.cameron(a)huawei.com> >> Subject: Re: [RFC PATCH v0.1 22/25] ACPI: add support to register CPUs based >> on the _STA enabled bit >> >> Hi Salil, >> >> On 09/09/2022 15:53, Salil Mehta wrote: >>>> From: James Morse [mailto:james.morse@arm.com] >>>> Sent: Wednesday, August 31, 2022 12:09 PM >>>> To: linaro-open-discussions(a)op-lists.linaro.org >>>> Cc: Salil Mehta <salil.mehta(a)huawei.com>; james.morse(a)arm.com; >>>> lorenzo.pieralisi(a)linaro.org; Jean-Philippe Brucker >>>> <jean-philippe(a)linaro.org> >>>> Subject: [RFC PATCH v0.1 22/25] ACPI: add support to register CPUs based on >> the >>>> _STA enabled bit >>>> >>>> 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. >> >>>> 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; >>>> + } >> >>> This change and setting all possible cpus as *present* in smp_prepare_cpus() >>> will always cause all present == possible in the guest kernel. >> >> This is quite deliberate. I don't want to redefine present without a machine >> that actually >> supports hotplug/package-hotadd. This stuff is the tip of an ill-defined iceberg >> in the >> ACPI spec. Once there is hardware that supports this, we will have a better idea >> of what >> needs changing. Until then: everything described by ACPI must be present. > > > Present mask operates on the logical cpuids. Later are more closely related to > the Linux abstract model. I see no problem in masking certain available devices(in > this case cpus) from upper user. This is done at many places inside the kernel to > intentionally not/conditionally expose certain devices to user even after getting > discovered at the boot time or later. > > As such, this change can co-exists irrespective of whether Hotplug or Hotadd will > ever exist in the system. > > I agree with the ACPI part and maybe interface is broken but then you have used > ACPI_STA_DEVICE_ENABLED which has not been used yet in acpi_processor.c code > which is ACPI related. How can you make sure this bit is being set by firmware > of other architectures, especially legacy? > > >>> I think we >>> can avoid that by the trick which Jean-Phillipe exploited in his patch-set[1] >>> sent earlier last year. >> >> That was the other side of this: >> https://gitlab.arm.com/linux-arm/linux-jm/-/commit/3106cccf5b9f01f44789b748 >> aaee3a95fee99a97 >> >> This was an attempt to do all this without changes to the ACPI spec - it doesn't >> touch the >> present cpumask. > > > Yes, I did refer those but the idea was not to use that change as it is. > > >> [..] >> >>> This shall ensure that we correctly reflect only present vcpus to the linux >>> kernel although the sizing and initialization of the GICC/GICR would have >>> already happened for the complete set for possible vcpus i.e. the ones with >>> >>> [1] _STA[0] is set & _STA[1] bit is set and >>> [2] Either GICC_flag_Intf_Flag.Enabled set OR GICC_flag.online_capable set >>> >>> so effectively we are only deferring populating the cpu present mask for the >>> disabled cpus but which are now online capable(or Hotplug capable in future?) >> >> What is the user observable effect of the kernel knowing this CPUs are really >> present? > > User Interface looks inconsistent and can break existing scripts. > > As you can see, user requested max possible cpus(=6) and cold booted cpus(=4) > Hence, the number of cpus directories correctly being shown are 4 but then > total number of cpus present are being shown as 6 (i.e. 0-5). > > If we can defer the registration of the disabled cpus (but are online capable > i.e. for possible - present) then I don’t see why we can't mask availability > of these cpus by not marking them as present to user so that the entries > are consistent. With this scripts/utils using these values can go horribly > wrong. > > At Guest Kernel > --------------- > estuary:/$ ls -al /sys/devices/system/cpu/ > total 0 > drwxr-xr-x 12 root 0 0 Sep 9 19:19 . > drwxr-xr-x 8 root 0 0 Sep 9 19:19 .. > drwxr-xr-x 7 root 0 0 Sep 9 19:19 cpu0 > drwxr-xr-x 7 root 0 0 Sep 9 19:19 cpu1 > drwxr-xr-x 7 root 0 0 Sep 9 19:19 cpu2 > drwxr-xr-x 7 root 0 0 Sep 9 19:19 cpu3 > drwxr-xr-x 2 root 0 0 Sep 9 19:19 cpufreq > drwxr-xr-x 2 root 0 0 Sep 9 19:19 cpuidle > [...] > > estuary:/$ cat /sys/devices/system/cpu/possible > 0-5 > estuary:/$ cat /sys/devices/system/cpu/present > 0-5 > estuary:/$ cat /sys/devices/system/cpu/offline > 4-5 > estuary:/$ > > At Qemu > ------- > $QEMUBIN --enable-kvm -machine virt,gic-version=3 -cpu host -smp cpus=4,maxcpus=6 > -append "console=ttyAMA0 root=/dev/ram earlycon rdinit=/init maxcpus=4 acpi=force" > > >> The intention of this series is to do this as pure policy. >> >> I anticipate pressure on the "use the MADT GICR" line, even though ACPI doesn't >> say >> anything about the presence of MADT GICC's redistributor entry. If this happens, >> we'd >> depend on present meaning present. > > > If we are confident that flag ACPI_STA_DEVICE_ENABLED is being set properly by > ARM and other architecture firmware, then Qemu can take care of that policy. It > has all the information of the vcpus which are possible and disabled (but are > online capable). We can use this info to conditionally return appropriate status > when _STA ACPI method is evaluated. > > I intentionally refrained to use the this approach in my first RFC[1] as the > default code in the acpi_processor.c was only making use of the > ACPI_STA_DEVICE_PRESENT bit after evaluation of _STA method. Qemu was also > setting only present bit in the returned status value. Plus, I wanted to > minimize the changes in the kernel in the first version of the RFC. > > > [1] https://lore.kernel.org/qemu-devel/38a034f82da78b8861af6d25a83fddea@kernel.… > >> >> All the hotplug/package-hotadd machinery is triggered by udev. We don't need >> to hack the >> cpu present mask to make that work. > > > May I know what exactly are your apprehensions with 'udev'? > > As such 'udev' should make use of the Linux device model and it is not necessary > to present 1:1 picture of the hardware to the abstract model(and which by the way > we are not doing by not registering the disabled cpus). It will just expose that > limited picture of the hardware to the user whatever is being presented by the > kernel. > > AFAICS it should work just fine but we need to limit the present cpus. > > >>> Question: >>> Q1: Current acpi_processor.c code is not using ACPI_STA_DEVICE_{ENABLED, UI} >>> bits. Could it break other architecture if we use these bits but some of their >>> legacy devices or firmware does not initialize these bits to their defaults? >> >> Almost certainly! I'm pretty confident some vendors generate their ACPI tables >> using >> markov-models. (It boots! Ship it!) >> >> The approach that used the UI bit to mean sysfs had to be hidden behind a Kconfig >> symbol, >> which is only marginally better than #ifdef CONFIG_ARM64. > > > If there are problems in using the ACPI_STA_DEVICE_UI Bit because it might > conflict with the legacy firmware of other architectures then let us drop that. > > We can alternatively use the ACPI_STA_DEVICE_ENABLED Bit in the _STA method > which can be conditionally set by the Qemu? > > >> This new version walks a fine line described in the cover-letter: any platform >> with >> firmware tables that get this wrong should get the same user-experience as there >> is no >> policy enforcement on x86, so the !online_capable CPUs can be detected as being >> online, >> and the policy stuff gets ignored. > > Yes, I do understand your predicament, but ideally user experience is dictated > by what *end* user sees. Here, by not masking the disabled cpus in the cpu present > mask user will not have similar experience on ARM64 and x86_64 platforms and that > is undeniable and will in the end matter the most since this feature will mostly > be used on the servers. > > > Thanks > Salil > > ------------------------------ > > 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 24, Issue 4 > ******************************************************

3 years, 2 months

4
7
0 0

ARM64 virt CPU HP - plan

by Lorenzo Pieralisi

Hi all, in the meeting held today we decided to go ahead as follows in relation to ARM64 virt CPU hotplug patches and QEmu changes: - James requires QEmu changes to test his branch[1] - Huawei (Salil) agreed to upgrade the QEmu patches to the latest ACPI specs (and James' code [1]) - QEmu updates will be given with a branch/link in reply to this email thread so that James can complete [1] testing against them - Any testing, bug report, communication will take place through this mailing list before public posting on a kernel ML, so please keep an eye on this thread if you'd like to collaborate/help - It would be good to get some feedback from containers/kubernetes developers on the full software stack - after all we are making these changes to enable the ecosystem Please chime in if I forgot something or reach out, all comments are welcome. Lorenzo [1] https://gitlab.arm.com/linux-arm/linux-jm/-/tree/virtual_cpu_hotplug/rfc/v0

3 years, 3 months