Re: [PATCH v2 2/2] HV: Reset physical core of lapic_pt vm when shutdown


Chen, Jason CJ
 

On Thu, Apr 11, 2019 at 06:11:58AM +0000, Grandhi, Sainath wrote:


-----Original Message-----
From: acrn-dev@... [mailto:acrn-dev@...]
On Behalf Of Chen, Jason CJ
Sent: Wednesday, April 10, 2019 10:12 PM
To: acrn-dev@...
Cc: Dong, Eddie <eddie.dong@...>
Subject: Re: [acrn-dev] [PATCH v2 2/2] HV: Reset physical core of lapic_pt vm
when shutdown

On Thu, Apr 11, 2019 at 05:05:39AM +0000, Kaige Fu wrote:

-----Original Message-----
From: Dong, Eddie
Sent: Thursday, April 11, 2019 11:35 AM
To: Fu, Kaige <kaige.fu@...>; acrn-dev@...
Cc: Dong, Eddie <eddie.dong@...>
Subject: RE: [acrn-dev] [PATCH v2 2/2] HV: Reset physical core of
lapic_pt vm when shutdown


For INIT signal, it will unblocked when turn VMX off:
Intel SDM Vol3 Chapter 33.2:
INIT assertions are always blocked in VMX root operation and
while in SMM, and unblocked otherwise.

Intel SDM Vol3 Chapter 30.3:
Takes the logical processor out of VMX operation, unblocks
INIT signals, conditionally re-enables A20M, and clears any
address-range monitoring
This is good to prove the blocked signal will be accepted after VMX OFF.

But, I have another question: Since the SOS VM/PCPU will send INIT
and SIPI, will the latterly sent SIPI signal overwrite INIT signal?
I.e. can the target CPU buffer the blocked INIT, and SIPI signal? I doubt...
I tried to find some statement about it but failed.

BTW, It is still better to send INIT/SIPI till VMX OFF is really
done in target PCPU side. Let us think of easy way to do so... For
example, can we do cpu_dead
Sure. May be we I do per Sainath's suggestion: Offline pcpu when pause_vm
and start it in shutdown_vm.
Kaige,
In the approach I suggested earlier, we cannot guarantee cpu_dead is called on
remote cpu, by the time shutdown_vm is called from SOS DM.
We get more time than your current approach, but no guarantee.
Can we use some of bitmap in memory to know whether cpu_dead is done on remote cpu?
why we cannot do all the thing in shutdown_vm? Like, if it's a lapit_pt cpu, then
we make it offline(cpu_dead) & start_cpu , we can even wrap a reset_cpu
function for it.
shutdown_vm is executing on SOS CPU and offline needs to be done on remote cpu before we send startup IPIs.
yes, here we should use a sync method for reset_cpu called from shutdown_vm:
1. make offline request to target cpu
I have a talk with Kaige about this, there is a concern about if cpu is idle in "hlt", then we may not be able to
wake up target cpu when it's in vmx_on state; but currently, we are using "pause" for idle, and in the future, we
suppose to use mwait. So it seemed no problem for me.
2. wait target cpu offline
3. start_cpu by sending INIT-SIPI



For SIPI signal, it says the SIPI will be blocked in VMX root
operation but doesn't say when to unblock it. From my test, it
will be unblocked after VMX off.
Intel SDM Vol3 Chapter 33.2:
SIPI events are always blocked in VMX root operation.

BTW, I see the following statement in SDM Vol3 Chapter 25.2:
Start-up IPIs (SIPIs). SIPIs cause VM exits. If a logical
processor is not in the wait-for-SIPI activity state when a SIPI
arrives, no VM exit occurs and the SIPI is discarded.

IMHO, if saying "block SIPI", it means the SIPI signal will be
unblocked. If saying "SIPI is discarded", it means the SIPI signal
will be
ignored.

What's your opinion here? Should we add some code the wait pcpu
offline or keep it as it is?



--

Thanks

Jason



--

Thanks

Jason

Join acrn-dev@lists.projectacrn.org to automatically receive all group messages.