On 2022-11-17 16:15, Sean Christopherson wrote:

On Thu, Nov 17, 2022, Mathieu Desnoyers wrote:

quoted

On 2022-11-17 14:10, Sean Christopherson wrote:

quoted

On Thu, Nov 17, 2022, Mathieu Desnoyers wrote:

quoted

On 2022-11-14 15:49, Sean Christopherson wrote:

quoted

On Fri, Nov 11, 2022, Mathieu Desnoyers wrote:

quoted

On 2022-11-10 23:41, Andy Lutomirski wrote:

quoted

On Thu, Nov 3, 2022 at 1:05 PM Mathieu Desnoyers
[off-list ref] wrote:
Also, in my mind "virtual cpu" is vCPU, which this isn't.  Maybe
"compacted cpu" or something?  It's a strange sort of concept.

I've kept the same wording that has been introduced in 2011 by Paul Turner
and used internally at Google since then, although it may be confusing if
people expect kvm-vCPU and rseq-vcpu to mean the same thing. Both really end
up providing the semantic of a virtually assigned cpu id (in opposition to
the logical cpu id on the system), but this is much more involved in the
case of KVM.

I had the same reaction as Andy.  The rseq concepts don't worry me so much as the
existence of "vcpu" in mm_struct/task_struct, e.g. switch_mm_vcpu() when switching
between KVM vCPU tasks is going to be super confusing.  Ditto for mm_vcpu_get()
and mm_vcpu_put() in the few cases where KVM currently does mmget()/mmput().

I'm fine with changing the wording if it helps make things less confusing.

Should we go for "compact-cpu-id" ? "packed-cpu-id" ? Other ideas ?

What about something like "process-local-cpu-id" to capture that the ID has meaning
only within the associated address space / process?

Considering that the shorthand for "memory space" is "VM" in e.g. "CLONE_VM"

No objection from me for "vm", I've already had to untrain myself and remember
that "vm" doesn't always mean "virtual machine" :-)

quoted

clone(2) flags, perhaps "vm-cpu-id", "vm-local-cpu-id" or "per-vm-cpu-id" ?

I have a slight preference for vm-local-cpu-id, but any of 'em work for me.

Taking a step back wrt naming (because if I do a name change across the 
series, I want it to be the last time I do it):

- VM (kvm) vs vm_ (rseq) is confusing.
- vCPU (kvm) vs vcpu (rseq) is confusing.

I propose "Address Space Concurrency ID". This indicates that those IDs 
are really just tags assigned uniquely within an address space for each 
thread running concurrently (and only while they are running).

Then the question that arises is whether the abbreviation presented to 
user-space should be "mm_cid" (as would be expected from an internal 
implementation perspective) or "as_cid" (which would match the name 
exposed to user-space) ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com