RE: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to epapr_hypercall()

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

 




> -----Original Message-----
> From: Alexander Graf [mailto:agraf@xxxxxxx]
> Sent: Friday, October 04, 2013 4:46 PM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
> epapr_hypercall()
> 
> 
> On 04.10.2013, at 06:26, Bhushan Bharat-R65777 wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Wood Scott-B07421
> >> Sent: Thursday, October 03, 2013 12:04 AM
> >> To: Alexander Graf
> >> Cc: Bhushan Bharat-R65777; kvm-ppc@xxxxxxxxxxxxxxx;
> >> kvm@xxxxxxxxxxxxxxx; Bhushan
> >> Bharat-R65777
> >> Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
> >> epapr_hypercall()
> >>
> >> On Wed, 2013-10-02 at 19:54 +0200, Alexander Graf wrote:
> >>> On 02.10.2013, at 19:49, Scott Wood wrote:
> >>>
> >>>> On Wed, 2013-10-02 at 19:46 +0200, Alexander Graf wrote:
> >>>>> On 02.10.2013, at 19:42, Scott Wood wrote:
> >>>>>
> >>>>>> On Wed, 2013-10-02 at 19:17 +0200, Alexander Graf wrote:
> >>>>>>> On 02.10.2013, at 19:04, Scott Wood wrote:
> >>>>>>>
> >>>>>>>> On Wed, 2013-10-02 at 18:53 +0200, Alexander Graf wrote:
> >>>>>>>>> On 02.10.2013, at 18:40, Scott Wood wrote:
> >>>>>>>>>
> >>>>>>>>>> On Wed, 2013-10-02 at 16:19 +0200, Alexander Graf wrote:
> >>>>>>>>>>> Won't this break when CONFIG_EPAPR_PARAVIRT=n? We wouldn't
> >>>>>>>>>>> have
> >> epapr_hcalls.S compiled into the code base then and the bl above
> >> would reference an unknown function.
> >>>>>>>>>>
> >>>>>>>>>> KVM_GUEST selects EPAPR_PARAVIRT.
> >>>>>>>>>
> >>>>>>>>> But you can not select KVM_GUEST and still call these inline
> >>>>>>>>> functions,
> >> no?
> >>>>>>>>
> >>>>>>>> No.
> >>>>>>>>
> >>>>>>>>> Like kvm_arch_para_features().
> >>>>>>>>
> >>>>>>>> Where does that get called without KVM_GUEST?
> >>>>>>>>
> >>>>>>>> How would that work currently, with the call to kvm_hypercall()
> >>>>>>>> in arch/powerpc/kernel/kvm.c (which calls epapr_hypercall, BTW)?
> >>>>>>>
> >>>>>>> It wouldn't ever get called because kvm_hypercall() ends up
> >>>>>>> always
> >> returning EV_UNIMPLEMENTED when #ifndef CONFIG_KVM_GUEST.
> >>>>>>
> >>>>>> OK, so the objection is to removing that stub?  Where would we
> >>>>>> actually want to call this without knowing that KVM_GUEST or
> >>>>>> EPAPR_PARAVIRT are enabled?
> >>>>>
> >>>>> In probing code. I usually prefer
> >>>>>
> >>>>> if (kvm_feature_available(X)) {
> >>>>>  ...
> >>>>> }
> >>>>>
> >>>>> over
> >>>>>
> >>>>> #ifdef CONFIG_KVM_GUEST
> >>>>> if (kvm_feature_available(X)) {
> >>>>>  ...
> >>>>> }
> >>>>> #endif
> >>>>>
> >>>>> at least when I can avoid it. With the current code the compiler
> >>>>> would be
> >> smart enough to just optimize out the complete branch.
> >>>>
> >>>> Sure.  My point is, where would you be calling that where the
> >>>> entire file isn't predicated on (or selecting) CONFIG_KVM_GUEST or similar?
> >>>>
> >>>> We don't do these stubs for every single function in the kernel --
> >>>> only ones where the above is a reasonable use case.
> >>>
> >>> Yeah, I'm fine on dropping it, but we need to make that a conscious
> >>> decision
> >> and verify that no caller relies on it.
> >>
> >> kvm_para_has_feature() is called from arch/powerpc/kernel/kvm.c,
> >> arch/x86/kernel/kvm.c, and arch/x86/kernel/kvmclock.c, all of which
> >> are enabled by CONFIG_KVM_GUEST.
> >>
> >> I did find one example of kvm_para_available() being used in an
> >> unexpected place
> >> -- sound/pci/intel8x0.c.  It defines its own non-CONFIG_KVM_GUEST
> >> stub, even though x86 defines kvm_para_available() using inline CPUID
> >> stuff which should work without CONFIG_KVM_GUEST.
> >> I'm not sure why it even needs to do that, though -- shouldn't the
> >> subsequent PCI subsystem vendor/device check should be sufficient?
> >> No hypercalls are involved.
> >>
> >> That said, the possibility that some random driver might want to make
> >> use of paravirt features is a decent argument for keeping the stub.
> >>
> >
> > I am not sure where we are agreeing on?
> > Do we want to remove the stub in arch/powerpc/include/asm/kvm_para.h ? as
> there is no caller without KVM_GUEST and in future caller ensure this to be
> called only from code selected by KVM_GUEST?
> >
> > Or let this stub stay to avoid any random driver calling this ?
> 
> I think the most reasonable way forward is to add a stub for non-CONFIG_EPAPR to
> the epapr code, then replace the kvm bits with generic epapr bits (which your
> patches already do).

Please describe which stub you are talking about.

Thanks
-Bharat

> 
> With that we should be 100% equivalent to today's code, just with a lot less
> lines of code :).
> 
> 
> Alex
> 


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux