* [PATCH 1/5] microblaze: turn CONFIG_OF into a select
From: Stephen Rothwell @ 2010-06-29 2:42 UTC (permalink / raw)
To: Michal Simek, microblaze-uclinux
Cc: David Miller, Paul Mackerras, sparclinux, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/microblaze/Kconfig | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 76818f9..2b37820 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -17,6 +17,8 @@ config MICROBLAZE
select HAVE_DMA_ATTRS
select HAVE_DMA_API_DEBUG
select TRACING_SUPPORT
+ select OF
+ select OF_FLATTREE
config SWAP
def_bool n
@@ -125,8 +127,7 @@ config CMDLINE_FORCE
override those passed by the boot loader.
config OF
- def_bool y
- select OF_FLATTREE
+ bool
config PROC_DEVICETREE
bool "Support for device tree in /proc"
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: Using devices trees on X86
From: Stephen Rothwell @ 2010-06-29 2:38 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss,
Paul Mackerras, sparclinux, linuxppc-dev, David Miller
In-Reply-To: <0bcc23b9-2cbd-4465-b17c-7b3c2dff9fd3@VA3EHSMHS007.ehs.local>
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
Hi Stephen,
On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> 2) config OF is currently implemented in the architecture code. This
> should be non-architecture dependent and selected by the arches that
> need it.
>
> Comments greatly appreciated, in particular if you have
> likely-to-be-easy-to-get-accepted suggestions for 3), or feel like
> carefully solving 2) in
> a way which doesn't bork the existing of-based arches.
See the following patch set. Parts 1, 2 and 3 could be applied to the
respective architecture trees as well as Grant's tree to aleviate some
conflict problems. Part 5 could wait until a later time if necessary.
However, this is relatively trivial, so we could just collect ACKs and
put it all in Grant's tree and live with any minor pain.
Having OF in more than one Kconfig file should not cause any problems as
long as they are all the same.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] sched: fix spelling of sibling
From: Michael Neuling @ 2010-06-29 2:02 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, Ingo Molnar, linux-kernel
No logic changes, only spelling.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/process.c | 2 +-
include/linux/topology.h | 2 +-
kernel/sched_fair.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-tip/arch/powerpc/kernel/process.c
===================================================================
--- linux-tip.orig/arch/powerpc/kernel/process.c
+++ linux-tip/arch/powerpc/kernel/process.c
@@ -1270,7 +1270,7 @@ unsigned long randomize_et_dyn(unsigned
}
#ifdef CONFIG_SMP
-int arch_sd_sibiling_asym_packing(void)
+int arch_sd_sibling_asym_packing(void)
{
if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
printk_once(KERN_INFO "Enabling Asymmetric SMT scheduling\n");
Index: linux-tip/include/linux/topology.h
===================================================================
--- linux-tip.orig/include/linux/topology.h
+++ linux-tip/include/linux/topology.h
@@ -103,7 +103,7 @@ int arch_update_cpu_topology(void);
| 1*SD_SHARE_PKG_RESOURCES \
| 0*SD_SERIALIZE \
| 0*SD_PREFER_SIBLING \
- | arch_sd_sibiling_asym_packing() \
+ | arch_sd_sibling_asym_packing() \
, \
.last_balance = jiffies, \
.balance_interval = 1, \
Index: linux-tip/kernel/sched_fair.c
===================================================================
--- linux-tip.orig/kernel/sched_fair.c
+++ linux-tip/kernel/sched_fair.c
@@ -2567,7 +2567,7 @@ static inline void update_sd_lb_stats(st
} while (sg != sd->groups);
}
-int __weak arch_sd_sibiling_asym_packing(void)
+int __weak arch_sd_sibling_asym_packing(void)
{
return 0*SD_ASYM_PACKING;
}
^ permalink raw reply
* Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Marek Vasut @ 2010-06-29 1:33 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <201006041226.o54CQH2V017366@amcc.com>
Dne P=C3=A1 4. =C4=8Dervna 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> This patch enables the on-chip DWC SATA controller of the AppliedMicro
> processor 460EX.
>=20
> Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>=20
=2D-SNIP--
> + dev_err(ap->dev, "%s: Command not pending cmd_issued=3D%d "
> + "(tag=3D%d) DMA NOT started\n", __func__,
> + hsdevp->cmd_issued[tag], tag);
Just a nitpick, but don't break strings if possible.
^ permalink raw reply
* Re: [PATCH 01/40] ftrace syscalls: don't add events for unmapped syscalls
From: Ian Munsie @ 2010-06-29 1:18 UTC (permalink / raw)
To: Steven Rostedt
Cc: Frederic Weisbecker, Jason Baron, linux-kernel, linuxppc-dev,
Ingo Molnar, Paul Mackerras, Ingo Molnar, Masami Hiramatsu
In-Reply-To: <1277305339.9181.33.camel@gandalf.stny.rr.com>
Excerpts from Steven Rostedt's message of Thu Jun 24 01:02:19 +1000 2010:
> > diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> > index 34e3580..82246ce 100644
> > --- a/kernel/trace/trace_syscalls.c
> > +++ b/kernel/trace/trace_syscalls.c
> > @@ -431,6 +431,14 @@ void unreg_event_syscall_exit(struct ftrace_event_call *call)
> > int init_syscall_trace(struct ftrace_event_call *call)
> > {
> > int id;
> > + int num;
> > +
> > + num = ((struct syscall_metadata *)call->data)->syscall_nr;
> > + if (num < 0 || num >= NR_syscalls) {
> > + pr_debug("syscall %s metadata not mapped, disabling ftrace event\n",
> > + ((struct syscall_metadata *)call->data)->name);
> > + return -ENOSYS;
> > + }
>
> Perhaps this should be:
>
> if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls)
> return -ENOSYS;
>
> -- Steve
Hi Steven,
I don't think this should produce a warning - it signifies that a
syscall defined in the code has not successfully matched a syscall at
boot.
That may signify the matching failed, but it may just as likely signify
that the syscall isn't used on that arch (for instance, if an arch uses
an arch specific implementation in favour of a generic implementation,
or doesn't implement a particular syscall at all that is defined in the
generic code).
The problem case is actually the other way around - when a syscall
number from an arch's syscall table has not successfully mapped to some
syscall meta-data. Patch #37 prints out those cases with KERN_DEBUG so
booting a kernel with loglevel=8 can track them down.
This pr_debug may still be useful, for example to help locate unused
syscalls which can be removed if no arch uses them.
Cheers,
-Ian
^ permalink raw reply
* Re: [PATCH 39/40] trace syscalls: Clean confusing {s, r, }name and fix ABI breakage
From: Ian Munsie @ 2010-06-29 1:02 UTC (permalink / raw)
To: Jason Baron
Cc: Jesper Nilsson, Frederic Weisbecker, linux-kernel, Steven Rostedt,
Christoph Hellwig, linuxppc-dev, Ingo Molnar, Paul Mackerras,
Ingo Molnar, Andrew Morton
In-Reply-To: <20100623180353.GB2680@redhat.com>
Excerpts from Jason Baron's message of Thu Jun 24 04:03:54 +1000 2010:
> overall this patch is a major improvement! My question though is
> about the naming of the compat syscalls in the context of events. I
> believe this patch differeniates compat syscall event names as:
> "sys32_enter_sname", and "compat_sys_enter_sname". I agree that we keep that
> distinction for purposes of defining the actual syscall function. However,
> we had discuessed previously about keeping the event name the same for
> all compat syscalls. ie they are all called "compat_sys_sname" or some
> such. Reason being you could just do "compat_*" to match all compat
> events.
Sorry for the delay in replying - I've been pretty busy with other work
over the last few days.
I can certainly change that to name them all compat_sys to be more
consistent. In terms of activating all of them at once that can still be
done fairly easily since they are in their own compat_sys category with
something like "perf record -e 'compat_syscalls:*' ..." or "echo 1 >
/sys/kernel/debug/tracing/events/compat_syscalls/enable".
Ideally I would actually like to consolidate these events with the
ordinary syscall events and just print out compat=0|1 as part of their
output.
Since many of the native syscalls are used as compat syscalls as well I
think that would make a whole lot more sense - at the moment to catch
all syscalls from a compat process both the compat and native syscalls
would need to be activated.
It would also have the benefit of removing any arch specific naming from
userspace, which would make things a lot nicer.
Cheers,
-Ian
^ permalink raw reply
* Re: JFFS2 corruption when mounting filesystem with filenamesoflength> 7
From: Wolfgang Denk @ 2010-06-28 22:30 UTC (permalink / raw)
To: Steve Deiters; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <181804936ABC2349BE503168465576460F20D651@exchserver.basler.com>
Dear "Steve Deiters",
In message <181804936ABC2349BE503168465576460F20D651@exchserver.basler.com> you wrote:
> > I think there may be something weird going on with the memcpy
> > in my build. If I use the following patch I no longer get
> > errors when I mount the filesystem. All I did was replace
> > the memcpy with a loop.
> >
> > I'm not sure what's special about this particular use of
> > memcpy. I can't believe that things would be working as well
> > as they do if memcpy was broken in general.
> >
> > This is on a PowerPC 32 bit build for a MPC5121. I am using
> > a GCC 4.1.2 to compile. Is anyone aware of any issues with
> > memcpy in this configuration?
> >
> > Thanks.
>
> It seems this processor is mangling the data when it access unaligned
> addresses into Flash with a lwz instruction. The memcpy implementation
> in copy_32.S aligns the destination, leaving the source possibly
> unaligned. In this particular instance the source is an address into my
> Flash address space which is causing the problem. When the filenames
> were < 8 it always does a bytewise copy which is why I wasn't having
> problems with those.
>
> It seems this only occurs when I have the translation enabled. If I
> clear the DR bit in the MSR and then repeat the instruction with the
> corresponding physical address it will read correctly.
>
> I'm not sure if this is expected behavior with this core. I can fix at
> least this one problem by using memcpy_fromio since it does alignment
> checks for the source and destination.
Both the MPC52xx and MPC512x have know problems (silent data
corruption) with unaligned accesses on the local bus.
This can be trivially demonstrated in U-Boot by reading the flash
memory with 32 bit accesses; for example like this:
=> md FC0C0000 20
fc0c0000: 7012ab65 01616464 636f6e73 3d736574 p..e.addcons=set
fc0c0010: 656e7620 626f6f74 61726773 20247b62 env bootargs ${b
fc0c0020: 6f6f7461 7267737d 20636f6e 736f6c65 ootargs} console
fc0c0030: 3d247b63 6f6e736f 6c657d2c 247b6261 =${console},${ba
fc0c0040: 75647261 74657d00 61646469 703d7365 udrate}.addip=se
fc0c0050: 74656e76 20626f6f 74617267 7320247b tenv bootargs ${
fc0c0060: 626f6f74 61726773 7d206970 3d247b69 bootargs} ip=${i
fc0c0070: 70616464 727d3a24 7b736572 76657269 paddr}:${serveri
=> md FC0C0001 20
fc0c0001: 65726901 00000063 0000003d 00000065 eri....c...=...e
fc0c0011: 00000062 00000061 00000020 0000006f ...b...a... ...o
fc0c0021: 00000072 00000020 00000073 0000003d ...r... ...s...=
fc0c0031: 0000006f 0000006c 00000024 00000075 ...o...l...$...u
fc0c0041: 00000074 00000061 00000070 00000074 ...t...a...p...t
fc0c0051: 00000020 00000074 00000073 00000062 ... ...t...s...b
fc0c0061: 00000061 0000007d 0000003d 00000070 ...a...}...=...p
fc0c0071: 00000072 0000007b 00000076 00000070 ...r...{...v...p
> I'm not sure what the proper fix is for this. If I use memcpy_fromio I
> think I'll just run into problems somewhere else. Any other
> suggestions?
See http://article.gmane.org/gmane.comp.boot-loaders.u-boot/80278 for
how we fix this in U-Boot.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"On two occasions I have been asked [by members of Parliament!],
'Pray, Mr. Babbage, if you put into the machine wrong figures, will
the right answers come out?' I am not able rightly to apprehend the
kind of confusion of ideas that could provoke such a question."
- Charles Babbage
^ permalink raw reply
* Re: BUG: scheduling while atomic: swapper/0/0x00000002
From: Benjamin Herrenschmidt @ 2010-06-28 21:29 UTC (permalink / raw)
To: paulmck; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20100628164906.GA6667@linux.vnet.ibm.com>
On Mon, 2010-06-28 at 09:49 -0700, Paul E. McKenney wrote:
> And it does appear to be reproducible perhaps 50% of boots running
> CONFIG_PREEMPT on kernel-ml8. I have not yet seen it on any other
> system.
> Do you have a patch to instrument the interrupts so as to get the info
> you need, or should I improvise?
ftrace & friends ?
I don't have anything existing in mind...
Cheers,
Ben.
^ permalink raw reply
* RE: JFFS2 corruption when mounting filesystem with filenamesoflength> 7
From: Steve Deiters @ 2010-06-28 21:25 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
In-Reply-To: <181804936ABC2349BE503168465576460F20CB90@exchserver.basler.com>
> I think there may be something weird going on with the memcpy=20
> in my build. If I use the following patch I no longer get=20
> errors when I mount the filesystem. All I did was replace=20
> the memcpy with a loop.
>=20
> I'm not sure what's special about this particular use of=20
> memcpy. I can't believe that things would be working as well=20
> as they do if memcpy was broken in general.
>=20
> This is on a PowerPC 32 bit build for a MPC5121. I am using=20
> a GCC 4.1.2 to compile. Is anyone aware of any issues with=20
> memcpy in this configuration?
>=20
> Thanks.
It seems this processor is mangling the data when it access unaligned
addresses into Flash with a lwz instruction. The memcpy implementation
in copy_32.S aligns the destination, leaving the source possibly
unaligned. In this particular instance the source is an address into=
my
Flash address space which is causing the problem. When the filenames
were < 8 it always does a bytewise copy which is why I wasn't having
problems with those.
It seems this only occurs when I have the translation enabled. If I
clear the DR bit in the MSR and then repeat the instruction with the
corresponding physical address it will read correctly.
I'm not sure if this is expected behavior with this core. I can fix at
least this one problem by using memcpy_fromio since it does alignment
checks for the source and destination.
I'm not sure what the proper fix is for this. If I use memcpy_fromio=
I
think I'll just run into problems somewhere else. Any other
suggestions?
Thanks.
^ permalink raw reply
* Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM
From: Kyle Moffett @ 2010-06-28 17:05 UTC (permalink / raw)
To: Milton Miller; +Cc: linux-mtd, linuxppc-dev
In-Reply-To: <1277709539_13309@mail4.comsite.net>
On Mon, Jun 28, 2010 at 03:18, Milton Miller <miltonm@bga.com> wrote:
> On Fri Jun 25 around 14:01:51 EST 2010 Kyle Moffett wrote:
>> I've got a new P2020 (32bit mpc85xx family) board I'm working on a
>> port for that includes 2 NOR flashes (128MB each) and a removable
>> SO-RDIMM of 2GB or 4GB. =C2=A0Unfortunately when I configure both flashe=
s
>> in the device-tree off my elbc, Linux is completely unable to access
>> the second one because it attempts to ioremap() the entire virtual
>> address space of both FLASH chips.
>>
>> Even with only one flash chip enabled, there's a bit of a noticeable
>> performance degradation because the mapping consumes almost all of my
>> available vmalloc space and forces bounce-buffering for all my
>> HIGHMEM.
>>
>> It looks like the "of-flash" driver currently requires that the whole
>> chip be mapped in the kernel at once. =C2=A0I would much rather have a 5=
0%
>> performance penalty on flash accesses (which are already very slow)
>> and regain most of the vmap space.
>>
>> So the question is, is there a way to convince the MTD layer to
>> iomap() only what it needs to access to do reads and writes? =C2=A0If no=
t,
>> what changes would need to be made to MTD and/or "of-flash" to create
>> such functionality?
>
> I believe the MTD layer would be happy, but it is beyond the scope of
> the physmap_of driver.
Well, I believe that the physmap_of driver is the correct place for
it; that driver is used by a large number of embedded PPC systems and
at present it is completely unable to handle some of the larger flash
memories currently being produced (256MByte+), and there's a decent
system-wide performance penalty (due to lack of ioremap space) even
for the larger flash memories which do function.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: BUG: scheduling while atomic: swapper/0/0x00000002
From: Paul E. McKenney @ 2010-06-28 16:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20100610010854.GA11432@linux.vnet.ibm.com>
On Wed, Jun 09, 2010 at 06:08:54PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 10, 2010 at 09:20:08AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > I get the following during boot on a 16 CPU Power box. Thoughts?
> > > (/proc/config attached)
> >
> > Wow... looks like the preempt count of the idle task got busted or
> > something ... how reproduceable ? Something like a record of previous
> > interrupts might be useful..
>
> I have seen it only once, but it did get my attention. I will try running
> it again this evening when/if kernel-ml8 is free again. 2.6.35-rc2,
> I should have mentioned.
And it does appear to be reproducible perhaps 50% of boots running
CONFIG_PREEMPT on kernel-ml8. I have not yet seen it on any other system.
Do you have a patch to instrument the interrupts so as to get the info
you need, or should I improvise?
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-28 13:32 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <4C28A409.9090207@redhat.com>
Avi Kivity wrote:
> 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 by spill?
>>>
>
>
> Well?
I was thinking of a global capping, but I guess I could still do it
per-vcpu. So yes, doing a global slab doesn't hurt.
>
>>> btw, in the midst of the nit-picking frenzy I forgot to ask how the
>>> individual hash chain lengths as well as the per-vm allocation were
>>> limited.
>>>
>>> On x86 we have a per-vm limit and we allow the mm shrinker to reduce
>>> shadow mmu data structures dynamically.
>>>
>>>
>> Very simple. I keep an int with the number of allocated entries around
>> and if that hits a define'd threshold, I flush all shadow pages.
>>
>
> A truly nefarious guest will make all ptes hash to the same chain,
> making some operations very long (O(n^2) in the x86 mmu, don't know
> about ppc) under a spinlock. So we had to limit hash chains, not just
> the number of entries.
>
> But your mmu is per-cpu, no? In that case, no spinlock, and any
> damage the guest does is limited to itself.
Yes, it is. No locking. The vcpu can kill its own performance, but I
don't care about that.
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-28 13:30 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <4C28A2C1.50700@suse.de>
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 by spill?
>>
Well?
>> btw, in the midst of the nit-picking frenzy I forgot to ask how the
>> individual hash chain lengths as well as the per-vm allocation were
>> limited.
>>
>> On x86 we have a per-vm limit and we allow the mm shrinker to reduce
>> shadow mmu data structures dynamically.
>>
>>
> Very simple. I keep an int with the number of allocated entries around
> and if that hits a define'd threshold, I flush all shadow pages.
>
A truly nefarious guest will make all ptes hash to the same chain,
making some operations very long (O(n^2) in the x86 mmu, don't know
about ppc) under a spinlock. So we had to limit hash chains, not just
the number of entries.
But your mmu is per-cpu, no? In that case, no spinlock, and any damage
the guest does is limited to itself.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-28 13:25 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <4C2872F5.20501@redhat.com>
Avi Kivity wrote:
> 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 invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache
>>> *pte)
>>> +{
>>> + dprintk_mmu("KVM: Flushing SPT: 0x%lx (0x%llx) -> 0x%llx\n",
>>> + pte->pte.eaddr, pte->pte.vpage, pte->host_va);
>>> +
>>> + /* Different for 32 and 64 bit */
>>> + kvmppc_mmu_invalidate_pte(vcpu, pte);
>>> +
>>> + if (pte->pte.may_write)
>>> + kvm_release_pfn_dirty(pte->pfn);
>>> + else
>>> + kvm_release_pfn_clean(pte->pfn);
>>> +
>>> + list_del(&pte->list_pte);
>>> + list_del(&pte->list_vpte);
>>> + list_del(&pte->list_vpte_long);
>>> + list_del(&pte->list_all);
>>> +
>>> + kmem_cache_free(vcpu->arch.hpte_cache, pte);
>>> +}
>>> +
>>>
>
> (that's the old one with list_all - better check what's going on here)
Yeah, I just searched my inbox for the first patch. Obviously it was the
old version :(.
>
>
>>>>> (another difference is using struct hlist_head instead of list_head,
>>>>> which I recommend since it saves space)
>>>>>
>>>> Hrm. I thought about this quite a bit before too, but that makes
>>>> invalidation more complicated, no? We always need to remember the
>>>> previous entry in a list.
>>>>
>>> hlist_for_each_entry_safe() does that.
>>>
>> Oh - very nice. So all I need to do is pass the previous list entry to
>> invalide_pte too and I'm good. I guess I'll give it a shot.
>>
>
> No, just the for_each cursor.
>
>>> 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 by spill?
>
> btw, in the midst of the nit-picking frenzy I forgot to ask how the
> individual hash chain lengths as well as the per-vm allocation were
> limited.
>
> On x86 we have a per-vm limit and we allow the mm shrinker to reduce
> shadow mmu data structures dynamically.
>
Very simple. I keep an int with the number of allocated entries around
and if that hits a define'd threshold, I flush all shadow pages.
Alex
^ permalink raw reply
* Fw:Re:Re: PCIe bus seems work while 'dma' can't under linux
From: jxnuxdy @ 2010-06-28 9:45 UTC (permalink / raw)
To: benh, linuxppc-dev, Michal Simek, devicetree-discuss,
microblaze-uclinux, Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 7311 bytes --]
Thanks Benjamin, Is there anyone else fimilar the part as CPU 8544E, my PCIe regions for CPU bridge seems not correct, what may be the probably root cause?
bash-2.04# cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Class 0b20 Header Type 01: PCI device 1957:0032 (rev 17).
Bus 1, device 0, function 0:
Class 0580 Header Type 00: PCI device 11ab:db10 (rev 1).
Prefetchable 64 bit memory at 0x80000000 [0x800fffff].
Prefetchable 64 bit memory at 0x84000000 [0x87ffffff].
bash-2.04#
,Regards
Denny
-------- Forwarding messages --------
From: jxnuxdy <jxnuxdy@163.com>
Date: 2010-06-15 15:05:56
To: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org,"Michal Simek" <monstr@monstr.eu>,devicetree-discuss@lists.ozlabs.org,microblaze-uclinux@itee.uq.edu.au,"Stephen Rothwell" <sfr@canb.auug.org.au>
Subject: Re:Re: PCIe bus seems work while 'dma' can't under linux
Thanks Benjamin, the regions don't display as what we expect, that's why we suspect if there any configuration probelms in CPU host bridge, but we changed the uboot/linux a lot, seems take no effect on that problems.
We use CPU MPC8544, and connect two PCIE devices to CPU PCIE1 and PCIE2 directly without a extended PCIE bridge, so we disabled PCIE3 and PCI controlers in uboot level.
More settings pls take a look at the attach file log.txt.
Many thanks,
Denny
----------------------------------------------------------------------------------------------------------------------------
在2010-06-11 15:21:24，"Benjamin Herrenschmidt" <benh@kernel.crashing.org> 写道：
>On Fri, 2010-06-11 at 09:30 +0800, jxnuxdy wrote:
>> Hi guys,
>>
>> I encountered a PCIe problem under linux, the two PCIe bus on my board seems work,
>> at least I can access the registers through the PCIe bus, however the dma for the
>> PCIe bus can't work, so I just dumped the pci device, but I am curiously to find
>> there is no regions displayed on PCIe controlers, why? is it relate with my 'dma' issue then?
>
>It would help if you told us a bit more what the HW is, what you are
>doing with it, etc...
>
>IE. What is your host, what is your device, what platform, etc...
>
>DMA should work provided that your platform code sets it up properly.
>The DMA regions don't appear in /proc/pci or lspci.
>
>Cheers,
>Ben.
>
>>
>> bash-2.04# cat /proc/pci
>> PCI devices found:
>> Bus 0, device 0, function 0:
>> Class 0b20 Header Type 01: PCI device 1957:0032 (rev 17).
>> Bus 1, device 0, function 0:
>> Class 0580 Header Type 00: PCI device 11ab:db90 (rev 1).
>> Prefetchable 64 bit memory at 0x80000000 [0x800fffff].
>> Prefetchable 64 bit memory at 0x84000000 [0x87ffffff].
>> Bus 9, device 0, function 0:
>> Class 0b20 Header Type 01: PCI device 1957:0032 (rev 17).
>> Bus 10, device 0, function 0:
>> Class 0580 Header Type 00: PCI device 11ab:db90 (rev 1).
>> Prefetchable 64 bit memory at 0xa0000000 [0xa00fffff].
>> Prefetchable 64 bit memory at 0xa4000000 [0xa7ffffff].
>> bash-2.04# lspci -vv
>> 00:00.0 Power PC: Unknown device 1957:0032 (rev 11)
>> !!! Invalid class 0b20 for header type 01
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 0, cache line size 08
>> Bus: primary=00, secondary=01, subordinate=06, sec-latency=0
>> I/O behind bridge: 00000000-00000fff
>> Memory behind bridge: 80000000-9fffffff
>> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>> Capabilities: [44] Power Management version 2
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [4c] #10 [0041]
>>
>> 01:00.0 Memory controller: Galileo Technology Ltd.: Unknown device db90 (rev 01)
>> Subsystem: Galileo Technology Ltd.: Unknown device 11ab
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 0, cache line size 08
>> Interrupt: pin A routed to IRQ 0
>> Region 0: Memory at 80000000 (64-bit, prefetchable) [size=1M]
>> Region 2: Memory at 84000000 (64-bit, prefetchable) [size=64M]
>> Capabilities: [40] Power Management version 2
>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
>> Address: 0000000000000000 Data: 0000
>> Capabilities: [60] #10 [0011]
>>
>> 09:00.0 Power PC: Unknown device 1957:0032 (rev 11)
>> !!! Invalid class 0b20 for header type 01
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 0, cache line size 08
>> Bus: primary=00, secondary=0a, subordinate=0f, sec-latency=0
>> I/O behind bridge: 00000000-00000fff
>> Memory behind bridge: a0000000-bfffffff
>> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>> Capabilities: [44] Power Management version 2
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [4c] #10 [0041]
>>
>> 0a:00.0 Memory controller: Galileo Technology Ltd.: Unknown device db90 (rev 01)
>> Subsystem: Galileo Technology Ltd.: Unknown device 11ab
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 0, cache line size 08
>> Interrupt: pin A routed to IRQ 0
>> Region 0: Memory at a0000000 (64-bit, prefetchable) [size=1M]
>> Region 2: Memory at a4000000 (64-bit, prefetchable) [size=64M]
>> Capabilities: [40] Power Management version 2
>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
>> Address: 0000000000000000 Data: 0000
>> Capabilities: [60] #10 [0011]
>>
>> bash-2.04#
>>
>> Thanks
>> Denny
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 63314 bytes --]
U-Boot 1.1.3 (Jun 14 2010 - 19:26:53)
CPU: 8544_E, Version: 1.1, (0x803c0111)
Core: E500, Version: 2.2, (0x80210022)
Clock Configuration:
CPU: 800 MHz, CCB: 400 MHz,
DDR: 200 MHz, LBC: 50 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: C48
CPU Board Revision 0.0 (0x0000)
PCI2: disabled
I2C: ready
DRAM: Initializing DDRSDRAM
memsize = 200
DDR: 512 MB
POST RAM test disabled.
Now running in RAM - U-Boot at: 1fb7c000
trap_init : 0x0
system inventory subsystem initialized
FLASH: 64 MB
L2 cache 256KB: enabled
PCI:
Scanning PCI bus 00
01 00 11ab db90 0580 00
Scanning PCI bus 02
03 00 11ab db90 0580 00
In: serial
Out: serial
Err: serial
Net:
ENET0: PHY is Marvell 88E1112 (1410c97)
set_bootstatus: BS_LOAD_OS, platform_idx = 11
Hit ESC to stop autoboot: 0
## Booting image at fb400000 ...
Image Name: Linux-2.6.14.2
Image Type: PowerPC Linux Multi-File Image (gzip compressed)
Data Size: 2506379 Bytes = 2.4 MB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 1429862 Bytes = 1.4 MB
Image 1: 1076503 Bytes = 1 MB
Uncompressing Multi-File Image ... ## Current stack ends at 0x1FB5ABD0 => set upper limit to 0x00800000
## initrd at 0xFB55D1B4 ... 0xFB663ECA (len=1076503=0x106D17)
Loading Ramdisk to 1fa53000, end 1fb59d17 ... OK
initrd_start = 1fa53000, initrd_end = 1fb59d17
## Transferring control to Linux (at address 00000000) ...
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
tlbcam_index=2
Linux version 2.6.14.2 (dxiao@blc-10-6) (gcc version 3.4.6) #25 Fri Jun 11 17:59:39 PDT 2010
silkworm85xx_setup_arch
mpc85xx_setup: Doing Pcie bridge setup
Scanning PcieBus...
cpld_init: platform (101) not supported
Brocade Silkworm port (C) 2006 Brocade Communications Systems, Inc.
DMA zone: 131072 pages, LIFO batch:31
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: ip=off console=ttyS1,9600 noinitrd rootfstype=jffs2 root=/dev/mtdblock1 rw
OpenPIC Version 1.2 (1 CPUs and 60 IRQ sources) at fafb9000
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 514944k available (2280k kernel code, 668k data, 144k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1051k freed
softlockup thread 0 started up.
NET: Registered protocol family 16
PCI:: Probing PCI hardware
PCI: 0000:00:00.0: class b20 doesn't match header type 01. Ignoring class.
PCI: 0001:02:00.0: class b20 doesn't match header type 01. Ignoring class.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
Generic RTC Driver v1.07
SWBD Platform Driver v1.0: [type 101, rev 2].
Config Silkworm
PowerPC Book-E Watchdog Timer Loaded
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
ttyS0 at MMIO 0xe0004600 (irq = 26) is a 16550A
ttyS1 at MMIO 0xe0004500 (irq = 26) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: Gianfar Ethernet Controller Version 1.1, 00:e0:0c:00:00:fd
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
mtdchar: write-caching enabled
silkworm: Using SWBD101 flash configuration
Boot flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
Boot flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 6 MTD partitions on "Boot flash":
0x00000000-0x00800000 : "unused (mtd0)"
0x00800000-0x03400000 : "filesys: kernel and initrd (mtd1)"
0x03400000-0x03c00000 : "kernel: kernel and initrd (mtd2)"
0x03c00000-0x03c40000 : "bootenv0: boot environment (mtd3)"
0x03c40000-0x03c80000 : "bootenv1: boot environment (mtd4)"
0x03c80000-0x04000000 : "bootimage (mtd5)"
i2c /dev entries driver
MPC adapter: Platform type [101], Did not register I2C multiplexor callback.
MPC adapter: Platform type [101], Did not register I2C multiplexor callback.
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
ip_conntrack version 2.3 (4096 buckets, 32768 max) - 216 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
arp_tables: (C) 2002 David S. Miller
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
ip6_tables: (C) 2000-2002 Netfilter core team
NET: Registered protocol family 17
NET: Registered protocol family 15
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 144k init
INIT: version 2.78 booting
INIT: Entering runlevel: 2
Installing dpci dpci_switch_module: module license 'unspecified' taints kernel.
switch module
Installing dgen module
eth0: PHY is Generic MII (ffffffff)
/etc/rc.d/rc2.d/S30diags: /nfabos/bin/diagburnin.sh: No such file or directory
bash-2.04# eth0: Full Duplex
eth0: Speed 100BT
eth0: Link is up
bash-2.04# nfdiag
SWBD: modelId 0x0 extId 0x4e
CHOW48 platform.
slot: 0, bus: 1, dev: 0, size: 4194304, vAddr = 0x0, dmaAddr = 0x0 pciFd 0x4
DMA CPU Address 0xdf000000 PCI Address 0x9f000000 for slot 0 cheetah3 0
slot: 0, bus: 3, dev: 0, size: 4194304, vAddr = 0x0, dmaAddr = 0x0 pciFd 0x4
DMA CPU Address 0xdec00000 PCI Address 0x9ec00000 for slot 0 cheetah3 1
main (lc0)> pci -o read -s 0 -b 0 -u 0 -a 0 -l 0x128
00 BusNo 0 DevNo 0
00000000 1957 0032 0006 0010 0011 0b20 0008 0001 .W.2............
00000010 0000 0000 0000 0000 0100 0006 0000 0000 ................
00000020 8000 9ff0 1001 0001 0000 0000 0000 0000 ................
00000030 0000 0000 0044 0000 0000 0000 0000 0000 .....D..........
00000040 0000 0000 4c01 fe02 0000 0000 0010 0041 ....L..........A
00000050 0001 0000 2810 0000 d481 0003 0008 0011 ....(...........
00000060 07c0 0000 03c0 0040 0000 0000 0000 0000 .......@........
00000070 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100 0001 0001 0000 0000 0000 0000 2010 0006 ................
00000110 0000 0000 0000 0000 00a0 0000 0000 0000 ................
00000120 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000200 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000210 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000220 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000230 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000240 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000250 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000260 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000270 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000280 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000290 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000300 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000310 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000320 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000330 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000340 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000350 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000360 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000370 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000380 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000390 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000400 0000 0000 0016 0000 04e2 0000 0000 0000 ................
00000410 0004 0000 0001 0000 0000 0000 4040 0000 ............@@..
00000420 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000430 0000 0000 0000 0000 8121 009e b04c 0004 .........!...L..
00000440 0010 0000 0000 0000 0000 0000 0000 0000 ................
00000450 d7ce 0014 1e20 01fc 0000 0000 0c5c 0000 .............\..
00000460 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000470 1957 0032 0011 0b20 0000 0000 0001 0000 .W.2............
00000480 3d48 0000 0000 0000 07f0 0000 0000 0000 =H..............
00000490 07c0 0000 0000 0000 0000 0000 0000 0000 ................
main (lc0)> pci -o read -u 0 -s 0 -b 1 -a 0x0 -l 0xff
00 BusNo 1 DevNo 0
00000000 11ab db90 0006 0010 0001 0580 0008 0000 ................
00000010 000c 8000 0000 0000 000c 8400 0000 0000 ................
00000020 0000 0000 0000 0000 0000 0000 11ab 11ab ................
00000030 0000 0000 0040 0000 0000 0000 0100 0000 .....@..........
00000040 5001 0002 0000 0000 0000 0000 0000 0000 P...............
00000050 6005 0080 0000 0000 0000 0000 0000 0000 `...............
00000060 0010 0011 0080 003c 2000 0000 a411 0003 .......<........
00000070 0008 1011 0000 0000 0000 0000 0000 0000 ................
00000080 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100 0001 0001 0000 0000 0000 0000 0010 0006 ................
00000110 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000200 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000210 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000220 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000230 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000240 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000250 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000260 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000270 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000280 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000290 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000002F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000300 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000310 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000320 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000330 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000340 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000350 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000360 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000370 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000380 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000390 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000003F0 0000 0000 0000 0000 0000 0000
main (lc0)> pci -o read -s 0 -u 0 -a 0x0 -b 2 -l 0x40
00 BusNo 2 DevNo 0
00000000 1957 0032 0006 0010 0011 0b20 0008 0001 .W.2............
00000010 0000 0000 0000 0000 0300 000f 0000 0000 ................
00000020 a000 bff0 1001 0001 0000 0000 0000 0000 ................
00000030 0000 0000 0044 0000 0000 0000 0000 0000 .....D..........
00000040 0000 0000 4c01 fe02 0000 0000 0010 0041 ....L..........A
00000050 0001 0000 2810 0000 d481 0003 0008 0011 ....(...........
00000060 07c0 0000 03c0 0040 0000 0000 0000 0000 .......@........
00000070 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
main (lc0)> pci -o read -s 0 -u 0 -a 0x0 -b 3 -l 0x40
00 BusNo 3 DevNo 0
00000000 11ab db90 0006 0010 0001 0580 0008 0000 ................
00000010 000c a000 0000 0000 000c a400 0000 0000 ................
00000020 0000 0000 0000 0000 0000 0000 11ab 11ab ................
00000030 0000 0000 0040 0000 0000 0000 0100 0000 .....@..........
00000040 5001 0002 0000 0000 0000 0000 0000 0000 P...............
00000050 6005 0080 0000 0000 0000 0000 0000 0000 `...............
00000060 0010 0011 0080 003c 2000 0000 a411 0003 .......<........
00000070 0008 1011 0000 0000 0000 0000 0000 0000 ................
00000080 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000A0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000B0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000C0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000D0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000E0 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000F0 0000 0000 0000 0000 0000 0000 0000 0000 ................
main (lc0)> mem -o read -a 0xe000a000 -l 0x400
E000A000 $830100f8 $00000000 $00000000 $0010ffff ................
E000A010 $0400ffff $00000028 $00000000 $00000000 .......(........
E000A020 $00000000 $00000000 $00000000 $00000000 ................
E000A030 $00000000 $00000000 $00000000 $00000000 ................
E000A040 $00000000 $00000000 $00000000 $00000000 ................
E000A050 $00000000 $00000000 $00000000 $00000000 ................
E000A060 $00000000 $00000000 $00000000 $00000000 ................
E000A070 $00000000 $00000000 $00000000 $00000000 ................
E000A080 $00000000 $00000000 $00000000 $00000000 ................
E000A090 $00000000 $00000000 $00000000 $00000000 ................
E000A0A0 $00000000 $00000000 $00000000 $00000000 ................
E000A0B0 $00000000 $00000000 $00000000 $00000000 ................
E000A0C0 $00000000 $00000000 $00000000 $00000000 ................
E000A0D0 $00000000 $00000000 $00000000 $00000000 ................
E000A0E0 $00000000 $00000000 $00000000 $00000000 ................
E000A0F0 $00000000 $00000000 $00000000 $00000000 ................
E000A100 $00000000 $00000000 $00000000 $00000000 ................
E000A110 $00000000 $00000000 $00000000 $00000000 ................
E000A120 $00000000 $00000000 $00000000 $00000000 ................
E000A130 $00000000 $00000000 $00000000 $00000000 ................
E000A140 $00000000 $00000000 $00000000 $00000000 ................
E000A150 $00000000 $00000000 $00000000 $00000000 ................
E000A160 $00000000 $00000000 $00000000 $00000000 ................
E000A170 $00000000 $00000000 $00000000 $00000000 ................
E000A180 $00000000 $00000000 $00000000 $00000000 ................
E000A190 $00000000 $00000000 $00000000 $00000000 ................
E000A1A0 $00000000 $00000000 $00000000 $00000000 ................
E000A1B0 $00000000 $00000000 $00000000 $00000000 ................
E000A1C0 $00000000 $00000000 $00000000 $00000000 ................
E000A1D0 $00000000 $00000000 $00000000 $00000000 ................
E000A1E0 $00000000 $00000000 $00000000 $00000000 ................
E000A1F0 $00000000 $00000000 $00000000 $00000000 ................
E000A200 $00000000 $00000000 $00000000 $00000000 ................
E000A210 $00000000 $00000000 $00000000 $00000000 ................
E000A220 $00000000 $00000000 $00000000 $00000000 ................
E000A230 $00000000 $00000000 $00000000 $00000000 ................
E000A240 $00000000 $00000000 $00000000 $00000000 ................
E000A250 $00000000 $00000000 $00000000 $00000000 ................
E000A260 $00000000 $00000000 $00000000 $00000000 ................
E000A270 $00000000 $00000000 $00000000 $00000000 ................
E000A280 $00000000 $00000000 $00000000 $00000000 ................
E000A290 $00000000 $00000000 $00000000 $00000000 ................
E000A2A0 $00000000 $00000000 $00000000 $00000000 ................
E000A2B0 $00000000 $00000000 $00000000 $00000000 ................
E000A2C0 $00000000 $00000000 $00000000 $00000000 ................
E000A2D0 $00000000 $00000000 $00000000 $00000000 ................
E000A2E0 $00000000 $00000000 $00000000 $00000000 ................
E000A2F0 $00000000 $00000000 $00000000 $00000000 ................
E000A300 $00000000 $00000000 $00000000 $00000000 ................
E000A310 $00000000 $00000000 $00000000 $00000000 ................
E000A320 $00000000 $00000000 $00000000 $00000000 ................
E000A330 $00000000 $00000000 $00000000 $00000000 ................
E000A340 $00000000 $00000000 $00000000 $00000000 ................
E000A350 $00000000 $00000000 $00000000 $00000000 ................
E000A360 $00000000 $00000000 $00000000 $00000000 ................
E000A370 $00000000 $00000000 $00000000 $00000000 ................
E000A380 $00000000 $00000000 $00000000 $00000000 ................
E000A390 $00000000 $00000000 $00000000 $00000000 ................
E000A3A0 $00000000 $00000000 $00000000 $00000000 ................
E000A3B0 $00000000 $00000000 $00000000 $00000000 ................
E000A3C0 $00000000 $00000000 $00000000 $00000000 ................
E000A3D0 $00000000 $00000000 $00000000 $00000000 ................
E000A3E0 $00000000 $00000000 $00000000 $00000000 ................
E000A3F0 $00000000 $00000000 $00000000 $00000000 ................
E000A400 $00000000 $00000000 $00000000 $00000000 ................
E000A410 $00000000 $00000000 $00000000 $00000000 ................
E000A420 $00000000 $00000000 $00000000 $00000000 ................
E000A430 $00000000 $00000000 $00000000 $00000000 ................
E000A440 $00000000 $00000000 $00000000 $00000000 ................
E000A450 $00000000 $00000000 $00000000 $00000000 ................
E000A460 $00000000 $00000000 $00000000 $00000000 ................
E000A470 $00000000 $00000000 $00000000 $00000000 ................
E000A480 $00000000 $00000000 $00000000 $00000000 ................
E000A490 $00000000 $00000000 $00000000 $00000000 ................
E000A4A0 $00000000 $00000000 $00000000 $00000000 ................
E000A4B0 $00000000 $00000000 $00000000 $00000000 ................
E000A4C0 $00000000 $00000000 $00000000 $00000000 ................
E000A4D0 $00000000 $00000000 $00000000 $00000000 ................
E000A4E0 $00000000 $00000000 $00000000 $00000000 ................
E000A4F0 $00000000 $00000000 $00000000 $00000000 ................
E000A500 $00000000 $00000000 $00000000 $00000000 ................
E000A510 $00000000 $00000000 $00000000 $00000000 ................
E000A520 $00000000 $00000000 $00000000 $00000000 ................
E000A530 $00000000 $00000000 $00000000 $00000000 ................
E000A540 $00000000 $00000000 $00000000 $00000000 ................
E000A550 $00000000 $00000000 $00000000 $00000000 ................
E000A560 $00000000 $00000000 $00000000 $00000000 ................
E000A570 $00000000 $00000000 $00000000 $00000000 ................
E000A580 $00000000 $00000000 $00000000 $00000000 ................
E000A590 $00000000 $00000000 $00000000 $00000000 ................
E000A5A0 $00000000 $00000000 $00000000 $00000000 ................
E000A5B0 $00000000 $00000000 $00000000 $00000000 ................
E000A5C0 $00000000 $00000000 $00000000 $00000000 ................
E000A5D0 $00000000 $00000000 $00000000 $00000000 ................
E000A5E0 $00000000 $00000000 $00000000 $00000000 ................
E000A5F0 $00000000 $00000000 $00000000 $00000000 ................
E000A600 $00000000 $00000000 $00000000 $00000000 ................
E000A610 $00000000 $00000000 $00000000 $00000000 ................
E000A620 $00000000 $00000000 $00000000 $00000000 ................
E000A630 $00000000 $00000000 $00000000 $00000000 ................
E000A640 $00000000 $00000000 $00000000 $00000000 ................
E000A650 $00000000 $00000000 $00000000 $00000000 ................
E000A660 $00000000 $00000000 $00000000 $00000000 ................
E000A670 $00000000 $00000000 $00000000 $00000000 ................
E000A680 $00000000 $00000000 $00000000 $00000000 ................
E000A690 $00000000 $00000000 $00000000 $00000000 ................
E000A6A0 $00000000 $00000000 $00000000 $00000000 ................
E000A6B0 $00000000 $00000000 $00000000 $00000000 ................
E000A6C0 $00000000 $00000000 $00000000 $00000000 ................
E000A6D0 $00000000 $00000000 $00000000 $00000000 ................
E000A6E0 $00000000 $00000000 $00000000 $00000000 ................
E000A6F0 $00000000 $00000000 $00000000 $00000000 ................
E000A700 $00000000 $00000000 $00000000 $00000000 ................
E000A710 $00000000 $00000000 $00000000 $00000000 ................
E000A720 $00000000 $00000000 $00000000 $00000000 ................
E000A730 $00000000 $00000000 $00000000 $00000000 ................
E000A740 $00000000 $00000000 $00000000 $00000000 ................
E000A750 $00000000 $00000000 $00000000 $00000000 ................
E000A760 $00000000 $00000000 $00000000 $00000000 ................
E000A770 $00000000 $00000000 $00000000 $00000000 ................
E000A780 $00000000 $00000000 $00000000 $00000000 ................
E000A790 $00000000 $00000000 $00000000 $00000000 ................
E000A7A0 $00000000 $00000000 $00000000 $00000000 ................
E000A7B0 $00000000 $00000000 $00000000 $00000000 ................
E000A7C0 $00000000 $00000000 $00000000 $00000000 ................
E000A7D0 $00000000 $00000000 $00000000 $00000000 ................
E000A7E0 $00000000 $00000000 $00000000 $00000000 ................
E000A7F0 $00000000 $00000000 $00000000 $00000000 ................
E000A800 $00000000 $00000000 $00000000 $00000000 ................
E000A810 $00000000 $00000000 $00000000 $00000000 ................
E000A820 $00000000 $00000000 $00000000 $00000000 ................
E000A830 $00000000 $00000000 $00000000 $00000000 ................
E000A840 $00000000 $00000000 $00000000 $00000000 ................
E000A850 $00000000 $00000000 $00000000 $00000000 ................
E000A860 $00000000 $00000000 $00000000 $00000000 ................
E000A870 $00000000 $00000000 $00000000 $00000000 ................
E000A880 $00000000 $00000000 $00000000 $00000000 ................
E000A890 $00000000 $00000000 $00000000 $00000000 ................
E000A8A0 $00000000 $00000000 $00000000 $00000000 ................
E000A8B0 $00000000 $00000000 $00000000 $00000000 ................
E000A8C0 $00000000 $00000000 $00000000 $00000000 ................
E000A8D0 $00000000 $00000000 $00000000 $00000000 ................
E000A8E0 $00000000 $00000000 $00000000 $00000000 ................
E000A8F0 $00000000 $00000000 $00000000 $00000000 ................
E000A900 $00000000 $00000000 $00000000 $00000000 ................
E000A910 $00000000 $00000000 $00000000 $00000000 ................
E000A920 $00000000 $00000000 $00000000 $00000000 ................
E000A930 $00000000 $00000000 $00000000 $00000000 ................
E000A940 $00000000 $00000000 $00000000 $00000000 ................
E000A950 $00000000 $00000000 $00000000 $00000000 ................
E000A960 $00000000 $00000000 $00000000 $00000000 ................
E000A970 $00000000 $00000000 $00000000 $00000000 ................
E000A980 $00000000 $00000000 $00000000 $00000000 ................
E000A990 $00000000 $00000000 $00000000 $00000000 ................
E000A9A0 $00000000 $00000000 $00000000 $00000000 ................
E000A9B0 $00000000 $00000000 $00000000 $00000000 ................
E000A9C0 $00000000 $00000000 $00000000 $00000000 ................
E000A9D0 $00000000 $00000000 $00000000 $00000000 ................
E000A9E0 $00000000 $00000000 $00000000 $00000000 ................
E000A9F0 $00000000 $00000000 $00000000 $00000000 ................
E000AA00 $00000000 $00000000 $00000000 $00000000 ................
E000AA10 $00000000 $00000000 $00000000 $00000000 ................
E000AA20 $00000000 $00000000 $00000000 $00000000 ................
E000AA30 $00000000 $00000000 $00000000 $00000000 ................
E000AA40 $00000000 $00000000 $00000000 $00000000 ................
E000AA50 $00000000 $00000000 $00000000 $00000000 ................
E000AA60 $00000000 $00000000 $00000000 $00000000 ................
E000AA70 $00000000 $00000000 $00000000 $00000000 ................
E000AA80 $00000000 $00000000 $00000000 $00000000 ................
E000AA90 $00000000 $00000000 $00000000 $00000000 ................
E000AAA0 $00000000 $00000000 $00000000 $00000000 ................
E000AAB0 $00000000 $00000000 $00000000 $00000000 ................
E000AAC0 $00000000 $00000000 $00000000 $00000000 ................
E000AAD0 $00000000 $00000000 $00000000 $00000000 ................
E000AAE0 $00000000 $00000000 $00000000 $00000000 ................
E000AAF0 $00000000 $00000000 $00000000 $00000000 ................
E000AB00 $00000000 $00000000 $00000000 $00000000 ................
E000AB10 $00000000 $00000000 $00000000 $00000000 ................
E000AB20 $00000000 $00000000 $00000000 $00000000 ................
E000AB30 $00000000 $00000000 $00000000 $00000000 ................
E000AB40 $00000000 $00000000 $00000000 $00000000 ................
E000AB50 $00000000 $00000000 $00000000 $00000000 ................
E000AB60 $00000000 $00000000 $00000000 $00000000 ................
E000AB70 $00000000 $00000000 $00000000 $00000000 ................
E000AB80 $00000000 $00000000 $00000000 $00000000 ................
E000AB90 $00000000 $00000000 $00000000 $00000000 ................
E000ABA0 $00000000 $00000000 $00000000 $00000000 ................
E000ABB0 $00000000 $00000000 $00000000 $00000000 ................
E000ABC0 $00000000 $00000000 $00000000 $00000000 ................
E000ABD0 $00000000 $00000000 $00000000 $00000000 ................
E000ABE0 $00000000 $00000000 $00000000 $00000000 ................
E000ABF0 $00000000 $00000000 $02080100 $00000000 ................
E000AC00 $00000000 $00000000 $00000000 $00000000 ................
E000AC10 $80044023 $00000000 $00000000 $00000000 ..@#............
E000AC20 $00080000 $00000000 $00080000 $00000000 ................
E000AC30 $8004401c $00000000 $00000000 $00000000 ..@.............
E000AC40 $00000000 $00000000 $000e3000 $00000000 ..........0.....
E000AC50 $80088016 $00000000 $00000000 $00000000 ................
E000AC60 $00000000 $00000000 $00000000 $00000000 ................
E000AC70 $00044023 $00000000 $00000000 $00000000 ..@#............
E000AC80 $00000000 $00000000 $00000000 $00000000 ................
E000AC90 $00044023 $00000000 $00000000 $00000000 ..@#............
E000ACA0 $00000000 $00000000 $00000000 $00000000 ................
E000ACB0 $00000000 $00000000 $00000000 $00000000 ................
E000ACC0 $00000000 $00000000 $00000000 $00000000 ................
E000ACD0 $00000000 $00000000 $00000000 $00000000 ................
E000ACE0 $00000000 $00000000 $00000000 $00000000 ................
E000ACF0 $00000000 $00000000 $00000000 $00000000 ................
E000AD00 $00000000 $00000000 $00000000 $00000000 ................
E000AD10 $00000000 $00000000 $00000000 $00000000 ................
E000AD20 $00000000 $00000000 $00000000 $00000000 ................
E000AD30 $00000000 $00000000 $00000000 $00000000 ................
E000AD40 $00000000 $00000000 $00000000 $00000000 ................
E000AD50 $00000000 $00000000 $00000000 $00000000 ................
E000AD60 $00000000 $00000000 $00000000 $00000000 ................
E000AD70 $00000000 $00000000 $00000000 $00000000 ................
E000AD80 $00000000 $00000000 $00000000 $00000000 ................
E000AD90 $00000000 $00000000 $00000000 $00000000 ................
E000ADA0 $00000000 $00000000 $00000000 $00000000 ................
E000ADB0 $a0f5501e $00000000 $00000000 $00000000 ..P.............
E000ADC0 $00000000 $00000000 $00000000 $00000000 ................
E000ADD0 $20f44023 $00000000 $00000000 $00000000 ..@#............
E000ADE0 $00000000 $00000000 $00000000 $00000000 ................
E000ADF0 $20f44023 $00000000 $00000000 $00000000 ..@#............
E000AE00 $80020000 $00000000 $00bdfe00 $00000000 ................
E000AE10 $00000000 $00000000 $00000000 $00000000 ................
E000AE20 $00000041 $00000000 $00000800 $00000000 ...A............
E000AE30 $00000000 $00000000 $00000000 $00000000 ................
E000AE40 $00000000 $00000000 $00000000 $00000000 ................
E000AE50 $00000000 $00000000 $00000000 $00000000 ................
E000AE60 $00000000 $00000000 $00000000 $00000000 ................
E000AE70 $00000000 $00000000 $00000000 $00000000 ................
E000AE80 $00000000 $00000000 $00000000 $00000000 ................
E000AE90 $00000000 $00000000 $00000000 $00000000 ................
E000AEA0 $00000000 $00000000 $00000000 $00000000 ................
E000AEB0 $00000000 $00000000 $00000000 $00000000 ................
E000AEC0 $00000000 $00000000 $00000000 $00000000 ................
E000AED0 $00000000 $00000000 $00000000 $00000000 ................
E000AEE0 $00000000 $00000000 $00000000 $00000000 ................
E000AEF0 $00000000 $00000000 $00000000 $00000000 ................
E000AF00 $80400080 $00000000 $00000000 $00000000 .@..............
E000AF10 $c8800000 $a0000000 $00000000 $00000000 ................
E000AF20 $00008000 $00000000 $00000000 $00000000 ................
E000AF30 $00000000 $00000000 $00000000 $00000000 ................
E000AF40 $00000000 $00000000 $00000000 $00000000 ................
E000AF50 $00000000 $00000000 $00000000 $00000000 ................
E000AF60 $00000000 $00000000 $00000000 $00000000 ................
E000AF70 $00000000 $00000000 $00000000 $00000000 ................
E000AF80 $00000000 $00000000 $00000000 $00000000 ................
E000AF90 $00000000 $00000000 $00000000 $00000000 ................
E000AFA0 $00000000 $00000000 $00000000 $00000000 ................
E000AFB0 $00000000 $00000000 $00000000 $00000000 ................
E000AFC0 $00000000 $00000000 $00000000 $00000000 ................
E000AFD0 $00000000 $00000000 $00000000 $00000000 ................
E000AFE0 $00000000 $00000000 $00000000 $00000000 ................
E000AFF0 $00000000 $00000000 $00000000 $00000000 ................
main (lc0)> mem -o read -a 0xe0009000 0x400
Invalid usage
main (lc0)> mem -o read -a 0xe0009000 -l 0x400
E0009000 $800300fc $00000000 $00000000 $0010ffff ................
E0009010 $0400ffff $00000028 $00000000 $00000000 .......(........
E0009020 $00000000 $00000000 $00000000 $00000000 ................
E0009030 $00000000 $00000000 $00000000 $00000000 ................
E0009040 $00000000 $00000000 $00000000 $00000000 ................
E0009050 $00000000 $00000000 $00000000 $00000000 ................
E0009060 $00000000 $00000000 $00000000 $00000000 ................
E0009070 $00000000 $00000000 $00000000 $00000000 ................
E0009080 $00000000 $00000000 $00000000 $00000000 ................
E0009090 $00000000 $00000000 $00000000 $00000000 ................
E00090A0 $00000000 $00000000 $00000000 $00000000 ................
E00090B0 $00000000 $00000000 $00000000 $00000000 ................
E00090C0 $00000000 $00000000 $00000000 $00000000 ................
E00090D0 $00000000 $00000000 $00000000 $00000000 ................
E00090E0 $00000000 $00000000 $00000000 $00000000 ................
E00090F0 $00000000 $00000000 $00000000 $00000000 ................
E0009100 $00000000 $00000000 $00000000 $00000000 ................
E0009110 $00000000 $00000000 $00000000 $00000000 ................
E0009120 $00000000 $00000000 $00000000 $00000000 ................
E0009130 $00000000 $00000000 $00000000 $00000000 ................
E0009140 $00000000 $00000000 $00000000 $00000000 ................
E0009150 $00000000 $00000000 $00000000 $00000000 ................
E0009160 $00000000 $00000000 $00000000 $00000000 ................
E0009170 $00000000 $00000000 $00000000 $00000000 ................
E0009180 $00000000 $00000000 $00000000 $00000000 ................
E0009190 $00000000 $00000000 $00000000 $00000000 ................
E00091A0 $00000000 $00000000 $00000000 $00000000 ................
E00091B0 $00000000 $00000000 $00000000 $00000000 ................
E00091C0 $00000000 $00000000 $00000000 $00000000 ................
E00091D0 $00000000 $00000000 $00000000 $00000000 ................
E00091E0 $00000000 $00000000 $00000000 $00000000 ................
E00091F0 $00000000 $00000000 $00000000 $00000000 ................
E0009200 $00000000 $00000000 $00000000 $00000000 ................
E0009210 $00000000 $00000000 $00000000 $00000000 ................
E0009220 $00000000 $00000000 $00000000 $00000000 ................
E0009230 $00000000 $00000000 $00000000 $00000000 ................
E0009240 $00000000 $00000000 $00000000 $00000000 ................
E0009250 $00000000 $00000000 $00000000 $00000000 ................
E0009260 $00000000 $00000000 $00000000 $00000000 ................
E0009270 $00000000 $00000000 $00000000 $00000000 ................
E0009280 $00000000 $00000000 $00000000 $00000000 ................
E0009290 $00000000 $00000000 $00000000 $00000000 ................
E00092A0 $00000000 $00000000 $00000000 $00000000 ................
E00092B0 $00000000 $00000000 $00000000 $00000000 ................
E00092C0 $00000000 $00000000 $00000000 $00000000 ................
E00092D0 $00000000 $00000000 $00000000 $00000000 ................
E00092E0 $00000000 $00000000 $00000000 $00000000 ................
E00092F0 $00000000 $00000000 $00000000 $00000000 ................
E0009300 $00000000 $00000000 $00000000 $00000000 ................
E0009310 $00000000 $00000000 $00000000 $00000000 ................
E0009320 $00000000 $00000000 $00000000 $00000000 ................
E0009330 $00000000 $00000000 $00000000 $00000000 ................
E0009340 $00000000 $00000000 $00000000 $00000000 ................
E0009350 $00000000 $00000000 $00000000 $00000000 ................
E0009360 $00000000 $00000000 $00000000 $00000000 ................
E0009370 $00000000 $00000000 $00000000 $00000000 ................
E0009380 $00000000 $00000000 $00000000 $00000000 ................
E0009390 $00000000 $00000000 $00000000 $00000000 ................
E00093A0 $00000000 $00000000 $00000000 $00000000 ................
E00093B0 $00000000 $00000000 $00000000 $00000000 ................
E00093C0 $00000000 $00000000 $00000000 $00000000 ................
E00093D0 $00000000 $00000000 $00000000 $00000000 ................
E00093E0 $00000000 $00000000 $00000000 $00000000 ................
E00093F0 $00000000 $00000000 $00000000 $00000000 ................
E0009400 $00000000 $00000000 $00000000 $00000000 ................
E0009410 $00000000 $00000000 $00000000 $00000000 ................
E0009420 $00000000 $00000000 $00000000 $00000000 ................
E0009430 $00000000 $00000000 $00000000 $00000000 ................
E0009440 $00000000 $00000000 $00000000 $00000000 ................
E0009450 $00000000 $00000000 $00000000 $00000000 ................
E0009460 $00000000 $00000000 $00000000 $00000000 ................
E0009470 $00000000 $00000000 $00000000 $00000000 ................
E0009480 $00000000 $00000000 $00000000 $00000000 ................
E0009490 $00000000 $00000000 $00000000 $00000000 ................
E00094A0 $00000000 $00000000 $00000000 $00000000 ................
E00094B0 $00000000 $00000000 $00000000 $00000000 ................
E00094C0 $00000000 $00000000 $00000000 $00000000 ................
E00094D0 $00000000 $00000000 $00000000 $00000000 ................
E00094E0 $00000000 $00000000 $00000000 $00000000 ................
E00094F0 $00000000 $00000000 $00000000 $00000000 ................
E0009500 $00000000 $00000000 $00000000 $00000000 ................
E0009510 $00000000 $00000000 $00000000 $00000000 ................
E0009520 $00000000 $00000000 $00000000 $00000000 ................
E0009530 $00000000 $00000000 $00000000 $00000000 ................
E0009540 $00000000 $00000000 $00000000 $00000000 ................
E0009550 $00000000 $00000000 $00000000 $00000000 ................
E0009560 $00000000 $00000000 $00000000 $00000000 ................
E0009570 $00000000 $00000000 $00000000 $00000000 ................
E0009580 $00000000 $00000000 $00000000 $00000000 ................
E0009590 $00000000 $00000000 $00000000 $00000000 ................
E00095A0 $00000000 $00000000 $00000000 $00000000 ................
E00095B0 $00000000 $00000000 $00000000 $00000000 ................
E00095C0 $00000000 $00000000 $00000000 $00000000 ................
E00095D0 $00000000 $00000000 $00000000 $00000000 ................
E00095E0 $00000000 $00000000 $00000000 $00000000 ................
E00095F0 $00000000 $00000000 $00000000 $00000000 ................
E0009600 $00000000 $00000000 $00000000 $00000000 ................
E0009610 $00000000 $00000000 $00000000 $00000000 ................
E0009620 $00000000 $00000000 $00000000 $00000000 ................
E0009630 $00000000 $00000000 $00000000 $00000000 ................
E0009640 $00000000 $00000000 $00000000 $00000000 ................
E0009650 $00000000 $00000000 $00000000 $00000000 ................
E0009660 $00000000 $00000000 $00000000 $00000000 ................
E0009670 $00000000 $00000000 $00000000 $00000000 ................
E0009680 $00000000 $00000000 $00000000 $00000000 ................
E0009690 $00000000 $00000000 $00000000 $00000000 ................
E00096A0 $00000000 $00000000 $00000000 $00000000 ................
E00096B0 $00000000 $00000000 $00000000 $00000000 ................
E00096C0 $00000000 $00000000 $00000000 $00000000 ................
E00096D0 $00000000 $00000000 $00000000 $00000000 ................
E00096E0 $00000000 $00000000 $00000000 $00000000 ................
E00096F0 $00000000 $00000000 $00000000 $00000000 ................
E0009700 $00000000 $00000000 $00000000 $00000000 ................
E0009710 $00000000 $00000000 $00000000 $00000000 ................
E0009720 $00000000 $00000000 $00000000 $00000000 ................
E0009730 $00000000 $00000000 $00000000 $00000000 ................
E0009740 $00000000 $00000000 $00000000 $00000000 ................
E0009750 $00000000 $00000000 $00000000 $00000000 ................
E0009760 $00000000 $00000000 $00000000 $00000000 ................
E0009770 $00000000 $00000000 $00000000 $00000000 ................
E0009780 $00000000 $00000000 $00000000 $00000000 ................
E0009790 $00000000 $00000000 $00000000 $00000000 ................
E00097A0 $00000000 $00000000 $00000000 $00000000 ................
E00097B0 $00000000 $00000000 $00000000 $00000000 ................
E00097C0 $00000000 $00000000 $00000000 $00000000 ................
E00097D0 $00000000 $00000000 $00000000 $00000000 ................
E00097E0 $00000000 $00000000 $00000000 $00000000 ................
E00097F0 $00000000 $00000000 $00000000 $00000000 ................
E0009800 $00000000 $00000000 $00000000 $00000000 ................
E0009810 $00000000 $00000000 $00000000 $00000000 ................
E0009820 $00000000 $00000000 $00000000 $00000000 ................
E0009830 $00000000 $00000000 $00000000 $00000000 ................
E0009840 $00000000 $00000000 $00000000 $00000000 ................
E0009850 $00000000 $00000000 $00000000 $00000000 ................
E0009860 $00000000 $00000000 $00000000 $00000000 ................
E0009870 $00000000 $00000000 $00000000 $00000000 ................
E0009880 $00000000 $00000000 $00000000 $00000000 ................
E0009890 $00000000 $00000000 $00000000 $00000000 ................
E00098A0 $00000000 $00000000 $00000000 $00000000 ................
E00098B0 $00000000 $00000000 $00000000 $00000000 ................
E00098C0 $00000000 $00000000 $00000000 $00000000 ................
E00098D0 $00000000 $00000000 $00000000 $00000000 ................
E00098E0 $00000000 $00000000 $00000000 $00000000 ................
E00098F0 $00000000 $00000000 $00000000 $00000000 ................
E0009900 $00000000 $00000000 $00000000 $00000000 ................
E0009910 $00000000 $00000000 $00000000 $00000000 ................
E0009920 $00000000 $00000000 $00000000 $00000000 ................
E0009930 $00000000 $00000000 $00000000 $00000000 ................
E0009940 $00000000 $00000000 $00000000 $00000000 ................
E0009950 $00000000 $00000000 $00000000 $00000000 ................
E0009960 $00000000 $00000000 $00000000 $00000000 ................
E0009970 $00000000 $00000000 $00000000 $00000000 ................
E0009980 $00000000 $00000000 $00000000 $00000000 ................
E0009990 $00000000 $00000000 $00000000 $00000000 ................
E00099A0 $00000000 $00000000 $00000000 $00000000 ................
E00099B0 $00000000 $00000000 $00000000 $00000000 ................
E00099C0 $00000000 $00000000 $00000000 $00000000 ................
E00099D0 $00000000 $00000000 $00000000 $00000000 ................
E00099E0 $00000000 $00000000 $00000000 $00000000 ................
E00099F0 $00000000 $00000000 $00000000 $00000000 ................
E0009A00 $00000000 $00000000 $00000000 $00000000 ................
E0009A10 $00000000 $00000000 $00000000 $00000000 ................
E0009A20 $00000000 $00000000 $00000000 $00000000 ................
E0009A30 $00000000 $00000000 $00000000 $00000000 ................
E0009A40 $00000000 $00000000 $00000000 $00000000 ................
E0009A50 $00000000 $00000000 $00000000 $00000000 ................
E0009A60 $00000000 $00000000 $00000000 $00000000 ................
E0009A70 $00000000 $00000000 $00000000 $00000000 ................
E0009A80 $00000000 $00000000 $00000000 $00000000 ................
E0009A90 $00000000 $00000000 $00000000 $00000000 ................
E0009AA0 $00000000 $00000000 $00000000 $00000000 ................
E0009AB0 $00000000 $00000000 $00000000 $00000000 ................
E0009AC0 $00000000 $00000000 $00000000 $00000000 ................
E0009AD0 $00000000 $00000000 $00000000 $00000000 ................
E0009AE0 $00000000 $00000000 $00000000 $00000000 ................
E0009AF0 $00000000 $00000000 $00000000 $00000000 ................
E0009B00 $00000000 $00000000 $00000000 $00000000 ................
E0009B10 $00000000 $00000000 $00000000 $00000000 ................
E0009B20 $00000000 $00000000 $00000000 $00000000 ................
E0009B30 $00000000 $00000000 $00000000 $00000000 ................
E0009B40 $00000000 $00000000 $00000000 $00000000 ................
E0009B50 $00000000 $00000000 $00000000 $00000000 ................
E0009B60 $00000000 $00000000 $00000000 $00000000 ................
E0009B70 $00000000 $00000000 $00000000 $00000000 ................
E0009B80 $00000000 $00000000 $00000000 $00000000 ................
E0009B90 $00000000 $00000000 $00000000 $00000000 ................
E0009BA0 $00000000 $00000000 $00000000 $00000000 ................
E0009BB0 $00000000 $00000000 $00000000 $00000000 ................
E0009BC0 $00000000 $00000000 $00000000 $00000000 ................
E0009BD0 $00000000 $00000000 $00000000 $00000000 ................
E0009BE0 $00000000 $00000000 $00000000 $00000000 ................
E0009BF0 $00000000 $00000000 $02080100 $00000000 ................
E0009C00 $00000000 $00000000 $00000000 $00000000 ................
E0009C10 $80044023 $00000000 $00000000 $00000000 ..@#............
E0009C20 $000a0000 $00000000 $000a0000 $00000000 ................
E0009C30 $8004401c $00000000 $00000000 $00000000 ..@.............
E0009C40 $00000000 $00000000 $000e3800 $00000000 ..........8.....
E0009C50 $80088016 $00000000 $00000000 $00000000 ................
E0009C60 $00000000 $00000000 $00000000 $00000000 ................
E0009C70 $00044023 $00000000 $00000000 $00000000 ..@#............
E0009C80 $00000000 $00000000 $00000000 $00000000 ................
E0009C90 $00044023 $00000000 $00000000 $00000000 ..@#............
E0009CA0 $00000000 $00000000 $00000000 $00000000 ................
E0009CB0 $00000000 $00000000 $00000000 $00000000 ................
E0009CC0 $00000000 $00000000 $00000000 $00000000 ................
E0009CD0 $00000000 $00000000 $00000000 $00000000 ................
E0009CE0 $00000000 $00000000 $00000000 $00000000 ................
E0009CF0 $00000000 $00000000 $00000000 $00000000 ................
E0009D00 $00000000 $00000000 $00000000 $00000000 ................
E0009D10 $00000000 $00000000 $00000000 $00000000 ................
E0009D20 $00000000 $00000000 $00000000 $00000000 ................
E0009D30 $00000000 $00000000 $00000000 $00000000 ................
E0009D40 $00000000 $00000000 $00000000 $00000000 ................
E0009D50 $00000000 $00000000 $00000000 $00000000 ................
E0009D60 $00000000 $00000000 $00000000 $00000000 ................
E0009D70 $00000000 $00000000 $00000000 $00000000 ................
E0009D80 $00000000 $00000000 $00000000 $00000000 ................
E0009D90 $00000000 $00000000 $00000000 $00000000 ................
E0009DA0 $00000000 $00000000 $00000000 $00000000 ................
E0009DB0 $a0f5501e $00000000 $00000000 $00000000 ..P.............
E0009DC0 $00000000 $00000000 $00000000 $00000000 ................
E0009DD0 $20f44023 $00000000 $00000000 $00000000 ..@#............
E0009DE0 $00000000 $00000000 $00000000 $00000000 ................
E0009DF0 $20f44023 $00000000 $00000000 $00000000 ..@#............
E0009E00 $80020000 $00000000 $00bdfe00 $00000000 ................
E0009E10 $00000000 $00000000 $00000000 $00000000 ................
E0009E20 $00000041 $00000000 $00000800 $00000000 ...A............
E0009E30 $00000000 $00000000 $00000000 $00000000 ................
E0009E40 $00000000 $00000000 $00000000 $00000000 ................
E0009E50 $00000000 $00000000 $00000000 $00000000 ................
E0009E60 $00000000 $00000000 $00000000 $00000000 ................
E0009E70 $00000000 $00000000 $00000000 $00000000 ................
E0009E80 $00000000 $00000000 $00000000 $00000000 ................
E0009E90 $00000000 $00000000 $00000000 $00000000 ................
E0009EA0 $00000000 $00000000 $00000000 $00000000 ................
E0009EB0 $00000000 $00000000 $00000000 $00000000 ................
E0009EC0 $00000000 $00000000 $00000000 $00000000 ................
E0009ED0 $00000000 $00000000 $00000000 $00000000 ................
E0009EE0 $00000000 $00000000 $00000000 $00000000 ................
E0009EF0 $00000000 $00000000 $00000000 $00000000 ................
E0009F00 $80400080 $00000000 $00000000 $00000000 .@..............
E0009F10 $c8800000 $a0000000 $00000000 $00000000 ................
E0009F20 $00008000 $00000000 $00000000 $00000000 ................
E0009F30 $00000000 $00000000 $00000000 $00000000 ................
E0009F40 $00000000 $00000000 $00000000 $00000000 ................
E0009F50 $00000000 $00000000 $00000000 $00000000 ................
E0009F60 $00000000 $00000000 $00000000 $00000000 ................
E0009F70 $00000000 $00000000 $00000000 $00000000 ................
E0009F80 $00000000 $00000000 $00000000 $00000000 ................
E0009F90 $00000000 $00000000 $00000000 $00000000 ................
E0009FA0 $00000000 $00000000 $00000000 $00000000 ................
E0009FB0 $00000000 $00000000 $00000000 $00000000 ................
E0009FC0 $00000000 $00000000 $00000000 $00000000 ................
E0009FD0 $00000000 $00000000 $00000000 $00000000 ................
E0009FE0 $00000000 $00000000 $00000000 $00000000 ................
E0009FF0 $00000000 $00000000 $00000000 $00000000 ................
main (lc0)>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-28 10:01 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <4C2871A8.1060706@suse.de>
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 invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
>> +{
>> + dprintk_mmu("KVM: Flushing SPT: 0x%lx (0x%llx) -> 0x%llx\n",
>> + pte->pte.eaddr, pte->pte.vpage, pte->host_va);
>> +
>> + /* Different for 32 and 64 bit */
>> + kvmppc_mmu_invalidate_pte(vcpu, pte);
>> +
>> + if (pte->pte.may_write)
>> + kvm_release_pfn_dirty(pte->pfn);
>> + else
>> + kvm_release_pfn_clean(pte->pfn);
>> +
>> + list_del(&pte->list_pte);
>> + list_del(&pte->list_vpte);
>> + list_del(&pte->list_vpte_long);
>> + list_del(&pte->list_all);
>> +
>> + kmem_cache_free(vcpu->arch.hpte_cache, pte);
>> +}
>> +
>>
(that's the old one with list_all - better check what's going on here)
>>>> (another difference is using struct hlist_head instead of list_head,
>>>> which I recommend since it saves space)
>>>>
>>> Hrm. I thought about this quite a bit before too, but that makes
>>> invalidation more complicated, no? We always need to remember the
>>> previous entry in a list.
>>>
>> hlist_for_each_entry_safe() does that.
>>
> Oh - very nice. So all I need to do is pass the previous list entry to
> invalide_pte too and I'm good. I guess I'll give it a shot.
>
No, just the for_each cursor.
>> 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 by spill?
btw, in the midst of the nit-picking frenzy I forgot to ask how the
individual hash chain lengths as well as the per-vm allocation were limited.
On x86 we have a per-vm limit and we allow the mm shrinker to reduce
shadow mmu data structures dynamically.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-28 9:55 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <4C286C98.8060903@redhat.com>
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.
> +static void invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
> +{
> + dprintk_mmu("KVM: Flushing SPT: 0x%lx (0x%llx) -> 0x%llx\n",
> + pte->pte.eaddr, pte->pte.vpage, pte->host_va);
> +
> + /* Different for 32 and 64 bit */
> + kvmppc_mmu_invalidate_pte(vcpu, pte);
> +
> + if (pte->pte.may_write)
> + kvm_release_pfn_dirty(pte->pfn);
> + else
> + kvm_release_pfn_clean(pte->pfn);
> +
> + list_del(&pte->list_pte);
> + list_del(&pte->list_vpte);
> + list_del(&pte->list_vpte_long);
> + list_del(&pte->list_all);
> +
> + kmem_cache_free(vcpu->arch.hpte_cache, pte);
> +}
> +
>
>>
>>>
>>> (another difference is using struct hlist_head instead of list_head,
>>> which I recommend since it saves space)
>>
>> Hrm. I thought about this quite a bit before too, but that makes
>> invalidation more complicated, no? We always need to remember the
>> previous entry in a list.
>
> hlist_for_each_entry_safe() does that.
Oh - very nice. So all I need to do is pass the previous list entry to
invalide_pte too and I'm good. I guess I'll give it a shot.
>
>>>
>>>>>> +int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu)
>>>>>> +{
>>>>>> + char kmem_name[128];
>>>>>> +
>>>>>> + /* init hpte slab cache */
>>>>>> + snprintf(kmem_name, 128, "kvm-spt-%p", vcpu);
>>>>>> + vcpu->arch.hpte_cache = kmem_cache_create(kmem_name,
>>>>>> + sizeof(struct hpte_cache), sizeof(struct hpte_cache), 0,
>>>>>> NULL);
>>>>>>
>>>>>>
>>>>> Why not one global cache?
>>>>>
>>>> You mean over all vcpus? Or over all VMs?
>>>
>>> Totally global. As in 'static struct kmem_cache *kvm_hpte_cache;'.
>>
>> What would be the benefit?
>
> 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?
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-28 9:34 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <1A0E0E54-D055-4333-B5EC-DE2F71382AB7@suse.de>
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.
>
>>
>> (another difference is using struct hlist_head instead of list_head,
>> which I recommend since it saves space)
>
> Hrm. I thought about this quite a bit before too, but that makes
> invalidation more complicated, no? We always need to remember the
> previous entry in a list.
hlist_for_each_entry_safe() does that.
>>
>>>>> +int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu)
>>>>> +{
>>>>> + char kmem_name[128];
>>>>> +
>>>>> + /* init hpte slab cache */
>>>>> + snprintf(kmem_name, 128, "kvm-spt-%p", vcpu);
>>>>> + vcpu->arch.hpte_cache = kmem_cache_create(kmem_name,
>>>>> + sizeof(struct hpte_cache), sizeof(struct hpte_cache), 0,
>>>>> NULL);
>>>>>
>>>>>
>>>> Why not one global cache?
>>>>
>>> You mean over all vcpus? Or over all VMs?
>>
>> Totally global. As in 'static struct kmem_cache *kvm_hpte_cache;'.
>
> What would be the benefit?
Less and simpler code, better reporting through slabtop, less wastage of
partially allocated slab pages.
>>> Because this way they don't interfere. An operation on one vCPU
>>> doesn't inflict anything on another. There's also no locking
>>> necessary this way.
>>>
>>
>> The slab writers have solved this for everyone, not just us.
>> kmem_cache_alloc() will usually allocate from a per-cpu cache, so no
>> interference and/or locking. See ____cache_alloc().
>>
>> If there's a problem in kmem_cache_alloc(), solve it there, don't
>> introduce workarounds.
>
> So you would still keep different hash arrays and everything, just
> allocate the objects from a global pool?
Yes.
> I still fail to see how that benefits anyone.
See above.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-28 9:27 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <4C286770.6010204@redhat.com>
Am 28.06.2010 um 11:12 schrieb Avi Kivity <avi@redhat.com>:
> 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& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>> +}
>>>>
>>>>
>>> Still with the wierd coding style?
>>>
>> Not sure what's going on there. My editor displays it normally.
>> Weird.
>>
>
> Try hitting 'save'.
Thanks for the hint :). No really, no idea what's going on here.
>
>>>> +static void kvmppc_mmu_pte_flush_all(struct kvm_vcpu *vcpu)
>>>> +{
>>>> + struct hpte_cache *pte, *tmp;
>>>> + int i;
>>>> +
>>>> + for (i = 0; i< HPTEG_HASH_NUM_VPTE_LONG; i++) {
>>>> + struct list_head *list =&vcpu->arch.hpte_hash_vpte_long
>>>> [i];
>>>> +
>>>> + list_for_each_entry_safe(pte, tmp, list, list_vpte_long) {
>>>> + /* Jump over the helper entry */
>>>> + if (&pte->list_vpte_long == list)
>>>> + continue;
>>>>
>>>>
>>> I don't think l_f_e_e_s() will ever give you the head back.
>>>
>> Uh. Usually you have struct list_head in a struct and you point to
>> the first entry to loop over all. So if it doesn't return the first
>> entry, that would seem very counter-intuitive.
>>
>
> Linux list_heads aren't intuitive. The same structure is used for
> the container and for the nodes. Would have been better (and more
> typesafe) to have separate list_heads and list_nodes.
Hrm. Ok, I'll check by reading the source.
>
>>>> +
>>>> + invalidate_pte(vcpu, pte);
>>>> + }
>>>>
>>>>
>>> Does invalidate_pte() remove the pte? doesn't seem so, so you can
>>> drop the _safe iteration.
>>>
>> Yes, it does.
>>
>
> I don't see it?
>
>> static void invalidate_pte(struct hpte_cache *pte)
>> {
>> dprintk_mmu("KVM: Flushing SPT: 0x%lx (0x%llx) -> 0x%llx\n",
>> pte->pte.eaddr, pte->pte.vpage, pte->host_va);
>>
>> ppc_md.hpte_invalidate(pte->slot, pte->host_va,
>> MMU_PAGE_4K, MMU_SEGSIZE_256M,
>> false);
>> pte->host_va = 0;
>>
>> if (pte->pte.may_write)
>> kvm_release_pfn_dirty(pte->pfn);
>> else
>> kvm_release_pfn_clean(pte->pfn);
>> }
>
> Am I looking at old code?
Apparently. Check book3s_mmu_*.c
>
>>>> +
>>>> +/* Flush with mask 0xfffffffff */
>>>> +static void kvmppc_mmu_pte_vflush_short(struct kvm_vcpu *vcpu,
>>>> u64 guest_vp)
>>>> +{
>>>> + struct list_head *list;
>>>> + struct hpte_cache *pte, *tmp;
>>>> + u64 vp_mask = 0xfffffffffULL;
>>>> +
>>>> + list =&vcpu->arch.hpte_hash_vpte[kvmppc_mmu_hash_vpte
>>>> (guest_vp)];
>>>> +
>>>> + /* Check the list for matching entries */
>>>> + list_for_each_entry_safe(pte, tmp, list, list_vpte) {
>>>> + /* Jump over the helper entry */
>>>> + if (&pte->list_vpte == list)
>>>> + continue;
>>>>
>>>>
>>> list cannot contain list. Or maybe I don't understand the data
>>> structure. Isn't it multiple hash tables with lists holding
>>> matching ptes?
>>>
>> It is multiple hash tables with list_heads that are one element of
>> a list that contains the matching ptes. Usually you'd have
>>
>> struct x {
>> struct list_head;
>> int foo;
>> char bar;
>> };
>>
>> and you loop through each of those elements. What we have here is
>>
>> struct list_head hash[..];
>>
>> and some loose struct x's. The hash's "next" element is a struct x.
>>
>> The "normal" way would be to have "struct x hash[..];" but I
>> figured that eats too much space.
>>
>
> No, what you describe is quite normal. In fact, x86 kvm mmu is
> exactly like that, except we only have a single hash:
>
>> struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
I see.
>
> (another difference is using struct hlist_head instead of list_head,
> which I recommend since it saves space)
Hrm. I thought about this quite a bit before too, but that makes
invalidation more complicated, no? We always need to remember the
previous entry in a list.
>
>>>> +
>>>> + if ((pte->pte.raddr>= pa_start)&&
>>>> + (pte->pte.raddr< pa_end)) {
>>>> + invalidate_pte(vcpu, pte);
>>>> + }
>>>>
>>>>
>>> Extra braces.
>>>
>> Yeah, for two-lined if's I find it more readable that way. Is it
>> forbidden?
>>
>
> It's not forbidden, but it tends to attract "cleanup" patches, which
> are annoying. Best to conform to the coding style if there isn't a
> good reason not to.
>
> Personally I prefer braces for one-liners (yes they're ugly, but
> they're safer and easier to patch).
>
>>>> +int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu)
>>>> +{
>>>> + char kmem_name[128];
>>>> +
>>>> + /* init hpte slab cache */
>>>> + snprintf(kmem_name, 128, "kvm-spt-%p", vcpu);
>>>> + vcpu->arch.hpte_cache = kmem_cache_create(kmem_name,
>>>> + sizeof(struct hpte_cache), sizeof(struct hpte_cache), 0,
>>>> NULL);
>>>>
>>>>
>>> Why not one global cache?
>>>
>> You mean over all vcpus? Or over all VMs?
>
> Totally global. As in 'static struct kmem_cache *kvm_hpte_cache;'.
What would be the benefit?
>
>> Because this way they don't interfere. An operation on one vCPU
>> doesn't inflict anything on another. There's also no locking
>> necessary this way.
>>
>
> The slab writers have solved this for everyone, not just us.
> kmem_cache_alloc() will usually allocate from a per-cpu cache, so no
> interference and/or locking. See ____cache_alloc().
>
> If there's a problem in kmem_cache_alloc(), solve it there, don't
> introduce workarounds.
So you would still keep different hash arrays and everything, just
allocate the objects from a global pool? I still fail to see how that
benefits anyone.
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-28 9:12 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <20417D40-9345-485B-9201-8B3722B7457F@suse.de>
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& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>> +}
>>> +
>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>> +}
>>>
>>>
>> Still with the wierd coding style?
>>
> Not sure what's going on there. My editor displays it normally. Weird.
>
Try hitting 'save'.
>>> +static void kvmppc_mmu_pte_flush_all(struct kvm_vcpu *vcpu)
>>> +{
>>> + struct hpte_cache *pte, *tmp;
>>> + int i;
>>> +
>>> + for (i = 0; i< HPTEG_HASH_NUM_VPTE_LONG; i++) {
>>> + struct list_head *list =&vcpu->arch.hpte_hash_vpte_long[i];
>>> +
>>> + list_for_each_entry_safe(pte, tmp, list, list_vpte_long) {
>>> + /* Jump over the helper entry */
>>> + if (&pte->list_vpte_long == list)
>>> + continue;
>>>
>>>
>> I don't think l_f_e_e_s() will ever give you the head back.
>>
> Uh. Usually you have struct list_head in a struct and you point to the first entry to loop over all. So if it doesn't return the first entry, that would seem very counter-intuitive.
>
Linux list_heads aren't intuitive. The same structure is used for the
container and for the nodes. Would have been better (and more typesafe)
to have separate list_heads and list_nodes.
>>> +
>>> + invalidate_pte(vcpu, pte);
>>> + }
>>>
>>>
>> Does invalidate_pte() remove the pte? doesn't seem so, so you can drop the _safe iteration.
>>
> Yes, it does.
>
I don't see it?
> static void invalidate_pte(struct hpte_cache *pte)
> {
> dprintk_mmu("KVM: Flushing SPT: 0x%lx (0x%llx) -> 0x%llx\n",
> pte->pte.eaddr, pte->pte.vpage, pte->host_va);
>
> ppc_md.hpte_invalidate(pte->slot, pte->host_va,
> MMU_PAGE_4K, MMU_SEGSIZE_256M,
> false);
> pte->host_va = 0;
>
> if (pte->pte.may_write)
> kvm_release_pfn_dirty(pte->pfn);
> else
> kvm_release_pfn_clean(pte->pfn);
> }
Am I looking at old code?
>>> +
>>> +/* Flush with mask 0xfffffffff */
>>> +static void kvmppc_mmu_pte_vflush_short(struct kvm_vcpu *vcpu, u64 guest_vp)
>>> +{
>>> + struct list_head *list;
>>> + struct hpte_cache *pte, *tmp;
>>> + u64 vp_mask = 0xfffffffffULL;
>>> +
>>> + list =&vcpu->arch.hpte_hash_vpte[kvmppc_mmu_hash_vpte(guest_vp)];
>>> +
>>> + /* Check the list for matching entries */
>>> + list_for_each_entry_safe(pte, tmp, list, list_vpte) {
>>> + /* Jump over the helper entry */
>>> + if (&pte->list_vpte == list)
>>> + continue;
>>>
>>>
>> list cannot contain list. Or maybe I don't understand the data structure. Isn't it multiple hash tables with lists holding matching ptes?
>>
> It is multiple hash tables with list_heads that are one element of a list that contains the matching ptes. Usually you'd have
>
> struct x {
> struct list_head;
> int foo;
> char bar;
> };
>
> and you loop through each of those elements. What we have here is
>
> struct list_head hash[..];
>
> and some loose struct x's. The hash's "next" element is a struct x.
>
> The "normal" way would be to have "struct x hash[..];" but I figured that eats too much space.
>
No, what you describe is quite normal. In fact, x86 kvm mmu is exactly
like that, except we only have a single hash:
> struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
(another difference is using struct hlist_head instead of list_head,
which I recommend since it saves space)
>>> +
>>> + if ((pte->pte.raddr>= pa_start)&&
>>> + (pte->pte.raddr< pa_end)) {
>>> + invalidate_pte(vcpu, pte);
>>> + }
>>>
>>>
>> Extra braces.
>>
> Yeah, for two-lined if's I find it more readable that way. Is it forbidden?
>
It's not forbidden, but it tends to attract "cleanup" patches, which are
annoying. Best to conform to the coding style if there isn't a good
reason not to.
Personally I prefer braces for one-liners (yes they're ugly, but they're
safer and easier to patch).
>>> +int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu)
>>> +{
>>> + char kmem_name[128];
>>> +
>>> + /* init hpte slab cache */
>>> + snprintf(kmem_name, 128, "kvm-spt-%p", vcpu);
>>> + vcpu->arch.hpte_cache = kmem_cache_create(kmem_name,
>>> + sizeof(struct hpte_cache), sizeof(struct hpte_cache), 0, NULL);
>>>
>>>
>> Why not one global cache?
>>
> You mean over all vcpus? Or over all VMs?
Totally global. As in 'static struct kmem_cache *kvm_hpte_cache;'.
> Because this way they don't interfere. An operation on one vCPU doesn't inflict anything on another. There's also no locking necessary this way.
>
The slab writers have solved this for everyone, not just us.
kmem_cache_alloc() will usually allocate from a per-cpu cache, so no
interference and/or locking. See ____cache_alloc().
If there's a problem in kmem_cache_alloc(), solve it there, don't
introduce workarounds.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-28 8:55 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C285D1C.5060508@redhat.com>
On 28.06.2010, at 10:28, Avi Kivity wrote:
> 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.
>>=20
>> While this is a really simple implementation, it is probably the most
>> ineffective one possible. So instead, let's keep an array of lists =
around
>> that are indexed by a hash. This way each PTE can be added by 4 =
list_add,
>> removed by 4 list_del invocations and the search only needs to loop =
through
>> entries that share the same hash.
>>=20
>> This patch implements said lookup and exports generic functions that =
both
>> the 32-bit and 64-bit backend can use.
>>=20
>>=20
>> +
>> +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& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>> +}
>> +
>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>> + HPTEG_HASH_BITS_VPTE_LONG);
>> +}
>> =20
>=20
> Still with the wierd coding style?
Not sure what's going on there. My editor displays it normally. Weird.
>=20
>> +static void kvmppc_mmu_pte_flush_all(struct kvm_vcpu *vcpu)
>> +{
>> + struct hpte_cache *pte, *tmp;
>> + int i;
>> +
>> + for (i =3D 0; i< HPTEG_HASH_NUM_VPTE_LONG; i++) {
>> + struct list_head *list =
=3D&vcpu->arch.hpte_hash_vpte_long[i];
>> +
>> + list_for_each_entry_safe(pte, tmp, list, list_vpte_long) =
{
>> + /* Jump over the helper entry */
>> + if (&pte->list_vpte_long =3D=3D list)
>> + continue;
>> =20
>=20
> I don't think l_f_e_e_s() will ever give you the head back.
Uh. Usually you have struct list_head in a struct and you point to the =
first entry to loop over all. So if it doesn't return the first entry, =
that would seem very counter-intuitive.
>=20
>> +
>> + invalidate_pte(vcpu, pte);
>> + }
>> =20
>=20
> Does invalidate_pte() remove the pte? doesn't seem so, so you can =
drop the _safe iteration.
Yes, it does.
>=20
>> + }
>> +}
>> +
>> +void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, ulong guest_ea, =
ulong ea_mask)
>> +{
>> + u64 i;
>> +
>> + dprintk_mmu("KVM: Flushing %d Shadow PTEs: 0x%lx& 0x%lx\n",
>> + vcpu->arch.hpte_cache_count, guest_ea, ea_mask);
>> +
>> + guest_ea&=3D ea_mask;
>> +
>> + switch (ea_mask) {
>> + case ~0xfffUL:
>> + {
>> + struct list_head *list;
>> + struct hpte_cache *pte, *tmp;
>> +
>> + /* Find the list of entries in the map */
>> + list =
=3D&vcpu->arch.hpte_hash_pte[kvmppc_mmu_hash_pte(guest_ea)];
>> +
>> + /* Check the list for matching entries */
>> + list_for_each_entry_safe(pte, tmp, list, list_pte) {
>> + /* Jump over the helper entry */
>> + if (&pte->list_pte =3D=3D list)
>> + continue;
>> =20
>=20
> Same here.
>=20
>> +
>> + /* Invalidate matching PTE */
>> + if ((pte->pte.eaddr& ~0xfffUL) =3D=3D guest_ea)
>> + invalidate_pte(vcpu, pte);
>> + }
>> + break;
>> + }
>> =20
>=20
> Would be nice to put this block into a function.
Yup.
>=20
>> + case 0x0ffff000:
>> + /* 32-bit flush w/o segment, go through all possible =
segments */
>> + for (i =3D 0; i< 0x100000000ULL; i +=3D 0x10000000ULL)
>> + kvmppc_mmu_pte_flush(vcpu, guest_ea | i, =
~0xfffUL);
>> + break;
>> + case 0:
>> + /* Doing a complete flush -> start from scratch */
>> + kvmppc_mmu_pte_flush_all(vcpu);
>> + break;
>> + default:
>> + WARN_ON(1);
>> + break;
>> + }
>> +}
>> +
>> +/* Flush with mask 0xfffffffff */
>> +static void kvmppc_mmu_pte_vflush_short(struct kvm_vcpu *vcpu, u64 =
guest_vp)
>> +{
>> + struct list_head *list;
>> + struct hpte_cache *pte, *tmp;
>> + u64 vp_mask =3D 0xfffffffffULL;
>> +
>> + list =
=3D&vcpu->arch.hpte_hash_vpte[kvmppc_mmu_hash_vpte(guest_vp)];
>> +
>> + /* Check the list for matching entries */
>> + list_for_each_entry_safe(pte, tmp, list, list_vpte) {
>> + /* Jump over the helper entry */
>> + if (&pte->list_vpte =3D=3D list)
>> + continue;
>> =20
>=20
> list cannot contain list. Or maybe I don't understand the data =
structure. Isn't it multiple hash tables with lists holding matching =
ptes?
It is multiple hash tables with list_heads that are one element of a =
list that contains the matching ptes. Usually you'd have
struct x {
struct list_head;
int foo;
char bar;
};
and you loop through each of those elements. What we have here is
struct list_head hash[..];
and some loose struct x's. The hash's "next" element is a struct x.
The "normal" way would be to have "struct x hash[..];" but I figured =
that eats too much space.
>=20
>> +
>> + /* Invalidate matching PTEs */
>> + if ((pte->pte.vpage& vp_mask) =3D=3D guest_vp)
>> + invalidate_pte(vcpu, pte);
>> + }
>> +}
>> +
>>=20
>> +
>> +void kvmppc_mmu_pte_pflush(struct kvm_vcpu *vcpu, ulong pa_start, =
ulong pa_end)
>> +{
>> + struct hpte_cache *pte, *tmp;
>> + int i;
>> +
>> + dprintk_mmu("KVM: Flushing %d Shadow pPTEs: 0x%lx - 0x%lx\n",
>> + vcpu->arch.hpte_cache_count, pa_start, pa_end);
>> +
>> + for (i =3D 0; i< HPTEG_HASH_NUM_VPTE_LONG; i++) {
>> + struct list_head *list =
=3D&vcpu->arch.hpte_hash_vpte_long[i];
>> +
>> + list_for_each_entry_safe(pte, tmp, list, list_vpte_long) =
{
>> + /* Jump over the helper entry */
>> + if (&pte->list_vpte_long =3D=3D list)
>> + continue;
>> +
>> + if ((pte->pte.raddr>=3D pa_start)&&
>> + (pte->pte.raddr< pa_end)) {
>> + invalidate_pte(vcpu, pte);
>> + }
>> =20
>=20
> Extra braces.
Yeah, for two-lined if's I find it more readable that way. Is it =
forbidden?
>=20
>> + }
>> + }
>> +}
>> +
>>=20
>> +
>> +static void kvmppc_mmu_hpte_init_hash(struct list_head *hash_list, =
int len)
>> +{
>> + int i;
>> +
>> + for (i =3D 0; i< len; i++) {
>> + INIT_LIST_HEAD(&hash_list[i]);
>> + }
>> +}
>> =20
>=20
> Extra braces.
Yup.
>=20
>> +
>> +int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu)
>> +{
>> + char kmem_name[128];
>> +
>> + /* init hpte slab cache */
>> + snprintf(kmem_name, 128, "kvm-spt-%p", vcpu);
>> + vcpu->arch.hpte_cache =3D kmem_cache_create(kmem_name,
>> + sizeof(struct hpte_cache), sizeof(struct hpte_cache), 0, =
NULL);
>> =20
>=20
> Why not one global cache?
You mean over all vcpus? Or over all VMs? Because this way they don't =
interfere. An operation on one vCPU doesn't inflict anything on another. =
There's also no locking necessary this way.
Alex
^ permalink raw reply
* Re: [PATCH 18/26] KVM: PPC: KVM PV guest stubs
From: Avi Kivity @ 2010-06-28 8:33 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm-ppc, Matt Evans, KVM list
In-Reply-To: <AD79CD04-74CF-49B9-BACC-4C190DF5214A@suse.de>
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 need to guarantee they're in the RMO (first 8MB for the PS3).
>
> Even with the magic page in use, trapping instructions still works exactly as before, so we're only talking about a speed difference.
>
>
Yeah, that also answers my question re pv->nonpv transition.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 26/26] KVM: PPC: Add Documentation about PV interface
From: Avi Kivity @ 2010-06-28 8:32 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm-ppc, Milton Miller, KVM list
In-Reply-To: <4330E5DC-63C5-40EA-9E99-34EE58074D1A@suse.de>
On 06/28/2010 11:21 AM, Alexander Graf wrote:
>
> The other alternative I'd see is to reuse an instruction that is not sc. We could for example pull the mfpvr trick again, but pass a different magic value in the register this time that tells the hypervisor "this is a hypercall".
>
> Or we could reserve a different SPR. But from what I've seen there are already quite a lot of SPRs out there. More than available numbers :).
>
> The hypercall technique I used here is actually inspired by MOL. They use magic constants in r3 and r4 for their "OSI" identification. I'm frankly not sure what the best approach is, but considering that syscalls from the kernel lie in the guest kernel's hand, we could just declare any breakage a guest kernel bug.
>
>
Magic = liable to break without notice.
Given r0 is the architectural syscall number, and r3 is the Linux
syscall number, we can use a combination of r0 and r3, reserve r3 in
Linux, and hope that no one else uses our selection of r0.
Still smelly, but not as bad.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-28 8:28 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1277507817-626-2-git-send-email-agraf@suse.de>
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 most
> ineffective one possible. So instead, let's keep an array of lists around
> that are indexed by a hash. This way each PTE can be added by 4 list_add,
> removed by 4 list_del invocations and the search only needs to loop through
> entries that share the same hash.
>
> This patch implements said lookup and exports generic functions that both
> the 32-bit and 64-bit backend can use.
>
>
> +
> +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& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
> +}
> +
> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
> + return hash_64((vpage& 0xffffff000ULL)>> 12,
> + HPTEG_HASH_BITS_VPTE_LONG);
> +}
>
Still with the wierd coding style?
> +static void kvmppc_mmu_pte_flush_all(struct kvm_vcpu *vcpu)
> +{
> + struct hpte_cache *pte, *tmp;
> + int i;
> +
> + for (i = 0; i< HPTEG_HASH_NUM_VPTE_LONG; i++) {
> + struct list_head *list =&vcpu->arch.hpte_hash_vpte_long[i];
> +
> + list_for_each_entry_safe(pte, tmp, list, list_vpte_long) {
> + /* Jump over the helper entry */
> + if (&pte->list_vpte_long == list)
> + continue;
>
I don't think l_f_e_e_s() will ever give you the head back.
> +
> + invalidate_pte(vcpu, pte);
> + }
>
Does invalidate_pte() remove the pte? doesn't seem so, so you can drop
the _safe iteration.
> + }
> +}
> +
> +void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, ulong guest_ea, ulong ea_mask)
> +{
> + u64 i;
> +
> + dprintk_mmu("KVM: Flushing %d Shadow PTEs: 0x%lx& 0x%lx\n",
> + vcpu->arch.hpte_cache_count, guest_ea, ea_mask);
> +
> + guest_ea&= ea_mask;
> +
> + switch (ea_mask) {
> + case ~0xfffUL:
> + {
> + struct list_head *list;
> + struct hpte_cache *pte, *tmp;
> +
> + /* Find the list of entries in the map */
> + list =&vcpu->arch.hpte_hash_pte[kvmppc_mmu_hash_pte(guest_ea)];
> +
> + /* Check the list for matching entries */
> + list_for_each_entry_safe(pte, tmp, list, list_pte) {
> + /* Jump over the helper entry */
> + if (&pte->list_pte == list)
> + continue;
>
Same here.
> +
> + /* Invalidate matching PTE */
> + if ((pte->pte.eaddr& ~0xfffUL) == guest_ea)
> + invalidate_pte(vcpu, pte);
> + }
> + break;
> + }
>
Would be nice to put this block into a function.
> + case 0x0ffff000:
> + /* 32-bit flush w/o segment, go through all possible segments */
> + for (i = 0; i< 0x100000000ULL; i += 0x10000000ULL)
> + kvmppc_mmu_pte_flush(vcpu, guest_ea | i, ~0xfffUL);
> + break;
> + case 0:
> + /* Doing a complete flush -> start from scratch */
> + kvmppc_mmu_pte_flush_all(vcpu);
> + break;
> + default:
> + WARN_ON(1);
> + break;
> + }
> +}
> +
> +/* Flush with mask 0xfffffffff */
> +static void kvmppc_mmu_pte_vflush_short(struct kvm_vcpu *vcpu, u64 guest_vp)
> +{
> + struct list_head *list;
> + struct hpte_cache *pte, *tmp;
> + u64 vp_mask = 0xfffffffffULL;
> +
> + list =&vcpu->arch.hpte_hash_vpte[kvmppc_mmu_hash_vpte(guest_vp)];
> +
> + /* Check the list for matching entries */
> + list_for_each_entry_safe(pte, tmp, list, list_vpte) {
> + /* Jump over the helper entry */
> + if (&pte->list_vpte == list)
> + continue;
>
list cannot contain list. Or maybe I don't understand the data
structure. Isn't it multiple hash tables with lists holding matching ptes?
> +
> + /* Invalidate matching PTEs */
> + if ((pte->pte.vpage& vp_mask) == guest_vp)
> + invalidate_pte(vcpu, pte);
> + }
> +}
> +
>
> +
> +void kvmppc_mmu_pte_pflush(struct kvm_vcpu *vcpu, ulong pa_start, ulong pa_end)
> +{
> + struct hpte_cache *pte, *tmp;
> + int i;
> +
> + dprintk_mmu("KVM: Flushing %d Shadow pPTEs: 0x%lx - 0x%lx\n",
> + vcpu->arch.hpte_cache_count, pa_start, pa_end);
> +
> + for (i = 0; i< HPTEG_HASH_NUM_VPTE_LONG; i++) {
> + struct list_head *list =&vcpu->arch.hpte_hash_vpte_long[i];
> +
> + list_for_each_entry_safe(pte, tmp, list, list_vpte_long) {
> + /* Jump over the helper entry */
> + if (&pte->list_vpte_long == list)
> + continue;
> +
> + if ((pte->pte.raddr>= pa_start)&&
> + (pte->pte.raddr< pa_end)) {
> + invalidate_pte(vcpu, pte);
> + }
>
Extra braces.
> + }
> + }
> +}
> +
>
> +
> +static void kvmppc_mmu_hpte_init_hash(struct list_head *hash_list, int len)
> +{
> + int i;
> +
> + for (i = 0; i< len; i++) {
> + INIT_LIST_HEAD(&hash_list[i]);
> + }
> +}
>
Extra braces.
> +
> +int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu)
> +{
> + char kmem_name[128];
> +
> + /* init hpte slab cache */
> + snprintf(kmem_name, 128, "kvm-spt-%p", vcpu);
> + vcpu->arch.hpte_cache = kmem_cache_create(kmem_name,
> + sizeof(struct hpte_cache), sizeof(struct hpte_cache), 0, NULL);
>
Why not one global cache?
> +
> + /* init hpte lookup hashes */
> + kvmppc_mmu_hpte_init_hash(vcpu->arch.hpte_hash_pte,
> + ARRAY_SIZE(vcpu->arch.hpte_hash_pte));
> + kvmppc_mmu_hpte_init_hash(vcpu->arch.hpte_hash_vpte,
> + ARRAY_SIZE(vcpu->arch.hpte_hash_vpte));
> + kvmppc_mmu_hpte_init_hash(vcpu->arch.hpte_hash_vpte_long,
> + ARRAY_SIZE(vcpu->arch.hpte_hash_vpte_long));
> +
> + return 0;
> +}
>
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 18/26] KVM: PPC: KVM PV guest stubs
From: Alexander Graf @ 2010-06-28 8:23 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, kvm-ppc, Matt Evans, KVM list
In-Reply-To: <4C285A13.8070208@redhat.com>
On 28.06.2010, at 10:15, Avi Kivity wrote:
> On 06/28/2010 09:33 AM, Alexander Graf wrote:
>>=20
>>> Could you do something similar in module_finalize() to patch loaded =
modules' .text sections?
>>> =20
>> I could, but do we need it? I objdump -d | grep'ed all my modules and =
didn't find any need to do so.
>> =20
>=20
> 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 need to guarantee they're in the RMO =
(first 8MB for the PS3).
Even with the magic page in use, trapping instructions still works =
exactly as before, so we're only talking about a speed difference.
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox