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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Borislav Petkov [mailto:bp@xxxxxxxxx]
> Sent: Thursday, January 24, 2013 4:28 AM
> To: KY Srinivasan
> Cc: x86@xxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx;
> jasowang@xxxxxxxxxx; tglx@xxxxxxxxxxxxx; hpa@xxxxxxxxx; JBeulich@xxxxxxxx
> 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.
> --
> 

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel


[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux