Hi Salil,
On 31/03/2023 17:42, Salil Mehta wrote:
From: James Morse james.morse@arm.com Sent: Friday, March 31, 2023 4:40 PM To: Salil Mehta salil.mehta@huawei.com; salil.mehta@opnsrc.net Cc: linaro-open-discussions@op-lists.linaro.org; Jonathan Cameron jonathan.cameron@huawei.com; Lorenzo Pieralisi lorenzo.pieralisi@linaro.org Subject: Re: FYI, Regarding the talk at KVM Forum 2023 in June (CFP 2nd April)
For a title I suggest: "Supporting hotplug on architectures that don't".
Sure, that sounds good, just that I would add below as well:
"Challenges Revisited in Supporting Virtual CPU Hotplug on architectures that don't".
I don't think we are revisiting the challenges, we're proposing this as the solution for any architecture with the same problem.
I think we are. Qemu code is 95% same as presented part of RFC V1 and in KVM Forum2020 but this time with a support to a new kernel approach. There are still old design problems lingering which need open discussion and there are some new problems which needs mention. These could not be discussed earlier because Qemu community was not interested to discuss till they hear from ARM about the resolution of the kernel/ARM arch problems mentioned in the earlier presentation. This was the official feedback of the first presentation I gave in KVMForum2020. So I have to continue from there...
Fair enough - I assumed the kernel support was the principle challenge!
Please don’t take Qemu changes for granted. There are already known hard bits in Qemu. It is very important to present them clearly. Forum's like these are very important From Huawei's perspective for the reasons you already know. We don’t have many channels to discuss quickly.
Kernel approach of handling ACPI Hotplug events is new and we are disclosing it to wider public in this forum and asking for their feedback. But then this also opens the door for Qemu discussions.
Adding 'virtual', confuses what the 'that don't' was supposed to be about, but I agree its too terse.
How about "Supporting vCPU hotplug on architectures that don't have CPU hotplug (volume 2)"
I would stick with revisiting as I have to present Qemu updates here and then Jump to what is being done extra from the last presentation to support new kernel Changes. This is very important from Qemu perspective.
Sure, fine by me. I wasn't aware of the Qemu discussions.
[...]
Comparing it to what you've written. I'm not sure the abstract needs any technical details. We can mention the history in the talk, but I don't think its useful to dwell on it.
Agreed, A rough summary might help organizers weigh in terms of relevance when considering whether to accept the talk in case there are many talks submitted. Whole idea is to convince them that this talk is relevant which we think it is. (I was given feedback about the same in the past)
We should put this sort of stuff in the notes section for the reviewers: | This is a follow up to where the problem was first presented at KVM forum, we've now got | a solution we think works for arm64 and probably others. | There are rough edges, so this would benefit from discussion with orchestration | developers.
Sure, we will add few bits there as well. But lets stick with some point wise rough abstract in the mains as that generates the interest of the audiences. It is also important to attract the audiences on the basis of relevance :)
The rough edge being the present mask in /sys. I think the orchestrator folk need to be aware that this adds a new 'enabled' state, and they can't just rely on 'present'. (they don't appear to today)
You will get an answer only if any cloud vendors are present (I hope they are). I think you should raise this in the LKML (and distros related mailing-list first)
I'm pretty sure its mentioned in the cover-letter, but I doubt any user-space developers read that. I think KVM forum is a better way to reach them.
Thanks,
James