> -----Original Message----- > From: devel [mailto:devel-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of KY > Srinivasan > Sent: Thursday, April 18, 2013 9:23 AM > To: Michael S. Tsirkin > Cc: olaf@xxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; jasowang@xxxxxxxxxx; > x86@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; bp@xxxxxxxxx; Jan Beulich; > hpa@xxxxxxxxx; apw@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; > tglx@xxxxxxxxxxxxx > Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V > > > > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:mst@xxxxxxxxxx] > > Sent: Thursday, April 18, 2013 3:48 AM > > To: KY Srinivasan > > Cc: Jan Beulich; olaf@xxxxxxxxx; bp@xxxxxxxxx; apw@xxxxxxxxxxxxx; > > x86@xxxxxxxxxx; tglx@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; > > gregkh@xxxxxxxxxxxxxxxxxxx; jasowang@xxxxxxxxxx; linux- > > kernel@xxxxxxxxxxxxxxx; hpa@xxxxxxxxx > > 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:JBeulich@xxxxxxxx] > > > > Sent: Wednesday, April 17, 2013 11:51 AM > > > > To: KY Srinivasan; Michael S. Tsirkin > > > > Cc: olaf@xxxxxxxxx; bp@xxxxxxxxx; apw@xxxxxxxxxxxxx; x86@xxxxxxxxxx; > > > > tglx@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; > > gregkh@xxxxxxxxxxxxxxxxxxx; > > > > jasowang@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; hpa@xxxxxxxxx > > > > 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 <kys@xxxxxxxxxxxxx> 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 > devel@xxxxxxxxxxxxxxxxxxxxxx > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
