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

From: David Woodhouse <dwmw2@infradead.org>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>, Paul Durrant <paul@xen.org>,
	Joao Martins <joao.m.martins@oracle.com>,
	Ankur Arora <ankur.a.arora@oracle.com>
Subject: Re: [RFC PATCH 03/21] i386/kvm: handle Xen HVM cpuid leaves
Date: Tue, 06 Dec 2022 08:05:01 +0000	[thread overview]
Message-ID: <16654e32de0689ebdeb0bc317e56d09024621d08.camel@infradead.org> (raw)
In-Reply-To: <6340aeda-9a57-4b21-5340-1c624f98f3e8@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

On Tue, 2022-12-06 at 08:58 +0100, Philippe Mathieu-Daudé wrote:
> On 6/12/22 01:18, David Woodhouse wrote:
> > 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?
> 
> It would be silly to run a non-Xen guest on the Xen machine, so it is
> not a bad idea :)

Right. I just wasn't sure how to do it as *default* but still let it be
overridden. I may just hard-code it.

> > > > +    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.
> 
> In which case we don't want to use the vAPIC?

Indeed. In that case we won't advertise vAPIC to the guest, and then
the guest will use PIRQ to route MSIs to event channels instead of
directly to guest vCPUs.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]