Re: [RFC PATCH 03/21] i386/kvm: handle Xen HVM cpuid leaves

[David Woodhouse]

On Mon, 2022-12-05 at 22:58 +0100, Philippe Mathieu-Daudé wrote:
> > 
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 22b681ca37..45aa9e40a5 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -7069,6 +7069,8 @@ static Property x86_cpu_properties[] = {
> >        * own cache information (see x86_cpu_load_def()).
> >        */
> >       DEFINE_PROP_BOOL("legacy-cache", X86CPU, legacy_cache, true),
> > +    DEFINE_PROP_BOOL("xen", X86CPU, xen, false),
> 
> Maybe name it 'xen-hvm'?

I think I'd prefer it to go away completely. If the *machine* has the
Xen feature enabled (which I've made implicit in the 'xen-version'
property), perhaps we should *always* disable 'expose_kvm' and enable
the Xen CPUID leaves instead? 

> > +    DEFINE_PROP_BOOL("xen-vapic", X86CPU, xen_vapic, false),
> 
> What happens if we use -cpu host,-kvm,+xen,-xen-vapic ?

That's sane; it does the Xen CPUID thing but doesn't advertise the
vAPIC feature in the Xen CPUID leaves.

> Is -cpu host,-kvm,-xen,+xen-vapic meaningful? Otherwise we need to error
> out (eventually displaying some hint).

Indeed it isn't meaningful, and should cause an error.

smime.p7s
Description: S/MIME cryptographic signature