Re: [PATCH tip/core/rcu 1/3] membarrier: Provide register expedited private command

On 10/05/2017 07:23 AM, Nicholas Piggin wrote: On Wed, 4 Oct 2017 14:37:53 -0700 "Paul E. McKenney" wrote: From: Mathieu Desnoyers Provide a new command allowing processes to register their intent to use the private expedited

Re: [RFC PATCH 03/17] KVM: PPC64: booke: Add EPCR support in sregs

On 06/25/2012 03:26 PM, Mihai Caraman wrote: Add KVM_SREGS_E_64 feature and EPCR spr support in get/set sregs for 64-bit hosts. Signed-off-by: Mihai Caraman mihai.cara...@freescale.com --- arch/powerpc/kvm/booke.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-)

Re: [RFC PATCH 03/17] KVM: PPC64: booke: Add EPCR support in sregs

On 06/25/2012 04:24 PM, Caraman Mihai Claudiu-B02008 wrote: -Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Monday, June 25, 2012 4:00 PM To: Caraman Mihai Claudiu-B02008 Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; qemu

Re: [PATCH] arch/powerpc/kvm/book3s_hv.c: included linux/sched.h twice

On 02/16/2012 03:55 PM, Danny Kukawka wrote: arch/powerpc/kvm/book3s_hv.c: included 'linux/sched.h' twice, remove the duplicate. Thanks, applied. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list

Re: [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h

On 01/16/2012 03:18 PM, Alexander Graf wrote: Avi? ACK! -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h

On 01/12/2012 12:41 PM, Paul Mackerras wrote: This moves __gfn_to_memslot() and search_memslots() from kvm_main.c to kvm_host.h to reduce the code duplication caused by the need for non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c to call gfn_to_memslot() in real mode. Rather than

Re: [RFC PATCH 16/16] KVM: PPC: e500mc support

On 01/09/2012 09:29 PM, Scott Wood wrote: Best to include their signoffs, if possible. These patches are based in part on a bunch of different patches from these people (for which I did receive signoffs). I was reluctant to put their signoff directly on the new patches, since I didn't

Re: [RFC PATCH 16/16] KVM: PPC: e500mc support

On 12/21/2011 03:34 AM, Scott Wood wrote: Add processor support for e500mc, using hardware virtualization support (GS-mode). Current issues include: - No support for external proxy (coreint) interrupt mode in the guest. Includes work by Ashish Kalra ashish.ka...@freescale.com, Varun Sethi

Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h

On 01/02/2012 05:23 PM, Alexander Graf wrote: Or we could move the implementation into a header file, with an extra __ prefix, and have the C stubs call those inlines, so we have exactly on instantiation. Your real mode code can then call the inlines. I like this version. That way

Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h

On 12/20/2011 11:21 AM, Paul Mackerras wrote: This moves gfn_to_memslot(), and the functions it calls, that is, search_memslots() and __gfn_to_memslot(), from kvm_main.c to kvm_host.h so that gfn_to_memslot() can be called from non-modular code even when KVM is a module. On powerpc, the

Re: [PATCH v3 12/14] KVM: Add barriers to allow mmu_notifier_retry to be used locklessly

-by: Avi Kivity a...@redhat.com -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 01/11] KVM: PPC: Add memory-mapping support for PCI passthrough and emulation

On 11/17/2011 12:52 AM, Paul Mackerras wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org This adds support for adding PCI device I/O regions to the guest memory map, and for trapping guest accesses to emulated MMIO regions and delivering them to qemu for MMIO emulation. To trap

Re: [RFC PATCH 10/11] KVM: PPC: Implement MMU notifiers

On 11/17/2011 01:52 AM, Paul Mackerras wrote: This implements the low-level functions called by the MMU notifiers in the generic KVM code, and defines KVM_ARCH_WANT_MMU_NOTIFIER if CONFIG_KVM_BOOK3S_64_HV so that the generic KVM MMU notifiers get included. That means we also have to take

Re: kvm PCI assignment VFIO ramblings

