Re: [PATCH v2 1/2] sched/wait: introduce wait_event_freezable_hrtimeout

[Ingo Molnar]

* Hugo Lefeuvre  wrote:

> introduce wait_event_freezable_hrtimeout, an interruptible and freezable
> version of wait_event_hrtimeout.
> 
> This helper will allow for simplifications in staging/android/vsoc.c, among
> others.
> 
> Signed-off-by: Hugo Lefeuvre 
> ---
> Changes in v2:
>   - No change.
> 
>  include/linux/wait.h | 25 +
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index 5f3efabc36f4..c4cf5113f58a 100644
> --- a/include/linux/wait.h
> +++ b/include/linux/wait.h
> @@ -483,7 +483,7 @@ do {  
> \
>   __ret;  
> \
>  })
>  
> -#define __wait_event_hrtimeout(wq_head, condition, timeout, state)   
> \
> +#define __wait_event_hrtimeout(wq_head, condition, timeout, state, cmd)  
> \
>  ({   
> \
>   int __ret = 0;  
> \
>   struct hrtimer_sleeper __t; 
> \
> @@ -500,7 +500,7 @@ do {  
> \
>   __ret = -ETIME; 
> \
>   break;  
> \
>   }   
> \
> - schedule());
> \
> + cmd);   
> \
>   
> \
>   hrtimer_cancel(&__t.timer); 
> \
>   destroy_hrtimer_on_stack(&__t.timer);   
> \
> @@ -529,7 +529,23 @@ do { 
> \
>   might_sleep();  
> \
>   if (!(condition))   
> \
>   __ret = __wait_event_hrtimeout(wq_head, condition, timeout, 
> \
> -TASK_UNINTERRUPTIBLE);   
> \
> +TASK_UNINTERRUPTIBLE,
> \
> +schedule()); 
> \
> + __ret;  
> \
> +})
> +
> +/*
> + * like wait_event_hrtimeout() -- except it uses TASK_INTERRUPTIBLE to avoid
> + * increasing load and is freezable.
> + */
> +#define wait_event_freezable_hrtimeout(wq_head, condition, timeout)  
> \
> +({   
> \
> + int __ret = 0;  
> \
> + might_sleep();  
> \
> + if (!(condition))   
> \
> + __ret = __wait_event_hrtimeout(wq_head, condition, timeout, 
> \
> +TASK_INTERRUPTIBLE,  
> \
> +freezable_schedule());   
> \
>   __ret;  
> \
>  })
>  
> @@ -555,7 +571,8 @@ do {  
> \
>   might_sleep();  
> \
>   if (!(condition))   
> \
>   __ret = __wait_event_hrtimeout(wq, condition, timeout,  
> \
> -TASK_INTERRUPTIBLE); 
> \
> +TASK_INTERRUPTIBLE,  
> \
> +schedule()); 
> \
>   __ret;  
> \
>  })

Looks good to me - unless PeterZ objects I suspect this wants to go 
upstream via the driver tree, not the scheduler tree:

  Acked-by: Ingo Molnar 

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.

[Ingo Molnar]

* Thomas Gleixner  wrote:

> On Fri, 6 Jul 2018, Ingo Molnar wrote:
> > * KY Srinivasan  wrote:
> > > I am confused. The label ipi_mask_done was introduced in this patch
> > > (the patch under question fixes a circular dependency in this patch):
> > > 
> > > commit 68bb7bfb7985df2bd15c2dc975cb68b7a901488a
> > > Author: K. Y. Srinivasan 
> > > Date:   Wed May 16 14:53:31 2018 -0700
> > > 
> > > X86/Hyper-V: Enable IPI enlightenments
> > > 
> > > Hyper-V supports hypercalls to implement IPI; use them.
> > > 
> > > Signed-off-by: K. Y. Srinivasan 
> > > Signed-off-by: Thomas Gleixner 
> > > Reviewed-by: Michael Kelley 
> > > 
> > > This patch was committed by Thomas some weeks ago and is in linux-next.
> > > This patch is also in 4.18-rc3.
> > 
> > And then that name was changed to a different label in:
> > 
> >   4bd06060762b: x86/hyper-v: Use cheaper HVCALL_SEND_IPI hypercall when 
> > possible
> > 
> > So maybe you were testing on an older kernel. Could you try the latest -tip?
> 
> The problem is that the wreckage is in Linus tree and needs to be fixed
> there, i.e. via x86/urgent.

