Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 22/01/20 06:47, Sean Christopherson wrote: >>> Yes, it most likely is and it would be nice if Microsoft fixed it, but I >>> guess we're stuck with it for existing Windows versions. Well, for one >>> we found a bug in Hyper-V and not the converse. :) >>> >>> There is a problem with this approach, in that we're stuck with it >>> forever due to live migration. But I guess if in the future eVMCS v2 >>> adds an apic_address field we can limit the hack to eVMCS v1. Another >>> possibility is to use the quirks mechanism but it's overkill for now. >>> >>> Unless there are objections, I plan to apply these patches. >> Doesn't applying this patch contradict your earlier opinion? This patch >> would still hide the affected controls from the guest because the host >> controls enlightened_vmcs_enabled. > > It does. Unfortunately the key sentence is "we're stuck with it for > existing Windows versions". :( > >> Rather than update vmx->nested.msrs or filter vmx_get_msr(), what about >> manually adding eVMCS consistency checks on the disallowed bits and handle >> SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES as a one-off case by simply >> clearing it from the eVMCS? Or alternatively, squashing all the disallowed >> bits. > > Hmm, that is also a possibility. It's a very hacky one, but I guess > adding APIC virtualization to eVMCS would require bumping the version to > 2. Vitaly, what do you think? As I already replied to Sean I like the idea to filter out unsupported controls from eVMCS but unfortunately it doesn't work: Hyper-V actually expects APIC virtualization to work when it enables SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES (I have no idea how without apic_access_addr field but). I checked and at least Hyper-V 2016 doesn't boot (when >1 vCPU). -- Vitaly