On 08/26/2011 12:24 PM, Roedel, Joerg wrote: As I see it there are two options: (a) make subsequent accesses from userspace or the guest result in either a SIGBUS that userspace must either deal with or die, or (b) replace the mapping with a dummy RO mapping containing 0xff, with any

Re: kvm PCI assignment VFIO ramblings

On 08/28/2011 04:56 PM, Joerg Roedel wrote: On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote: On 08/26/2011 12:24 PM, Roedel, Joerg wrote: The biggest problem with this approach is that it has to happen in the context of the given process. Linux can't really modify an mm which

Re: kvm PCI assignment VFIO ramblings

On 08/20/2011 07:51 PM, Alex Williamson wrote: We need to address both the description and enforcement of device groups. Groups are formed any time the iommu does not have resolution between a set of devices. On x86, this typically happens when a PCI-to-PCI bridge exists between the set of

Re: kvm PCI assignment VFIO ramblings

On 08/22/2011 01:46 PM, Joerg Roedel wrote: $ readlink /sys/devices/pci:00/:00:19.0/iommu_group ../../../path/to/device/which/represents/the/resource/constraint (the pci-to-pci bridge on x86, or whatever node represents partitionable endpoints on power) That does not work. The

Re: kvm PCI assignment VFIO ramblings

On 08/22/2011 03:36 PM, Roedel, Joerg wrote: On Mon, Aug 22, 2011 at 06:51:35AM -0400, Avi Kivity wrote: On 08/22/2011 01:46 PM, Joerg Roedel wrote: That does not work. The bridge in question may not even be visible as a PCI device, so you can't link to it. This is the case on a few

Re: kvm PCI assignment VFIO ramblings

On 08/22/2011 03:55 PM, Roedel, Joerg wrote: On Mon, Aug 22, 2011 at 08:42:35AM -0400, Avi Kivity wrote: On 08/22/2011 03:36 PM, Roedel, Joerg wrote: On the AMD IOMMU side this information is stored in the IVRS ACPI table. Not sure about the VT-d side, though. I see

Re: kvm PCI assignment VFIO ramblings

On 08/22/2011 04:15 PM, Roedel, Joerg wrote: On Mon, Aug 22, 2011 at 09:06:07AM -0400, Avi Kivity wrote: On 08/22/2011 03:55 PM, Roedel, Joerg wrote: Well, I don't think its really meaningless, but we need some way to communicate the information about device groups to userspace. I

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

On 08/09/2011 07:31 PM, Alexander Graf wrote: When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows). So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried to share the code with

Re: [PATCH 00/10] PAPR virtualization on PR KVM

On 08/09/2011 07:31 PM, Alexander Graf wrote: In KVM for Book3S PPC we currently have 2 implementations. There is the PR based implementation which works on any POWER system you pass in and the super fast HV implementation which requires libre firmware (so almost nobody can use it). Did you

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

On 08/09/2011 07:46 PM, Alexander Graf wrote: On 08/09/2011 06:40 PM, Avi Kivity wrote: On 08/09/2011 07:31 PM, Alexander Graf wrote: When running a PAPR guest, we need to handle a few hypercalls in kernel space, most prominently the page table invalidation (to sync the shadows). So

Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode

On 08/09/2011 07:51 PM, Alexander Graf wrote: Just put your own (or your employers'). If someone contributed to the code they can add their copyrights (or ask you do do it before inclusion). It would be good to get Paul's or Ben's so that the unimportant characters between the whitespace

Re: kvm PCI assignment VFIO ramblings

On 08/03/2011 05:04 AM, David Gibson wrote: I still don't understand the distinction you're making. We're saying the group is owned by a given user or guest in the sense that no-one else may use anything in the group (including host drivers). At that point none, some or all of the devices in

Re: kvm PCI assignment VFIO ramblings

On 08/01/2011 11:27 PM, Alex Williamson wrote: On Sun, 2011-07-31 at 17:09 +0300, Avi Kivity wrote: On 07/30/2011 02:58 AM, Benjamin Herrenschmidt wrote: Due to our paravirt nature, we don't need to masquerade the MSI-X table for example. At all. If the guest configures crap

Re: kvm PCI assignment VFIO ramblings

On 08/02/2011 04:27 AM, Benjamin Herrenschmidt wrote: I have a feeling you'll be getting the same capabilities sooner or later, or you won't be able to make use of S/R IOV VFs. I'm not sure why you mean. We can do SR/IOV just fine (well, with some limitations due to constraints with how

Re: kvm PCI assignment VFIO ramblings

On 08/02/2011 03:58 PM, Benjamin Herrenschmidt wrote: What you mean 2-level is two passes through two trees (ie 6 or 8 levels right ?). (16 or 25) 25 levels ? You mean 25 loads to get to a translation ? And you get any kind of performance out of that ? :-) Aggressive partial