Indeed, I missed that!

> Now we have the new bits queued in x86/hyperv already which collide. So we
> need to merge x86/urgent into x86/hyperv after applying the fix and mop up
> the merge wreckage in x86/hyperv.
> 
> I'll have a look tomorrow morning unless you beat me to it.

Ok!

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.

[Ingo Molnar]

* KY Srinivasan  wrote:

> 
> 
> > -Original Message-
> > From: Ingo Molnar  On Behalf Of Ingo Molnar
> > Sent: Thursday, July 5, 2018 8:38 AM
> > To: KY Srinivasan 
> > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> > h...@zytor.com; Stephen Hemminger ; Michael
> > Kelley (EOSG) ; vkuzn...@redhat.com
> > Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI
> > enlightenment.
> > 
> > 
> > * KY Srinivasan  wrote:
> > 
> > >
> > >
> > > > -Original Message-
> > > > From: Ingo Molnar  On Behalf Of Ingo
> > Molnar
> > > > Sent: Wednesday, July 4, 2018 9:11 AM
> > > > To: KY Srinivasan 
> > > > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > > > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> > > > h...@zytor.com; Stephen Hemminger ;
> > Michael
> > > > Kelley (EOSG) ;
> > vkuzn...@redhat.com
> > > > Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in 
> > > > IPI
> > > > enlightenment.
> > > >
> > > >
> > > > * k...@linuxonhyperv.com  wrote:
> > > >
> > > > > From: "K. Y. Srinivasan" 
> > > > >
> > > > > The IPI hypercalls depend on being able to map the Linux notion of CPU
> > ID
> > > > > to the hypervisor's notion of the CPU ID. The array hv_vp_index[]
> > provides
> > > > > this mapping. Code for populating this array depends on the IPI
> > > > functionality.
> > > > > Break this circular dependency.
> > > > >
> > > > > Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan 
> > > > > Tested-by: Michael Kelley 
> > > > > ---
> > > > >  arch/x86/hyperv/hv_apic.c   | 5 +
> > > > >  arch/x86/hyperv/hv_init.c   | 5 -
> > > > >  arch/x86/include/asm/mshyperv.h | 2 ++
> > > > >  3 files changed, 11 insertions(+), 1 deletion(-)
> > > >
> > > > Ugh, this patch wasn't even build tested, on 64-bit allyes/allmodconfig:
> > > >
> > > >  arch/x86/hyperv/hv_apic.c: In function ‘__send_ipi_mask’:
> > > >  arch/x86/hyperv/hv_apic.c:171:4: error: label ‘ipi_mask_done’ used but
> > not
> > > > defined
> > > >  scripts/Makefile.build:317: recipe for target 
> > > > 'arch/x86/hyperv/hv_apic.o'
> > > > failed
> > > >  make[2]: *** [arch/x86/hyperv/hv_apic.o] Error 1
> > >
> > > Sorry Ingo. I had a clean build on the linux-next tree (tag: 
> > > next-20180702)
> > that
> > > I used to base this patch. What was the tree you applied the patch to?
> > 
> > If you look at the error message, it won't build against *any* tree, because
> > there's no 'ipi_mask_done' label either in the kernel source, or introduced
> > by the patch.
> > 
> > So whatever tree you used it on, if you build arch/x86/hyperv/hv_apic.o it
> > should
> > be broken.
> 
> Ingo,
> 
> I am confused. The label ipi_mask_done was introduced in this patch
> (the patch under question fixes a circular dependency in this patch):
> 
> commit 68bb7bfb7985df2bd15c2dc975cb68b7a901488a
> Author: K. Y. Srinivasan 
> Date:   Wed May 16 14:53:31 2018 -0700
> 
> X86/Hyper-V: Enable IPI enlightenments
> 
> Hyper-V supports hypercalls to implement IPI; use them.
> 
> Signed-off-by: K. Y. Srinivasan 
> Signed-off-by: Thomas Gleixner 
> Reviewed-by: Michael Kelley 
> 
> This patch was committed by Thomas some weeks ago and is in linux-next.
> This patch is also in 4.18-rc3.

