Re: [Qemu-devel] [PATCH] WHPX fixes an issue with CPUID 1 not returning CPUID_EXT_HYPERVISOR

[Justin Terry (VM)]

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 <address@hidden>
> Sent: Monday, April 16, 2018 9:33 AM
> To: Paolo Bonzini <address@hidden>
> Cc: Justin Terry (VM) <address@hidden>; address@hidden;
> address@hidden
> 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