On 12/17/20 11:53 PM, Eduardo Habkost wrote: > On Thu, Dec 17, 2020 at 11:33:57PM +0100, Claudio Fontana wrote: >> Hello all, >> >> On 12/17/20 7:46 PM, Eduardo Habkost wrote: >>> From: Vitaly Kuznetsov <vkuzn...@redhat.com> >>> >>> As a preparation to expanding Hyper-V CPU features early, move >>> hyperv_vendor_id initialization to x86_cpu_realizefn(). Introduce >>> x86_cpu_hyperv_realize() to not not pollute x86_cpu_realizefn() >>> itself. >> >> this seems to fit very well the ongoing work on separating accelerator >> specific realize functions; >> >> related to the previous discussions about the class hierarchies, >> do you think that we should have a separate class in target/i386/kvm/ for a >> hyperv variant of the kvm-cpu.c? >> >> Should it be a separate class or a subclass of "kvm-accel-x86_64-cpu" ? > > I don't see how a separate QOM class for Hyper-V would be helpful > here. What would be the problem you are trying to solve in this > case?
there is now a call to accelerator specific code x86_hyperv_cpu_realize just before cpu_exec_realize, tying the generic target/i386/cpu.c code to kvm/hyperv-specific accel initialization. if this is just a feature of the kvm accel, maybe I should just move all to kvm-cpu.c and that's it. Thanks, Claudio > > Note that the Hyper-V features here are just a set of > configurable VCPU features that appear on CPUID. This is not a > different kind of hypervisor and/or a different kind of > accelerator. >