And then that name was changed to a different label in:

  4bd06060762b: x86/hyper-v: Use cheaper HVCALL_SEND_IPI hypercall when possible

So maybe you were testing on an older kernel. Could you try the latest -tip?

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.

[Ingo Molnar]

* KY Srinivasan  wrote:

> 
> 
> > -Original Message-
> > From: Ingo Molnar  On Behalf Of Ingo Molnar
> > Sent: Wednesday, July 4, 2018 9:11 AM
> > To: KY Srinivasan 
> > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> > h...@zytor.com; Stephen Hemminger ; Michael
> > Kelley (EOSG) ; vkuzn...@redhat.com
> > Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI
> > enlightenment.
> > 
> > 
> > * k...@linuxonhyperv.com  wrote:
> > 
> > > From: "K. Y. Srinivasan" 
> > >
> > > The IPI hypercalls depend on being able to map the Linux notion of CPU ID
> > > to the hypervisor's notion of the CPU ID. The array hv_vp_index[] provides
> > > this mapping. Code for populating this array depends on the IPI
> > functionality.
> > > Break this circular dependency.
> > >
> > > Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
> > >
> > > Signed-off-by: K. Y. Srinivasan 
> > > Tested-by: Michael Kelley 
> > > ---
> > >  arch/x86/hyperv/hv_apic.c   | 5 +
> > >  arch/x86/hyperv/hv_init.c   | 5 -
> > >  arch/x86/include/asm/mshyperv.h | 2 ++
> > >  3 files changed, 11 insertions(+), 1 deletion(-)
> > 
> > Ugh, this patch wasn't even build tested, on 64-bit allyes/allmodconfig:
> > 
> >  arch/x86/hyperv/hv_apic.c: In function ‘__send_ipi_mask’:
> >  arch/x86/hyperv/hv_apic.c:171:4: error: label ‘ipi_mask_done’ used but not
> > defined
> >  scripts/Makefile.build:317: recipe for target 'arch/x86/hyperv/hv_apic.o'
> > failed
> >  make[2]: *** [arch/x86/hyperv/hv_apic.o] Error 1
> 
> Sorry Ingo. I had a clean build on the linux-next tree (tag: next-20180702) 
> that
> I used to base this patch. What was the tree you applied the patch to?

If you look at the error message, it won't build against *any* tree, because 
there's no 'ipi_mask_done' label either in the kernel source, or introduced
by the patch.

So whatever tree you used it on, if you build arch/x86/hyperv/hv_apic.o it 
should 
be broken.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.

[Ingo Molnar]

* k...@linuxonhyperv.com  wrote:

> From: "K. Y. Srinivasan" 
> 
> The IPI hypercalls depend on being able to map the Linux notion of CPU ID
> to the hypervisor's notion of the CPU ID. The array hv_vp_index[] provides
> this mapping. Code for populating this array depends on the IPI functionality.
> Break this circular dependency.
> 
> Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
> 
> Signed-off-by: K. Y. Srinivasan 
> Tested-by: Michael Kelley 
> ---
>  arch/x86/hyperv/hv_apic.c   | 5 +
>  arch/x86/hyperv/hv_init.c   | 5 -
>  arch/x86/include/asm/mshyperv.h | 2 ++
>  3 files changed, 11 insertions(+), 1 deletion(-)

Ugh, this patch wasn't even build tested, on 64-bit allyes/allmodconfig:

 arch/x86/hyperv/hv_apic.c: In function ‘__send_ipi_mask’:
 arch/x86/hyperv/hv_apic.c:171:4: error: label ‘ipi_mask_done’ used but not 
defined
 scripts/Makefile.build:317: recipe for target 'arch/x86/hyperv/hv_apic.o' 
