diff mbox

kvm-kmod and kernels 3.11.*

Message ID 20131213161859.GB14762@ERROL.INI.CMU.EDU (mailing list archive)
State New, archived
Headers show

Commit Message

Gabriel L. Somlo Dec. 13, 2013, 4:19 p.m. UTC
On Fri, Dec 13, 2013 at 04:36:07PM +0100, Jan Kiszka wrote:
> On 2013-12-13 16:12, Paolo Bonzini wrote:
>> I think the relevance of releases is ~zero.  kvm-kmod still remains
>> extremely useful IMHO as a hacking tool.
> 
> Exactly.

I agree. No idea how "Real KVM Hackers (tm)" do it, but this wannabe
amateur KVM hacker couldn't pull it off without the safety blanket of
his stock distro kernel (and kvm-kmod) :) So thanks again for
maintaining it !

>> Agreed on this as well.  Personally I would be fine even with only 3-4
>> releases backwards compatibility (e.g. 3.8) right now.

Same here. I tend to run up-to-date stock Fedoras that are still
maintained (which right now means as old as F18, with its current
kernel (which is 3.11.10). What's important to me is the ability
to track the latest-and-greatest KVM master, but compile it against
such a distro kernel. I've never had a need to use the releases.

Paolo, thanks for pointing out the "next" branch of kvm-kmod.

Using that, I still got an error when building against the latest KVM
(commit 2e7babfa892a55588467ef03b545002e32f31528):

  CC [M]  /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/x86.o
/home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/x86.c: In function 'vcpu_enter_guest':
/home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/x86.c:6042:2: error: implicit declaration of function 'smp_mb__after_srcu_read_unlock' [-Werror=implicit-function-declaration]


Adding the following string (cut'n'paste from kvm's srchu.h):

static inline void smp_mb__after_srcu_read_unlock(void) {}

to include-compat/linux/srcu.h didn't work, as apparently
x86/x86.c doesn't want to include *our* srcu.h :(

So I tried to mimic the existing "sed" functionality of the "sync"
script, and was was left deciding between excising the call to         smp_mb__after_srcu_read_unlock() from line 6009 of x86.c (since it's
defined as a no-op in the header), or sed-ing in the declaration from
the kvm srcu.h via the sync script. I think the latter is slightly less
cheesy, but I'm really curious what you think would have been the
"canonical" way to do this :)

With the patch below, kvm-kmod:next can build kvm modules from the
latest/current kvm tree. I don't know if/how I can "update source link"
by way of a patch, but 2e7babfa892a55588467ef03b545002e32f31528 works
fine after applying the enclosed fix.

Thanks again,
--Gabriel


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

Comments

Jan Kiszka Dec. 13, 2013, 4:26 p.m. UTC | #1
On 2013-12-13 17:19, Gabriel L. Somlo wrote:
> On Fri, Dec 13, 2013 at 04:36:07PM +0100, Jan Kiszka wrote:
>> On 2013-12-13 16:12, Paolo Bonzini wrote:
>>> I think the relevance of releases is ~zero.  kvm-kmod still remains
>>> extremely useful IMHO as a hacking tool.
>>
>> Exactly.
> 
> I agree. No idea how "Real KVM Hackers (tm)" do it, but this wannabe
> amateur KVM hacker couldn't pull it off without the safety blanket of
> his stock distro kernel (and kvm-kmod) :) So thanks again for
> maintaining it !
> 
>>> Agreed on this as well.  Personally I would be fine even with only 3-4
>>> releases backwards compatibility (e.g. 3.8) right now.
> 
> Same here. I tend to run up-to-date stock Fedoras that are still
> maintained (which right now means as old as F18, with its current
> kernel (which is 3.11.10). What's important to me is the ability
> to track the latest-and-greatest KVM master, but compile it against
> such a distro kernel. I've never had a need to use the releases.
> 
> Paolo, thanks for pointing out the "next" branch of kvm-kmod.
> 
> Using that, I still got an error when building against the latest KVM
> (commit 2e7babfa892a55588467ef03b545002e32f31528):
> 
>   CC [M]  /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/x86.o
> /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/x86.c: In function 'vcpu_enter_guest':
> /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/x86.c:6042:2: error: implicit declaration of function 'smp_mb__after_srcu_read_unlock' [-Werror=implicit-function-declaration]
> 
> 
> Adding the following string (cut'n'paste from kvm's srchu.h):
> 
> static inline void smp_mb__after_srcu_read_unlock(void) {}
> 
> to include-compat/linux/srcu.h didn't work, as apparently
> x86/x86.c doesn't want to include *our* srcu.h :(
> 
> So I tried to mimic the existing "sed" functionality of the "sync"
> script, and was was left deciding between excising the call to         smp_mb__after_srcu_read_unlock() from line 6009 of x86.c (since it's
> defined as a no-op in the header), or sed-ing in the declaration from
> the kvm srcu.h via the sync script. I think the latter is slightly less
> cheesy, but I'm really curious what you think would have been the
> "canonical" way to do this :)

In this case it is rather via external-module-compat-comm.h. I already
had a patch for this here, will now push it very soon.

sync is already pretty slow, we need to keep it short, possibly even
clean it up in the light of the new entry level (3.0).

Jan

> 
> With the patch below, kvm-kmod:next can build kvm modules from the
> latest/current kvm tree. I don't know if/how I can "update source link"
> by way of a patch, but 2e7babfa892a55588467ef03b545002e32f31528 works
> fine after applying the enclosed fix.
> 
> Thanks again,
> --Gabriel
> 
> 
> diff --git a/sync b/sync
> index c22ee9a..1a941b6 100755
> --- a/sync
> +++ b/sync
> @@ -337,6 +337,12 @@ def hack_content(fname, data):
>              w('\t.shrink = mmu_shrink,')
>              line = '#else'
>  
> +        if line == 'static int vcpu_enter_guest(struct kvm_vcpu *vcpu)':
> +            w('#if LINUX_VERSION_CODE < KERNEL_VERSION(3,12,0)')
> +            w('static inline void smp_mb__after_srcu_read_unlock(void) {}')
> +            w('#endif')
> +            w('')
> +
>          w(line)
>  
>          if line == '\t.scan_objects = mmu_shrink_scan,':
>
diff mbox

Patch

diff --git a/sync b/sync
index c22ee9a..1a941b6 100755
--- a/sync
+++ b/sync
@@ -337,6 +337,12 @@  def hack_content(fname, data):
             w('\t.shrink = mmu_shrink,')
             line = '#else'
 
+        if line == 'static int vcpu_enter_guest(struct kvm_vcpu *vcpu)':
+            w('#if LINUX_VERSION_CODE < KERNEL_VERSION(3,12,0)')
+            w('static inline void smp_mb__after_srcu_read_unlock(void) {}')
+            w('#endif')
+            w('')
+
         w(line)
 
         if line == '\t.scan_objects = mmu_shrink_scan,':