Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 02.09.2009, at 07:40, Benjamin Herrenschmidt wrote: On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote: KVM for PowerPC only supports embedded cores at the moment. While it makes sense to virtualize on small machines, it's even more fun to do so on big boxes. So I figured we need KVM for PowerPC64 as well. This patchset implements KVM support for Book3s_64 hosts and guest support for Book3s_64 and G3/G4. To really make use of this, you will also need a modified version of qemu that can deal with KVM on desktop cores. I will send out patches for those later, but want to get feedback on the kernel side first. In the meanwhile, use the qemu version from http://www.powerkvm.org/powerkvm.git which already includes all required patches to run G3/G4 and G5 guests. The git pull request is good when the series is good to pull or for testing, but for review patches are nice :-) Ok, guess I'll go back to sending patches in the future then ;-). So I never got enough time to look into too much details so far (I'm still up for a little walkthrough on IRC one of these days btw) but I did look at the changes to the powerpc core code and they look ok to me. The only thing I couldn't quite figure out is why you are adding exports for mm_alloc() and switch_slb(). Well, we need mm_alloc to reserve a VA range. And since that happens in module code, it needs to be exported. As far as switch_slb goes, I think with the new always switch the full SLB in entry/exit code logic, that's not required anymore. I spotted tons of stuff that could be optimized Yes. It might also be worth collecting all the potential optimizations on some wiki, so if someone feels like jumping in on this project, he knows where to start. It'd even be good for us, because I always tend to forget where exactly the code is the worst :-). , especially in the interrupt handling (but then, we all agree that using a magic page is going to be much better) The interrupt handling is a separate beast that should be handled more generically, but the current code works for KVM at least. Let's take baby steps here. , and I suppose we need to have a close look at some aspects of the MMU emulation. I fully agree. The MMU emulation could probably also get quite some speedups. For the first version I merely wanted to have something that boots and runs Linux. But for now, I'm happy with the merge, feel free to add my Acked-by, just make sure it's marked CONFIG_EXPERIMENTAL. It definitely is experimental still, so yes, I agree. Should I send out a v4 that removes the slb_switch export and marks things as experimental? 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
Well, we need mm_alloc to reserve a VA range. And since that happens in module code, it needs to be exported. Hrm... I've missed where you call it. Can't you directly allocate a context ID instead of a whole mm ? As far as switch_slb goes, I think with the new always switch the full SLB in entry/exit code logic, that's not required anymore. Ok. In general, I'd rather keep the KVM SLB switching separate from the normal one since there's different constraints anyways. Should I send out a v4 that removes the slb_switch export and marks things as experimental? Please, and add my Acks. Pls dbl check the need for mm_alloc() though. Cheers, Ben. -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 02.09.2009, at 08:23, Benjamin Herrenschmidt wrote: Well, we need mm_alloc to reserve a VA range. And since that happens in module code, it needs to be exported. Hrm... I've missed where you call it. Can't you directly allocate a context ID instead of a whole mm ? It's in the vcpu init code: ./book3s.c:862: vcpu-arch.mm_guest = mm_alloc(); And the mm_alloc() call was the closest I could find to only allocate a context ID. I didn't really want to change too much code in there unless I really have to and it seems like mm_alloc doesn't have that much overhead. As far as switch_slb goes, I think with the new always switch the full SLB in entry/exit code logic, that's not required anymore. Ok. In general, I'd rather keep the KVM SLB switching separate from the normal one since there's different constraints anyways. Yes, that's why we're at v3 already :-). Should I send out a v4 that removes the slb_switch export and marks things as experimental? Please, and add my Acks. Pls dbl check the need for mm_alloc() though. I'm open for suggestions on how to get a context_id easily/cleanly without exporting mm_alloc. 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On Wed, 2009-09-02 at 08:34 +0200, Alexander Graf wrote: On 02.09.2009, at 08:23, Benjamin Herrenschmidt wrote: Well, we need mm_alloc to reserve a VA range. And since that happens in module code, it needs to be exported. Hrm... I've missed where you call it. Can't you directly allocate a context ID instead of a whole mm ? It's in the vcpu init code: ./book3s.c:862: vcpu-arch.mm_guest = mm_alloc(); And the mm_alloc() call was the closest I could find to only allocate a context ID. I didn't really want to change too much code in there unless I really have to and it seems like mm_alloc doesn't have that much overhead. I'm open for suggestions on how to get a context_id easily/cleanly without exporting mm_alloc. I see ... init_new_context() and destroy_context() only operate on an mm_struct... Well, in that case, I'm open to something that would change those two to __init_new_context() and __destroy_conext() that respectively return the new ID and take an ID as an argument, which you can export, and have static inlines in mmu-context.h that implement init_new_context() and destroy_context() in terms of the above. Cheers, Ben. -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On Wed, 2009-09-02 at 15:40 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote: KVM for PowerPC only supports embedded cores at the moment. While it makes sense to virtualize on small machines, it's even more fun to do so on big boxes. So I figured we need KVM for PowerPC64 as well. This patchset implements KVM support for Book3s_64 hosts and guest support for Book3s_64 and G3/G4. To really make use of this, you will also need a modified version of qemu that can deal with KVM on desktop cores. I will send out patches for those later, but want to get feedback on the kernel side first. In the meanwhile, use the qemu version from http://www.powerkvm.org/powerkvm.git which already includes all required patches to run G3/G4 and G5 guests. The git pull request is good when the series is good to pull or for testing, but for review patches are nice :-) Yeah, I actually went looking for the v3 patchset last week, and gave up trying to extract it from git... -- 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
Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote: KVM for PowerPC only supports embedded cores at the moment. While it makes sense to virtualize on small machines, it's even more fun to do so on big boxes. So I figured we need KVM for PowerPC64 as well. This patchset implements KVM support for Book3s_64 hosts and guest support for Book3s_64 and G3/G4. To really make use of this, you will also need a modified version of qemu that can deal with KVM on desktop cores. I will send out patches for those later, but want to get feedback on the kernel side first. In the meanwhile, use the qemu version from http://www.powerkvm.org/powerkvm.git which already includes all required patches to run G3/G4 and G5 guests. The git pull request is good when the series is good to pull or for testing, but for review patches are nice :-) So I never got enough time to look into too much details so far (I'm still up for a little walkthrough on IRC one of these days btw) but I did look at the changes to the powerpc core code and they look ok to me. The only thing I couldn't quite figure out is why you are adding exports for mm_alloc() and switch_slb(). I spotted tons of stuff that could be optimized, especially in the interrupt handling (but then, we all agree that using a magic page is going to be much better), and I suppose we need to have a close look at some aspects of the MMU emulation. But for now, I'm happy with the merge, feel free to add my Acked-by, just make sure it's marked CONFIG_EXPERIMENTAL. Avi, are you taking care of it from here ? Cheers, Ben. To not spam on everyone on the list, I figured I'd send this as a git pull request this time. If I did anything wrong, please tell me :-). V1 - V2: - extend sregs with padding - new naming scheme (ppc64 - book3s_64; 74xx - book3s_32) - to_phys - in-kernel tophys() - loadimm - LOAD_REG_IMMEDIATE - call .ko kvm.ko - set magic paca bit later - run guest code with PACA-soft_enabled=true - pt_regs for host state saving (guest too?) - only do HV dcbz trick on 970 - refuse to run on LPAR because of missing SLB pieces V2 - V3: - fix DAR/DSISR saving - allow running on LPAR by modifying the SLB shadow - change the SLB implementation to use a mem-backed cache and do full world switch on enter/exit. gets rid of context magic - be more aggressive about DEC injection - remove fast ld/st because we're always in host context - don't use SPRGs in real-paged transition - implement dirty log - remove MMIO speedup code - SPRG cleanup - rename SPRG3 - SPRN_SPRG_PACA - rename SPRG1 - SPRN_SPRG_SCRATCH0 - don't use SPRG2 TODO: - use MMU Notifiers - use u64* for dirty log The following changes since commit 84a3c0818fe9d7a1e34c188d6182793f213a6a66: Gleb Natapov (1): KVM: Reduce runnability interface with arch support code are available in the git repository at: git://csgraf.de/kvm ppc-v3 Alexander Graf (25): Move dirty logging code to sub-arch Pass PVR in sregs Add Book3s definitions Add Book3s fields to vcpu structs Add asm/kvm_book3s.h Add Book3s_64 intercept helpers Add book3s_64 highmem asm code Add SLB switching code for entry/exit Add interrupt handling code Add book3s.c Add book3s_64 Host MMU handling Add book3s_64 guest MMU Add book3s_32 guest MMU Add book3s_64 specific opcode emulation Add mfdec emulation Add desktop PowerPC specific emulation Make head_64.S aware of KVM real mode code Add Book3s_64 offsets to asm-offsets.c Export symbols for KVM module Export KVM symbols for module Add fields to PACA Export new PACA constants in asm-offsets Include Book3s_64 target in buildsystem Fix trace.h Enable 32bit dirty log pointers on 64bit host arch/powerpc/include/asm/exception.h |2 + arch/powerpc/include/asm/kvm.h |2 + arch/powerpc/include/asm/kvm_asm.h | 49 ++ arch/powerpc/include/asm/kvm_book3s.h| 135 arch/powerpc/include/asm/kvm_book3s_64_asm.h | 58 ++ arch/powerpc/include/asm/kvm_host.h | 76 +++- arch/powerpc/include/asm/kvm_ppc.h |1 + arch/powerpc/include/asm/paca.h |9 + arch/powerpc/kernel/asm-offsets.c| 18 + arch/powerpc/kernel/exceptions-64s.S |8 + arch/powerpc/kernel/head_64.S|6 + arch/powerpc/kernel/ppc_ksyms.c |3 +- arch/powerpc/kernel/time.c |1 + arch/powerpc/kvm/Kconfig | 17 + arch/powerpc/kvm/Makefile| 27 +- arch/powerpc/kvm/book3s.c| 919 ++ arch/powerpc/kvm/book3s_32_mmu.c | 354 ++ arch/powerpc/kvm/book3s_64_emulate.c | 338
Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 07/28/2009 02:43 AM, Benjamin Herrenschmidt wrote: On Mon, 2009-07-27 at 12:04 -0700, Hollis Blanchard wrote: The way I've done this in the past is to get acks from PPC maintainers, and then push the patches through Avi. If a generic PPC patch is required by a KVM patch, pushing them through different trees would leave KVM broken for weeks until it all ends up merged in Linus's tree. Despite Ben's newfound interest in KVM, I don't see a good reason to change this model. :) Depends how invasive the powerpc bits are. I'll figure something out. Yes. If they are invasive, the best way is to carry the non-kvm changes in both trees, and for me to push after you (I'll omit the duplicates when pushing). -- error compiling committee.c: too many arguments to function -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 07/26/2009 11:47 PM, Alexander Graf wrote: When we just interpret the bitmap as u64* do we break 32 on 64 x86? If not, that makes it work for 32 on 64 ppc, because the kernel is always 64. No. little-endian is insensitive to the word size for bitops. -- error compiling committee.c: too many arguments to function -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 07/24/2009 07:30 PM, Alexander Graf wrote: KVM for PowerPC only supports embedded cores at the moment. While it makes sense to virtualize on small machines, it's even more fun to do so on big boxes. So I figured we need KVM for PowerPC64 as well. This patchset implements KVM support for Book3s_64 hosts and guest support for Book3s_64 and G3/G4. To really make use of this, you will also need a modified version of qemu that can deal with KVM on desktop cores. I will send out patches for those later, but want to get feedback on the kernel side first. In the meanwhile, use the qemu version from http://www.powerkvm.org/powerkvm.git which already includes all required patches to run G3/G4 and G5 guests. To not spam on everyone on the list, I figured I'd send this as a git pull request this time. If I did anything wrong, please tell me :-). I will need some acks from ppc people. Obviously for the non-kvm bits, but also for the kvm bits as I am not qualified to review ppc code. - use MMU Notifiers What's the plan here? - use u64* for dirty log Is this a userspace interface issue? if so it will need to be addressed before merging. -- error compiling committee.c: too many arguments to function -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 07/26/2009 02:55 PM, Alexander Graf wrote: I will need some acks from ppc people. Obviously for the non-kvm bits, but also for the kvm bits as I am not qualified to review ppc code. Right, FWIW Ben would actually even prefer to take the whole thing in his tree. That's likely to cause conflicts if some kvm API changes and needs modifications to this code. Perhaps the best option is for the non-kvm changes to go through the ppc tree, and for me to duplicate (but not push) them. - use MMU Notifiers What's the plan here? Implement MMU Notifiers as soon as I fully understand them? :-) I'm aware of the basic concept, but the callbacks still seem somewhat magical to me. Ask and I'll do my best to answer. - use u64* for dirty log Is this a userspace interface issue? if so it will need to be addressed before merging. Yes, on big endian having a 64-bit kernel and 32-bit userspace breaks when dirty log is ulong*. Nobody saw this until now, because it's not a big deal on little endian. I sent a patch doing the qemu side of things already, but haven't went through the kvm bits yet. Basically we can't use set_bit and test_bit for the dirty log, because they require us to have the bitmap as ulong*. Yuck. What do we do? Implement set_bit_u64() and friends? -- error compiling committee.c: too many arguments to function -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 26.07.2009, at 14:10, Avi Kivity wrote: On 07/26/2009 02:55 PM, Alexander Graf wrote: I will need some acks from ppc people. Obviously for the non-kvm bits, but also for the kvm bits as I am not qualified to review ppc code. Right, FWIW Ben would actually even prefer to take the whole thing in his tree. That's likely to cause conflicts if some kvm API changes and needs modifications to this code. Perhaps the best option is for the non- kvm changes to go through the ppc tree, and for me to duplicate (but not push) them. I agree, but that's for you two to decide I guess :-). Let's just wait for Ben to wake up. - use MMU Notifiers What's the plan here? Implement MMU Notifiers as soon as I fully understand them? :-) I'm aware of the basic concept, but the callbacks still seem somewhat magical to me. Ask and I'll do my best to answer. Cool, next week :-). The current version works fine without. And I need a weekend for a change :-D. - use u64* for dirty log Is this a userspace interface issue? if so it will need to be addressed before merging. Yes, on big endian having a 64-bit kernel and 32-bit userspace breaks when dirty log is ulong*. Nobody saw this until now, because it's not a big deal on little endian. I sent a patch doing the qemu side of things already, but haven't went through the kvm bits yet. Basically we can't use set_bit and test_bit for the dirty log, because they require us to have the bitmap as ulong*. Yuck. What do we do? Implement set_bit_u64() and friends? That's what I'd think we should do, yes. For qemu I sent a patch that always uses uint64_t because that works fine with the current code (32-bit on 64-bit uses the right bytes for LE, 64-bit on 64-bit doesn't change). PPC is not implement yet for anyone either and for now we only have dirty logging with 64 bit kernels and 32-bit or 64-bit userspace, so that's fine too. As soon as someone implement dirty logging on a 32-bit big endian target, it will break though, so before that day comes we need to change set_bit to set_bit_64. 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 07/26/2009 03:26 PM, Alexander Graf wrote: Cool, next week :-). The current version works fine without. And I need a weekend for a change :-D. Having returned from a 10-day weekend, I can only recommend this. Yuck. What do we do? Implement set_bit_u64() and friends? That's what I'd think we should do, yes. For qemu I sent a patch that always uses uint64_t because that works fine with the current code (32-bit on 64-bit uses the right bytes for LE, 64-bit on 64-bit doesn't change). PPC is not implement yet for anyone either and for now we only have dirty logging with 64 bit kernels and 32-bit or 64-bit userspace, so that's fine too. As soon as someone implement dirty logging on a 32-bit big endian target, it will break though, so before that day comes we need to change set_bit to set_bit_64. Perhaps we can get away with disabling 32-on-64 for the configurations that break to start with. -- error compiling committee.c: too many arguments to function -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 26.07.2009, at 14:46, Avi Kivity wrote: On 07/26/2009 03:26 PM, Alexander Graf wrote: Cool, next week :-). The current version works fine without. And I need a weekend for a change :-D. Having returned from a 10-day weekend, I can only recommend this. Hope you had fun and didn't read too much mail :-). Yuck. What do we do? Implement set_bit_u64() and friends? That's what I'd think we should do, yes. For qemu I sent a patch that always uses uint64_t because that works fine with the current code (32-bit on 64-bit uses the right bytes for LE, 64-bit on 64-bit doesn't change). PPC is not implement yet for anyone either and for now we only have dirty logging with 64 bit kernels and 32-bit or 64-bit userspace, so that's fine too. As soon as someone implement dirty logging on a 32-bit big endian target, it will break though, so before that day comes we need to change set_bit to set_bit_64. Perhaps we can get away with disabling 32-on-64 for the configurations that break to start with. 32-on-64 only breaks for big endian which nobody except for this target implements. Since my PPC enabling patches for qemu change the type to uint64_t always, nobody is broken right now. 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 07/26/2009 03:46 PM, Alexander Graf wrote: On 26.07.2009, at 14:46, Avi Kivity wrote: On 07/26/2009 03:26 PM, Alexander Graf wrote: Cool, next week :-). The current version works fine without. And I need a weekend for a change :-D. Having returned from a 10-day weekend, I can only recommend this. Hope you had fun and didn't read too much mail :-). I didn't read _any_ email. Perhaps we can get away with disabling 32-on-64 for the configurations that break to start with. 32-on-64 only breaks for big endian which nobody except for this target implements. Since my PPC enabling patches for qemu change the type to uint64_t always, nobody is broken right now. That assumes you implement set_bit_u64(), no? -- error compiling committee.c: too many arguments to function -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 26.07.2009, at 14:56, Avi Kivity wrote: On 07/26/2009 03:46 PM, Alexander Graf wrote: On 26.07.2009, at 14:46, Avi Kivity wrote: On 07/26/2009 03:26 PM, Alexander Graf wrote: Cool, next week :-). The current version works fine without. And I need a weekend for a change :-D. Having returned from a 10-day weekend, I can only recommend this. Hope you had fun and didn't read too much mail :-). I didn't read _any_ email. Perhaps we can get away with disabling 32-on-64 for the configurations that break to start with. 32-on-64 only breaks for big endian which nobody except for this target implements. Since my PPC enabling patches for qemu change the type to uint64_t always, nobody is broken right now. That assumes you implement set_bit_u64(), no? No, little endian works as-is :-). -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
Am 26.07.2009 um 14:54 schrieb Alexander Graf ag...@suse.de: On 26.07.2009, at 14:56, Avi Kivity wrote: On 07/26/2009 03:46 PM, Alexander Graf wrote: On 26.07.2009, at 14:46, Avi Kivity wrote: On 07/26/2009 03:26 PM, Alexander Graf wrote: Cool, next week :-). The current version works fine without. And I need a weekend for a change :-D. Having returned from a 10-day weekend, I can only recommend this. Hope you had fun and didn't read too much mail :-). I didn't read _any_ email. Perhaps we can get away with disabling 32-on-64 for the configurations that break to start with. 32-on-64 only breaks for big endian which nobody except for this target implements. Since my PPC enabling patches for qemu change the type to uint64_t always, nobody is broken right now. That assumes you implement set_bit_u64(), no? No, little endian works as-is :-). Let me rephrase: It shouldn't if I understand little endian correctly :). I haven't actually verified that 32 on 64 doesn't break. But then again that's a rather uncommon configuration for x86 anyways, but really common on ppc. 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On 07/26/2009 08:25 PM, Alexander Graf wrote: Perhaps we can get away with disabling 32-on-64 for the configurations that break to start with. 32-on-64 only breaks for big endian which nobody except for this target implements. Since my PPC enabling patches for qemu change the type to uint64_t always, nobody is broken right now. That assumes you implement set_bit_u64(), no? No, little endian works as-is :-). Let me rephrase: It shouldn't if I understand little endian correctly :). I haven't actually verified that 32 on 64 doesn't break. But then again that's a rather uncommon configuration for x86 anyways, but really common on ppc. I meant disable 32-on-64 ppc. 32-on-64 x86 is supported and works (though it is rare). Given that you say 32-on-64 ppc is common, it could only be a short term fix until we implemlement u64 bitops. Alternatively we can mangle the bitmap when copying it to userspace. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
Am 26.07.2009 um 19:53 schrieb Avi Kivity a...@redhat.com: On 07/26/2009 08:25 PM, Alexander Graf wrote: Perhaps we can get away with disabling 32-on-64 for the configurations that break to start with. 32-on-64 only breaks for big endian which nobody except for this target implements. Since my PPC enabling patches for qemu change the type to uint64_t always, nobody is broken right now. That assumes you implement set_bit_u64(), no? No, little endian works as-is :-). Let me rephrase: It shouldn't if I understand little endian correctly :). I haven't actually verified that 32 on 64 doesn't break. But then again that's a rather uncommon configuration for x86 anyways, but really common on ppc. I meant disable 32-on-64 ppc. 32-on-64 x86 is supported and works (though it is rare). Given that you say 32-on-64 ppc is common, it could only be a short term fix until we implemlement u64 bitops. Alternatively we can mangle the bitmap when copying it to userspace. When we just interpret the bitmap as u64* do we break 32 on 64 x86? If not, that makes it work for 32 on 64 ppc, because the kernel is always 64. 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On Sun, 2009-07-26 at 15:10 +0300, Avi Kivity wrote: Yuck. What do we do? Implement set_bit_u64() and friends? We may be able to hijack some of the filesystem ones... those are used for on-disk format so should fit the bill Cheers, Ben. -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On Sun, 2009-07-26 at 14:26 +0200, Alexander Graf wrote: On 26.07.2009, at 14:10, Avi Kivity wrote: On 07/26/2009 02:55 PM, Alexander Graf wrote: I will need some acks from ppc people. Obviously for the non-kvm bits, but also for the kvm bits as I am not qualified to review ppc code. Right, FWIW Ben would actually even prefer to take the whole thing in his tree. That's likely to cause conflicts if some kvm API changes and needs modifications to this code. Perhaps the best option is for the non- kvm changes to go through the ppc tree, and for me to duplicate (but not push) them. I agree, but that's for you two to decide I guess :-). Let's just wait for Ben to wake up. I need to review and test a bit, hopefully I'll have a better idea of what goes where some time this week. Cheers, Ben. -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On Sun, 2009-07-26 at 15:46 +0300, Avi Kivity wrote: As soon as someone implement dirty logging on a 32-bit big endian target, it will break though, so before that day comes we need to change set_bit to set_bit_64. Perhaps we can get away with disabling 32-on-64 for the configurations that break to start with. Well, 32-on-64 is probably still the most widely used configuration on ppc Cheers, Ben. -- 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: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
On Sun, 2009-07-26 at 22:47 +0200, Alexander Graf wrote: When we just interpret the bitmap as u64* do we break 32 on 64 x86? If not, that makes it work for 32 on 64 ppc, because the kernel is always 64. It just a matter of having the bits in the right place. The kernel will not always be 64-bit though, for example it's no for kvm/e500 or kvm/440 and there's no reason those could get gfx at some stage. Now, the kernel -does- provide _le variants of the bitops, and those have the side advantage of being agnostic to 32 vs. 64 bit so maybe that what we should use everywhere ? Look at ppc's bitops.h, it has nice descriptions of the format. Cheers, Ben. -- 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
