vcpu_on()

[Hong-Seok Kim]

Just one random thought. What if we turn on all vCPUs when their VMs are loaded? vCPUs are making progress only when they are assigned to physical CPUs. So, conceptually, isn't it safe to assume that all vCPUs are on immediately when VMs are loaded except they will begin making progress when some physical CPUs begin executing them?

[Andrew Scull]

Primarily, we have made the choice to use an existing model and the standard PSCI interface.

I'm sure there are alternatives which can be considered safe. If you're suggesting this change, is there a benefit you see from an alternate model?

On Fri, 5 Jul 2019 at 14:53, 'Hong-Seok Kim' via Hafnium <hafnium...@googlegroups.com> wrote:

Just one random thought. What if we turn on all vCPUs when their VMs are loaded? vCPUs are making progress only when they are assigned to physical CPUs. So, conceptually, isn't it safe to assume that all vCPUs are on immediately when VMs are loaded except they will begin making progress when some physical CPUs begin executing them?

--
You received this message because you are subscribed to the Google Groups "Hafnium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hafnium-discu...@googlegroups.com.
To post to this group, send email to hafnium...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/hafnium-discuss/CAHvD%3DH8DiWN1m%3DtP0nSr_a%3DJkW3dLO7Mh-_nTfRz1pfqFsXL5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Walbran]

If we were to turn on all vCPUs for a VM, the VM would need some way of distinguishing them, and to deal with concurrent execution right from the start. We could have done this, but we decided that letting VMs use PSCI to start their other vCPUs was simpler and more architectural. We want VMs to be able to start and stop vCPUs with PSCI anyway, so we may as well be consistent and do the same thing for the initial start.

To view this discussion on the web, visit https://groups.google.com/d/msgid/hafnium-discuss/CADcWuH0tkeJ7SA2Oi7-eC_LnccQjNfPndhasBJ%3DtNg1zU6OycA%40mail.gmail.com.

[Hong-Seok Kim]

Here, I am assuming that vcpu_on() is used only when we're initializing vCPUs. Once a vCPU is on, we don't call vcpu_on() when we context switch the vCPU. Am I correct on this?

If so, isn't it always safe to turn on a vCPU when its VM gets loaded while leaving its real initiation by being schedule to a physical CPU to the rest of mechanism? If we could do it, the logic/process how vPUs get turned on gets simpler.

Am I making sense here?

 

[Andrew Walbran]

vcpu_on(...) does two things: sets the program counter for the vCPU, and sets its state so that Hafnium knows it is ready to run. Once this is done then hf_vcpu_run can run it. So we can't call vcpu_on(...) until the VM is ready for the vCPU to run, and has provided somewhere for it to start executing, which it does with a PSCI call.

To view this discussion on the web, visit https://groups.google.com/d/msgid/hafnium-discuss/CAHvD%3DH8OsevHLn6Ch8-_%2BaKC0ApVUfrAx8wVjSgdFoNPzAPn2A%40mail.gmail.com.

[Hong-Seok Kim]

run. Once this is done then hf_vcpu_run can run it. So we can't call vcpu_on(...) until the VM is ready for the vCPU to run, and has provided somewhere for it to start executing, which it does with a PSCI call.

vcpu_seondary_reset_and_start() is called within load_secondary() for vCPU[0]. So, at least, the VM is ready to run vCPU[0] when its loading gets completed in vpcu_secondary_reset_and_start()'s while loop?

If so, in theory, we can also turn on other vCPUs except we may not want to introduce concurrency at the very beginning of VM initiation. Effectively, we want to let the VM make its own discussion when to initiate concurrency?

[Andrew Walbran]

On Fri, 5 Jul 2019 at 15:20, Hong-Seok Kim <hong...@google.com> wrote:

run. Once this is done then hf_vcpu_run can run it. So we can't call vcpu_on(...) until the VM is ready for the vCPU to run, and has provided somewhere for it to start executing, which it does with a PSCI call.

vcpu_seondary_reset_and_start() is called within load_secondary() for vCPU[0]. So, at least, the VM is ready to run vCPU[0] when its loading gets completed in vpcu_secondary_reset_and_start()'s while loop?

If so, in theory, we can also turn on other vCPUs except we may not want to introduce concurrency at the very beginning of VM initiation. Effectively, we want to let the VM make its own discussion when to initiate concurrency?

Yes. But also, VMs probably don't want to start executing on all vCPUs at the same point in the code. The first vCPU starts at the beginning, but they probably want to start other vCPUs running from different places. They can do this with PSCI.

[Hong-Seok Kim]

So, the contract is that (1) for the primary VM, Hafnuim is reponsible for turning on & executing the first physical CPU and its virtual counterpart and (2) for secondary VMs, Hafnuim is responsible for turning its first virtual CPU and the primary VM to schedule that virtual CPU on some physcial CPU.

Then, how VMs turn on other vCPUs is up to the VMs themselves. 

And, when the primary VM turns on its virtual CPU, the physical CPU also gets turned on - or should we interpret this in a reverse way...

2019년 7월 5일 (금) 오전 7:26, Andrew Walbran <qwa...@google.com>님이 작성: