> -----Original Message----- > From: devel [mailto:[email protected]] On Behalf Of KY > Srinivasan > Sent: Thursday, April 18, 2013 9:23 AM > To: Michael S. Tsirkin > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; Jan Beulich; > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V > > > > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:[email protected]] > > Sent: Thursday, April 18, 2013 3:48 AM > > To: KY Srinivasan > > Cc: Jan Beulich; [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; linux- > > [email protected]; [email protected] > > 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:[email protected]] > > > > Sent: Wednesday, April 17, 2013 11:51 AM > > > > To: KY Srinivasan; Michael S. Tsirkin > > > > Cc: [email protected]; [email protected]; [email protected]; [email protected]; > > > > [email protected]; [email protected]; > > [email protected]; > > > > [email protected]; [email protected]; [email protected] > > > > 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 <[email protected]> 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 > [email protected] > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel > _______________________________________________ devel mailing list [email protected] http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
