Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Apr 17, 2013 at 02:12:12PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > Sent: Wednesday, April 17, 2013 8:49 AM
> > To: KY Srinivasan
> > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > JBeulich@suse.com; bp@alien8.de
> > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > 
> > On Wed, Apr 17, 2013 at 01:20:58PM +0000, KY Srinivasan wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > > > Sent: Wednesday, April 17, 2013 3:06 AM
> > > > To: KY Srinivasan
> > > > Cc: x86@kernel.org; gregkh@linuxfoundation.org; linux-
> > kernel@vger.kernel.org;
> > > > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> > > > jasowang@redhat.com; tglx@linutronix.de; hpa@zytor.com;
> > > > JBeulich@suse.com; bp@alien8.de
> > > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> > > >
> > > > On Sun, Feb 03, 2013 at 05:22:38PM -0800, K. Y. Srinivasan wrote:
> > > > > Xen emulates Hyper-V to host enlightened Windows. Looks like this
> > > > > emulation may be turned on by default even for Linux guests. Check and
> > > > > fail Hyper-V detection if we are on Xen.
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > >
> > > > I'm very curious what's the specific bug that is fixed here?
> > > > I went over the original discussion in
> > > > https://patchwork.kernel.org/patch/2064331/
> > > > and that's still not clear to me. Is there a configuration
> > > > that is broken without this patch but starts working with
> > > > this patch?
> > > >
> > > > It seems that one might want to use hyper-v emulation e.g. to test
> > > > hyper-v code without using windows, so the functionality
> > > > that this patch disables is not completely useless,
> > > > so there should be a good reason for disabling it.
> > > >
> > > > Could you enlighten me please? :)
> > >
> > > Michael,
> > >
> > > If I recall correctly, the issue here was that Xen was enabling
> > > Hyper-V emulation un-conditionally even for Linux guests.
> > 
> > Okay so basically some Xen specific strangeness.
> > 
> > > Clearly,
> > > this was not the intention to begin with. This check was added to
> > > ensure that while hosting Linux we would not un-intentionally enable
> > > Hyper-V emulation in Xen.
> > 
> > What if you want to intentionally enable Hyper-V emulation in Xen?
> > There's no way to do this now, right?
> > 
> > > Not all Hyper-V features are tagged with a
> > > CPUID feature bit and so it was agreed that it would be better to
> > > disable Hyper-V emulation when hosting Linux on Xen.
> > >
> > > Regards,
> > >
> > > K. Y
> > 
> > I was just asking whether there are any specific examples of a bug
> > or is this change done just in case?
> 
> Ideally, if Hyper-V could be emulated in a plug compatible way, in that the guest would not know
> the difference as to whether Hyper-V was being emulated or indeed it was Hyper-V underneath, I would agree with you.
> Even in this case, I would argue that we would somehow give preference to the native implementation rather
> than the emulated environment. Having done the initial emulation of Hyper-V on Xen, I know the current emulation of 
> Hyper-V is restricted to emulating a few features advertised via the CPUID bits. If I recall correctly, Xen did not implement
> the enlightened TLB flush scheme. Furthermore, none of the Hyper-V emulations implement the I/O related infrastructure.
> For Linux to run efficiently on Hyper-V, the I/O paths are significantly more important than what Hyper-V emulation there is
> in Xen and I suspect in KVM. So, I don't think we want to run Linux on Xen/KVM that is emulating Hyper-V (cpuids).

No, it's a Xen specific bug.  KVM in a hyper-v mode still emulates PCI
so can still use KVM PV devices which are all PCI devices. So there's no problem there.

Also, why override this in the guest? With time Xen hyper-v emulation
might improve, meanwhile it's always possible to disable this in
the hypervisor.

> The specific case I ran into that required this patch was when I moved the VMBUS interrupts to be delivered via a special
> hypervisor vector (to support full interrupt distribution amongst all VCPUs in the guest). This feature is not tagged in the CPUID
> feature bits and without this check, I would install an interrupt handler for the hypervisor vector that clearly did not make
> any sense in anything other than Hyper-V. I suspect there will be more such situations as we go forward.
> 
> Regards,
> 
> K. Y 

Why? Because there's no VMBUS on Xen? So check whether VMBUS exists?

> > 
> > > >
> > > > > ---
> > > > >  arch/x86/kernel/cpu/mshyperv.c |    7 +++++++
> > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c
> > > > b/arch/x86/kernel/cpu/mshyperv.c
> > > > > index 646d192..4dab317 100644
> > > > > --- a/arch/x86/kernel/cpu/mshyperv.c
> > > > > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > > > > @@ -30,6 +30,13 @@ static bool __init ms_hyperv_platform(void)
> > > > >  	if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > > > >  		return false;
> > > > >
> > > > > +	/*
> > > > > +	 * Xen emulates Hyper-V to support enlightened Windows.
> > > > > +	 * Check to see first if we are on a Xen Hypervisor.
> > > > > +	 */
> > > > > +	if (xen_cpuid_base())
> > > > > +		return false;
> > > > > +
> > > > >  	cpuid(HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS,
> > > > >  	      &eax, &hyp_signature[0], &hyp_signature[1], &hyp_signature[2]);
> > > > >
> > > > > --
> > > > > 1.7.4.1
> > > > >
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > > the body of a message to majordomo@vger.kernel.org
> > > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > > > Please read the FAQ at  http://www.tux.org/lkml/
> > > >
> > >
> > 
>