Re: kvm PCI assignment VFIO ramblings

On 07/30/2011 02:58 AM, Benjamin Herrenschmidt wrote: - Having a magic heuristic in libvirt to figure out those constraints is WRONG. This reeks of XFree 4 PCI layer trying to duplicate the kernel knowledge of PCI resource management and getting it wrong in many many cases, something that took

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 07/04/2011 01:59 PM, Alexander Graf wrote: On 03.07.2011, at 11:12, Avi Kivity wrote: On 07/03/2011 12:09 PM, Alexander Graf wrote: Right. The idea is that if KVM_FLAG_BLAH implies a field kvm_struct::blah, then either both are present in the headers, or none of them. Yup

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 07/04/2011 02:36 PM, Alexander Graf wrote: What intermediate steps? We can't add fields to the structure before we get the extensibility infrastructure, but that's all. If we add it now without extensibility code, we will have a kernel that only knows the ioctl with the size as it is

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 06/30/2011 07:33 PM, Alexander Graf wrote: On 30.06.2011, at 18:00, Avi Kivitya...@redhat.com wrote: On 06/30/2011 06:22 PM, Alexander Graf wrote: Regarding that. There's another option - the ioctl code embeds the structure size. So if we extend the ioctl parsing to pad up (or

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 07/03/2011 11:34 AM, Alexander Graf wrote: Yup, which requires knowledge in the code on what actually fits :). Logic we don't have today. I don't follow. What knowledge is required? Please give an example. Sure. Let's take an easy example Currently we have for get_pvinfo: snip

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 07/03/2011 12:00 PM, Alexander Graf wrote: } Otherwise we might write over data the user expected. And that logic that tells to copy_to_user how much data it actually takes to put all the information in is not there today and would have to be added. You can even verify that

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 07/03/2011 12:09 PM, Alexander Graf wrote: Right. The idea is that if KVM_FLAG_BLAH implies a field kvm_struct::blah, then either both are present in the headers, or none of them. Yup, makes sense. I like the idea :). Gets rid of all the useless paddings and reserved fields. We could

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 06/29/2011 02:58 PM, Josh Boyer wrote: This makes me wonder if a similar thing might eventually be usable for running an i686 or x32 guest on an x86_64 KVM host. I have no idea if that is even theoretically possible, but if it is it might be better to rename the ioctl to be

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 06/30/2011 06:04 PM, Alexander Graf wrote: +4.64 KVM_PPC_SET_PLATFORM + +Capability: none +Architectures: powerpc +Type: vm ioctl +Parameters: struct kvm_ppc_set_platform (in) +Returns: 0, or -1 on error + +This is used by userspace to tell KVM what sort of platform it should +emulate. The

Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate

On 06/30/2011 06:22 PM, Alexander Graf wrote: Regarding that. There's another option - the ioctl code embeds the structure size. So if we extend the ioctl parsing to pad up (or truncate down) from the user's size to our size, and similarly in the other direction, we can get away from this

Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7

On 05/17/2011 02:38 PM, Alexander Graf wrote: What would be the path for these patches to get upstream? Would this stuff normally go through Avi's tree? There is a bit of a complication in that they are based on Ben's next branch. Would Avi pull Ben's next branch, or would they go in

Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode

On 05/11/2011 01:44 PM, Paul Mackerras wrote: This adds support for KVM running on 64-bit Book 3S processors, specifically POWER7, in hypervisor mode. Using hypervisor mode means that the guest can use the processor's supervisor mode. That means that the guest can execute privileged

Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections

On 09/29/2010 02:37 PM, Greg KH wrote: Thankfully things like rpm, hald, and other miscellaneous commands scan that information. Really? Why? Why would rpm care about this? hald is dead now so we don't need to worry about that anymore, That's not what compatiblity means.

Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections

On 09/29/2010 04:50 AM, Greg KH wrote: Because the old ABI creates 129,000+ entries inside /sys/devices/system/memory with their associated links from /sys/devices/system/node/node*/ back to those directory entries. Thankfully things like rpm, hald, and other miscellaneous commands

Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections

On 09/27/2010 09:09 PM, Nathan Fontenot wrote: This set of patches decouples the concept that a single memory section corresponds to a single directory in /sys/devices/system/memory/. On systems with large amounts of memory (1+ TB) there are perfomance issues related to creating the large

Re: [PATCH 8/8] v2 Update memory hotplug documentation

On 09/27/2010 09:28 PM, Nathan Fontenot wrote: For example, assume 1GiB section size. A device for a memory starting at 0x1 is /sys/device/system/memory/memory4 (0x1 / 1Gib = 4) This device covers address range [0x1 ... 0x14000) -Under each section, you can

Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections

On 09/28/2010 05:12 PM, Robin Holt wrote: Why not update sysfs directory creation to be fast, for example by using an rbtree instead of a linked list. This fixes an implementation problem in the kernel instead of working around it and creating a new ABI. Because the old ABI creates

Re: [PULL 00/35] KVM: PPC: End-August patch queue

On 08/31/2010 05:31 AM, Alexander Graf wrote: Howdy, This is my local patch queue with stuff that has accumulated over the last weeks on KVM for PPC with some last minute fixes, speedups and debugging help that I needed for the KVM Forum ;-). The highlights of this set are: - Converted

Re: [PATCH 13/26] KVM: PPC: Add feature bitmap for magic page

On 08/31/2010 03:56 AM, Alexander Graf wrote: On 22.08.2010, at 18:42, Avi Kivity wrote: On 08/17/2010 04:57 PM, Alexander Graf wrote: We will soon add SR PV support to the shared page, so we need some infrastructure that allows the guest to query for features KVM exports. This patch adds

Re: [PATCH] KVM: PPC: Fix CONFIG_KVM_GUEST !CONFIG_KVM case

On 08/30/2010 01:01 PM, Alexander Graf wrote: When CONFIG_KVM_GUEST is selected, but CONFIG_KVM is not, we were missing some defines in asm-offsets.c and included too many headers at other places. This patch makes above configuration work. Applied, thanks. -- error compiling committee.c:

Re: [PATCH 13/26] KVM: PPC: Add feature bitmap for magic page

On 08/17/2010 04:57 PM, Alexander Graf wrote: We will soon add SR PV support to the shared page, so we need some infrastructure that allows the guest to query for features KVM exports. This patch adds a second return value to the magic mapping that indicated to the guest which features are

Re: [PATCH 00/26] KVM: PPC: Mid-August patch queue

On 08/17/2010 04:57 PM, Alexander Graf wrote: Howdy, This is my local patch queue with stuff that has accumulated over the last weeks on KVM for PPC with some last minute fixes, speedups and debugging help that I needed for the KVM Forum ;-). The highlights of this set are: - Converted

Re: [PATCH 00/27] KVM PPC PV framework v3

On 08/03/2010 07:16 PM, Scott Wood wrote: On Sun, 1 Aug 2010 22:21:37 +0200 Alexander Grafag...@suse.de wrote: On 01.08.2010, at 16:02, Avi Kivity wrote: Looks reasonable. Since it's fair to say I understand nothing about powerpc, I'd like someone who does to review it and ack, please

Re: [PATCH 00/27] KVM PPC PV framework v3