failed
 make[2]: *** [arch/x86/hyperv/hv_apic.o] Error 1

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] x86/hyper-V: Allocate the IDT entry early in boot

[Ingo Molnar]

* KY Srinivasan  wrote:

> 
> 
> > -Original Message-
> > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > Sent: Saturday, September 9, 2017 4:04 AM
> > To: KY Srinivasan 
> > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> > h...@zytor.com; mi...@kernel.org
> > Subject: Re: [PATCH 1/1] x86/hyper-V: Allocate the IDT entry early in boot
> > 
> > On Fri, Sep 08, 2017 at 04:15:57PM -0700, k...@exchange.microsoft.com
> > wrote:
> > > From: "K. Y. Srinivasan" 
> > >
> > > Allocate the hypervisor callback IDT entry early in the boot sequence.
> > >
> > 
> > I'm guessing this fixes a NULL dereference or something?  The changelog
> > doesn't really say why we are doing this.
> 
> The changelog does say what we are doing - allocating the IDT entry early in 
> the boot sequence.

But the question was the 'why', not the 'what' - so Dan's question is
fully justified ...

> The current code would allocate the entry as part of registering the handler 
> when vmbus driver loaded and this caused a problem for the cleanup Thomas had 
> implemented.

I've put this explanation into the changelog.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Ingo Molnar]

* Vitaly Kuznetsov <vkuzn...@redhat.com> wrote:

> Ingo Molnar <mi...@kernel.org> writes:
> 
> > * Vitaly Kuznetsov <vkuzn...@redhat.com> wrote:
> >
> >> > Changes since v9:
> >> > - Rebase to 4.13-rc3.
> >> > - Drop PATCH1 as it was already taken by Greg to char-misc tree. 
> >> > There're no
> >> >   functional dependencies on this patch so the series can go through a 
> >> > different tree
> >> >   (and it actually belongs to x86 if I got Ingo's comment right).
> >> > - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, 
> >> > Greg KH]
> >> > - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
> >> >   hyperv_flush_tlb_others() [Andy Shevchenko]
> >> > - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
> >> >   reported by kbuild test robot (#include )
> >> > - Add Steven's 'Reviewed-by:' to PATCH9.
> >> 
> >> Ingo,
> >> 
> >> this series ended up being 'almost merged' - you merged all but the last
> >> two patches to 'x86/platform' branch when Peter reported an issue with
> >> pagetable walkers. Now as we have 'x86/mm: Enable RCU based page table
> >> freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)' merged to 'x86/mm' this is
> >> resolved and we can hopefully proceed with this series. Could you please
> >> let me know if I need to resend these last two patches or if you can
> >> take them from v10?
> >
> > Ok, I have merged tip:x86/mm into tip:x86/platform to pick up the 
> > dependency and 
> > have applied patches #9 and #10.
> 
> Hope you meant '#8 and #9' as v10 had only 9 patches :-)

Yes ;-)

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Ingo Molnar]

* Vitaly Kuznetsov <vkuzn...@redhat.com> wrote:

> > Changes since v9:
> > - Rebase to 4.13-rc3.
> > - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
> >   functional dependencies on this patch so the series can go through a 
> > different tree
> >   (and it actually belongs to x86 if I got Ingo's comment right).
> > - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
> > KH]
> > - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
> >   hyperv_flush_tlb_others() [Andy Shevchenko]
> > - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
> >   reported by kbuild test robot (#include )
> > - Add Steven's 'Reviewed-by:' to PATCH9.
> 
> Ingo,
> 
> this series ended up being 'almost merged' - you merged all but the last
> two patches to 'x86/platform' branch when Peter reported an issue with
> pagetable walkers. Now as we have 'x86/mm: Enable RCU based page table
> freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)' merged to 'x86/mm' this is
> resolved and we can hopefully proceed with this series. Could you please
> let me know if I need to resend these last two patches or if you can
> take them from v10?

Ok, I have merged tip:x86/mm into tip:x86/platform to pick up the dependency 
and 
have applied patches #9 and #10. Will push it all out after testing.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Ingo Molnar]

