Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Thursday 03 April 2008 01:52:36 Kumar Gala wrote: > Wanted to get any feedback on this initial port of the fixmap support over > from x86. There are a few TODOs: > > * change HIGHMEM support to use fixmap > * fixup up VMALLOC config to respect fixmap > > (after initial powerpc patch is in tree/accepted): > * rework a few bits of fixmap.h into an asm-generic/fixmap.h > > The reason for introducing fixmap into ppc32 is it provides us with a > clean way of getting fixed compile time virtual addresses for things. > > Beyond the HIGHMEM usage. Ben and I have discussed cleaning up the PCIe > 44x config code (and 83xx PCIe cfg) to use it. Also, Dale's kexec/kdump > support on ppc32 can take advantage of it. I'm also told this is useful > for hypervisor interactions. > > One question for the guys looking at hypervisor. The x86 code also has a > function called reserve_top_address (see arch/x86/mm/pgtable_32.c). Is > this functionality something useful on ppc? If so for what? x86 virtualization implementations often needs a trampoline that's mapped into both host and guest virtual address space, so that's part of what you're seeing. In general though, it can be very useful for the host to own a piece of the guest's virtual address space. For example, the host could rewrite problematic guest instructions to branch to host-optimized code which avoids hypercalls. However, this is impossible unless the host knows it can overwrite some portion of the guest's effective address space. reserve_top_address() doesn't look complicated, so we might as well keep it? -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Thu, 2008-04-03 at 13:47 -0500, Hollis Blanchard wrote: > > x86 virtualization implementations often needs a trampoline that's > mapped into > both host and guest virtual address space, so that's part of what > you're > seeing. > > In general though, it can be very useful for the host to own a piece > of the > guest's virtual address space. For example, the host could rewrite > problematic guest instructions to branch to host-optimized code which > avoids > hypercalls. However, this is impossible unless the host knows it can > overwrite some portion of the guest's effective address space. > > reserve_top_address() doesn't look complicated, so we might as well > keep it ? Agreed. In fact, using the top of the address space for that is a good idea as you can do the branching there using absolute branch instructions which is simpler. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
Kumar Gala writes: > Wanted to get any feedback on this initial port of the fixmap support over > from x86. There are a few TODOs: I have no objection in principle, but your patch below imports a few things that aren't (and won't be) needed on powerpc AFAICS -- for example, we don't need FIX_VDSO, since our VDSO is mapped into user space at the 1MB point (by default). You have FIX_PCIE_MCFG in there too (keyed off CONFIG_PCI_MMCONFIG which we don't have and don't want to have). If you need to map in PCIe config space, what's wrong with just using ioremap? Why do you need to have a fixed virtual address for it? More generally, I think we need to take an overall look at what things we are using fixed virtual addresses for, and why they need to be fixed. If there are indeed several such things then we can introduce the fixmap stuff. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
> You have FIX_PCIE_MCFG in there too (keyed off CONFIG_PCI_MMCONFIG > which we don't have and don't want to have). If you need to map in > PCIe config space, what's wrong with just using ioremap? Why do you > need to have a fixed virtual address for it? Well, that was the whole point for doing the fixmap stuff actually, to be able to have a non-HIGHMEM version of a quick kmap_atomic for ... PCIe config space :-) On some PCIe host brigdes like the ones used on 4xx or FSL chips, the config space is physically mapped as a large linear space, too large to ioremap permanently, and we can't ioremap from within the low level config ops. So the idea is to use a fixmap as a "window" to the config space, possibly per-cpu. Ultimately, we should even be able to directly insert TLB entries in kmap_atomic/fixmap to make it even faster. > More generally, I think we need to take an overall look at what things > we are using fixed virtual addresses for, and why they need to be > fixed. If there are indeed several such things then we can introduce > the fixmap stuff. The virtual address doesn't _need_ to be fixed in our case. It's more like x86 builds kmap on top of fixmap and we were thinking about doing the same, having it fixed makes it slightly easier to whack things but I agree it's not necessarily the best option. We could instead have something allocated a chunk of virtual space at boot and provide a quick map/unmap. But by using fixmap, we can use common code with kmap_atomic quickly and easily. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Apr 6, 2008, at 6:48 PM, Paul Mackerras wrote: Kumar Gala writes: Wanted to get any feedback on this initial port of the fixmap support over from x86. There are a few TODOs: I have no objection in principle, but your patch below imports a few things that aren't (and won't be) needed on powerpc AFAICS -- for example, we don't need FIX_VDSO, since our VDSO is mapped into user space at the 1MB point (by default). Agreed. You have FIX_PCIE_MCFG in there too (keyed off CONFIG_PCI_MMCONFIG which we don't have and don't want to have). If you need to map in PCIe config space, what's wrong with just using ioremap? Why do you need to have a fixed virtual address for it? Ben has commented on this. I know on the 83xx systems we have two PCIe PHBs that would require ioremapping 512M of virtual address space which we don't have if the system has any large amount of memory. More generally, I think we need to take an overall look at what things we are using fixed virtual addresses for, and why they need to be fixed. If there are indeed several such things then we can introduce the fixmap stuff. The list as I see it: * kmap * pci-e config for 4xx/83xx * kexec/kdump (ben commented on this when Dale posted his patches for ppc32 support) future: * possible usage by HV since we already have three users and a possible fourth it seems like a useful change. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Mon, Apr 07, 2008 at 08:09:57AM -0500, Kumar Gala wrote: > On Apr 6, 2008, at 6:48 PM, Paul Mackerras wrote: >> More generally, I think we need to take an overall look at what things >> we are using fixed virtual addresses for, and why they need to be >> fixed. If there are indeed several such things then we can introduce >> the fixmap stuff. > > The list as I see it: > * kmap > * pci-e config for 4xx/83xx > * kexec/kdump (ben commented on this when Dale posted his patches for > ppc32 support) > > future: > * possible usage by HV > > since we already have three users and a possible fourth it seems like a > useful change. Another possible use is a BAT/TLB1 mapping for SoC registers (or anything else on the board which is frequently accessed), which can be reused by ioremap() to avoid wasting normal TLB entries, and to facilitate early debugging. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Apr 7, 2008, at 11:20 AM, Scott Wood wrote: On Mon, Apr 07, 2008 at 08:09:57AM -0500, Kumar Gala wrote: On Apr 6, 2008, at 6:48 PM, Paul Mackerras wrote: More generally, I think we need to take an overall look at what things we are using fixed virtual addresses for, and why they need to be fixed. If there are indeed several such things then we can introduce the fixmap stuff. The list as I see it: * kmap * pci-e config for 4xx/83xx * kexec/kdump (ben commented on this when Dale posted his patches for ppc32 support) future: * possible usage by HV since we already have three users and a possible fourth it seems like a useful change. Another possible use is a BAT/TLB1 mapping for SoC registers (or anything else on the board which is frequently accessed), which can be reused by ioremap() to avoid wasting normal TLB entries, and to facilitate early debugging. x86 has an early ioremap() that is implemented on top of their fixmap usage that we could also steal if desired :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Mon, 2008-04-07 at 11:20 -0500, Scott Wood wrote: > > Another possible use is a BAT/TLB1 mapping for SoC registers (or > anything > else on the board which is frequently accessed), which can be reused > by > ioremap() to avoid wasting normal TLB entries, and to facilitate early > debugging. As far as the above is concerned, I'm not too fan of fixed virtual addresses. I'd rather dynamically assign it. But we can do it. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote: On Mon, 2008-04-07 at 11:20 -0500, Scott Wood wrote: Another possible use is a BAT/TLB1 mapping for SoC registers (or anything else on the board which is frequently accessed), which can be reused by ioremap() to avoid wasting normal TLB entries, and to facilitate early debugging. As far as the above is concerned, I'm not too fan of fixed virtual addresses. I'd rather dynamically assign it. But we can do it. I'm in agreement with Ben here. On Freescale parts that could mean using up to 16M of virtual address space while in reality we may only need a handful of 4k pages to cover SoC registers that we are truly accessing at runtime. However I think there might be some utility to have an early ioremap mappings for debug. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Tue, Apr 08, 2008 at 09:28:12AM -0500, Kumar Gala wrote: > On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote: >> As far as the above is concerned, I'm not too fan of fixed virtual >> addresses. I'd rather dynamically assign it. But we can do it. > > I'm in agreement with Ben here. On Freescale parts that could mean > using up to 16M of virtual address space while in reality we may only > need a handful of 4k pages to cover SoC registers that we are truly > accessing at runtime. So make it configurable, and turn it off if you're low on address space. Most of the time, I'd think saving TLB0 entries would be more beneficial, especially with heavy I/O workloads where registers get banged on a lot. It's the early debugging that I'm really concerned with, though. It gets old hacking an early mapping in each time. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev