Re: [PATCH 0/5] PPC: Current patch queue for HV KVM
On 24.06.15 13:18, Paul Mackerras wrote: This is my current queue of patches for HV KVM. This series is based on the kvm next branch. They have all been posted 6 weeks ago or more, though I have just added a 3-line fix to patch 2/5 to fix a bug that we found in testing migration, and I expanded a comment (no code change) in patch 3/5 following a suggestion by Aneesh. I'd like to see these go into 4.2 if possible. Thanks, applied all to kvm-ppc-queue. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] PPC: Current patch queue for HV KVM
This is my current queue of patches for HV KVM. This series is based on the kvm next branch. They have all been posted 6 weeks ago or more, though I have just added a 3-line fix to patch 2/5 to fix a bug that we found in testing migration, and I expanded a comment (no code change) in patch 3/5 following a suggestion by Aneesh. I'd like to see these go into 4.2 if possible. Paul. --- arch/powerpc/include/asm/kvm_book3s.h | 1 + arch/powerpc/include/asm/kvm_book3s_asm.h | 20 + arch/powerpc/include/asm/kvm_host.h | 24 +- arch/powerpc/kernel/asm-offsets.c | 9 + arch/powerpc/kvm/book3s_64_mmu_hv.c | 8 +- arch/powerpc/kvm/book3s_hv.c | 648 ++ arch/powerpc/kvm/book3s_hv_builtin.c | 32 +- arch/powerpc/kvm/book3s_hv_rm_mmu.c | 161 +++- arch/powerpc/kvm/book3s_hv_rm_xics.c | 4 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 122 +- 10 files changed, 906 insertions(+), 123 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Fixes and improvements for HV KVM on PPC
On 03.12.14 03:30, Paul Mackerras wrote: This series of patches is based on Alex Graf's kvm-ppc-queue branch and is intended for the 3.19 merge window. It starts by removing the code to support HV KVM on PPC970 processors. This code is hardly used now since there are not many HV-capable PPC970 machines (Apple G5 machines are not HV-capable) and POWER8 systems capable of running HV KVM are generally available now. Then there is a fix for a potential endianness problem, an improvement for the existing H_CONFER implementation, a real-mode H_RANDOM implementation, and a small Kconfig change. None of these should be controversial with the possible exception of H_RANDOM - but now that userspace has full control over whether the H_RANDOM handler is active or not (via the KVM_CAP_PPC_ENABLE_HCALL capability) it will hopefully be controversial no longer. Thanks, applied all to kvm-ppc-queue. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Fixes and improvements for HV KVM on PPC
This series of patches is based on Alex Graf's kvm-ppc-queue branch and is intended for the 3.19 merge window. It starts by removing the code to support HV KVM on PPC970 processors. This code is hardly used now since there are not many HV-capable PPC970 machines (Apple G5 machines are not HV-capable) and POWER8 systems capable of running HV KVM are generally available now. Then there is a fix for a potential endianness problem, an improvement for the existing H_CONFER implementation, a real-mode H_RANDOM implementation, and a small Kconfig change. None of these should be controversial with the possible exception of H_RANDOM - but now that userspace has full control over whether the H_RANDOM handler is active or not (via the KVM_CAP_PPC_ENABLE_HCALL capability) it will hopefully be controversial no longer. Thanks, Paul. Documentation/virtual/kvm/api.txt| 17 ++ arch/powerpc/include/asm/archrandom.h| 11 +- arch/powerpc/include/asm/kvm_book3s.h| 2 - arch/powerpc/include/asm/kvm_book3s_64.h | 1 - arch/powerpc/include/asm/kvm_host.h | 17 +- arch/powerpc/include/asm/kvm_ppc.h | 4 +- arch/powerpc/kernel/asm-offsets.c| 2 +- arch/powerpc/kvm/Kconfig | 1 + arch/powerpc/kvm/book3s_64_mmu_hv.c | 200 ++--- arch/powerpc/kvm/book3s_hv.c | 337 ++-- arch/powerpc/kvm/book3s_hv_builtin.c | 151 + arch/powerpc/kvm/book3s_hv_interrupts.S | 39 +--- arch/powerpc/kvm/book3s_hv_ras.c | 5 +- arch/powerpc/kvm/book3s_hv_rm_mmu.c | 110 ++ arch/powerpc/kvm/book3s_hv_rmhandlers.S | 366 +++ arch/powerpc/kvm/powerpc.c | 13 +- arch/powerpc/platforms/powernv/rng.c | 25 +++ include/uapi/linux/kvm.h | 1 + 18 files changed, 341 insertions(+), 961 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Some fixes for HV KVM on PPC
On 03.11.14 05:51, Paul Mackerras wrote: Here are fixes for five bugs which were found in the testing of our PowerKVM product. The bugs range from guest performance issues to guest crashes and memory corruption. Please apply. Thanks, applied patches 1-4 to kvm-ppc-queue. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Some fixes for HV KVM on PPC
Here are fixes for five bugs which were found in the testing of our PowerKVM product. The bugs range from guest performance issues to guest crashes and memory corruption. Please apply. Paul. --- arch/powerpc/include/asm/kvm_book3s_64.h | 2 +- arch/powerpc/kvm/book3s_hv.c | 22 arch/powerpc/kvm/book3s_hv_rm_mmu.c | 44 arch/powerpc/kvm/book3s_hv_rm_xics.c | 36 -- arch/powerpc/kvm/book3s_xics.c | 30 +- arch/powerpc/kvm/book3s_xics.h | 1 + 6 files changed, 92 insertions(+), 43 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5 v2] Guest debug emulation
This patchset adds debug register and interrupt emulation support for guest, which enables running gdb/kgdb etc in guest. Bharat Bhushan (5): KVM: PPC: BOOKE: allow debug interrupt at debug level KVM: PPC: BOOKE : Emulate rfdi instruction KVM: PPC: BOOKE: Allow guest to change MSR_DE KVM: PPC: BOOKE: Clear guest dbsr in userspace exit KVM_EXIT_DEBUG KVM: PPC: BOOKE: Emulate debug registers and exception arch/powerpc/include/asm/kvm_host.h | 1 + arch/powerpc/include/asm/kvm_ppc.h | 3 + arch/powerpc/include/asm/reg_booke.h | 2 + arch/powerpc/kvm/booke.c | 50 ++- arch/powerpc/kvm/booke_emulate.c | 170 +++ arch/powerpc/kvm/e500mc.c| 2 +- 6 files changed, 226 insertions(+), 2 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] Improve PPC instruction emulation
On 19.07.14 12:14, Paul Mackerras wrote: This series aims to increase the range of instructions that KVM on PPC can emulate and reduce code duplication by using the existing instruction emulation code from arch/powerpc/lib/sstep.c for KVM. The ultimate goal is to make PR KVM run faster on the kind of instruction sequences that we get in Linux's first-level interrupt handlers, where we have privileged instructions such as move to/from SPR, mtmsrd, rfid, etc., intermingled with ordinary unprivileged loads, stores, arithmetic instructions, etc. If KVM could emulate those ordinary instructions as well as the privileged ones, we could emulate these code sequences without incurring the cost to exit and re-enter the guest for every single privileged instruction. That would be a speedup provided the guest entry/exit cost was greater than the cost of emulating a few ordinary instructions. This series doesn't get to that ultimate goal but does lay the groundwork. It splits the emulate_step() function into two parts, analyse_instr() and emulate_step(), and uses analyse_instr() in kvmppc_emulate_instruction(). This means that KVM needs to store its vcpu integer register state in a struct pt_regs like the rest of the kernel does. We also need to make kvmppc_handle_load() and kvmppc_handle_store() handle loads and stores to ordinary guest memory as well as emulated MMIO. Please take a look at my other patch set that implemented instruction emulation. There we split the code paths between MMIO emulation and normal instruction emulation. I really think that approach is a prerequisite to doing full instruction emulation in longer code snippets. Obviously the generic load/store should then handle MMIO as well as generic memory operations. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/5] Improve PPC instruction emulation
This series aims to increase the range of instructions that KVM on PPC can emulate and reduce code duplication by using the existing instruction emulation code from arch/powerpc/lib/sstep.c for KVM. The ultimate goal is to make PR KVM run faster on the kind of instruction sequences that we get in Linux's first-level interrupt handlers, where we have privileged instructions such as move to/from SPR, mtmsrd, rfid, etc., intermingled with ordinary unprivileged loads, stores, arithmetic instructions, etc. If KVM could emulate those ordinary instructions as well as the privileged ones, we could emulate these code sequences without incurring the cost to exit and re-enter the guest for every single privileged instruction. That would be a speedup provided the guest entry/exit cost was greater than the cost of emulating a few ordinary instructions. This series doesn't get to that ultimate goal but does lay the groundwork. It splits the emulate_step() function into two parts, analyse_instr() and emulate_step(), and uses analyse_instr() in kvmppc_emulate_instruction(). This means that KVM needs to store its vcpu integer register state in a struct pt_regs like the rest of the kernel does. We also need to make kvmppc_handle_load() and kvmppc_handle_store() handle loads and stores to ordinary guest memory as well as emulated MMIO. I have tested this series by running a Fedora 20 PR guest inside a HV guest on POWER7. The series is against Alex Graf's kvm-ppc-queue branch, plus the 3 bug-fix patches I just posted, and a bug-fix entitled powerpc: Fix bugs in emulate_step() that I posted to the linuxppc-dev list. Paul. -- arch/powerpc/include/asm/kvm_book3s.h| 24 +- arch/powerpc/include/asm/kvm_booke.h | 24 +- arch/powerpc/include/asm/kvm_host.h | 22 +- arch/powerpc/include/asm/kvm_ppc.h | 21 +- arch/powerpc/include/asm/sstep.h | 62 ++ arch/powerpc/kernel/asm-offsets.c| 32 +- arch/powerpc/kvm/Makefile| 1 + arch/powerpc/kvm/book3s_32_mmu.c | 2 +- arch/powerpc/kvm/book3s_64_mmu_hv.c | 10 +- arch/powerpc/kvm/book3s_64_vio_hv.c | 2 +- arch/powerpc/kvm/book3s_emulate.c| 22 +- arch/powerpc/kvm/book3s_hv.c | 42 +- arch/powerpc/kvm/book3s_hv_rm_mmu.c | 10 +- arch/powerpc/kvm/book3s_hv_rm_xics.c | 2 +- arch/powerpc/kvm/book3s_paired_singles.c | 121 +--- arch/powerpc/kvm/book3s_pr.c | 88 +-- arch/powerpc/kvm/booke.c | 45 +- arch/powerpc/kvm/booke_emulate.c | 12 +- arch/powerpc/kvm/e500_mmu.c | 2 +- arch/powerpc/kvm/emulate.c | 318 -- arch/powerpc/kvm/powerpc.c | 148 +++-- arch/powerpc/lib/sstep.c | 987 --- 22 files changed, 1093 insertions(+), 904 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5 v4] Read guest last instruction from kvmppc_get_last_inst()
Read guest last instruction from kvmppc_get_last_inst() allowing the function to fail in order to emulate again. On bookehv architecture search for the physical address and kmap it, instead of using Load External PID (lwepx) instruction. This fixes an infinite loop caused by lwepx's data TLB miss exception handled in the host and the TODO for execute-but-not-read entries and TLB eviction. Mihai Caraman (5): KVM: PPC: e500mc: Revert add load inst fixup KVM: PPC: Book3e: Add TLBSEL/TSIZE defines for MAS0/1 KVM: PPC: Book3s: Remove kvmppc_read_inst() function KVM: PPC: Alow kvmppc_get_last_inst() to fail KVM: PPC: Bookehv: Get vcpu's last instruction for emulation arch/powerpc/include/asm/kvm_book3s.h| 26 --- arch/powerpc/include/asm/kvm_booke.h | 5 -- arch/powerpc/include/asm/kvm_ppc.h | 24 +++ arch/powerpc/include/asm/mmu-book3e.h| 7 +- arch/powerpc/kvm/book3s.c| 11 +++ arch/powerpc/kvm/book3s_64_mmu_hv.c | 17 ++--- arch/powerpc/kvm/book3s_paired_singles.c | 38 ++ arch/powerpc/kvm/book3s_pr.c | 116 +-- arch/powerpc/kvm/booke.c | 47 + arch/powerpc/kvm/bookehv_interrupts.S| 55 ++- arch/powerpc/kvm/e500_mmu_host.c | 97 ++ arch/powerpc/kvm/emulate.c | 18 +++-- arch/powerpc/kvm/powerpc.c | 10 ++- 13 files changed, 302 insertions(+), 169 deletions(-) -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] powerpc: implement reset/shutdown hcalls
From: Bharat Bhushan bharat.bhus...@freescale.com This patchset implements the hcall exit interface to userspace. Also we added reset and shutdown hcall Bharat Bhushan (5): powerpc: define ePAPR hcall exit interface booke: exit to guest userspace for unimplemented hcalls in kvm booke: define reset and shutdown hcalls powerpc: Resolve KVM_HC_FEATURES compilation dependeny powerpc: using reset hcall when kvm,has-reset Documentation/virtual/kvm/api.txt| 20 Documentation/virtual/kvm/hypercalls.txt | 16 ++ arch/powerpc/include/asm/kvm_para.h |1 + arch/powerpc/kernel/epapr_paravirt.c | 12 +++ arch/powerpc/kvm/booke.c | 47 + arch/powerpc/kvm/powerpc.c |1 + include/uapi/linux/kvm.h |8 + include/uapi/linux/kvm_para.h|3 +- 8 files changed, 100 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Some fixes and improvements for PR KVM
On 22.06.2013, at 09:12, Paul Mackerras wrote: This series of 5 patches is against the KVM next branch. It fixes some bugs in PR-style KVM on Book 3S PPC and adds support for the guest using 1TB segments as well as 256MB segments. My ultimate goal is to make it possible to configure both HV and PR KVM into the same kernel binary, and this is just the first few steps. Thanks, applied all except 4/5 to kvm-ppc-queue. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] KVM: PPC: e500: Enable FSL e6500 core
Enable Freescale e6500 core adding missing MAV 2.0 support. LRAT and Page Table are not addresses by this commit. Mihai Caraman (5): KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier KVM: PPC: e500: Emulate TLBnPS registers KVM: PPC: e500: Remove E.PT category from VCPUs KVM: PPC: e500: Emulate EPTCFG register KVM: PPC: e500mc: Enable e6500 cores arch/powerpc/include/asm/kvm_host.h |2 ++ arch/powerpc/kvm/e500.h | 11 +++ arch/powerpc/kvm/e500_emulate.c | 19 +++ arch/powerpc/kvm/e500_mmu.c | 24 ++-- arch/powerpc/kvm/e500mc.c |2 ++ 5 files changed, 52 insertions(+), 6 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] KVM: PPC: Book3S HV: HPT read/write functions for userspace
This series of patches provides an interface by which userspace can read and write the hashed page table (HPT) of a Book3S HV guest. The interface is an ioctl which provides a file descriptor which can be accessed with the read() and write() system calls. The data read and written is the guest view of the HPT, in which the second doubleword of each HPTE (HPT entry) contains a guest physical address, as distinct from the real HPT that the hardware accesses, where the second doubleword of each HPTE contains a real address. Because the HPT is divided into groups (HPTEGs) of 8 entries each, where each HPTEG usually only contains a few valid entries, or none, the data format that we use does run-length encoding of the invalid entries, so in fact the invalid entries take up no space in the stream. The interface also provides for doing multiple passes over the HPT, where the first pass provides information on all HPTEs, and subsequent passes only return the HPTEs that have changed since the previous pass. I have implemented a read/write interface rather than an mmap-based interface because the data is not stored contiguously anywhere in kernel memory. Of each 16-byte HPTE, the first 8 bytes come from the real HPT and the second 8 bytes come from the parallel vmalloc'd array where we store the guest view of the guest physical address, permissions, accessed/dirty bits etc. Thus a mmap-based interface would not be practicable (not without doubling the size of the parallel array, typically requiring an extra 8MB of kernel memory per guest). This is also why I have not used the memslot interface for this. This implements the interface for HV-style KVM but not for PR-style KVM. Userspace does not need any additional interface with PR-style KVM because userspace maintains the guest HPT already in that case, and has an image of the guest view of the HPT in its address space. This series is against the next branch of the kvm tree plus my recently-posted set of 8 patches (Various Book3s HV fixes that haven't been picked up yet). The overall diffstat is: Documentation/virtual/kvm/api.txt| 53 + arch/powerpc/include/asm/kvm.h | 24 ++ arch/powerpc/include/asm/kvm_book3s.h|8 +- arch/powerpc/include/asm/kvm_book3s_64.h | 24 ++ arch/powerpc/include/asm/kvm_host.h |1 + arch/powerpc/include/asm/kvm_ppc.h |2 + arch/powerpc/kvm/book3s_64_mmu_hv.c | 380 +- arch/powerpc/kvm/book3s_hv.c | 12 - arch/powerpc/kvm/book3s_hv_rm_mmu.c | 71 -- arch/powerpc/kvm/powerpc.c | 17 ++ include/linux/kvm.h |3 + include/linux/kvm_host.h | 11 +- 12 files changed, 559 insertions(+), 47 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Improve memory slot handling and other fixes
On 06.08.2012, at 12:02, Paul Mackerras wrote: This series of 5 patches starts off with two fixes that I have posted previously but not got any response to, and then has 3 patches to improve our handling of memory slots on PPC. The first of those 3 makes HV-style KVM able to handle deletion and modification of memory slots properly. The second one adds proper SRCU read-locking around accesses to memslot data for HV KVM, and the third adds SRCU read-locking around accesses to memslot data for the other styles of KVM on PPC. These patches are against Avi's next branch as of today. Thanks, applied 1/5 and 2/5 to kvm-ppc-next. The others are still subject of discussions :) Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] KVM: PPC: E500: Implement MMU Notifiers
This patch set adds a very simple implementation of MMU notifiers for the e500 target. Along the way, I stumbled over a few other things that I've put into the same patch set, namely: * support remote vcpu requests * hva_to_memslot helper function * icache flushing on page map * additional trace points v1 - v2: - remove patches that are already merged into kvm-ppc-next - split up mmu notifier patch - remove hva_to_memslot - add trace points - change icache flush method to be in arch/powerpc - make request checks preemptible Alexander Graf (5): KVM: PPC: BookE: Add check_requests helper function KVM: PPC: BookE: Add support for vcpu-mode KVM: PPC: E500: Implement MMU notifiers KVM: PPC: Add cache flush on page map KVM: PPC: BookE: Add some more trace points arch/powerpc/include/asm/kvm_host.h |4 +- arch/powerpc/include/asm/kvm_ppc.h| 13 ++ arch/powerpc/kvm/Kconfig |2 + arch/powerpc/kvm/book3s_32_mmu_host.c |3 + arch/powerpc/kvm/book3s_64_mmu_host.c |2 + arch/powerpc/kvm/booke.c | 44 +--- arch/powerpc/kvm/e500_tlb.c | 66 +++--- arch/powerpc/kvm/trace.h | 71 + arch/powerpc/mm/mem.c |1 + 9 files changed, 192 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Improve memory slot handling and other fixes
This series of 5 patches starts off with two fixes that I have posted previously but not got any response to, and then has 3 patches to improve our handling of memory slots on PPC. The first of those 3 makes HV-style KVM able to handle deletion and modification of memory slots properly. The second one adds proper SRCU read-locking around accesses to memslot data for HV KVM, and the third adds SRCU read-locking around accesses to memslot data for the other styles of KVM on PPC. These patches are against Avi's next branch as of today. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Make use of hardware reference and change bits in HPT
This series of patches builds on top of my previous series and modifies the Book3S HV memory management code to use the hardware reference and change bits in the guest hashed page table. This makes kvm_age_hva() more efficient, lets us implement the dirty page tracking properly (which in turn means that things like VGA emulation in qemu can work), and also means that we can supply hardware reference and change information to the guest -- not that Linux guests currently use that information, but possibly they will want it in future, and there is an interface defined in PAPR for it. Paul. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5]
On Tue, Jul 28, 2009 at 04:11:57PM +0800, Liu Yu-B13201 wrote: On Sat, Jul 25, 2009 at 04:40:12PM +0800, Liu Yu wrote: For example booke has a code template for jumping to and returning from interrupt handlers: bl transfer .long handler_addr .long ret_addr when call transfer, it never return but in transfer assembly code it will read the handler_addr and ultimately call the handler. Gdb doesn't know that and treat it as a normal function call. so gdb put a software breakpoint instruction at handler_addr, in order to get trap there when return from transfer. Then guest will read software breakpoint as handler_addr and jump to there.. I'm not sure if x86 suffer this kind of issue. Is there any way to avoid this? You would need to modify GDB to recognize this sort of case with the skip_trampoline_code gdbarch method. Hmm.. I am not a gdb expert. But even gdb can recognize this pattern, is it safe to skip it? The code doesn't get skipped. skip_trampoline_code is a hook for telling GDB this function doesn't return in the normal way: here's where execution will resume once this function finishes. That way GDB can place the software breakpoint in the correct location: in this case, at the address handler_addr. -Nathan -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5]
-Original Message- From: jan.kis...@web.de [mailto:jan.kis...@web.de] Sent: Saturday, July 25, 2009 6:44 PM To: Liu Yu-B13201 Cc: qemu-devel; Hollis Blanchard; kvm-ppc; Nathan Froyd Subject: Re: [PATCH 0/5] Liu Yu wrote: 2. gdb 'watch' command Jan told me gdb6.8 can issue hardware watchpoint request via command 'watch', my gdb is 6.8.50.20080821-cvs and our toolchain provider confirm that it supports hardware watch However when I use 'watch', I can only see single step from gdbstub side. Did I miss anything? Did you install a watchpoint on a symbol? If yes, try if placing one on an absolute address changes the picture. Cool, it did use hardware watch when I used absolute address. Seems I need to test more. :) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5]
On Sat, Jul 25, 2009 at 04:40:12PM +0800, Liu Yu wrote: For example booke has a code template for jumping to and returning from interrupt handlers: bl transfer .long handler_addr .long ret_addr when call transfer, it never return but in transfer assembly code it will read the handler_addr and ultimately call the handler. Gdb doesn't know that and treat it as a normal function call. so gdb put a software breakpoint instruction at handler_addr, in order to get trap there when return from transfer. Then guest will read software breakpoint as handler_addr and jump to there.. I'm not sure if x86 suffer this kind of issue. Is there any way to avoid this? You would need to modify GDB to recognize this sort of case with the skip_trampoline_code gdbarch method. -Nathan -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5]
The whole patchset includes: patch 1: fix kvmppc build error patch 2: fix kvmppc init error patch 3~5: add kvmppc guest debug support The guest debug still have some problems I haven't solved. 1. gdb 'next' command uses software breakpoint software breakpoint is implemented via modify guest's code. In most case it works well, but when used by 'next' it's easy to make trouble on powerpc booke. For example booke has a code template for jumping to and returning from interrupt handlers: bl transfer .long handler_addr .long ret_addr when call transfer, it never return but in transfer assembly code it will read the handler_addr and ultimately call the handler. Gdb doesn't know that and treat it as a normal function call. so gdb put a software breakpoint instruction at handler_addr, in order to get trap there when return from transfer. Then guest will read software breakpoint as handler_addr and jump to there.. I'm not sure if x86 suffer this kind of issue. Is there any way to avoid this? 2. gdb 'watch' command Jan told me gdb6.8 can issue hardware watchpoint request via command 'watch', my gdb is 6.8.50.20080821-cvs and our toolchain provider confirm that it supports hardware watch However when I use 'watch', I can only see single step from gdbstub side. Did I miss anything? -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5]
Liu Yu wrote: The whole patchset includes: patch 1: fix kvmppc build error patch 2: fix kvmppc init error patch 3~5: add kvmppc guest debug support The guest debug still have some problems I haven't solved. 1. gdb 'next' command uses software breakpoint software breakpoint is implemented via modify guest's code. In most case it works well, but when used by 'next' it's easy to make trouble on powerpc booke. For example booke has a code template for jumping to and returning from interrupt handlers: bl transfer .long handler_addr .long ret_addr when call transfer, it never return but in transfer assembly code it will read the handler_addr and ultimately call the handler. Gdb doesn't know that and treat it as a normal function call. so gdb put a software breakpoint instruction at handler_addr, in order to get trap there when return from transfer. Then guest will read software breakpoint as handler_addr and jump to there.. I'm not sure if x86 suffer this kind of issue. It would if it had such a pattern. Is there any way to avoid this? Unless there is a mechanism via the debug infos of a binary to tell gdb about this, I think one can only avoid it by not using next here. 2. gdb 'watch' command Jan told me gdb6.8 can issue hardware watchpoint request via command 'watch', my gdb is 6.8.50.20080821-cvs and our toolchain provider confirm that it supports hardware watch However when I use 'watch', I can only see single step from gdbstub side. Did I miss anything? Did you install a watchpoint on a symbol? If yes, try if placing one on an absolute address changes the picture. Frankly, I didn't understand gdb's logic for selecting soft or hard watchpoints so far. Soft watchpoints are those you saw: single step to the program, checking after each step if the watched variable has changed. In theory it should be clear when to use which. But practice appears to be non-deterministic, at least with the versions we recently tried on x86. Jan signature.asc Description: OpenPGP digital signature
