linux-kernel - RE: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3f75c2349f8348668639c04f6590fa8b@SN2PR03MB061.namprd03.prod.outlook.com>
Date:	Thu, 24 Jan 2013 17:42:40 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	"x86@...nel.org" <x86@...nel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"olaf@...fle.de" <olaf@...fle.de>,
	"apw@...onical.com" <apw@...onical.com>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"hpa@...or.com" <hpa@...or.com>,
	"JBeulich@...e.com" <JBeulich@...e.com>
Subject: RE: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as
 special hypervisor interrupts



> -----Original Message-----
> From: Borislav Petkov [mailto:bp@...en8.de]
> Sent: Thursday, January 24, 2013 4:28 AM
> To: KY Srinivasan
> Cc: x86@...nel.org; gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; olaf@...fle.de; apw@...onical.com;
> jasowang@...hat.com; tglx@...utronix.de; hpa@...or.com; JBeulich@...e.com
> Subject: Re: [PATCH RESEND 1/1] X86: Handle Hyper-V vmbus interrupts as
> special hypervisor interrupts
> 
> On Wed, Jan 23, 2013 at 05:56:09PM -0800, K. Y. Srinivasan wrote:
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index 1975122..803ca69 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -1446,11 +1446,16 @@ ENTRY(xen_failsafe_callback)
> >  	CFI_ENDPROC
> >  END(xen_failsafe_callback)
> >
> > -apicinterrupt XEN_HVM_EVTCHN_CALLBACK \
> > +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
> >  	xen_hvm_callback_vector xen_evtchn_do_upcall
> >
> >  #endif /* CONFIG_XEN */
> >
> > +#if IS_ENABLED(CONFIG_HYPERV)
> > +apicinterrupt HYPERVISOR_CALLBACK_VECTOR \
> > +	hyperv_callback_vector hyperv_vector_handler
> > +#endif /* CONFIG_HYPERV */
> 
> arch/x86/built-in.o: In function `_set_gate':
> /w/kernel/linux-2.6/arch/x86/include/asm/desc.h:328: undefined reference to
> `hyperv_callback_vector'
> make: *** [vmlinux] Error 1
> 
> because, of course:
> 
> # CONFIG_HYPERV is not set

My mistake. I should have properly guarded code that needs to be conditional. This also would address
the issue that Jan raised. I will resend this patch soon.

Regards,

K. Y 

> 
> But, I have a more serious pet-peeve with the whole hypervisors
> detection stuff: we're building arch/x86/kernel/cpu/hypervisor.c
> unconditionally and yet, we have CONFIG_PARAVIRT_GUEST to ask the user
> whether she wants to enable some options for running linux as a guest.
> 
> And actually, it would be better to put all that virt-related stuff
> under a config option called HYPERVISOR or whatever, under "Processor
> type and features" which opens a menu with all virt stuff for people and
> distros to select.
> 
> This way, init_hypervisor_platform and the rest of hypervisors stuff
> won't run needlessly on baremetal and setups who don't want that.
> 
> Any non-starter reasons for not doing that?


> 
> --
> Regards/Gruss,
>     Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --
>