From: Yin Fengwei <fengwei.yin@...> microcode update from UOS is disabled. microcode version checking is available for both SOS and UOS. Signed-off-by: Yin Fengwei <fengwei.yin@...> --- Ma

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

Tried bypass the uCode update for VM0. But it doesn't work. Regards Yin, Fengwei

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

Yes. We are using identical mapping for VM0. But Linux kernel uses vmalloc to allocate memory to load uCode itself. But I did try changing vmalloc to kmalloc in kernel. The uCode update still failed.

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..

Yes. According to Documentation/x86/x86_64/mm.txt, the 64bit is available. Let me check why the code could work and get you guys back later. Regards Yin, Fengwei

We expose the uCode version to SOS and SOS kernel does the check before issue update the uCode. Regards Yin, Fengwei

OK

Here is what I got: bit63 of the line address is actually not used for now. With 4-level paging, the PML4 entry is selected using: bits 51:12 from CR3 bits 11:3 are from bits 47:39 of liner address. b

Thanks for confirmation. sorry I forgot there is canonical definition of available linear address bits. above info explains why kernel va can be 0xffffffffxxxxxxxx and yes anyway we don't need clear b

Yes. Working on new patch version. Regards Yin, Fengwei

From: Yin Fengwei <fengwei.yin@...> microcode update from UOS is disabled. microcode version checking is available for both SOS and UOS. Signed-off-by: Yin Fengwei <fengwei.yin@...> --- Ch

there is a problem with current implementation. microcode needs being updated on all CPU cores, however SOS only sees partial. If there is no plan to introduce a hypercall, we need hook on the 1st MSR

Yes. It's on my TODO list. Because we only allow SOS to update uCode, only pCPU running SOS get uCode updated. We try not to change kernel source. So I prefer IPI approach( cpu offline depends on the

From: "Yan, Like" <like.yan@...> - CHECK macro checks the given condition, if false, print a fatal message, dump both host and guest context and return void; - CHECK_RET macro checks the given c

From: "Yan, Like" <like.yan@...> Replace ASSERT which should not pause hypervisor with CHECK or CHECK_RET in hypercall and vmexit handling. Change-Id: If80b6be0abb808365e0208557a2682e67d245277 S

Yes. It's in Table 9-7 of SDM vol 3. Should I add comments for 2000? For uCode case, there is valid mapping for sure. The uCode itself is loaded by kernel to memory allocated with vmalloc. When the uC

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