Re: [PATCH 1/2] i386/xen: Move KVM_XEN_HVM_CONFIG ioctl to kvm_xen_init_vcpu()
On Fri, 2025-02-07 at 14:37 +, David Woodhouse wrote: > From: David Woodhouse > > At the time kvm_xen_init() is called, hyperv_enabled() doesn't yet work, so > the correct MSR index to use for the hypercall page isn't known. > > Rather than setting it to the default and then shifting it later for the > Hyper-V case with a confusing second call to kvm_init_xen(), just do it > once in kvm_xen_init_vcpu(). > > Signed-off-by: David Woodhouse Ping? smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 1/2] i386/xen: Move KVM_XEN_HVM_CONFIG ioctl to kvm_xen_init_vcpu()
On 7 February 2025 15:37:40 GMT, Sean Christopherson wrote: >On Fri, Feb 07, 2025, David Woodhouse wrote: >> From: David Woodhouse >> >> At the time kvm_xen_init() is called, hyperv_enabled() doesn't yet work, so >> the correct MSR index to use for the hypercall page isn't known. >> >> Rather than setting it to the default and then shifting it later for the >> Hyper-V case with a confusing second call to kvm_init_xen(), just do it >> once in kvm_xen_init_vcpu(). > >Is it possible the funky double-init is deliberate, to ensure that Xen is >configured in KVM during VM setup? I looked through KVM and didn't see any >obvious dependencies, but that doesn't mean a whole lot. I am fairly sure there are no such dependencies. It was just this way because shifting the MSR to accommodate Hyper-V (and making kvm_xen_init() idempotent in order to do so) was an afterthought. In retrospect, I should have done it this way from the start. It's cleaner. And you don't require as much caffeine to understand it :)
Re: [PATCH 1/2] i386/xen: Move KVM_XEN_HVM_CONFIG ioctl to kvm_xen_init_vcpu()
On Fri, Feb 07, 2025, David Woodhouse wrote: > From: David Woodhouse > > At the time kvm_xen_init() is called, hyperv_enabled() doesn't yet work, so > the correct MSR index to use for the hypercall page isn't known. > > Rather than setting it to the default and then shifting it later for the > Hyper-V case with a confusing second call to kvm_init_xen(), just do it > once in kvm_xen_init_vcpu(). Is it possible the funky double-init is deliberate, to ensure that Xen is configured in KVM during VM setup? I looked through KVM and didn't see any obvious dependencies, but that doesn't mean a whole lot.
