> -----Original Message----- > From: devel [mailto:devel-boun...@linuxdriverproject.org] On Behalf Of KY > Srinivasan > Sent: Thursday, April 18, 2013 9:23 AM > To: Michael S. Tsirkin > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > x...@kernel.org; linux-kernel@vger.kernel.org; b...@alien8.de; Jan Beulich; > h...@zytor.com; a...@canonical.com; de...@linuxdriverproject.org; > t...@linutronix.de > Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V > > > > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:m...@redhat.com] > > Sent: Thursday, April 18, 2013 3:48 AM > > To: KY Srinivasan > > Cc: Jan Beulich; o...@aepfle.de; b...@alien8.de; a...@canonical.com; > > x...@kernel.org; t...@linutronix.de; de...@linuxdriverproject.org; > > gre...@linuxfoundation.org; jasow...@redhat.com; linux- > > ker...@vger.kernel.org; h...@zytor.com > > Subject: Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V > > > > On Wed, Apr 17, 2013 at 04:28:36PM +0000, KY Srinivasan wrote: > > > > > > > > > > -----Original Message----- > > > > From: Jan Beulich [mailto:jbeul...@suse.com] > > > > Sent: Wednesday, April 17, 2013 11:51 AM > > > > To: KY Srinivasan; Michael S. Tsirkin > > > > Cc: o...@aepfle.de; b...@alien8.de; a...@canonical.com; x...@kernel.org; > > > > t...@linutronix.de; de...@linuxdriverproject.org; > > gre...@linuxfoundation.org; > > > > jasow...@redhat.com; linux-kernel@vger.kernel.org; h...@zytor.com > > > > Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of > > > > Hyper- > V > > > > > > > > >>> On 17.04.13 at 17:31, KY Srinivasan <k...@microsoft.com> wrote: > > > > > If Xen were to change where it would not unconditionally emulate > > > > > Hyper- > V, > > I > > > > > would not be opposed to taking > > > > > this check out. > > > > > > > > But it doesn't do this unconditionally, only upon admin request. > > > > > > >From the discussion we had a couple of months ago, the default setting > > > >was > to > > enable > > > Hyper-V emulation for all guests. If this is not the case, we ought to be > > > able to > > drop this. > > > However, I think it is not reasonable to add additional checks (in > > > addition to > > hypervisor check) > > > to customize the run-time in the guest for the specific Hypervisor. > > > > > > Regards, > > > > > > K. Y > > > > Parse error. What are you trying to say? I'm just saying it's best to do > > things in the way that make it possible for Xen to implement hyperv in a > > more complete way in the future and have things just work > > and in a way that does not change guest/hypervisor interface. > > There is no error to parse here. I need to setup the vmbus interrupt before I > can contact the host. As I said I am fine with dropping this check if Xen > behavior is > changed appropriately. We have a mechanism for hypervisor detection and a > mechanism for discovering features within a hypervisor. Once we confirm the > existence of a specific hypervisor, we ought to be able to do what is needed > for > that hypervisor (unless the hypervisor feature flag precludes it) without > having to > go through hoops to discover if we are in a hypervisor emulation mode where > the emulation > may not be complete. In this particular case, the need for VMBUS related > infrastructure cannot be > currently determined via the feature detection mechanism. > > For features that cannot be detected via CPUID feature bits, we can use some > other CPUID based > mechanism to discriminate. For instance in the case under discussion, I could > install > hyperv_callback_vector only if we are on an environment that supports the > vmbus infrastructure. > Unfortunately there is no positive test for this. The best we can do is a > negative > test. I could move the > Xen check and conditionally install the hyperv_callback vector.
Michael, I think I can address the problem you have raised. I will send a patch out soon. Regards, K. Y > > Regards, > > K. Y > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > _______________________________________________ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
