lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 18 Apr 2013 13:30:56 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	KY Srinivasan <kys@...rosoft.com>,
	"Michael S. Tsirkin" <mst@...hat.com>
CC:	"olaf@...fle.de" <olaf@...fle.de>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"bp@...en8.de" <bp@...en8.de>, Jan Beulich <JBeulich@...e.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"apw@...onical.com" <apw@...onical.com>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>
Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V



> -----Original Message-----
> From: devel [mailto:devel-bounces@...uxdriverproject.org] On Behalf Of KY
> Srinivasan
> Sent: Thursday, April 18, 2013 9:23 AM
> To: Michael S. Tsirkin
> Cc: olaf@...fle.de; gregkh@...uxfoundation.org; jasowang@...hat.com;
> x86@...nel.org; linux-kernel@...r.kernel.org; bp@...en8.de; Jan Beulich;
> hpa@...or.com; apw@...onical.com; devel@...uxdriverproject.org;
> tglx@...utronix.de
> Subject: RE: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V
> 
> 
> 
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@...hat.com]
> > Sent: Thursday, April 18, 2013 3:48 AM
> > To: KY Srinivasan
> > Cc: Jan Beulich; olaf@...fle.de; bp@...en8.de; apw@...onical.com;
> > x86@...nel.org; tglx@...utronix.de; devel@...uxdriverproject.org;
> > gregkh@...uxfoundation.org; jasowang@...hat.com; linux-
> > kernel@...r.kernel.org; hpa@...or.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:JBeulich@...e.com]
> > > > Sent: Wednesday, April 17, 2013 11:51 AM
> > > > To: KY Srinivasan; Michael S. Tsirkin
> > > > Cc: olaf@...fle.de; bp@...en8.de; apw@...onical.com; x86@...nel.org;
> > > > tglx@...utronix.de; devel@...uxdriverproject.org;
> > gregkh@...uxfoundation.org;
> > > > jasowang@...hat.com; linux-kernel@...r.kernel.org; hpa@...or.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 <kys@...rosoft.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
> devel@...uxdriverproject.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists