Hey Eduardo/Paolo, I have not forgotten about your responses. I am working out how best to do this in our platform and will send a follow up patch (this one is already merged) to fully support the -cpu flag. It looks like all the pieces are in place between the two and we just need a bit of translation between the QEMU state at partition creation/start/execution to handle the various exits either by pre-setting the value or via the actual CPUID trap at runtime. Thank you for all your insights/input up to here. It has been really helpful. More to come.
Thanks, Justin > -----Original Message----- > From: Eduardo Habkost <ehabk...@redhat.com> > Sent: Monday, April 16, 2018 9:33 AM > To: Paolo Bonzini <pbonz...@redhat.com> > Cc: Justin Terry (VM) <jute...@microsoft.com>; qemu-devel@nongnu.org; > r...@twiddle.net > Subject: Re: [PATCH] WHPX fixes an issue with CPUID 1 not returning > CPUID_EXT_HYPERVISOR > > On Thu, Apr 05, 2018 at 05:50:20PM +0200, Paolo Bonzini wrote: > > On 28/03/2018 22:48, Justin Terry (VM) wrote: > [...] > > > If we use [2] to inject the answers at creation time WHPX needs > > > access to the CPUX86State at accel init which also doesn't seem to > > > be possible in QEMU today. WHPX could basically just call > > > cpu_x86_cpuid() for each CPUID QEMU cares about and plumb the > answer > > > before start. This has the best performance as we avoid the > > > additional exits but has an issue in that the results must be known ahead > of time. > > > > The earliest where you have access to that is x86_cpu_initfn. > > x86_cpu_initfn() is the earliest you have access to the CPU object, but note > that the final CPUID bits (based on -cpu options, accel data, and possibly > other input) are known only when x86_cpu_realizefn() is called. > > -- > Eduardo