On 08/05/2010 11:01 AM, Alexander Graf wrote: Shall I take this as an ACK? Hollis wanted to take a look at it too. But given the fact that I have another ~10 patches lying here I'd appreciate if things could get committed. If changes are so dramatic that they'd render things incompatible,

Re: [PATCH 00/27] KVM PPC PV framework v3

On 07/29/2010 03:47 PM, Alexander Graf wrote: On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the hypervisor extensions. While that is all great to show that virtualization is possible, there are quite some cases where the emulation overhead of privileged instructions

Re: [PATCH 00/27] KVM PPC PV framework v3

On 07/29/2010 03:47 PM, Alexander Graf wrote: On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the hypervisor extensions. While that is all great to show that virtualization is possible, there are quite some cases where the emulation overhead of privileged instructions

Re: [PATCH 4/7] KVM: PPC: Add book3s_32 tlbie flush acceleration

On 07/29/2010 04:04 PM, Alexander Graf wrote: On Book3s_32 the tlbie instruction flushed effective addresses by the mask 0x0000. This is pretty hard to reflect with a hash that hashes ~0xfff, so to speed up that target we should also keep a special hash around for it. static inline u64

Re: [PATCH 0/7] Rest of my KVM-PPC patch queue

On 07/29/2010 04:04 PM, Alexander Graf wrote: During the past few weeks a couple of fixes have gathered in my queue. This is a dump of everything that is not related to the PV framework. Please apply on top of the PV stuff. Looks reasonable as well. I'll apply as soon as I get a review on

Re: [PATCH] KVM: PPC: Make long relocations be ulong

On 07/19/2010 05:54 PM, Alexander Graf wrote: I'm not sure which tree this should go through. Avi and Ben, please coordinate this. --- arch/powerpc/include/asm/kvm_book3s.h |4 ++-- arch/powerpc/kvm/book3s_rmhandlers.S |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)

Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface

On 07/04/2010 12:04 PM, Alexander Graf wrote: My biggest concern about putting things in the device-tree is that I was trying to keep things as separate as possible. Why does the firmware have to know that it's running in KVM? It doesn't need to know about kvm, it needs to know that a

Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface

On 07/04/2010 12:17 PM, Alexander Graf wrote: On 04.07.2010, at 11:10, Avi Kivity wrote: On 07/04/2010 12:04 PM, Alexander Graf wrote: My biggest concern about putting things in the device-tree is that I was trying to keep things as separate as possible. Why does the firmware have

Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface

On 07/04/2010 12:30 PM, Alexander Graf wrote: Considering how the parts of the draft that I read about sound like, that's not the inventor's idea. PPC people love to see the BIOS be part of the virtualization solution. I don't. That's the biggest difference here and reason for us going

Re: [PATCH 13/27] KVM: PPC: Magic Page Book3s support

On 07/02/2010 06:37 PM, Alexander Graf wrote: Alexander Graf wrote: We need to override EA as well as PA lookups for the magic page. When the guest tells us to project it, the magic page overrides any guest mappings. In order to reflect that, we need to hook into all the MMU layers of KVM

Re: [PATCH 0/2] Faster MMU lookups for Book3s v3

On 06/30/2010 04:18 PM, Alexander Graf wrote: Book3s suffered from my really bad shadow MMU implementation so far. So I finally got around to implement a combined hash and list mechanism that allows for much faster lookup of mapped pages. To show that it really is faster, I tried to run simple

Re: [PATCH 0/2] Faster MMU lookups for Book3s v3

On 07/01/2010 11:18 AM, Alexander Graf wrote: How does dirty bitmap flushing work on x86 atm? I loop through all mapped pages and flush the ones that match the range of the region I need to flush. But wouldn't it be a lot more efficient to have an hlist in the memslot and loop through that

Re: [PATCH 0/2] Faster MMU lookups for Book3s v3

On 07/01/2010 01:00 PM, Alexander Graf wrote: But doesn't that mean that you still need to loop through all the hvas that you want to invalidate? It does. Wouldn't it speed up dirty bitmap flushing a lot if we'd just have a simple linked list of all sPTEs belonging to that memslot?