* Vitaly Kuznetsov <vkuzn...@redhat.com> wrote:

> Vitaly Kuznetsov <vkuzn...@redhat.com> writes:
> 
> > Changes since v9:
> > - Rebase to 4.13-rc3.
> > - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
> >   functional dependencies on this patch so the series can go through a 
> > different tree
> >   (and it actually belongs to x86 if I got Ingo's comment right).
> > - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
> > KH]
> > - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
> >   hyperv_flush_tlb_others() [Andy Shevchenko]
> > - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
> >   reported by kbuild test robot (#include )
> > - Add Steven's 'Reviewed-by:' to PATCH9.
> 
> Thomas, Ingo, Greg,
> 
> do I get it right that the intention is to take this series through x86
> tree? (See: https://www.spinics.net/lists/kernel/msg2561174.html) If so,
> is there anything else I need to do to get it accepted?

Yeah, the patches are arch/x86/-heavy, so that would be the ideal workflow - 
it's 
just that the series coincided with x86 maintainers vacation time!

I've picked them up now into tip:x86/platform (they look good to me) and will 
push 
them out after some testing.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] hv: hide unused label

[Ingo Molnar]

* Arnd Bergmann  wrote:

> This new 32-bit warning just showed up:
> 
> arch/x86/hyperv/hv_init.c: In function 'hyperv_init':
> arch/x86/hyperv/hv_init.c:167:1: error: label 'register_msr_cs' defined but 
> not used [-Werror=unused-label]
> 
> The easiest solution is to move the label up into the existing #ifdef that
> has the goto.
> 
> Fixes: dee863b571b0 ("hv: export current Hyper-V clocksource")
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/x86/hyperv/hv_init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index db64baf0e500..8bef70e7f3cc 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -158,13 +158,13 @@ void hyperv_init(void)
>   clocksource_register_hz(_cs_tsc, NSEC_PER_SEC/100);
>   return;
>   }
> +register_msr_cs:
>  #endif
>   /*
>* For 32 bit guests just use the MSR based mechanism for reading
>* the partition counter.
>*/
>  
> -register_msr_cs:

Now the warning triggers upstream:

 arch/x86/hyperv/hv_init.c: In function ‘hyperv_init’:
 arch/x86/hyperv/hv_init.c:167:1: warning: label ‘register_msr_cs’ defined but 
not used [-Wunused-label]

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/6] Intel Secure Guard Extensions

[Ingo Molnar]

* Andy Lutomirski  wrote:

> > What new syscalls would be needed for ssh to get all this support?
> 
> This patchset or similar, plus some user code and an enclave to use.
> 
> Sadly, on current CPUs, you also need Intel to bless the enclave.  It looks 
> like 
> new CPUs might relax that requirement.

That looks like a fundamental technical limitation in my book - to an open 
source 
user this is essentially a very similar capability as tboot: it only allows the 
execution of externally blessed static binary blobs...

I don't think we can merge any of this upstream until it's clear that the 
hardware 
owner running open-source user-space can also freely define/start his own 
secure 
enclaves without having to sign the enclave with any external party. I.e. 
self-signed enclaves should be fundamentally supported as well.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h

[Ingo Molnar]

* Stephen Rothwell s...@canb.auug.org.au wrote:

 Nothing in asm/io.h uses anything from vmalloc.h, so remove the include
 and fix up the build problems in an allmodconfig (64 bit and 32 bit)
 build.
 
 This may be the place where x86 builds get vmalloc.h implicitly included
 and that tends to hide places where vmalloc() et al are added to files
 but the include of vmalloc.h is forgotten.

Good idea.

Acked-by: Ingo Molnar mi...@kernel.org

 Based in Linus' tree of today.
 
 There are probably more places that need vmalloc.h included, but this passes 
 64 
 bit and 32 bit allmodconfig builds, so is a place to start.

Please also test x86 allnoconfig and defconfig 32/64, that tends to unearth the 
remaining places. People doing randconfig testing will find the rest.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH V2 1/1] X86: hyperv: Enable MSR based APIC access

