Hi Joyce,
I will join the call for NUMA topology too
Regards, Vincent
On Fri, 22 Apr 2022 at 16:27, Joyce Qi joyce.qi@linaro.org wrote:
Hi Jonathan，Lorenzo，
Thanks for the topics and update, I will update to the LOD Agenda.
@Vincent, Mike,
Can you help to loop more people who may have interests in the vCPUHP and Scheduler Tunable from NUMA topology topics?
Thanks:) Joyce
在 2022年4月22日，下午9:00，Jonathan Cameron Jonathan.Cameron@Huawei.com 写道：
On Fri, 22 Apr 2022 11:33:29 +0100 Lorenzo Pieralisi lorenzo.pieralisi@arm.com wrote:
On Fri, Apr 22, 2022 at 10:36:43AM +0100, Jonathan Cameron wrote:
On Thu, 21 Apr 2022 21:32:01 +0800 Joyce Qi via Linaro-open-discussions linaro-open-discussions@op-lists.linaro.org wrote:
Hi Jonathon锟斤拷Lorenzo锟斤拷
Do we have some topic to discuss for the Linaro-open-disscussions next week?
Thanks:) Joyce
Hi Joyce,
Thanks for the reminder. So topics:
RMR: Nothing from our side
vCPUHP: we have a 'working' QEMU tree though it has some known problems (doesn't work with SVE for some reason - so some debugging to do). Should be able to upload that shortly for anyone else who wants to play with it. Any updates on progress of kernel patches from ARM side would be good but email is fine for that.
Could not work on them, I need to figure out a plan and quickly, we can talk about that though, I should be able to have a clearer picture by Tuesday.
I am still using your SPDM stack and there are a couple of things I don't get (eg CHALLENGE_AUTH signature verification, RSA path, spdm_asym_rsassa_3072 path in spdm_verify_signature() - just wanted to ask if you tested this path, I am struggling with signature verification - just wanted to ask in particular about the need for ASN.1 encoding to use verify_signature()).
Ah. Been a while, but IIRC correctly the spec doesn't make it clear when signatures should be ASN.1. My basis for choosing combinations in that code were what libSPDM did at the time. I remember a bunch of trial and error and also hand decoding binary to try to figure out what the encodings were. I also enjoyed those places where various different ASN.1 encoded structures were concatenated rather that encoded in one go - hence no cheap way to index to the next one.
I'm reviewing a nice short 972 page spec draft this week (which will remain unnamed :) but if I get time I'll see if I can test that path before Tuesday.
I think I ran basic tests on all the protocol types, but it was a long time ago so possible I missed one.
I meant to seek a spec clarification but haven't gotten around to it yet. Request from DMTF people was to file tickets against he spec for stuff like that.
Jonathan
Thanks, Lorenzo
New Potential topic.
Scheduler Tuneables from NUMA topology.
This is yangyicong's topic but I'll attempt to summarize:
https://lore.kernel.org/lkml/ef3b3e55-8be9-595f-6d54-886d13a7e2fd@hisilicon....
The scheduler contains a bunch of tunables including this one which is "migration cost" This value is used to make decisions in load balancing + to control the frequency of load balancing to avoid doing it too often. The default value has been fixed for a long time and systems have changed a lot in that time.
Currently the value is tunable via debugfs, but in the above thread the proposal to somehow base the value on the system topology was made.
We haven't yet proceeded very far with this but if we can get appropriate people for the call it may be a good opportunity to do some brainstorming, particularly as we don't have ready access to that many machine topologies so testing any proposal will be very challenging. Also I fear this space is only going to get more complex as systems get larger over the next year or two.
Next week may be too soon for such a discussion though given the short notice!
+CC Vincent and Dietmar, but please drag anyone else in who is relevant to this discussion.
I might also mention this topic at the LDCG meeting this week to see if we can interest from others who might be able to help with data + testing.
Thanks,
Jonathan
锟斤拷 2022锟斤拷4锟斤拷14锟秸ｏ拷锟斤拷锟斤拷8:00锟斤拷linaro-open-discussions-request@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: LOD Call notes: 22 March 2022 - vCPU Hotplug Update (Jonathan Cameron)
Message: 1 Date: Wed, 13 Apr 2022 19:17:32 +0100 From: Jonathan Cameron Jonathan.Cameron@Huawei.com Subject: [Linaro-open-discussions] Re: LOD Call notes: 22 March 2022 - vCPU Hotplug Update To: Ilkka Koskinen ilkka@os.amperecomputing.com Cc: linaro-open-discussions@op-lists.linaro.org Message-ID: 20220413191732.00000e4e@Huawei.com Content-Type: text/plain; charset="US-ASCII"
On Thu, 31 Mar 2022 11:47:26 -0700 (PDT) Ilkka Koskinen ilkka@os.amperecomputing.com wrote:
> Hi everyone, > > On Tue, 22 Mar 2022, Jonathan Cameron via Linaro-open-discussions wrote: >> Hi All, >> >> A quick set of notes on the discussion on vCPU hotplug. >> >> Great to have Ed join the discussion. If we are going to >> have further calls on this topic we may want to move the time to be >> more friendly for the US. >> >> Current status >> * ACPI spec change via code first route approved. >> * Kernel patches being reworked / rebased by ARM. Expected to be sent >> out in 5.19 cycle. >> * QEMU patches being updated by Huawei. Will do at least some light testing >> and then push out a public git tree so that others can test - will aim >> to do this so it aligns with kernel code availability. >> * Ed (Ampere) gave an update to say they are interested in pushing this >> forwards ASAP and have customer / OS vendor engagement which will be >> very useful in moving towards a complete solution, particularly ensuring >> good test coverage etc. >> >> Noted that current QEMU patches may not cover all corner cases, for example >> live migration of VMs that have vCPUs hotplugged. Might 'just work' >> but we haven't tested it yet so probably not. >> >> Given we didn't really add anything on DOE / SPDM over previous calls, >> I don't plan to send out anything on that topic this time. >> >> Thanks to Joyce for hosting the call. If I noted down anything wrong, >> or incomplete let the list know. >> >> Jonathan >> -- >> Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org >> https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > > Thanks for the great meeting and the update! As Ed mentioned (and you > wrote above), we're interested in joining the vCPU Hotplug development.
Hi Ilkka
Great to have you on board for this.
Status wise, on QEMU side we have the new interface up and running (it was a whole 2 lines of code once we'd dealt with some rebasing related issues).
Rather more changes were needed to make it work sensibly on top of Gavin Shan's QEMU topology configuration patch set. https://lore.kernel.org/qemu-devel/20220403145953.10522-1-gshan@redhat.com/ The code going through some light internal review before we put it up somewhere public. Note it's definitely not production quality code but it is somewhere to start from. Given Easter related vacations I doubt we'll get enough eyes on it until next week.
We were thrown briefly by the fact there is a recently added apcica/actbl2.h entry for MADT_ONLINE_CAPABLE but it's a different bit. Seems x86 folk wanted something similar last year. We'll have to do something ugly in ACPICA to mangle the name for the new bit to avoid that collision. Lorenzo, I'm assuming the ACPCIA one line patch to add that define is something the ARM team will deal with?
There are some known limitations though that we'll need to sort out before upstreaming the QEMU support. One of which is SVE currently breaks things. Plenty of time though as kernel needs to be upstream first anyway.
Testing wise we are using QEMU on top of QEMU so we can poke corners of the architecture don't have hardware for (e.g. SVE :). Even on a rubbish x86 desktop it's not that slow :)
Lorenzo, any update on kernel side of things or expected time scale for more information?
Obviously we have some hacked patches based on Salil's original proposal that sanity check the QEMU side of things but I suspect the final version will look rather different :)
One question on the spec change for Lorenzo. It's not entirely clear but I think we should not be using _MAT when 'hotplugging' the vCPUs? For now the QEMU code provides the relevant entries anyway but it would be nice to drop that if not necessary (it's not a huge amount of code or complexity though so not a big thing either way).
Thanks and an early happy Easter to those celebrating on Sunday.
Jonathan
> > Br, Ilkka
Subject: Digest Footer
Linaro-open-discussions mailing list -- linaro-open-discussions@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 19, Issue 1