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: Anthony L. <an...@co...> - 2008-06-24 02:33:44
|
Hollis Blanchard wrote: > On Mon, 2008-06-09 at 11:35 -0500, Anthony Liguori wrote: > >> Jerone Young wrote: >> >>> So upstream qemu is being pervasive about changes with TCG, starting to >>> place tcg only functions in exec.c . I've spun a quick patch that fixes >>> things for PowerPC when building qemu. But we need to try and isolate >>> TCG in upstream qemu as it is starting to leak, and I'm not sure of a >>> good way to fix it as there is no CONFIG defined for tcg currently. >>> >>> Just something to keep in mind. >>> >>> >> Now that TCG supports PPC, shouldn't ya'll be able to drop >> --disable-cpu-emulation. I believe that will simultaneously fix your >> problem and reduce the difference between upstream QEMU. >> > > Unfortunately, dropping --disable-cpu-emulation would create a gcc3 > dependency for us, which would suck. (Qemu still uses dyngen for > PowerPC, and it does still require gcc3.) > But there's always been a GCC3 dependency. --disable-cpu-emulation was working around the breakage caused by TCG's introduction. That's been fixed. Regards, Anthony Liguori |
From: Hollis B. <ho...@us...> - 2008-06-23 20:07:34
|
On Mon, 2008-06-09 at 11:35 -0500, Anthony Liguori wrote: > Jerone Young wrote: > > So upstream qemu is being pervasive about changes with TCG, starting to > > place tcg only functions in exec.c . I've spun a quick patch that fixes > > things for PowerPC when building qemu. But we need to try and isolate > > TCG in upstream qemu as it is starting to leak, and I'm not sure of a > > good way to fix it as there is no CONFIG defined for tcg currently. > > > > Just something to keep in mind. > > > > Now that TCG supports PPC, shouldn't ya'll be able to drop > --disable-cpu-emulation. I believe that will simultaneously fix your > problem and reduce the difference between upstream QEMU. Unfortunately, dropping --disable-cpu-emulation would create a gcc3 dependency for us, which would suck. (Qemu still uses dyngen for PowerPC, and it does still require gcc3.) -- Hollis Blanchard IBM Linux Technology Center |
From: Anthony L. <an...@co...> - 2008-06-09 21:02:27
|
Jerone Young wrote: > Actually I was mistaken. While upstream qemu does compile, after doing a > clean on my local directory of kvm-userspace. I'm finding that after > removing cpu-emulation stuff I get a error when building exec.c > > In file included from /home/jerone/work/kvm-userspace/qemu/tcg/tcg.h:50, > from /home/jerone/work/kvm-userspace/qemu/exec.c:40: > /home/jerone/work/kvm-userspace/qemu/tcg/tcg-opc.h:25:24: dyngen-opc.h: > No such file or directory > dyngen-opc.h is build from op.o. If you removed CONFIG_DYNGEN_OP, op.o won't be added to LIBOBJS which would cause this problem. > Now removing CONFIG_DYNGEN from configure yields more errors ;-). This > is removed for x86 & ia64. > Don't do that. PPC still depends on dyngen. Nothing is wrong with dyngen on PPC, the problem was that TCG didn't support PPC. It does now though. Regards, Anthony Liguori > So lets not remove it till can git this sorted out. But here is a patch > attached to play with :-L > > > On Mon, 2008-06-09 at 11:35 -0500, Anthony Liguori wrote: > >> Jerone Young wrote: >> >>> So upstream qemu is being pervasive about changes with TCG, starting to >>> place tcg only functions in exec.c . I've spun a quick patch that fixes >>> things for PowerPC when building qemu. But we need to try and isolate >>> TCG in upstream qemu as it is starting to leak, and I'm not sure of a >>> good way to fix it as there is no CONFIG defined for tcg currently. >>> >>> Just something to keep in mind. >>> >>> >> Now that TCG supports PPC, shouldn't ya'll be able to drop >> --disable-cpu-emulation. I believe that will simultaneously fix your >> problem and reduce the difference between upstream QEMU. >> >> Regards, >> >> Anthony Liguori >> >> >>> Signed-off-by: Jerone Young <jy...@us...> >>> >>> diff --git a/qemu/Makefile.target b/qemu/Makefile.target >>> --- a/qemu/Makefile.target >>> +++ b/qemu/Makefile.target >>> @@ -196,7 +196,6 @@ LIBOBJS+=fake-exec.o >>> LIBOBJS+=fake-exec.o >>> else >>> LIBOBJS+= translate-all.o translate.o >>> -endif >>> ifdef CONFIG_DYNGEN_OP >>> LIBOBJS+=op.o >>> endif >>> @@ -205,6 +204,7 @@ CPPFLAGS+=-I$(SRC_PATH)/tcg -I$(SRC_PATH >>> CPPFLAGS+=-I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/$(ARCH) >>> ifeq ($(ARCH),sparc64) >>> CPPFLAGS+=-I$(SRC_PATH)/tcg/sparc >>> +endif >>> endif >>> >>> ifeq ($(USE_KVM), 1) >>> diff --git a/qemu/exec.c b/qemu/exec.c >>> --- a/qemu/exec.c >>> +++ b/qemu/exec.c >>> @@ -37,8 +37,11 @@ >>> #include "exec-all.h" >>> #include "qemu-common.h" >>> >>> +#ifdef USE_KVM >>> +#include "qemu-kvm.h" >>> +#else >>> #include "tcg.h" >>> -#include "qemu-kvm.h" >>> +#endif >>> >>> #if defined(CONFIG_USER_ONLY) >>> #include <qemu.h> >>> @@ -3197,7 +3200,9 @@ void dump_exec_info(FILE *f, >>> cpu_fprintf(f, "TB flush count %d\n", tb_flush_count); >>> cpu_fprintf(f, "TB invalidate count %d\n", >>> tb_phys_invalidate_count); >>> cpu_fprintf(f, "TLB flush count %d\n", tlb_flush_count); >>> +#if !defined(USE_KVM) >>> tcg_dump_info(f, cpu_fprintf); >>> +#endif >>> } >>> >>> #if !defined(CONFIG_USER_ONLY) >>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe kvm" in >>> the body of a message to maj...@vg... >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to maj...@vg... >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> |
From: Anthony L. <an...@co...> - 2008-06-09 16:35:38
|
Jerone Young wrote: > So upstream qemu is being pervasive about changes with TCG, starting to > place tcg only functions in exec.c . I've spun a quick patch that fixes > things for PowerPC when building qemu. But we need to try and isolate > TCG in upstream qemu as it is starting to leak, and I'm not sure of a > good way to fix it as there is no CONFIG defined for tcg currently. > > Just something to keep in mind. > Now that TCG supports PPC, shouldn't ya'll be able to drop --disable-cpu-emulation. I believe that will simultaneously fix your problem and reduce the difference between upstream QEMU. Regards, Anthony Liguori > Signed-off-by: Jerone Young <jy...@us...> > > diff --git a/qemu/Makefile.target b/qemu/Makefile.target > --- a/qemu/Makefile.target > +++ b/qemu/Makefile.target > @@ -196,7 +196,6 @@ LIBOBJS+=fake-exec.o > LIBOBJS+=fake-exec.o > else > LIBOBJS+= translate-all.o translate.o > -endif > ifdef CONFIG_DYNGEN_OP > LIBOBJS+=op.o > endif > @@ -205,6 +204,7 @@ CPPFLAGS+=-I$(SRC_PATH)/tcg -I$(SRC_PATH > CPPFLAGS+=-I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/$(ARCH) > ifeq ($(ARCH),sparc64) > CPPFLAGS+=-I$(SRC_PATH)/tcg/sparc > +endif > endif > > ifeq ($(USE_KVM), 1) > diff --git a/qemu/exec.c b/qemu/exec.c > --- a/qemu/exec.c > +++ b/qemu/exec.c > @@ -37,8 +37,11 @@ > #include "exec-all.h" > #include "qemu-common.h" > > +#ifdef USE_KVM > +#include "qemu-kvm.h" > +#else > #include "tcg.h" > -#include "qemu-kvm.h" > +#endif > > #if defined(CONFIG_USER_ONLY) > #include <qemu.h> > @@ -3197,7 +3200,9 @@ void dump_exec_info(FILE *f, > cpu_fprintf(f, "TB flush count %d\n", tb_flush_count); > cpu_fprintf(f, "TB invalidate count %d\n", > tb_phys_invalidate_count); > cpu_fprintf(f, "TLB flush count %d\n", tlb_flush_count); > +#if !defined(USE_KVM) > tcg_dump_info(f, cpu_fprintf); > +#endif > } > > #if !defined(CONFIG_USER_ONLY) > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > |
From: Avi K. <av...@qu...> - 2008-06-09 16:14:58
|
Jerone Young wrote: > So upstream qemu is being pervasive about changes with TCG, starting to > place tcg only functions in exec.c . I've spun a quick patch that fixes > things for PowerPC when building qemu. But we need to try and isolate > TCG in upstream qemu as it is starting to leak, and I'm not sure of a > good way to fix it as there is no CONFIG defined for tcg currently. > > > ifeq ($(USE_KVM), 1) > diff --git a/qemu/exec.c b/qemu/exec.c > --- a/qemu/exec.c > +++ b/qemu/exec.c > @@ -37,8 +37,11 @@ > #include "exec-all.h" > #include "qemu-common.h" > > +#ifdef USE_KVM > +#include "qemu-kvm.h" > +#else > #include "tcg.h" > -#include "qemu-kvm.h" > +#endif > We want to keep the ability to have both emulation (-no-kvm) and virtualization, at least for x86, so let's keep tcg.h includable. > > #if defined(CONFIG_USER_ONLY) > #include <qemu.h> > @@ -3197,7 +3200,9 @@ void dump_exec_info(FILE *f, > cpu_fprintf(f, "TB flush count %d\n", tb_flush_count); > cpu_fprintf(f, "TB invalidate count %d\n", > tb_phys_invalidate_count); > cpu_fprintf(f, "TLB flush count %d\n", tlb_flush_count); > +#if !defined(USE_KVM) > tcg_dump_info(f, cpu_fprintf); > +#endif > } > > How about #define tcg_dump_info(x, y) (void)0 in some strategic spot? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
From: Jan K. <jan...@we...> - 2008-05-16 07:43:47
|
Jan Kiszka wrote: > Avi Kivity wrote: >> [I forgot to do this last weekend, so it's postponed to Saturday] >> >> During the upcoming Saturday, the various kvm lists will move to >> vger.kenel.org. This will improve responsiveness, and reduce spam and >> advertising. >> >> Please subscribe to the lists you are interested in as soon as >> possible. You can subscribe by sending an email to >> maj...@vg..., with the following lines in the body: >> >> subscribe kvm >> subscribe kvm-commits >> subscribe kvm-ia64 >> subscribe kvm-ppc > > Will someone take care of creating new gmane.org archives at the same > time, too? I'm relying on their news services for high-traffic lists > like kvm's. (Which means, if nobody does, I would do. Later, I'll "just" need the mbox archives in order to feed-in all postings up to the subscription time.) Jan |
From: Jan K. <jan...@we...> - 2008-05-16 07:34:56
|
Avi Kivity wrote: > [I forgot to do this last weekend, so it's postponed to Saturday] > > During the upcoming Saturday, the various kvm lists will move to > vger.kenel.org. This will improve responsiveness, and reduce spam and > advertising. > > Please subscribe to the lists you are interested in as soon as > possible. You can subscribe by sending an email to > maj...@vg..., with the following lines in the body: > > subscribe kvm > subscribe kvm-commits > subscribe kvm-ia64 > subscribe kvm-ppc Will someone take care of creating new gmane.org archives at the same time, too? I'm relying on their news services for high-traffic lists like kvm's. Thanks, Jan |
From: Tan, L. <li...@in...> - 2008-05-16 06:26:50
|
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. */ } seems umagic and extra are no need now. I guess they were designed as record pad to keep the format of trace log transparent to kvmtrace_format, but now kvmtrace_format has to know the format: the first record is metadata So I’ll change to struct metadata { u32 kmagic; /* stores kernel defined metadata */ } Tan Li -----Original Message----- From: Tan, Li Sent: 2008年5月15日 9:20 To: 'Hollis Blanchard' Cc: kvm-devel; kvm...@li... Subject: RE: kvm trace support for ppc -----Original Message----- From: Hollis Blanchard [mailto:ho...@us...] Sent: 2008年5月15日 5:37 To: Tan, Li Cc: kvm-devel; kvm...@li... Subject: Re: kvm trace support for ppc On Tuesday 13 May 2008 03:06:19 Tan, Li wrote: > Hollisb, > I have 2 more questions: > 1. seems record won't be overwritten because current code is as following: > /* > * The relay channel is used in "no-overwrite" mode, it keeps trace of how > * many times we encountered a full subbuffer, to tell user space app the > * lost records there were. > */ > static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf, > void *prev_subbuf, size_t prev_padding) > { > struct kvm_trace *kt; > > if (!relay_buf_full(buf)) > return 1; > > kt = buf->chan->private_data; > atomic_inc(&kt->lost_records); > > return 0; > } > > 2. Then needn't expose debugfs entry "kvmtrace-metadata", we can use existing relayfs to output struct metadata with kmagic, if we update code as following? > static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf, > void *prev_subbuf, size_t prev_padding) > { > struct kvm_trace *kt; > > if (!relay_buf_full(buf)) > { > if (!prev_subbuf) { > //here is executed only once (when the channel is opened) > subbuf_start_reserve(buf, sizeof(struct metadata)); > ((struct metadata *)subbuf)->kmagic = 0x1234; > } > > return 1; > } > > kt = buf->chan->private_data; > atomic_inc(&kt->lost_records); > > return 0; > } Ah, I didn't understand what the "lost records" handling was about. Given that it won't be lost, it would be OK for the kernel to export the header, and in that case I guess you would want it to be the same size as the other records. I'm not sure how I feel about that from a layering point of view, but at least it would be functional. [tan] The relay channel is used in "no-overwrite" mode, so it will lost any new items if encounters a full subbuffer, "lost records" is to count lost records. Yes, metadata is the same size as the other records. This solution needn't change kvmtrace user app, only need to change kvmtrace_format.pl like following: if i == 1: line = sys.stdin.read(struct.calcsize(HDRREC)) (kmgc, umgc, mgcpad) = struct.unpack(HDRREC, line) if kmgc == 0x1234: rev = False else: rev = True continue # If i > 1: line = sys.stdin.read(struct.calcsize(HDRREC)) (event, pid, vcpu_id) = struct.unpack(HDRREC, line) ... if rev: event = reverse_int(event) pid = reverse_int(pid) vcpu_id = reverse_int(vcpu_id) tsc = reverse_qword(tsc) d1 = reverse_int(d1) d2 = reverse_int(d2) d3 = reverse_int(d3) d4 = reverse_int(d4) d5 = reverse_int(d5) -- Hollis Blanchard IBM Linux Technology Center |
From: Tan, L. <li...@in...> - 2008-05-15 01:22:03
|
-----Original Message----- From: Hollis Blanchard [mailto:ho...@us...] Sent: 2008年5月15日 5:37 To: Tan, Li Cc: kvm-devel; kvm...@li... Subject: Re: kvm trace support for ppc On Tuesday 13 May 2008 03:06:19 Tan, Li wrote: > Hollisb, > I have 2 more questions: > 1. seems record won't be overwritten because current code is as following: > /* > * The relay channel is used in "no-overwrite" mode, it keeps trace of how > * many times we encountered a full subbuffer, to tell user space app the > * lost records there were. > */ > static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf, > void *prev_subbuf, size_t prev_padding) > { > struct kvm_trace *kt; > > if (!relay_buf_full(buf)) > return 1; > > kt = buf->chan->private_data; > atomic_inc(&kt->lost_records); > > return 0; > } > > 2. Then needn't expose debugfs entry "kvmtrace-metadata", we can use existing relayfs to output struct metadata with kmagic, if we update code as following? > static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf, > void *prev_subbuf, size_t prev_padding) > { > struct kvm_trace *kt; > > if (!relay_buf_full(buf)) > { > if (!prev_subbuf) { > //here is executed only once (when the channel is opened) > subbuf_start_reserve(buf, sizeof(struct metadata)); > ((struct metadata *)subbuf)->kmagic = 0x1234; > } > > return 1; > } > > kt = buf->chan->private_data; > atomic_inc(&kt->lost_records); > > return 0; > } Ah, I didn't understand what the "lost records" handling was about. Given that it won't be lost, it would be OK for the kernel to export the header, and in that case I guess you would want it to be the same size as the other records. I'm not sure how I feel about that from a layering point of view, but at least it would be functional. [tan] The relay channel is used in "no-overwrite" mode, so it will lost any new items if encounters a full subbuffer, "lost records" is to count lost records. Yes, metadata is the same size as the other records. This solution needn't change kvmtrace user app, only need to change kvmtrace_format.pl like following: if i == 1: line = sys.stdin.read(struct.calcsize(HDRREC)) (kmgc, umgc, mgcpad) = struct.unpack(HDRREC, line) if kmgc == 0x1234: rev = False else: rev = True continue # If i > 1: line = sys.stdin.read(struct.calcsize(HDRREC)) (event, pid, vcpu_id) = struct.unpack(HDRREC, line) ... if rev: event = reverse_int(event) pid = reverse_int(pid) vcpu_id = reverse_int(vcpu_id) tsc = reverse_qword(tsc) d1 = reverse_int(d1) d2 = reverse_int(d2) d3 = reverse_int(d3) d4 = reverse_int(d4) d5 = reverse_int(d5) -- Hollis Blanchard IBM Linux Technology Center |
From: Hollis B. <ho...@us...> - 2008-05-14 21:37:05
|
On Tuesday 13 May 2008 03:06:19 Tan, Li wrote: > Hollisb, > I have 2 more questions: > 1. seems record won't be overwritten because current code is as following: > /* > * The relay channel is used in "no-overwrite" mode, it keeps trace of how > * many times we encountered a full subbuffer, to tell user space app the > * lost records there were. > */ > static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf, > void *prev_subbuf, size_t prev_padding) > { > struct kvm_trace *kt; > > if (!relay_buf_full(buf)) > return 1; > > kt = buf->chan->private_data; > atomic_inc(&kt->lost_records); > > return 0; > } > > 2. Then needn't expose debugfs entry "kvmtrace-metadata", we can use existing relayfs to output struct metadata with kmagic, if we update code as following? > static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf, > void *prev_subbuf, size_t prev_padding) > { > struct kvm_trace *kt; > > if (!relay_buf_full(buf)) > { > if (!prev_subbuf) { > //here is executed only once (when the channel is opened) > subbuf_start_reserve(buf, sizeof(struct metadata)); > ((struct metadata *)subbuf)->kmagic = 0x1234; > } > > return 1; > } > > kt = buf->chan->private_data; > atomic_inc(&kt->lost_records); > > return 0; > } Ah, I didn't understand what the "lost records" handling was about. Given that it won't be lost, it would be OK for the kernel to export the header, and in that case I guess you would want it to be the same size as the other records. I'm not sure how I feel about that from a layering point of view, but at least it would be functional. -- Hollis Blanchard IBM Linux Technology Center |
From: Hollis B. <ho...@us...> - 2008-05-14 21:15:55
|
On Wednesday 14 May 2008 16:11:39 Hollis Blanchard wrote: > On Wednesday 14 May 2008 16:06:00 Hollis Blanchard wrote: > > In > > fact, in the case of soft breakpoints, KVM doesn't even know where all the > > set breakpoints are. > > Side note: I'm retract this sentence: I wrote it before I sketched out the > pseudocode, and forgot to remove it. :) Er no, let me try that again: In my proposed design, the stub needs to know where all breakpoints are, HW or SW. (That means it must implement Z0/Z1.) However, KVM itself doesn't need to know any of that: all breakpoints are referred to the stub for handling, and the stub will notify KVM if further action is needed in-kernel. -- Hollis Blanchard IBM Linux Technology Center |
From: Hollis B. <ho...@us...> - 2008-05-14 21:12:20
|
On Wednesday 14 May 2008 16:06:00 Hollis Blanchard wrote: > In > fact, in the case of soft breakpoints, KVM doesn't even know where all the > set breakpoints are. Side note: I'm retract this sentence: I wrote it before I sketched out the pseudocode, and forgot to remove it. :) -- Hollis Blanchard IBM Linux Technology Center |
From: Hollis B. <ho...@us...> - 2008-05-14 21:06:18
|
On Wednesday 14 May 2008 14:49:02 Jan Kiszka wrote: > > In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would > > just need to see if that address is for a breakpoint Qemu set or not. If so, > > it's happy. If not, (commence handwaving) tell KVM to forward the debug > > interrupt to the guest. This way, the list of breakpoints is maintained in > > userspace (in the qemu gdb stub), which is nice because it could be > > arbitrarily large. > > Yes, but I would rather pass the debug registers (more general: some > arch dependent state set) back in this slot. Those contain everything > the gdbstub needs to know to catch relevant hardware-BP/watchpoint > events (and report them to the gdb frontend). But what would the stub *do* with the contents of the debug registers? The only reason they were set is on behalf of the stub in the first place. In fact, in the case of soft breakpoints, KVM doesn't even know where all the set breakpoints are. The only thing KVM needs to report is the address of the breakpoint that was just hit. Sorry if this gets formatted badly: gdb qemu stub KVM break *0xf00 sends Z0 packet 0xf00 0xf00 -> BP list ioctl(KVM_DEBUG, 0xf00) continue ioctl(KVM_RUN) running... breakpoint hit exit_reason = KVM_EXIT_DEBUG kvm_run.debug.address = current PC value search BP list for address bp hit <--- present not present ---> send debug interrupt to guest Notes: - KVM_DEBUG in this case will set a hardware breakpoint. The alternative is to write an int3 into guest memory. - The stub doesn't care how the hardware registers were configured. All it needs to know is a) that a breakpoint was hit, and b) at what address. Does this make sense? -- Hollis Blanchard IBM Linux Technology Center |
From: Jan K. <jan...@we...> - 2008-05-14 19:50:09
|
Hollis Blanchard wrote: > On Wednesday 14 May 2008 14:10:06 Jan Kiszka wrote: >> Hollis Blanchard wrote: >>> On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: >>>> So gdb on power relies only on those few hw-breakpoints? With x86 you >>>> can perfectly run gdb (with soft BPs) in parallel with the gdbstub >>>> (currently based on hw-BPs, but the same would be true for soft-BPs >>>> inserted by the gdbstub). >>> GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. > It >>> does not rely on the hardware breakpoints. >>> >>> It gets a little more complicated when you involve a GDB stub. IIRC, GDB > will >>> ask the stub to set the breakpoint, and if the stub doesn't support it, > GDB >>> will fall back to overwriting the instructions in memory. Does the Qemu > GDB >>> stub advertise breakpoint support? >> Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something >> even gdbserver does not do! It just handles watchpoints (Z2..4). >> >>> If not, the only support needed in KVM would be to send all debug > interrupts >>> to qemu, and allow qemu to send them back down for in-guest breakpoints. >>> >> Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's >> kernel side should not yet inform QEMU about soft-BP exceptions. But in >> theory, this should be easily fixable (or is already the case for other >> archs). And it would safe us from keeping track of N software >> breakpoints, where N could even become larger than 32, the current >> hardcoded limit for plain QEMU. :) >> >> Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is >> insufficient: We need a return channel for the debug register state >> (specifically to figure out details about hit watchpoints). I'm now >> favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us >> to write _and_ read-back the suggested data structure. > > How about simply extending kvm_exit.debug to contain the virtual address of > the breakpoint hit? Ah, there is an interface for such stuff already! And it can even take quite some payload... > In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would > just need to see if that address is for a breakpoint Qemu set or not. If so, > it's happy. If not, (commence handwaving) tell KVM to forward the debug > interrupt to the guest. This way, the list of breakpoints is maintained in > userspace (in the qemu gdb stub), which is nice because it could be > arbitrarily large. Yes, but I would rather pass the debug registers (more general: some arch dependent state set) back in this slot. Those contain everything the gdbstub needs to know to catch relevant hardware-BP/watchpoint events (and report them to the gdb frontend). > > Also, this is not specific to hardware debug registers: soft and hard > breakpoint interrupts would follow the same path. There's still a question of > whether the GDB stub should set the breakpoint itself (Z0/Z1) or force GDB to > modify memory, but either way the KVM code is simple. Only rejecting Z0 will enable us to avoid any soft-BP tracking in qemu-kvm, and that is definitely my plan. Z1 may become an option to add later on and would be answered as "unsupported" for now. Jan |
From: Hollis B. <ho...@us...> - 2008-05-14 19:37:01
|
On Wednesday 14 May 2008 14:10:06 Jan Kiszka wrote: > Hollis Blanchard wrote: > > On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: > >> So gdb on power relies only on those few hw-breakpoints? With x86 you > >> can perfectly run gdb (with soft BPs) in parallel with the gdbstub > >> (currently based on hw-BPs, but the same would be true for soft-BPs > >> inserted by the gdbstub). > > > > GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It > > does not rely on the hardware breakpoints. > > > > It gets a little more complicated when you involve a GDB stub. IIRC, GDB will > > ask the stub to set the breakpoint, and if the stub doesn't support it, GDB > > will fall back to overwriting the instructions in memory. Does the Qemu GDB > > stub advertise breakpoint support? > > Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something > even gdbserver does not do! It just handles watchpoints (Z2..4). > > > > > If not, the only support needed in KVM would be to send all debug interrupts > > to qemu, and allow qemu to send them back down for in-guest breakpoints. > > > > Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's > kernel side should not yet inform QEMU about soft-BP exceptions. But in > theory, this should be easily fixable (or is already the case for other > archs). And it would safe us from keeping track of N software > breakpoints, where N could even become larger than 32, the current > hardcoded limit for plain QEMU. :) > > Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is > insufficient: We need a return channel for the debug register state > (specifically to figure out details about hit watchpoints). I'm now > favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us > to write _and_ read-back the suggested data structure. How about simply extending kvm_exit.debug to contain the virtual address of the breakpoint hit? In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would just need to see if that address is for a breakpoint Qemu set or not. If so, it's happy. If not, (commence handwaving) tell KVM to forward the debug interrupt to the guest. This way, the list of breakpoints is maintained in userspace (in the qemu gdb stub), which is nice because it could be arbitrarily large. Also, this is not specific to hardware debug registers: soft and hard breakpoint interrupts would follow the same path. There's still a question of whether the GDB stub should set the breakpoint itself (Z0/Z1) or force GDB to modify memory, but either way the KVM code is simple. -- Hollis Blanchard IBM Linux Technology Center |
From: Jan K. <jan...@we...> - 2008-05-14 19:10:11
|
Hollis Blanchard wrote: > On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: >> So gdb on power relies only on those few hw-breakpoints? With x86 you >> can perfectly run gdb (with soft BPs) in parallel with the gdbstub >> (currently based on hw-BPs, but the same would be true for soft-BPs >> inserted by the gdbstub). > > GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It > does not rely on the hardware breakpoints. > > It gets a little more complicated when you involve a GDB stub. IIRC, GDB will > ask the stub to set the breakpoint, and if the stub doesn't support it, GDB > will fall back to overwriting the instructions in memory. Does the Qemu GDB > stub advertise breakpoint support? Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something even gdbserver does not do! It just handles watchpoints (Z2..4). > > If not, the only support needed in KVM would be to send all debug interrupts > to qemu, and allow qemu to send them back down for in-guest breakpoints. > Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's kernel side should not yet inform QEMU about soft-BP exceptions. But in theory, this should be easily fixable (or is already the case for other archs). And it would safe us from keeping track of N software breakpoints, where N could even become larger than 32, the current hardcoded limit for plain QEMU. :) Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is insufficient: We need a return channel for the debug register state (specifically to figure out details about hit watchpoints). I'm now favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us to write _and_ read-back the suggested data structure. Jan |
From: Hollis B. <ho...@us...> - 2008-05-14 18:27:07
|
On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: > So gdb on power relies only on those few hw-breakpoints? With x86 you > can perfectly run gdb (with soft BPs) in parallel with the gdbstub > (currently based on hw-BPs, but the same would be true for soft-BPs > inserted by the gdbstub). GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It does not rely on the hardware breakpoints. It gets a little more complicated when you involve a GDB stub. IIRC, GDB will ask the stub to set the breakpoint, and if the stub doesn't support it, GDB will fall back to overwriting the instructions in memory. Does the Qemu GDB stub advertise breakpoint support? If not, the only support needed in KVM would be to send all debug interrupts to qemu, and allow qemu to send them back down for in-guest breakpoints. -- Hollis Blanchard IBM Linux Technology Center |
From: Avi K. <av...@qu...> - 2008-05-14 09:39:18
|
[I forgot to do this last weekend, so it's postponed to Saturday] During the upcoming Saturday, the various kvm lists will move to vger.kenel.org. This will improve responsiveness, and reduce spam and advertising. Please subscribe to the lists you are interested in as soon as possible. You can subscribe by sending an email to maj...@vg..., with the following lines in the body: subscribe kvm subscribe kvm-commits subscribe kvm-ia64 subscribe kvm-ppc Of course, omit lines for the lists you are not interested in. Majordomo will then send further instructions. Thanks to the vger admins for hosting the kvm lists. -- Any sufficiently difficult bug is indistinguishable from a feature. |
From: Avi K. <av...@qu...> - 2008-05-13 16:25:32
|
If you haven't already, please sign up for KVM Developer's Forum 2008. The final agenda (now boasting twenty presentations) has been posted at: http://kforum.qumranet.com/KVMForum/agenda.php Registration details are at: http://kforum.qumranet.com/KVMForum/register_now.php -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-05-06 15:11:07
|
Jerone Young wrote: > These patches fell through the cracks. > Unfortunately, the cracks are getting wider. Anyway, applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
From: Hollis B. <ho...@us...> - 2008-05-05 18:00:44
|
On Monday 05 May 2008 11:04:52 Jerone Young wrote: > These patches fell through the cracks. > > This set of patches fixes setting memory for PowerPC bamboo board model. Besides just setting memory in qemu, you must also set it in the device tree. This sets the memory in the device tree so that it can be something other then the hard coded memory size of 144MB. > > Signed-off-by: Jerone Young <jy...@us...> Acked-by: Hollis Blanchard <ho...@us...> Avi, please apply to kvm-userspace; thanks. -- Hollis Blanchard IBM Linux Technology Center |
From: Jerone Y. <jy...@us...> - 2008-05-05 16:07:39
|
# HG changeset patch # User Jerone Young <jy...@us...> # Date 1210003411 18000 # Branch merge # Node ID c455452c9b217abed8a2e6147bbeb91f33ff1799 # Parent cf3ccc3add69052aade695c746151b1cb8812252 Fix memory defined in device tree by declaring it dynamically for bamboo board model This fixes a issue where the amount of memory is not properly being defined in the device tree. It currently is hardcoded for 144MB. The result is that if you specify a memory size below the hardcoded size, the guest crashes. This patch now dynamically changes the device tree to the memory value specified. Signed-off-by: Jerone Young <jy...@us...> diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c --- a/qemu/hw/ppc440_bamboo.c +++ b/qemu/hw/ppc440_bamboo.c @@ -50,6 +50,7 @@ void bamboo_init(ram_addr_t ram_size, in int i=0, k=0; uint32_t cpu_freq; uint32_t timebase_freq; + uint32_t mem_reg_property[]={0, 0, ram_size}; printf("%s: START\n", __func__); @@ -73,6 +74,7 @@ void bamboo_init(ram_addr_t ram_size, in printf("WARNING: %i MB left over memory is ram\n", bytes_to_mb((int)tmp_ram_size)); ram_size -= tmp_ram_size; + mem_reg_property[2] = ram_size; } /* Setup CPU */ @@ -159,6 +161,8 @@ void bamboo_init(ram_addr_t ram_size, in /* manipulate device tree in memory */ dt_cell(fdt, "/cpus/cpu@0", "clock-frequency", cpu_freq); dt_cell(fdt, "/cpus/cpu@0", "timebase-frequency", timebase_freq); + dt_cell_multi(fdt, "/memory", "reg", mem_reg_property, + sizeof(mem_reg_property)); dt_cell(fdt, "/chosen", "linux,initrd-start", initrd_base); dt_cell(fdt, "/chosen", "linux,initrd-end", (initrd_base + initrd_size)); |
From: Jerone Y. <jy...@us...> - 2008-05-05 16:07:35
|
# HG changeset patch # User Jerone Young <jy...@us...> # Date 1210003408 18000 # Branch merge # Node ID cf3ccc3add69052aade695c746151b1cb8812252 # Parent 97e439fdd4e91c3fb1ef9055f073add55084d69f Add function dt_cell_multi to hw/device_tree.c This patch adds function dt_cell_multi to allow for manipulation of device tree properties that contain mulitiple 32bit values. Signed-off-by: Jerone Young <jy...@us...> diff --git a/qemu/hw/device_tree.c b/qemu/hw/device_tree.c --- a/qemu/hw/device_tree.c +++ b/qemu/hw/device_tree.c @@ -162,6 +162,21 @@ void dt_cell(void *fdt, char *node_path, } } +/* This function is to manipulate a cell with multiple values */ +void dt_cell_multi(void *fdt, char *node_path, char *property, + uint32_t *val_array, int size) +{ + int offset; + int ret; + offset = get_offset_of_node(fdt, node_path); + ret = fdt_setprop(fdt, offset, property, val_array, size); + if (ret < 0) { + printf("Unable to set device tree property '%s'\n", + property); + exit(1); + } +} + void dt_string(void *fdt, char *node_path, char *property, char *string) { diff --git a/qemu/hw/device_tree.h b/qemu/hw/device_tree.h --- a/qemu/hw/device_tree.h +++ b/qemu/hw/device_tree.h @@ -19,6 +19,8 @@ void dump_device_tree_to_file(void *fdt, void dump_device_tree_to_file(void *fdt, char *filename); void dt_cell(void *fdt, char *node_path, char *property, uint32_t val); +void dt_cell_multi(void *fdt, char *node_path, char *property, + uint32_t *val_array, int size); void dt_string(void *fdt, char *node_path, char *property, char *string); void dt_node(void *fdt, char *node_parent_path, char *name); |
From: Jerone Y. <jy...@us...> - 2008-05-05 16:07:28
|
These patches fell through the cracks. This set of patches fixes setting memory for PowerPC bamboo board model. Besides just setting memory in qemu, you must also set it in the device tree. This sets the memory in the device tree so that it can be something other then the hard coded memory size of 144MB. Signed-off-by: Jerone Young <jy...@us...> |
From: Avi K. <av...@qu...> - 2008-05-04 08:17:14
|
Hollis Blanchard wrote: > Avi, please apply these patches to the kvm-userspace repository. I've submitted > the device emulation patches (UIC and PCI) to qemu-devel, but have received no > response. > > Applied all, thanks. > Thinking ahead to qemu integration, many of these should be folded into a > single "Bamboo board" patch, but e.g. the device emulation patches are > logically separate. Do you track qemu patches for upstream integration like > you do for the kernel? Do you want me to keep these split-out patches locally? > Unsplitting them later would be a pain... > It's better to keep the patches split. As you point out, folding patches together is easy but splitting them later is hard. I don't keep a qemu patch queue; whether to take patches from kvm-userspace.git or rediff against upstream qemu is a decision that is best taken on a case-by-case basis, if and when qemu upstream becomes receptive to these patches. -- error compiling committee.c: too many arguments to function |