[Ingo Molnar]

* K. Y. Srinivasan k...@microsoft.com wrote:

 If the hypervisor supports MSR based access to the APIC registers
 (EOI, TPR and ICR), implement the MSR based access.
 
 Signed-off-by: K. Y. Srinivasan k...@microsoft.com
 ---
  Changes from V1: Addressed comments from Ingo Molnar 
 mingo.kernel@gmail.com

You didn't address my primary feedback:

  So since we are trying to explain things, wouldn't this comment be 
  more informative if it explained why we are trying to use the 
  x2APIC facilities of Hyper-V?
 
  I.e. what are the benefits of using the x2apic API towards the 
  hypervisor?

please explain the purpose, context and benefits, not just what the 
patch does - even if the comment from your first patch is now gone.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] X86: hyperv: Enable MSR based APIC access

[Ingo Molnar]

* K. Y. Srinivasan k...@microsoft.com wrote:

 If the hypervisor supports MSR based access to the APIC registers
 (EOI, TPR and ICR), implement the MSR based access.
 
 Signed-off-by: K. Y. Srinivasan k...@microsoft.com
 ---
  arch/x86/include/uapi/asm/hyperv.h |5 +++
  arch/x86/kernel/cpu/mshyperv.c |   69 
 
  2 files changed, 74 insertions(+), 0 deletions(-)
 
 diff --git a/arch/x86/include/uapi/asm/hyperv.h 
 b/arch/x86/include/uapi/asm/hyperv.h
 index 90c458e..6ce69e0 100644
 --- a/arch/x86/include/uapi/asm/hyperv.h
 +++ b/arch/x86/include/uapi/asm/hyperv.h
 @@ -140,6 +140,11 @@
   */
  #define HV_X64_RELAXED_TIMING_RECOMMENDED(1  5)
  
 +/*
 + * Recommend using x2APIC MSRs.

So since we are trying to explain things, wouldn't this comment be 
more informative if it explained why we are trying to use the x2APIC 
facilities of Hyper-V?

I.e. what are the benefits of using the x2apic API towards the 
hypervisor?

 + */
 +#define HV_X64_X2APIC_MSRS_RECOMMENDED   (1  8)
 +
  /* MSR used to identify the guest OS. */
  #define HV_X64_MSR_GUEST_OS_ID   0x4000
  
 diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
 index 939155f..dd2eb49 100644
 --- a/arch/x86/kernel/cpu/mshyperv.c
 +++ b/arch/x86/kernel/cpu/mshyperv.c
 @@ -110,6 +110,55 @@ static struct clocksource hyperv_cs = {
   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
  };
  
 +static u64 ms_hv_apic_icr_read(void)
 +{
 + u64 reg_val;
 +
 + rdmsrl(HV_X64_MSR_ICR, reg_val);
 + return reg_val;
 +}
 +
 +static void ms_hv_apic_icr_write(u32 low, u32 id)
 +{
 + u64 reg_val;
 +
 + reg_val = SET_APIC_DEST_FIELD(id);
 + reg_val = (reg_val  32);

Those parentheses are not needed.

 + reg_val |= low;
 +
 + wrmsrl(HV_X64_MSR_EOI, reg_val);
 +}
 +
 +static u32 ms_hv_apic_read(u32 reg)
 +{
 + u64 reg_val;
 +
 + switch (reg) {
 + case APIC_EOI:
 + case APIC_TASKPRI:
 + rdmsrl(HV_X64_MSR_EOI, reg_val);
 + return reg_val;

So wouldn't it be faster to use u32 for 'reg_val' and rdmsr() instead 
of u64 and rdmsrl()? This 64-bit read just throws away the high 32 
bits.

 +
 + default:
 + return native_apic_mem_read(reg);
 + }
 +}
 +
 +static void ms_hv_apic_write(u32 reg, u32 val)
 +{
 + u64 reg_val;
 +
 + reg_val =  val;
 + switch (reg) {
 + case APIC_EOI:
 + case APIC_TASKPRI:
 + wrmsrl(HV_X64_MSR_EOI, reg_val);
 + default:
 + native_apic_mem_write(reg, val);
 + }
 +}

