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
| ||
|
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