Can we bypass the uCode update process for VM0? Why we need to intercept? Thx Eddie

That is stranger... We use identical mapping for VM0, right? Anyway, it is ok to leave as it is. BTW, why: It clears bit 63. The rest is fine to me. Thx Eddie

Not sure if clear bit 63 is an architectural requirement or not. + Kevin.

BTW, when upload the uCode, should we check the guest uCode version with physical uCode version before doing real uCode upload? This can save time, and helps the real time behavior..

OK

Acked by <Eddie.dong@...> Leave to Anthony...

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 need

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

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 Eddie

Make sence..

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

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

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

What is the purpose of rename mmu_invept to invalidate_ept? BTW, one the major concept is that: when we remove an mapping or change a mapping (no matter HV host MMU mapping or EPT mapping), we should

OK, if we position it as an temp solution, I am fine. Please prepare a PR.

Acked. Please submit a PR or update it..

Please update the PR then...

This is a kind of current solution, which is dirty. I am not sure if we still need to keep it. Can we remove it? Anyway it won't work smoothly, we prefer to see an obvious Failure rather than a possib

I can merge this patch for now, but this solution is temporary only. We need to find a way following the convention of EFI boot flow/address location etc... Move this to platform specific header files

Please run check patch for style issues.