Same observation: it would be faster to use a 32-bit WRMSR.

 +
 +
  static void __init ms_hyperv_init_platform(void)
  {
   /*
 @@ -143,11 +192,31 @@ static void __init ms_hyperv_init_platform(void)
   no_timer_check = 1;
  #endif
  
 + if (ms_hyperv.features  HV_X64_MSR_APIC_ACCESS_AVAILABLE) {
 + /*
 +  * Setup the hooks for optimized APIC read/write.
 +  */
 + apic-read = ms_hv_apic_read;
 + apic-write = ms_hv_apic_write;
 + apic-icr_write = ms_hv_apic_icr_write;
 + apic-icr_read = ms_hv_apic_icr_read;
 + apic-eoi_write = ms_hv_apic_write;

Please align the initialization vertically via tabs, like 
'x86_hyper_ms_hyperv' is initialized.

 + }
 +
 +}
 +
 +static bool ms_hyperv_x2apic(void)
 +{
 + if (ms_hyperv.hints  HV_X64_X2APIC_MSRS_RECOMMENDED)
 + return true;
 + else
 + return false;
  }

Isn't this shorter:

return (ms_hyperv.hints  HV_X64_X2APIC_MSRS_RECOMMENDED) != 0;

?

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 18/22] x86/olpc/xo15/sci: Use newly added power_supply_put API

[Ingo Molnar]

* Krzysztof Kozlowski k.kozlow...@samsung.com wrote:

 Replace direct usage of put_device() with new API: power_supply_put().
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Acked-by: Pavel Machek pa...@ucw.cz
 Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Reviewed-by: Sebastian Reichel s...@kernel.org
 ---
  arch/x86/platform/olpc/olpc-xo15-sci.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/x86/platform/olpc/olpc-xo15-sci.c 
 b/arch/x86/platform/olpc/olpc-xo15-sci.c
 index 186634e9021d..55130846ac87 100644
 --- a/arch/x86/platform/olpc/olpc-xo15-sci.c
 +++ b/arch/x86/platform/olpc/olpc-xo15-sci.c
 @@ -83,7 +83,7 @@ static void battery_status_changed(void)
  
   if (psy) {
   power_supply_changed(psy);
 - put_device(psy-dev);
 + power_supply_put(psy);
   }
  }
  
 @@ -93,7 +93,7 @@ static void ac_status_changed(void)
  
   if (psy) {
   power_supply_changed(psy);
 - put_device(psy-dev);
 + power_supply_put(psy);
   }
  }

Acked-by: Ingo Molnar mi...@kernel.org

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 17/22] x86/olpc/xo1/sci: Use newly added power_supply_put API

[Ingo Molnar]

* Krzysztof Kozlowski k.kozlow...@samsung.com wrote:

 Replace direct usage of put_device() with new API: power_supply_put().
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Acked-by: Pavel Machek pa...@ucw.cz
 Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 Reviewed-by: Sebastian Reichel s...@kernel.org
 ---
  arch/x86/platform/olpc/olpc-xo1-sci.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/x86/platform/olpc/olpc-xo1-sci.c 
 b/arch/x86/platform/olpc/olpc-xo1-sci.c
 index e4ed28bbf79d..7fa8b3b53bc0 100644
 --- a/arch/x86/platform/olpc/olpc-xo1-sci.c
 +++ b/arch/x86/platform/olpc/olpc-xo1-sci.c
 @@ -61,7 +61,7 @@ static void battery_status_changed(void)
  
   if (psy) {
   power_supply_changed(psy);
 - put_device(psy-dev);
 + power_supply_put(psy);
   }
  }
  
 @@ -71,7 +71,7 @@ static void ac_status_changed(void)
  
   if (psy) {
   power_supply_changed(psy);
 - put_device(psy-dev);
 + power_supply_put(psy);
   }
  }

Acked-by: Ingo Molnar mi...@kernel.org

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel