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
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
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
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
Re: [PATCH 0/5] KVM: PPC: Fix various bugs and vulnerabilities in HV KVM
On 22.11.2012, at 10:24, Paul Mackerras wrote: > This series of patches fixes various bugs that we have found recently. > The bugs fixed in patches 1, 3 and 4 are also vulnerabilities where > the guest could cause the host to crash or could access host memory > inappropriately. The bug fixed in patch 2 could cause the host to > hang or crash after the guest reboots. The bug fixed in patch 5 is a > simple thinko in the recently-added HPT reading code. > > These patches are against Alex Graf's kvm-ppc-next branch. They only > affect HV code. > > The first two patches have been posted previously but got no comments. > > Please apply - given the nature of these bugs I'd really like this > series to make it into the 3.8 merge window. Thanks, applied 2/5 and 5/5 to kvm-ppc-next :) Alex > > Paul. > > arch/powerpc/include/asm/kvm_host.h |5 +- > arch/powerpc/kernel/asm-offsets.c |4 +- > arch/powerpc/kvm/Makefile |1 + > arch/powerpc/kvm/book3s_64_mmu_hv.c | 29 ++-- > arch/powerpc/kvm/book3s_hv.c|9 ++- > arch/powerpc/kvm/book3s_hv_ras.c| 115 ++ > arch/powerpc/kvm/book3s_hv_rm_mmu.c | 59 ++-- > arch/powerpc/kvm/book3s_hv_rmhandlers.S | 117 +-- > 8 files changed, 271 insertions(+), 68 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 -- 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
Re: [PATCH 0/5] Make use of hardware reference and change bits in HPT
On 15.12.2011, at 13:00, Paul Mackerras wrote: > 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. I applied Patches 1-4 to kvm-ppc-next. 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
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: Nathan Froyd [mailto:froy...@codesourcery.com] > Sent: Monday, July 27, 2009 9:14 PM > To: Liu Yu-B13201 > Cc: qemu-de...@nongnu.org; holl...@us.ibm.com; > kvm-ppc@vger.kernel.org; jan.kis...@siemens.com > Subject: 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. > Hmm.. I am not a gdb expert. But even gdb can recognize this pattern, is it safe to skip it? -- 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
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 gdb>6.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]
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 gdb>6.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
Re: [PATCH 0/5] qemu/kvm: Add E500/MPC85xx support
A little description of your patches couldn't hurt. Anyways, you need to send these to qemu-devel... -- Hollis Blanchard IBM Linux Technology Center -- 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
