The platform might end up with multiple microcode versions with the patch, which is not what we want. Should we support microcode update in embedded HV/SOS? is run time microcode update needed in

Hi Like: I felt we have so many error check code now, and it becomes a little over-complicated. May be we can do: 1) Add dump_context in ASSERT. But no need to introduce another one (CHECK) 2) We

SOS will have all CPUS at boot time, so this is not a problem. Enabling uCode update is good to me. BIOS update could be, but OS update is also useful. The only issue to me is that why we cannot rely

Then we probably want to wait until SOS have all CPUs. Anthony

BTW, we are generating a VM environment, with no assumption of what SOS it may be. For native usage, Intel CPU provides the capability for OSes to update uCode, we are going to support too. Thx

Make sence..

Per below spec, microcode update in VMX non-root operation does nothing. Anthony * WRMSR. Section 25.1.3 identifies when executions of the WRMSR instruction cause VM exits. If such an execution

OK, that explains... It is an VMX limitation... Thanks! Eddie

in the future please include your TODO plan in the commit msg so reviewers can save effort on commenting those... Thanks Kevin

yes please. why did you take it for sure? hypervisor doesn't control linear mapping inside SOS. there could be software bugs or other issues resulting an invalid mapping. When we give some permission

Hi Eddie, Current ASSERT dumps both host and guest context already. Yes, the purpose of the patches is to do the ASSERT cleanup. CHECK is not a MUST, just added to replace some ASSERT, which is not

I'm not sure whether new MACROs are really required. the readability is worse than explicitly checking error and return in caller place. Looks the main addition is to dump guest context upon those

Hi Kevin, -------------------8<----------------------------------- OK. Will add comments. OK. I will add the return value check for gva2gpa and GPA2HVA. Here we have: hva = GPA2HVA(gva2gpa(v))

Hi Anthony, Thanks a lot for the information. Regards Yin, Fengwei

What about we do uCode update for all pCPUs when SOS is trying ot update uCode? SOS kernel could trigger uCode update after the pCPUs is assigned to UOS. At that situation, SOS can't request to

Sure. Regards Yin, Fengwei

OK. Will hold the patch till the SOS could own all CPUs. Thanks. Regards Yin, Fengwei

I think we want to let SOS own all the PCPU at boot time, and then offline the cores not necessary... Thx Eddie

There is one case of uCode update which is triggered by writing 1 to /sys/devices/system/cpu/microcode/reload. In this case, uCode update could be triggered after SOS offline the cores which is used

This is fine. The SOS knows the cores are offlined already, so the user should not trigger update at that point.