Re: [PATCH 0/2] Faster MMU lookups for Book3s v3

On 07/01/2010 03:28 PM, Alexander Graf wrote: Wouldn't it speed up dirty bitmap flushing a lot if we'd just have a simple linked list of all sPTEs belonging to that memslot? The complexity is O(pages_in_slot) + O(sptes_for_slot). Usually, every page is mapped at least once, so

Re: [PATCH 0/2] Faster MMU lookups for Book3s v3

On 07/01/2010 03:52 PM, Alexander Graf wrote: Don't you use lazy spte updates? We do, but given enough time, the guest will touch its entire memory. Oh, so that's the major difference. On PPC we have the HTAB with a fraction of all the mapped pages in it. We don't have a

Re: [PATCH 01/26] KVM: PPC: Introduce shared page

On 06/29/2010 12:54 PM, Alexander Graf wrote: Code repeats 3x. Share please. Looking at this again, I could combine the 3 lines of init code into 3 lines of code that do a generic function call and then error checking. And I could convert the one free_page line with one function call

Re: [PATCH] KVM: PPC: Add generic hpte management functions

On 06/29/2010 03:56 PM, Alexander Graf wrote: Avi Kivity wrote: On 06/28/2010 11:55 AM, Alexander Graf wrote: + +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) { +return hash_64(eaddrPTE_SIZE, HPTEG_HASH_BITS_PTE); +} + +static inline u64 kvmppc_mmu_hash_vpte(u64

Re: [PATCH] KVM: PPC: Add generic hpte management functions

On 06/29/2010 04:06 PM, Alexander Graf wrote: Are we looking at the same link? Looks good to me there. We're probably looking at the same link but looking at different things. I'm whining about static u64 f() { ... } as opposed to the more sober static u64 f()

Re: [PATCH 18/26] KVM: PPC: KVM PV guest stubs

On 06/28/2010 09:33 AM, Alexander Graf wrote: Could you do something similar in module_finalize() to patch loaded modules' .text sections? I could, but do we need it? I objdump -d | grep'ed all my modules and didn't find any need to do so. You mean even kvm.ko doesn't use

Re: [PATCH] KVM: PPC: Add generic hpte management functions

On 06/26/2010 02:16 AM, Alexander Graf wrote: Currently the shadow paging code keeps an array of entries it knows about. Whenever the guest invalidates an entry, we loop through that entry, trying to invalidate matching parts. While this is a really simple implementation, it is probably the

Re: [PATCH 18/26] KVM: PPC: KVM PV guest stubs

On 06/28/2010 11:23 AM, Alexander Graf wrote: You mean even kvm.ko doesn't use privileged instructions? It does, but I don't think it's worth speeding those up. There are only a couple. Most of the privileged instructions in PPC KVM are statically compiled into the kernel because we

Re: [PATCH] KVM: PPC: Add generic hpte management functions

On 06/28/2010 11:55 AM, Alexander Graf wrote: + +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) { + return hash_64(eaddr PTE_SIZE, HPTEG_HASH_BITS_PTE); +} + +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) { + return hash_64(vpage 0xfULL, HPTEG_HASH_BITS_VPTE); +}

Re: [PATCH] KVM: PPC: Add generic hpte management functions

On 06/28/2010 12:55 PM, Alexander Graf wrote: Avi Kivity wrote: On 06/28/2010 12:27 PM, Alexander Graf wrote: Am I looking at old code? Apparently. Check book3s_mmu_*.c I don't have that pattern. It's in this patch. Yes. Silly me. +static void

Re: [PATCH] KVM: PPC: Add generic hpte management functions

On 06/28/2010 04:25 PM, Alexander Graf wrote: Less and simpler code, better reporting through slabtop, less wastage of partially allocated slab pages. But it also means that one VM can spill the global slab cache and kill another VM's mm performance, no? What do you mean

Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions

On 06/27/2010 01:58 AM, Benjamin Herrenschmidt wrote: Then mmu intensive loads can expect to be slow. Well, depends. ppc64 indeed requires the hash to be managed by the hypervisor, so inserting or invalidating translations will mean a roundtrip to the hypervisor, though there are ways

Re: [PATCH 26/26] KVM: PPC: Add Documentation about PV interface

On 06/26/2010 02:25 AM, Alexander Graf wrote: We just introduced a new PV interface that screams for documentation. So here it is - a shiny new and awesome text file describing the internal works of the PPC KVM paravirtual interface. Good, that lets people who have no idea what they're

Re: [PATCH 02/26] KVM: PPC: Convert MSR to shared page

On 06/26/2010 02:24 AM, Alexander Graf wrote: One of the most obvious registers to share with the guest directly is the MSR. The MSR contains the interrupts enabled flag which the guest has to toggle in critical sections. So in order to bring the overhead of interrupt en- and disabling down,

Re: [PATCH 08/26] KVM: PPC: Add PV guest critical sections

On 06/26/2010 02:24 AM, Alexander Graf wrote: When running in hooked code we need a way to disable interrupts without clobbering any interrupts or exiting out to the hypervisor. To achieve this, we have an additional critical field in the shared page. If that field is equal to the r1 register

Re: [PATCH 09/26] KVM: PPC: Add PV guest scratch registers

On 06/26/2010 02:24 AM, Alexander Graf wrote: While running in hooked code we need to store register contents out because we must not clobber any registers. So let's add some fields to the shared page we can just happily write to. How are these protected during interrupts? -- error

Re: [PATCH 12/26] KVM: PPC: First magic page steps

On 06/26/2010 02:25 AM, Alexander Graf wrote: We will be introducing a method to project the shared page in guest context. As soon as we're talking about this coupling, the shared page is colled magic page. This patch introduces simple defines, so the follow-up patches are easier to read.

Re: [PATCH 18/26] KVM: PPC: KVM PV guest stubs

On 06/26/2010 02:25 AM, Alexander Graf wrote: We will soon start and replace instructions from the text section with other, paravirtualized versions. To ease the readability of those patches I split out the generic looping and magic page mapping code out. This patch still only contains stubs.

Re: [PATCH 26/26] KVM: PPC: Add Documentation about PV interface

On 06/26/2010 02:25 AM, Alexander Graf wrote: We just introduced a new PV interface that screams for documentation. So here it is - a shiny new and awesome text file describing the internal works of the PPC KVM paravirtual interface. +Querying for existence +== + +To find

Re: [PATCH 02/26] KVM: PPC: Convert MSR to shared page

On 06/27/2010 12:38 PM, Alexander Graf wrote: Am 27.06.2010 um 10:16 schrieb Avi Kivity a...@redhat.com: On 06/26/2010 02:24 AM, Alexander Graf wrote: One of the most obvious registers to share with the guest directly is the MSR. The MSR contains the interrupts enabled flag which the guest

Re: [PATCH 08/26] KVM: PPC: Add PV guest critical sections

On 06/27/2010 12:40 PM, Alexander Graf wrote: Am 27.06.2010 um 10:21 schrieb Avi Kivity a...@redhat.com: On 06/26/2010 02:24 AM, Alexander Graf wrote: When running in hooked code we need a way to disable interrupts without clobbering any interrupts or exiting out to the hypervisor

Re: [PATCH 09/26] KVM: PPC: Add PV guest scratch registers

On 06/27/2010 12:41 PM, Alexander Graf wrote: Am 27.06.2010 um 10:22 schrieb Avi Kivity a...@redhat.com: On 06/26/2010 02:24 AM, Alexander Graf wrote: While running in hooked code we need to store register contents out because we must not clobber any registers. So let's add some fields

Re: [PATCH 08/26] KVM: PPC: Add PV guest critical sections

On 06/26/2010 02:24 AM, Alexander Graf wrote: When running in hooked code we need a way to disable interrupts without clobbering any interrupts or exiting out to the hypervisor. To achieve this, we have an additional critical field in the shared page. If that field is equal to the r1 register

Re: [PATCH 18/26] KVM: PPC: KVM PV guest stubs

On 06/27/2010 12:47 PM, Alexander Graf wrote: Am 27.06.2010 um 10:28 schrieb Avi Kivity a...@redhat.com: On 06/26/2010 02:25 AM, Alexander Graf wrote: We will soon start and replace instructions from the text section with other, paravirtualized versions. To ease the readability of those

Re: [PATCH 08/26] KVM: PPC: Add PV guest critical sections

On 06/27/2010 01:33 PM, Alexander Graf wrote: Or inc/dec... Uh - huh? How would that help? inc shared-critical # disable interrupts -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list

Re: [PATCH 08/26] KVM: PPC: Add PV guest critical sections

On 06/27/2010 02:49 PM, Alexander Graf wrote: Am 27.06.2010 um 12:59 schrieb Avi Kivity a...@redhat.com: On 06/27/2010 01:33 PM, Alexander Graf wrote: Or inc/dec... Uh - huh? How would that help? inc shared-critical # disable interrupts There is no opcode in the ppc isa that acts

Re: [PATCH 01/26] KVM: PPC: Introduce shared page

On 06/26/2010 02:24 AM, Alexander Graf wrote: For transparent variable sharing between the hypervisor and guest, I introduce a shared page. This shared page will contain all the registers the guest can read and write safely without exiting guest context. This patch only implements the stubs

Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions

On 06/21/2010 04:44 PM, Alexander Graf wrote: Currently the shadow paging code keeps an array of entries it knows about. Whenever the guest invalidates an entry, we loop through that entry, trying to invalidate matching parts. While this is a really simple implementation, it is probably the

Re: [PATCH] KVM: PPC: Remove obsolete kvmppc_mmu_find_pte

On 06/21/2010 04:25 PM, Alexander Graf wrote: Initially we had to search for pte entries to invalidate them. Since the logic has improved since then, we can just get rid of the search function. Applied, thanks. -- error compiling committee.c: too many arguments to function

Re: [PATCH] KVM: PPC: Use kernel hash function

On 06/21/2010 04:25 PM, Alexander Graf wrote: The linux kernel already provides a hash function. Let's reuse that instead of reinventing the wheel! Applied, thanks. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev

Re: [PATCH] KVM: PPC: Make BAT only guest segments work

On 06/21/2010 04:24 PM, Alexander Graf wrote: When a guest sets its SR entry to invalid, we may still find a corresponding entry in a BAT. So we need to make sure we're not faulting on invalid SR entries, but instead just claim them to be BAT resolved. This resolves breakage experienced when

Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions

On 06/22/2010 03:04 PM, Alexander Graf wrote: Avi Kivity wrote: On 06/21/2010 04:44 PM, Alexander Graf wrote: Currently the shadow paging code keeps an array of entries it knows about. Whenever the guest invalidates an entry, we loop through that entry, trying to invalidate matching

Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions

On 06/22/2010 03:10 PM, Alexander Graf wrote: If you have more performance hints, I'll gladly take them :). Using a cpu that virtualizes the mmu in hardware helps tremendously. -- error compiling committee.c: too many arguments to function ___

Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions

On 06/22/2010 03:14 PM, Alexander Graf wrote: Avi Kivity wrote: On 06/22/2010 03:10 PM, Alexander Graf wrote: If you have more performance hints, I'll gladly take them :). Using a cpu that virtualizes the mmu in hardware helps tremendously. PPC never does that. Even

Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space

On 05/10/2010 03:26 PM, Takuya Yoshikawa wrote: No doubt get.org - get.opt is measurable, but get.opt-switch.opt is problematic. Have you tried profiling to see where the time is spent (well I can guess, clearing the write access from the sptes). Sorry but no, and I agree with your guess.

Re: [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro

On 05/10/2010 02:46 PM, Takuya Yoshikawa wrote: (2010/05/06 22:38), Arnd Bergmann wrote: On Wednesday 05 May 2010, Takuya Yoshikawa wrote: Date: Yesterday 04:59:24 That's why the bitmaps are defined as little endian u64 aligned, even on big endian 32-bit systems. Little endian bitmaps are

  1   2   >