Menu
▾
▴
kvm-ppc-devel — The kvm PowerPC port
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(22) |
Sep
(45) |
Oct
(165) |
Nov
(149) |
Dec
(53) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(155) |
Feb
(71) |
Mar
(219) |
Apr
(262) |
May
(21) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jerone Y. <jy...@us...> - 2008-04-25 05:57:37
|
This set of patches fixes 100% CPU usage when a guest is idle on PowerPC. This ti me it uses common kvm functions to sleep the guest. Signed-off-by: Jerone Young <jy...@us...> 5 files changed, 91 insertions(+), 4 deletions(-) arch/powerpc/kvm/booke_guest.c | 6 +++ arch/powerpc/kvm/emulate.c | 5 ++ arch/powerpc/kvm/powerpc.c | 15 ++++++- arch/powerpc/platforms/44x/Makefile | 2 - arch/powerpc/platforms/44x/idle.c | 67 +++++++++++++++++++++++++++++++++++ |
|
From: Jerone Y. <jy...@us...> - 2008-04-25 05:57:36
|
2 files changed, 16 insertions(+)
arch/powerpc/kvm/booke_guest.c | 6 ++++++
arch/powerpc/kvm/powerpc.c | 10 ++++++++++
This patch adds vcpu_put & vpu_load in strategic places (as x86 does it), for use of premption. This patch also adds a very critial bit need to wake up guest that end up going to being rescheduled and go to sleep.
Signed-off-by: Jerone Young <jy...@us...>
diff --git a/arch/powerpc/kvm/booke_guest.c b/arch/powerpc/kvm/booke_guest.c
--- a/arch/powerpc/kvm/booke_guest.c
+++ b/arch/powerpc/kvm/booke_guest.c
@@ -514,6 +514,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct
{
int i;
+ vcpu_load(vcpu);
+
regs->pc = vcpu->arch.pc;
regs->cr = vcpu->arch.cr;
regs->ctr = vcpu->arch.ctr;
@@ -533,6 +535,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct
for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
regs->gpr[i] = vcpu->arch.gpr[i];
+
+ vcpu_put(vcpu);
return 0;
}
@@ -595,6 +599,7 @@ int kvm_arch_vcpu_ioctl_translate(struct
u8 pid;
u8 as;
+ vcpu_load(vcpu);
eaddr = tr->linear_address;
pid = (tr->linear_address >> 32) & 0xff;
as = (tr->linear_address >> 40) & 0x1;
@@ -610,6 +615,7 @@ int kvm_arch_vcpu_ioctl_translate(struct
tr->physical_address = tlb_xlate(gtlbe, eaddr);
/* XXX what does "writeable" and "usermode" even mean? */
tr->valid = 1;
+ vcpu_put(vcpu);
return 0;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -212,6 +212,9 @@ static void kvmppc_decrementer_func(unsi
{
struct kvm_vcpu *vcpu = (struct kvm_vcpu *)data;
+ if (waitqueue_active(&vcpu->wq))
+ wake_up_interruptible(&vcpu->wq);
+
kvmppc_queue_exception(vcpu, BOOKE_INTERRUPT_DECREMENTER);
}
@@ -338,6 +341,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
int r;
sigset_t sigsaved;
+ vcpu_load(vcpu);
+
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
@@ -362,12 +367,17 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, &sigsaved, NULL);
+ vcpu_put(vcpu);
+
return r;
}
int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt *irq)
{
+ vcpu_load(vcpu);
kvmppc_queue_exception(vcpu, BOOKE_INTERRUPT_EXTERNAL);
+ vcpu_put(vcpu);
+
return 0;
}
|
|
From: Andi K. <an...@fi...> - 2008-04-24 19:43:15
|
David Miller <da...@da...> writes: > I'm fine with adding the list, but we don't do mass subscribes like > that, and this rule applies to every list which moves to vger from > somewhere else. > > People will need to subscribe themselves to the new list. Can someone please resubscribe gmane too for us gmane users when the move occurs? Thanks, -Andi |
|
From: Hollis B. <ho...@us...> - 2008-04-24 16:38:03
|
On Thursday 24 April 2008 07:54:10 Avi Kivity wrote: > I propose moving the kvm lists to vger.kernel.org, for the following > benefits: > > - better spam control > - faster service (I see significant lag with the sourceforge lists) > - no ads appended to the end of each email > > If no objections are raised, and if the vger postmasters agree, I will > mass subscribe the current subscribers so that there will be no service > interruption. Sounds good to me. Will we continue to have manual moderation for non-subscribers? That seems to be a good way to handle the last 1% of spam that sneaks through the automated filters. -- Hollis Blanchard IBM Linux Technology Center |
|
From: Avi K. <av...@qu...> - 2008-04-24 16:01:34
|
Hollis Blanchard wrote: > On Thursday 24 April 2008 07:54:10 Avi Kivity wrote: > >> I propose moving the kvm lists to vger.kernel.org, for the following >> benefits: >> >> - better spam control >> - faster service (I see significant lag with the sourceforge lists) >> - no ads appended to the end of each email >> >> If no objections are raised, and if the vger postmasters agree, I will >> mass subscribe the current subscribers so that there will be no service >> interruption. >> > > Sounds good to me. > > Will we continue to have manual moderation for non-subscribers? That seems to > be a good way to handle the last 1% of spam that sneaks through the automated > filters. > kvm-devel doesn't do manual moderation. If vger has the infrastructure, I don't see why you can't continue doing this on kvm-ppc-devel. btw, we can probably shorten the names to kvm@ and kvm-$arch@ while we're at it. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-24 13:33:25
|
David Miller wrote: >> If no objections are raised, and if the vger postmasters agree, I will >> mass subscribe the current subscribers so that there will be no service >> interruption. >> > > I'm fine with adding the list, but we don't do mass subscribes like > that, and this rule applies to every list which moves to vger from > somewhere else. > > (three lists) > People will need to subscribe themselves to the new list. > Okay. Will give people a week's notice to subscribe. -- error compiling committee.c: too many arguments to function |
|
From: David M. <da...@da...> - 2008-04-24 13:26:41
|
From: Avi Kivity <av...@qu...> Date: Thu, 24 Apr 2008 15:54:10 +0300 > I propose moving the kvm lists to vger.kernel.org, for the following > benefits: > > - better spam control > - faster service (I see significant lag with the sourceforge lists) > - no ads appended to the end of each email > > If no objections are raised, and if the vger postmasters agree, I will > mass subscribe the current subscribers so that there will be no service > interruption. I'm fine with adding the list, but we don't do mass subscribes like that, and this rule applies to every list which moves to vger from somewhere else. People will need to subscribe themselves to the new list. We enforce this for two reasons: 1) If they don't go through the action of subscribing, they won't be able to unsubscribe, so they'll be upset and also bug us postmasters for help. 2) People are generally unhappy when they are subscribed to mailing lists at a site they didn't ask to be at. |
|
From: Yang, S. <she...@in...> - 2008-04-24 12:58:48
|
On Thursday 24 April 2008 20:54:10 Avi Kivity wrote: > I propose moving the kvm lists to vger.kernel.org, for the following > benefits: > > - better spam control > - faster service (I see significant lag with the sourceforge lists) > - no ads appended to the end of each email > > If no objections are raised, and if the vger postmasters agree, I will > mass subscribe the current subscribers so that there will be no service > interruption. > > Opinions? Yeah, finally we don't need to meet something like this everyday: "This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/" ;) -- Thanks Yang, Sheng |
|
From: Avi K. <av...@qu...> - 2008-04-24 12:54:19
|
I propose moving the kvm lists to vger.kernel.org, for the following benefits: - better spam control - faster service (I see significant lag with the sourceforge lists) - no ads appended to the end of each email If no objections are raised, and if the vger postmasters agree, I will mass subscribe the current subscribers so that there will be no service interruption. Opinions? -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-24 12:38:20
|
Jerone Young wrote: > 1 file changed, 37 insertions(+), 21 deletions(-) > kernel/Makefile | 58 +++++++++++++++++++++++++++++++++++-------------------- > > > - This adapts perviously sent patch to new changes to kernel/Makefile > - Fixes improper check in conditional > > This patch add the ability for make sync in the kernel directory to work for mulitiple architectures and not just x86. > > I addressed this in a different way by always syncing headers from all architectures. This means the tarballs can be used to build userspace on any arch (though kernel modules are limited to x86, mostly due to arch limitations). In addition, we no longer refer to KERNELDIR when building userspace, so it ought to be easier to build on random kernels. Patches to be pushed shortly... -- error compiling committee.c: too many arguments to function |
|
From: Jerone Y. <jy...@us...> - 2008-04-24 04:56:47
|
2 files changed, 6 insertions(+), 1 deletion(-) configure | 6 ++++++ libkvm/Makefile | 1 - This is a relic of the big userspace refactoring, but today libkvm does should not include settings from the test suite. This patch resolves this and removes the overwriting of setting from the main config.mak with test suite settings. Signed-off-by: Jerone Young <jy...@us...> diff --git a/configure b/configure --- a/configure +++ b/configure @@ -2,6 +2,9 @@ prefix=/usr/local kerneldir=/lib/modules/$(uname -r)/build +cc=cc +ld=ld +objcopy=objcopy want_module=1 qemu_cc= qemu_cflags= @@ -131,4 +134,7 @@ KERNELDIR=$kerneldir KERNELDIR=$kerneldir WANT_MODULE=$want_module CROSS_COMPILE=$cross_prefix +CC=$cross_prefix$cc +LD=$cross_prefix$ld +OBJCOPY=$cross_prefix$objcopy EOF diff --git a/libkvm/Makefile b/libkvm/Makefile --- a/libkvm/Makefile +++ b/libkvm/Makefile @@ -1,5 +1,4 @@ include ../config.mak include ../config.mak -include ../user/config.mak include config-$(ARCH).mak # cc-option |
|
From: Jerone Y. <jy...@us...> - 2008-04-24 04:41:20
|
1 file changed, 37 insertions(+), 21 deletions(-) kernel/Makefile | 58 +++++++++++++++++++++++++++++++++++-------------------- - This adapts perviously sent patch to new changes to kernel/Makefile - Fixes improper check in conditional This patch add the ability for make sync in the kernel directory to work for mulitiple architectures and not just x86. Signed-off-by: Jerone Young <jy...@us...> diff --git a/kernel/Makefile b/kernel/Makefile --- a/kernel/Makefile +++ b/kernel/Makefile @@ -1,5 +1,10 @@ include ../config.mak include ../config.mak +ARCH_DIR=$(ARCH) +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' '' + ARCH_DIR=x86 +endif + KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR)) DESTDIR= @@ -18,11 +23,25 @@ _hack = mv $1 $1.orig && \ | sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig _unifdef = mv $1 $1.orig && \ - unifdef -DCONFIG_X86 $1.orig > $1; \ - [ $$? -le 1 ] && rm $1.orig + unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') $1.orig > $1; \ + [ $$? -le 1 ] && rm $1.orig hack = $(call _hack,$T/$(strip $1)) unifdef = $(call _unifdef,$T/$(strip $1)) + +UNIFDEF_FILES = include/linux/kvm.h \ + include/linux/kvm_para.h \ + include/asm-$(ARCH_DIR)/kvm.h \ + include/asm-$(ARCH_DIR)/kvm_para.h + +ifneq '$(filter $(ARCH_DIR), x86)' '' +HACK_FILES = kvm_main.c \ + mmu.c \ + vmx.c \ + svm.c \ + x86.c \ + irq.h +endif all:: # include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat @@ -39,17 +58,16 @@ header-sync: rm -rf $T rsync -R \ "$(LINUX)"/./include/linux/kvm*.h \ - "$(LINUX)"/./include/asm-x86/kvm*.h \ - $T/ - mkdir -p include/linux include/asm-x86 - ln -sf asm-x86 include/asm - ln -sf asm-x86 include-compat/asm + "$(LINUX)"/./include/asm-$(ARCH_DIR)/kvm*.h \ + $T/ - $(call unifdef, include/linux/kvm.h) - $(call unifdef, include/linux/kvm_para.h) - $(call unifdef, include/asm-x86/kvm.h) - $(call unifdef, include/asm-x86/kvm_para.h) - $(call hack, include/linux/kvm.h) + mkdir -p include/linux include/asm-$(ARCH_DIR) + ln -sf asm-$(ARCH_DIR) include/asm + ln -sf asm-$(ARCH_DIR) include-compat/asm + + for i in $(UNIFDEF_FILES); \ + do $(call unifdef, $$i); done + for i in $$(find $T -type f -printf '%P '); \ do cmp -s $$i $T/$$i || cp $T/$$i $$i; done rm -rf $T @@ -57,15 +75,13 @@ source-sync: source-sync: rm -rf $T rsync --exclude='*.mod.c' -R \ - "$(LINUX)"/arch/x86/kvm/./*.[ch] \ - "$(LINUX)"/virt/kvm/./*.[ch] \ - $T/ - $(call hack, kvm_main.c) - $(call hack, mmu.c) - $(call hack, vmx.c) - $(call hack, svm.c) - $(call hack, x86.c) - $(call hack, irq.h) + "$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \ + "$(LINUX)"/virt/kvm/./*.[ch] \ + $T/ + + for i in $(HACK_FILES); \ + do $(call hack, $$i); done + for i in $$(find $T -type f -printf '%P '); \ do cmp -s $$i $T/$$i || cp $T/$$i $$i; done rm -rf $T |
|
From: Jerone Y. <jy...@us...> - 2008-04-24 04:35:46
|
On Wed, 2008-04-23 at 18:02 -0500, Anthony Liguori wrote: > > diff --git a/kernel/Makefile b/kernel/Makefile > > --- a/kernel/Makefile > > +++ b/kernel/Makefile > > @@ -1,5 +1,10 @@ include ../config.mak > > include ../config.mak > > > > +ARCH_DIR=$(ARCH) > > +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' '' > > + ARCH_DIR=x86 > > +endif > > + > > > > This sets ARCH_DIR to x86 yeap. > > > KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR)) > > > > DESTDIR= > > @@ -18,11 +23,25 @@ _hack = mv $1 $1.orig && \ > > | sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig > > > > _unifdef = mv $1 $1.orig && \ > > - unifdef -DCONFIG_X86 $1.orig > $1; \ > > + unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') $1.orig > $1; \ > > [ $$? -le 1 ] && rm $1.orig > > > > hack = $(call _hack,$T/$(strip $1)) > > unifdef = $(call _unifdef,$T/$(strip $1)) > > + > > +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' '' > > Doh! Yeap again. This was caused when things where need to change in a respin of the last patch. I just didn't notice it. I'll change it and resend ... again. > > And I'm not quite sure what this is supposed to do but it doesn't look > right. ARCH_DIR is going to equal 'x86' so this is going to break > things on x86 sinc ethe filter will return an empty string. > > Regards, > > Anthony Liguori > > > +UNIFDEF_FILES = include/linux/kvm.h \ > > + include/linux/kvm_para.h \ > > + include/asm-$(ARCH_DIR)/kvm.h \ > > + include/asm-x86/kvm_para.h > > + > > +HACK_FILES = kvm_main.c \ > > + mmu.c \ > > + vmx.c \ > > + svm.c \ > > + x86.c \ > > + irq.h > > +endif > > > > all:: > > # include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat > > @@ -39,17 +58,16 @@ header-sync: > > rm -rf $T > > rsync -R \ > > "$(LINUX)"/./include/linux/kvm*.h \ > > - "$(LINUX)"/./include/asm-x86/kvm*.h \ > > - $T/ > > - mkdir -p include/linux include/asm-x86 > > - ln -sf asm-x86 include/asm > > - ln -sf asm-x86 include-compat/asm > > + "$(LINUX)"/./include/asm-$(ARCH_DIR)/kvm*.h \ > > + $T/ > > > > - $(call unifdef, include/linux/kvm.h) > > - $(call unifdef, include/linux/kvm_para.h) > > - $(call unifdef, include/asm-x86/kvm.h) > > - $(call unifdef, include/asm-x86/kvm_para.h) > > - $(call hack, include/linux/kvm.h) > > + mkdir -p include/linux include/asm-$(ARCH_DIR) > > + ln -s asm-$(ARCH_DIR) include/asm > > + ln -sf asm-$(ARCH_DIR) include-compat/asm > > + > > + for i in $(UNIFDEF_FILES); \ > > + do $(call unifdef, $$i); done > > + > > for i in $$(find $T -type f -printf '%P '); \ > > do cmp -s $$i $T/$$i || cp $T/$$i $$i; done > > rm -rf $T > > @@ -57,15 +75,13 @@ source-sync: > > source-sync: > > rm -rf $T > > rsync --exclude='*.mod.c' -R \ > > - "$(LINUX)"/arch/x86/kvm/./*.[ch] \ > > - "$(LINUX)"/virt/kvm/./*.[ch] \ > > - $T/ > > - $(call hack, kvm_main.c) > > - $(call hack, mmu.c) > > - $(call hack, vmx.c) > > - $(call hack, svm.c) > > - $(call hack, x86.c) > > - $(call hack, irq.h) > > + "$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \ > > + "$(LINUX)"/virt/kvm/./*.[ch] \ > > + $T/ > > + > > + for i in $(HACK_FILES); \ > > + do $(call hack, $$i); done > > + > > for i in $$(find $T -type f -printf '%P '); \ > > do cmp -s $$i $T/$$i || cp $T/$$i $$i; done > > rm -rf $T > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Don't miss this year's exciting event. There's still time to save $100. > > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > kvm-devel mailing list > > kvm...@li... > > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel |
|
From: Anthony L. <an...@co...> - 2008-04-23 23:02:54
|
> diff --git a/kernel/Makefile b/kernel/Makefile > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -1,5 +1,10 @@ include ../config.mak > include ../config.mak > > +ARCH_DIR=$(ARCH) > +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' '' > + ARCH_DIR=x86 > +endif > + > This sets ARCH_DIR to x86 > KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR)) > > DESTDIR= > @@ -18,11 +23,25 @@ _hack = mv $1 $1.orig && \ > | sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig > > _unifdef = mv $1 $1.orig && \ > - unifdef -DCONFIG_X86 $1.orig > $1; \ > + unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') $1.orig > $1; \ > [ $$? -le 1 ] && rm $1.orig > > hack = $(call _hack,$T/$(strip $1)) > unifdef = $(call _unifdef,$T/$(strip $1)) > + > +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' '' > And I'm not quite sure what this is supposed to do but it doesn't look right. ARCH_DIR is going to equal 'x86' so this is going to break things on x86 sinc ethe filter will return an empty string. Regards, Anthony Liguori > +UNIFDEF_FILES = include/linux/kvm.h \ > + include/linux/kvm_para.h \ > + include/asm-$(ARCH_DIR)/kvm.h \ > + include/asm-x86/kvm_para.h > + > +HACK_FILES = kvm_main.c \ > + mmu.c \ > + vmx.c \ > + svm.c \ > + x86.c \ > + irq.h > +endif > > all:: > # include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat > @@ -39,17 +58,16 @@ header-sync: > rm -rf $T > rsync -R \ > "$(LINUX)"/./include/linux/kvm*.h \ > - "$(LINUX)"/./include/asm-x86/kvm*.h \ > - $T/ > - mkdir -p include/linux include/asm-x86 > - ln -sf asm-x86 include/asm > - ln -sf asm-x86 include-compat/asm > + "$(LINUX)"/./include/asm-$(ARCH_DIR)/kvm*.h \ > + $T/ > > - $(call unifdef, include/linux/kvm.h) > - $(call unifdef, include/linux/kvm_para.h) > - $(call unifdef, include/asm-x86/kvm.h) > - $(call unifdef, include/asm-x86/kvm_para.h) > - $(call hack, include/linux/kvm.h) > + mkdir -p include/linux include/asm-$(ARCH_DIR) > + ln -s asm-$(ARCH_DIR) include/asm > + ln -sf asm-$(ARCH_DIR) include-compat/asm > + > + for i in $(UNIFDEF_FILES); \ > + do $(call unifdef, $$i); done > + > for i in $$(find $T -type f -printf '%P '); \ > do cmp -s $$i $T/$$i || cp $T/$$i $$i; done > rm -rf $T > @@ -57,15 +75,13 @@ source-sync: > source-sync: > rm -rf $T > rsync --exclude='*.mod.c' -R \ > - "$(LINUX)"/arch/x86/kvm/./*.[ch] \ > - "$(LINUX)"/virt/kvm/./*.[ch] \ > - $T/ > - $(call hack, kvm_main.c) > - $(call hack, mmu.c) > - $(call hack, vmx.c) > - $(call hack, svm.c) > - $(call hack, x86.c) > - $(call hack, irq.h) > + "$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \ > + "$(LINUX)"/virt/kvm/./*.[ch] \ > + $T/ > + > + for i in $(HACK_FILES); \ > + do $(call hack, $$i); done > + > for i in $$(find $T -type f -printf '%P '); \ > do cmp -s $$i $T/$$i || cp $T/$$i $$i; done > rm -rf $T > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel > |
|
From: Jerone Y. <jy...@us...> - 2008-04-23 22:48:51
|
1 file changed, 36 insertions(+), 20 deletions(-)
kernel/Makefile | 56 +++++++++++++++++++++++++++++++++++--------------------
- This adapts perviously sent patch to new changes to kernel/Makefile
This patch add the ability for make sync in the kernel directory to work for mulitiple architectures and not just x86.
Signed-off-by: Jerone Young <jy...@us...>
diff --git a/kernel/Makefile b/kernel/Makefile
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -1,5 +1,10 @@ include ../config.mak
include ../config.mak
+ARCH_DIR=$(ARCH)
+ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
+ ARCH_DIR=x86
+endif
+
KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR))
DESTDIR=
@@ -18,11 +23,25 @@ _hack = mv $1 $1.orig && \
| sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig
_unifdef = mv $1 $1.orig && \
- unifdef -DCONFIG_X86 $1.orig > $1; \
+ unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') $1.orig > $1; \
[ $$? -le 1 ] && rm $1.orig
hack = $(call _hack,$T/$(strip $1))
unifdef = $(call _unifdef,$T/$(strip $1))
+
+ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
+UNIFDEF_FILES = include/linux/kvm.h \
+ include/linux/kvm_para.h \
+ include/asm-$(ARCH_DIR)/kvm.h \
+ include/asm-x86/kvm_para.h
+
+HACK_FILES = kvm_main.c \
+ mmu.c \
+ vmx.c \
+ svm.c \
+ x86.c \
+ irq.h
+endif
all::
# include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
@@ -39,17 +58,16 @@ header-sync:
rm -rf $T
rsync -R \
"$(LINUX)"/./include/linux/kvm*.h \
- "$(LINUX)"/./include/asm-x86/kvm*.h \
- $T/
- mkdir -p include/linux include/asm-x86
- ln -sf asm-x86 include/asm
- ln -sf asm-x86 include-compat/asm
+ "$(LINUX)"/./include/asm-$(ARCH_DIR)/kvm*.h \
+ $T/
- $(call unifdef, include/linux/kvm.h)
- $(call unifdef, include/linux/kvm_para.h)
- $(call unifdef, include/asm-x86/kvm.h)
- $(call unifdef, include/asm-x86/kvm_para.h)
- $(call hack, include/linux/kvm.h)
+ mkdir -p include/linux include/asm-$(ARCH_DIR)
+ ln -s asm-$(ARCH_DIR) include/asm
+ ln -sf asm-$(ARCH_DIR) include-compat/asm
+
+ for i in $(UNIFDEF_FILES); \
+ do $(call unifdef, $$i); done
+
for i in $$(find $T -type f -printf '%P '); \
do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
rm -rf $T
@@ -57,15 +75,13 @@ source-sync:
source-sync:
rm -rf $T
rsync --exclude='*.mod.c' -R \
- "$(LINUX)"/arch/x86/kvm/./*.[ch] \
- "$(LINUX)"/virt/kvm/./*.[ch] \
- $T/
- $(call hack, kvm_main.c)
- $(call hack, mmu.c)
- $(call hack, vmx.c)
- $(call hack, svm.c)
- $(call hack, x86.c)
- $(call hack, irq.h)
+ "$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \
+ "$(LINUX)"/virt/kvm/./*.[ch] \
+ $T/
+
+ for i in $(HACK_FILES); \
+ do $(call hack, $$i); done
+
for i in $$(find $T -type f -printf '%P '); \
do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
rm -rf $T
|
|
From: Avi K. <av...@qu...> - 2008-04-23 13:59:39
|
The preliminary KVM Forum 2008 agenda is now online at http://kforum.qumranet.com/KVMForum/agenda.php If you haven't done so already, please register! There is a big "Register Now" button on the page. Early bird registration ends May 1. Note we have a few more sessions in the pipeline; the page will be updated in a few days. [Speakers: if we've misspelled your name or if you'd like to change your slot, let us know] -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Edward D D. <ed...@us...> - 2008-04-22 16:05:23
|
Oops, I hit "send" before I finished my note.
The problem is that my guest only seems to show the loopback device:
root:~> ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
How can I get eth working in my guest? Thanks for your help ...
/**************************************************
* Edward D. Doan
* Power Architecture Application Engineer
* Systems & Technology Group
* IBM Corporation
* 512.838.4936
* ed...@us...
*************************************************/
__________________
Here's what I have for .config:
[edoan@ps3ydl kvmppc.hg]$ grep VIRTIO .config
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
I created /dev/net/tap via mknod /dev/net/tap c 10 200. I also copied
brctl into /sbin/. I launch the guest on my ppc440 Sequoia board:
bash-3.00# ./qemu-system-ppcemb -nographic -M bamboo -kernel uImage
-append "console=ttyS0,115200" -L . -net
nic,model=virtio,macaddr=00:00:00:00:00:AA -net tap
test for existing bridge br0
port no mac addr is local? ageing timer
1 00:10:ec:80:ee:84 yes 0.00
ok - bridge br0 already available
bamboo_init: START
<snip>
I don't have lspci in my guest. Output of dmesg:
root:~> dmesg
Using Bamboo machine description
Linux version 2.6.25-rc9 (jerone@thinkpadL) (gcc version 3.4.5) #31 Mon
Apr 21 16:15:03 CDT 2008
Found legacy serial port 0 for /plb/opb/serial@ef600300
mem=ef600300, taddr=ef600300, irq=0, clk=11059200, speed=115200
Found legacy serial port 1 for /plb/opb/serial@ef600400
mem=ef600400, taddr=ef600400, irq=0, clk=11059200, speed=0
console [udbg0] enabled
Entering add_active_range(0, 0, 36864) 0 entries of 256 used
Top of RAM: 0x9000000, Total RAM: 0x9000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 36864
Normal 36864 -> 36864
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 36864
On node 0 totalpages: 36864
DMA zone: 288 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 36576 pages, LIFO batch:7
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 36576
Kernel command line: console=ttyS0,115200
UIC0 (32 IRQ sources) at DCR 0xc0
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 666.666660 MHz
time_init: processor frequency = 666.666660 MHz
clocksource: timebase mult[600000] shift[22] registered
clockevent: decrementer mult[aaaa] shift[16] cpu[0]
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 141824k/147456k available (3872k kernel code, 5492k reserved, 100k
data, 125k bss, 1500k init)
SLUB: Genslabs=10, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay loop... 2490.36 BogoMIPS (lpj=4980736)
Mount-cache hash table entries: 512
net_namespace: 152 bytes
NET: Registered protocol family 16
PCI host bridge /plb/pci@ec000000 (primary) ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xef600300 (irq = 16) is a 16450
console handover: boot [udbg0] -> real [ttyS0]
ef600300.serial: ttyS0 at MMIO 0xef600300 (irq = 16) is a 16450
brd: module loaded
PPC 4xx OCP EMAC driver, version 3.54
ZMII /plb/opb/emac-zmii@ef600d00 initialized
PCI: Enabling device 0000:00:01.0 (0000 -> 0001)
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Freeing unused kernel memory: 1500k init
/**************************************************
* Edward D. Doan
* Power Architecture Application Engineer
* Systems & Technology Group
* IBM Corporation
* 512.838.4936
* ed...@us...
*************************************************/
From:
Anthony Liguori <an...@co...>
To:
jy...@li...
Cc:
kvm-devel <kvm...@li...>, Edward D
Doan/Austin/IBM@IBMUS
Date:
04/22/08 08:35 AM
Subject:
Re: [kvm-devel] What kernel options do I need to properly enable virtio
net driver
Jerone Young wrote:
> What I am asking is do I have all the proper options in my kernel config
> set to use it?
>
Yes. You just need CONFIG_VIRTIO_NET and CONFIG_VIRTIO_PCI. The
remaining options will be automatically selected.
Regards,
Anthony Liguori
> On Mon, 2008-04-21 at 17:13 -0500, Anthony Liguori wrote:
>
>> Jerone Young wrote:
>>
>>> virtio net device does not appear to show itself in the guest. I'm
>>> curious of what options I may be missing. Here is my config
>>>
>> You'll have to be more specific about what "does not appear to show
>> itself" means. What's the output of lspci?
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>>
------------------------------------------------------------------------
>>>
>>>
-------------------------------------------------------------------------
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>> Don't miss this year's exciting event. There's still time to save
$100.
>>> Use priority code J8TL2D2.
>>>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>>
------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> kvm-devel mailing list
>>> kvm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>>>
>
>
|
|
From: Edward D D. <ed...@us...> - 2008-04-22 16:02:03
|
Here's what I have for .config:
[edoan@ps3ydl kvmppc.hg]$ grep VIRTIO .config
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
I created /dev/net/tap via mknod /dev/net/tap c 10 200. I also copied
brctl into /sbin/. I launch the guest on my ppc440 Sequoia board:
bash-3.00# ./qemu-system-ppcemb -nographic -M bamboo -kernel uImage
-append "console=ttyS0,115200" -L . -net
nic,model=virtio,macaddr=00:00:00:00:00:AA -net tap
test for existing bridge br0
port no mac addr is local? ageing timer
1 00:10:ec:80:ee:84 yes 0.00
ok - bridge br0 already available
bamboo_init: START
<snip>
I don't have lspci in my guest. Output of dmesg:
root:~> dmesg
Using Bamboo machine description
Linux version 2.6.25-rc9 (jerone@thinkpadL) (gcc version 3.4.5) #31 Mon
Apr 21 16:15:03 CDT 2008
Found legacy serial port 0 for /plb/opb/serial@ef600300
mem=ef600300, taddr=ef600300, irq=0, clk=11059200, speed=115200
Found legacy serial port 1 for /plb/opb/serial@ef600400
mem=ef600400, taddr=ef600400, irq=0, clk=11059200, speed=0
console [udbg0] enabled
Entering add_active_range(0, 0, 36864) 0 entries of 256 used
Top of RAM: 0x9000000, Total RAM: 0x9000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 36864
Normal 36864 -> 36864
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 36864
On node 0 totalpages: 36864
DMA zone: 288 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 36576 pages, LIFO batch:7
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 36576
Kernel command line: console=ttyS0,115200
UIC0 (32 IRQ sources) at DCR 0xc0
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 666.666660 MHz
time_init: processor frequency = 666.666660 MHz
clocksource: timebase mult[600000] shift[22] registered
clockevent: decrementer mult[aaaa] shift[16] cpu[0]
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 141824k/147456k available (3872k kernel code, 5492k reserved, 100k
data, 125k bss, 1500k init)
SLUB: Genslabs=10, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay loop... 2490.36 BogoMIPS (lpj=4980736)
Mount-cache hash table entries: 512
net_namespace: 152 bytes
NET: Registered protocol family 16
PCI host bridge /plb/pci@ec000000 (primary) ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xef600300 (irq = 16) is a 16450
console handover: boot [udbg0] -> real [ttyS0]
ef600300.serial: ttyS0 at MMIO 0xef600300 (irq = 16) is a 16450
brd: module loaded
PPC 4xx OCP EMAC driver, version 3.54
ZMII /plb/opb/emac-zmii@ef600d00 initialized
PCI: Enabling device 0000:00:01.0 (0000 -> 0001)
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Freeing unused kernel memory: 1500k init
/**************************************************
* Edward D. Doan
* Power Architecture Application Engineer
* Systems & Technology Group
* IBM Corporation
* 512.838.4936
* ed...@us...
*************************************************/
From:
Anthony Liguori <an...@co...>
To:
jy...@li...
Cc:
kvm-devel <kvm...@li...>, Edward D
Doan/Austin/IBM@IBMUS
Date:
04/22/08 08:35 AM
Subject:
Re: [kvm-devel] What kernel options do I need to properly enable virtio
net driver
Jerone Young wrote:
> What I am asking is do I have all the proper options in my kernel config
> set to use it?
>
Yes. You just need CONFIG_VIRTIO_NET and CONFIG_VIRTIO_PCI. The
remaining options will be automatically selected.
Regards,
Anthony Liguori
> On Mon, 2008-04-21 at 17:13 -0500, Anthony Liguori wrote:
>
>> Jerone Young wrote:
>>
>>> virtio net device does not appear to show itself in the guest. I'm
>>> curious of what options I may be missing. Here is my config
>>>
>> You'll have to be more specific about what "does not appear to show
>> itself" means. What's the output of lspci?
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>>
------------------------------------------------------------------------
>>>
>>>
-------------------------------------------------------------------------
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>> Don't miss this year's exciting event. There's still time to save
$100.
>>> Use priority code J8TL2D2.
>>>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>>
------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> kvm-devel mailing list
>>> kvm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>>>
>
>
|
|
From: Avi K. <av...@qu...> - 2008-04-22 11:36:51
|
Jerone Young wrote: > Recent change now requires target-ppc/helper.c to now include "qemu-kvm.h" to get the definition for kvm_enabled(). This fixes it so things now compile again. > > Applied, thanks. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-22 08:53:13
|
[Note: KVM Forum registration is now open at http://kforum.qumranet.com/KVMForum/about_kvmforum.php] [The deadline for submitting presentations has been extended by two weeks, until May 4th] This is the Call for Presentations for the second annual KVM Developer's Forum, to be held on June 10-13, 2008, in Napa, California, USA [1]. We are looking for presentations on KVM development, quality assurance, management, security, interoperability, architecture support, and interesting use cases. Presentations are 50 minutes in length; there are also 25-minute mini-presentation slots available. KVM Forum presentations are an excellent way to inform the KVM development community about your work, and to gather valuable feedback about your approach. Please send your presentation proposal to the KVM Forum 2008 Content Committee at kf2...@qu... by May 4th. KVM Forum 2008 Content Committee: Dor Laor Anthony Liguori Avi Kivity [1] http://kforum.qumranet.com/KVMForum/about_kvmforum.php -- Any sufficiently difficult bug is indistinguishable from a feature. |
|
From: Liu, E. E <eri...@in...> - 2008-04-22 02:21:58
|
Hollis Blanchard wrote:
> On Sunday 20 April 2008 00:38:32 Liu, Eric E wrote:
>> Christian Ehrhardt wrote:
>>> Liu, Eric E wrote:
>>>> Hollis Blanchard wrote:
>>>>> On Wednesday 16 April 2008 01:45:34 Liu, Eric E wrote: [...]
>>>>> Actually... we could have kvmtrace itself insert the metadata, so
>>>>> there would be no chance of it being overwritten in the kernel
>>>>> buffers. The header could be written in tip_open_output(), and
>>>>> update fs_size accordingly.
>>>>>
>>>> Yes, let kvmtrace insert the metadata is more reasonable.
>>>>
>>>
>>> I wanted to note that the kvmtrace tool should, but not need to know
>>> everything about the data format.
>>> I think of e.g. changing kernel implementations that change
>>> endianess or even flags we don't yet know, but we might need in the
>>> future.
>>>
>>> What about adding another debugfs entry the kernel can use to expose
>>> the "kvmtrace-metadata" defined by the kernel implementation.
>>> The kvmtrace tool could then use that to build up the record by
>>> using one entry for kernel defined metadata and another to add any
>>> metadata that would be defined by kvmtrace tool itself.
>>>
>>> what about that one:
>>> struct metadata {
>>> u32 kmagic; /* stores kernel defined metadata read from
debugfs
>>> entry */ u32 umagic; /* stores userspace tool defined
metadata */
>>> u32 extra; /* it is redundant, only use to fit into
record. */ }
>>>
>>> That should give us the flexibility to keep the format if we get
>>> more metadata requirements in the future.
>>
>> Yes, maybe we need metadata to indicate the changing kernel
>> implementations in the future, but adding debugfs entry seems not a
>> good approach. What about defining a similar metadat in kernel
>> rather than in userland and write it in rchan at the first time we
>> add trace data. Then we don't need kvmtrace tool to insert the
>> medadata again.
>> like this:
>> struct kvm_trace_metadata {
>> u32 kmagic; /* stores kernel defined metadata */
>> u64 extra; /* use to fit into record. */
>> }
>
> So you've gone back to the idea about the kernel inserting a special
> trace record? How do you handle the case where this record is
> overwritten before the logging app gets a chance to extract it? This
> issue is why I would prefer Christian's idea of a separate debugfs
> file (*not* relay channel) to export kernel flags.
>
Yes, seems my original idea not a good one, I agree with you and
Christian.
> At that point, kvmtrace can insert the flags in any way it wants. It
> doesn't need to appear as a trace record at all; it should simply be
> a header at the beginning of the trace file.
|
|
From: Hollis B. <ho...@us...> - 2008-04-21 21:24:33
|
On Sunday 20 April 2008 00:38:32 Liu, Eric E wrote:
> Christian Ehrhardt wrote:
> > Liu, Eric E wrote:
> >> Hollis Blanchard wrote:
> >>> On Wednesday 16 April 2008 01:45:34 Liu, Eric E wrote: [...]
> >>> Actually... we could have kvmtrace itself insert the metadata, so
> >>> there would be no chance of it being overwritten in the kernel
> >>> buffers. The header could be written in tip_open_output(), and
> >>> update fs_size accordingly.
> >>>
> >> Yes, let kvmtrace insert the metadata is more reasonable.
> >>
> >
> > I wanted to note that the kvmtrace tool should, but not need to know
> > everything about the data format.
> > I think of e.g. changing kernel implementations that change endianess
> > or even flags we don't yet know, but we might need in the future.
> >
> > What about adding another debugfs entry the kernel can use to expose
> > the "kvmtrace-metadata" defined by the kernel implementation.
> > The kvmtrace tool could then use that to build up the record by using
> > one entry for kernel defined metadata and another to add any metadata
> > that would be defined by kvmtrace tool itself.
> >
> > what about that one:
> > struct metadata {
> > u32 kmagic; /* stores kernel defined metadata read from
> debugfs
> > entry */ u32 umagic; /* stores userspace tool defined
> metadata */
> > u32 extra; /* it is redundant, only use to fit into
> record. */
> > }
> >
> > That should give us the flexibility to keep the format if we get more
> > metadata requirements in the future.
>
> Yes, maybe we need metadata to indicate the changing kernel
> implementations in the future, but adding debugfs entry seems not a good
> approach. What about defining a similar metadat in kernel rather than in
> userland and write it in rchan at the first time we add trace data. Then
> we don't need kvmtrace tool to insert the medadata again.
> like this:
> struct kvm_trace_metadata {
> u32 kmagic; /* stores kernel defined metadata */
> u64 extra; /* use to fit into record. */
> }
So you've gone back to the idea about the kernel inserting a special trace
record? How do you handle the case where this record is overwritten before
the logging app gets a chance to extract it? This issue is why I would prefer
Christian's idea of a separate debugfs file (*not* relay channel) to export
kernel flags.
At that point, kvmtrace can insert the flags in any way it wants. It doesn't
need to appear as a trace record at all; it should simply be a header at the
beginning of the trace file.
--
Hollis Blanchard
IBM Linux Technology Center
|
|
From: Avi K. <av...@qu...> - 2008-04-20 07:42:32
|
Hollis Blanchard wrote: Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Avi K. <av...@qu...> - 2008-04-20 07:39:26
|
Hollis Blanchard wrote: > 1 file changed, 5 insertions(+), 6 deletions(-) > arch/powerpc/kvm/Kconfig | 11 +++++------ > > > Don't allow building as a module (asm-offsets dependencies). > > Also, automatically select KVM_BOOKE_HOST until we better separate the guest > and host layers. > > Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
|
From: Liu, E. E <eri...@in...> - 2008-04-20 05:38:34
|
Christian Ehrhardt wrote:
> Liu, Eric E wrote:
>> Hollis Blanchard wrote:
>>> On Wednesday 16 April 2008 01:45:34 Liu, Eric E wrote: [...]
>>> Actually... we could have kvmtrace itself insert the metadata, so
>>> there would be no chance of it being overwritten in the kernel
>>> buffers. The header could be written in tip_open_output(), and
>>> update fs_size accordingly.
>>>
>> Yes, let kvmtrace insert the metadata is more reasonable.
>>
>
> I wanted to note that the kvmtrace tool should, but not need to know
> everything about the data format.
> I think of e.g. changing kernel implementations that change endianess
> or even flags we don't yet know, but we might need in the future.
>
> What about adding another debugfs entry the kernel can use to expose
> the "kvmtrace-metadata" defined by the kernel implementation.
> The kvmtrace tool could then use that to build up the record by using
> one entry for kernel defined metadata and another to add any metadata
> that would be defined by kvmtrace tool itself.
>
> what about that one:
> struct metadata {
> u32 kmagic; /* stores kernel defined metadata read from
debugfs
> entry */ u32 umagic; /* stores userspace tool defined
metadata */
> u32 extra; /* it is redundant, only use to fit into
record. */
> }
>
> That should give us the flexibility to keep the format if we get more
> metadata requirements in the future.
Yes, maybe we need metadata to indicate the changing kernel
implementations in the future, but adding debugfs entry seems not a good
approach. What about defining a similar metadat in kernel rather than in
userland and write it in rchan at the first time we add trace data. Then
we don't need kvmtrace tool to insert the medadata again.
like this:
struct kvm_trace_metadata {
u32 kmagic; /* stores kernel defined metadata */
u64 extra; /* use to fit into record. */
}
|
6 messages has been excluded from this view by a project administrator.
