All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: agraf@suse.de, Clemens Noss <cnoss@gmx.de>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: linux-next: Tree for January 23 (kvm)
Date: Wed, 28 Jan 2009 12:44:10 -0800	[thread overview]
Message-ID: <20090128124410.c203fab1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090128142616.GA4344@amt.cnet>

(cc mailing lists)

On Wed, 28 Jan 2009 12:26:16 -0200
Marcelo Tosatti <mtosatti@redhat.com> wrote:

> On Wed, Jan 28, 2009 at 11:20:16AM +0100, Alexander Graf wrote:
> >
> > On 28.01.2009, at 10:51, Andrew Morton wrote:
> >
> >> On Fri, 23 Jan 2009 12:34:24 -0800 Randy Dunlap 
> >> <randy.dunlap@oracle.com> wrote:
> >>
> >>> Stephen Rothwell wrote:
> >>>> Hi all,
> >>>>
> >>>> News:  I will be on leave next week, so there will probably be no
> >>>> linux-next release until Feb 2.
> >>>>
> >>>> Changes since 20090122:
> >>>
> >>>
> >>> kvm changes cause this build error on i386:
> >>>
> >>> when kvm is built as module:
> >>> ERROR: "__moddi3" [arch/x86/kvm/kvm.ko] undefined!
> >>>
> >>> or when kvm is built into the kernel image:
> >>> lapic.c:(.text+0x19276): undefined reference to `__moddi3'
> >>>
> >>>
> >>> I guess it's this line:
> >>> 	ns = ktime_to_ns(remaining) % apic->timer.period;
> >>>
> >>
> >> dammit, I just spent N minutes hunting down the same thing in
> >> the Jan 26 linux-next :(
> >>
> >
> > Yeah, Clemens Foss posted a real fix on kvm@vger already.

Probably wasn't the best mailing list, as this bug affects all
developers and testers..  But whatever - thanks.

> commit efe4ff38b2bbc3944d0b2c9b6ec669b67cb7acbc
> Author: Clemens Noss <cnoss@gmx.de>
> Date:   Mon Jan 26 02:55:16 2009 +0100
> 
>     KVM: x86: fix "__moddi3 undefined" build failure in lapic.c
>     
>     use mod_64 from arch/x86/kvm/i8254.c to fix
>     ERROR: "__moddi3" [arch/x86/kvm/kvm.ko] undefined!
>     
>     Signed-off-by: Clemens Noss <cnoss@gmx.de>
>     Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index d8adc50..f0b67f2 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -35,6 +35,12 @@
>  #include "kvm_cache_regs.h"
>  #include "irq.h"
>  
> +#ifndef CONFIG_X86_64
> +#define mod_64(x, y) ((x) - (y) * div64_u64(x, y))
> +#else
> +#define mod_64(x, y) ((x) % (y))
> +#endif
> +
>  #define PRId64 "d"
>  #define PRIx64 "llx"
>  #define PRIu64 "u"
> @@ -525,7 +531,7 @@ static u32 apic_get_tmcct(struct kvm_lapic *apic)
>  	if (ktime_to_ns(remaining) < 0)
>  		remaining = ktime_set(0, 0);
>  
> -	ns = ktime_to_ns(remaining) % apic->timer.period;
> +	ns = mod_64(ktime_to_ns(remaining), apic->timer.period);
>  	tmcct = div64_u64(ns, (APIC_BUS_CYCLE_NS * apic->timer.divide_count));
>  
>  	return tmcct;

Rather than cooking up a private implementation I think it would be
better to implement a kernel-wide mod64_u64() (?) facility and then to
use that in KVM.  There will presumably be other sites which will (or
already do) need such a thing.

However it'll probably be a bit hard, getting the signednesses of the
args and the return value right.


  parent reply	other threads:[~2009-01-28 20:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-23  7:48 linux-next: Tree for January 23 Stephen Rothwell
2009-01-23 20:34 ` linux-next: Tree for January 23 (kvm) Randy Dunlap
2009-01-28  9:51   ` Andrew Morton
2009-01-28 10:20     ` Alexander Graf
     [not found]       ` <20090128142616.GA4344@amt.cnet>
2009-01-28 20:44         ` Andrew Morton [this message]
2009-02-04 13:55   ` Avi Kivity
2009-01-23 21:03 ` [PATCH] kmemtrace: fix printk format warnings Randy Dunlap
2009-01-23 21:21 ` linux-next: Tree for January 23 (drivers/watchdog/cpwd.c:411: error: 'inode' undeclared (first use in this function)) Alexey Dobriyan
2009-01-23 21:46 ` linux-next: Tree for January 23 (9pnet_rdma) Richard Holden
2009-01-23 23:00   ` [patch -next] 9pnet_rdma build error Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090128124410.c203fab1.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=agraf@suse.de \
    --cc=cnoss@gmx.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.