* Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: David Gibson @ 2012-01-16 8:18 UTC (permalink / raw)
To: K.Prasad; +Cc: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20111222093447.GD26407@in.ibm.com>
On Thu, Dec 22, 2011 at 03:04:47PM +0530, K.Prasad wrote:
> On Wed, Dec 21, 2011 at 11:55:02AM +1100, David Gibson wrote:
> > On Thu, Dec 08, 2011 at 04:53:30PM +0530, K.Prasad wrote:
> > > While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts
> > > PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not intimated to the
> > > user-space debuggers (like GDB) who may want to use it. Hence we introduce a
> > > new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on the
> > > "features" member of "struct ppc_debug_info" to advertise support for the
> > > same on Book3E PowerPC processors.
> >
> > Hrm. I had assumed the reason there wasn't a feature bit for EXACT
> > originally was that EXACT breakpoints were *always* supposed to be
> > supported by the new interface.
> >
>
> Okay. Although BookS doesn't support EXACT breakpoints, it is possible
> (after the introduction of new hw-breakpoint interfaces) to request for
> a breakpoint of length 1 Byte.
Hrm. An EXACT breakpoint is not exactly the same as a range
breakpoint of length 1 (consider unaligned accesses). But despite
that, it should be possible to implement exact breakpoints on Book3S
server hardware with some software filtering.
And since that leaves no hardware that *can't* implement exact
breakpoints (directly or indirectly), I'm not yet convinced of the
need for a flag bit.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Alexander Graf @ 2012-01-16 13:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20111220102257.GC5626@bloggs.ozlabs.ibm.com>
On 20.12.2011, at 11:22, Paul Mackerras wrote:
> The PAPR API allows three sorts of per-virtual-processor areas to be
> registered (VPA, SLB shadow buffer, and dispatch trace log), and
> furthermore, these can be registered and unregistered for another
> virtual CPU. Currently we just update the vcpu fields pointing to
> these areas at the time of registration or unregistration. If this
> is done on another vcpu, there is the possibility that the target vcpu
> is using those fields at the time and could end up using a bogus
> pointer and corrupting memory.
>=20
> This fixes the race by making the target cpu itself do the update, so
> we can be sure that the update happens at a time when the fields =
aren't
> being used. These are updated from a set of 'next_*' fields, which
> are protected by a spinlock. (We could have just taken the spinlock
> when using the vpa, slb_shadow or dtl fields, but that would mean
> taking the spinlock on every guest entry and exit.)
>=20
> The code in do_h_register_vpa now takes the spinlock and updates the
> 'next_*' fields. There is also a set of '*_pending' flags to indicate
> that an update is pending.
>=20
> This also changes 'struct dtl' (which was undefined) to 'struct =
dtl_entry',
> which is what the rest of the kernel uses.
>=20
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/include/asm/kvm_host.h | 15 +++-
> arch/powerpc/kvm/book3s_hv.c | 167 =
+++++++++++++++++++++++++----------
> 2 files changed, 131 insertions(+), 51 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/kvm_host.h =
b/arch/powerpc/include/asm/kvm_host.h
> index 1cb6e52..b1126c1 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -82,7 +82,7 @@ struct kvm_vcpu;
>=20
> struct lppaca;
> struct slb_shadow;
> -struct dtl;
> +struct dtl_entry;
>=20
> struct kvm_vm_stat {
> u32 remote_tlb_flush;
> @@ -449,9 +449,18 @@ struct kvm_vcpu_arch {
> u32 last_inst;
>=20
> struct lppaca *vpa;
> + struct lppaca *next_vpa;
> struct slb_shadow *slb_shadow;
> - struct dtl *dtl;
> - struct dtl *dtl_end;
> + struct slb_shadow *next_slb_shadow;
> + struct dtl_entry *dtl;
> + struct dtl_entry *dtl_end;
> + struct dtl_entry *dtl_ptr;
> + struct dtl_entry *next_dtl;
> + struct dtl_entry *next_dtl_end;
> + u8 vpa_pending;
> + u8 slb_shadow_pending;
> + u8 dtl_pending;
> + spinlock_t vpa_update_lock;
>=20
> wait_queue_head_t *wqp;
> struct kvmppc_vcore *vcore;
> diff --git a/arch/powerpc/kvm/book3s_hv.c =
b/arch/powerpc/kvm/book3s_hv.c
> index c11d960..6f6e88d 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -140,7 +140,7 @@ static unsigned long do_h_register_vpa(struct =
kvm_vcpu *vcpu,
> {
> struct kvm *kvm =3D vcpu->kvm;
> unsigned long len, nb;
> - void *va;
> + void *va, *free_va, *tvpa, *dtl, *ss;
> struct kvm_vcpu *tvcpu;
> int err =3D H_PARAMETER;
>=20
> @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct =
kvm_vcpu *vcpu,
> flags &=3D 7;
> if (flags =3D=3D 0 || flags =3D=3D 4)
This could probably use a new variable name. Also, what do 0 and 4 mean? =
Constant defines would be nice here.
> return H_PARAMETER;
> + free_va =3D va =3D NULL;
> + len =3D 0;
> if (flags < 4) {
> if (vpa & 0x7f)
> return H_PARAMETER;
> @@ -165,65 +167,122 @@ static unsigned long do_h_register_vpa(struct =
kvm_vcpu *vcpu,
[pasted from real source]
> va =3D kvmppc_pin_guest_page(kvm, vpa, &nb);
Here you're pinning the page, setting va to that temporarily available =
address.
[...]
> len =3D *(unsigned short *)(va + 4);
This is a condition on (flags <=3D 1). We bail out on flags =3D=3D 0 a =
few lines up. Just move this whole thing into the respective function =
handlers.
> else
> len =3D *(unsigned int *)(va + 4);
va + 4 isn't really descriptive. Is this a defined struct? Why not =
actually define one which you can just read data from? Or at least make =
this a define too. Reading random numbers in code is barely readable.
> + free_va =3D va;
Now free_va is the temporarily available address.
> if (len > nb)
> goto out_unpin;
> - switch (flags) {
> - case 1: /* register VPA */
> - if (len < 640)
> - goto out_unpin;
> - if (tvcpu->arch.vpa)
> - kvmppc_unpin_guest_page(kvm, =
vcpu->arch.vpa);
> - tvcpu->arch.vpa =3D va;
> - init_vpa(vcpu, va);
> - break;
> - case 2: /* register DTL */
> - if (len < 48)
> - goto out_unpin;
> - len -=3D len % 48;
> - if (tvcpu->arch.dtl)
> - kvmppc_unpin_guest_page(kvm, =
vcpu->arch.dtl);
> - tvcpu->arch.dtl =3D va;
> - tvcpu->arch.dtl_end =3D va + len;
> + }
> +
> + spin_lock(&tvcpu->arch.vpa_update_lock);
> +
> + switch (flags) {
> + case 1: /* register VPA */
Yeah, these could also use defines :)
> + if (len < 640)
> break;
> - case 3: /* register SLB shadow buffer */
> - if (len < 16)
> - goto out_unpin;
> - if (tvcpu->arch.slb_shadow)
> - kvmppc_unpin_guest_page(kvm, =
vcpu->arch.slb_shadow);
> - tvcpu->arch.slb_shadow =3D va;
> + free_va =3D tvcpu->arch.next_vpa;
> + tvcpu->arch.next_vpa =3D va;
Now you're setting next_vpa to this temporarily available address? But =
next_vpa will be used after va is getting free'd, no? Or is that why you =
have free_va?
Wouldn't it be easier to just map it every time we actually use it and =
only shove the GPA around? We could basically save ourselves a lot of =
the logic here.
Alex
^ permalink raw reply
* Re: [KVM PATCH 2/2] KVM: PPC: Book3S HV: Report stolen time to guest through dispatch trace log
From: Alexander Graf @ 2012-01-16 13:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <20111220103723.GD5626@bloggs.ozlabs.ibm.com>
On 20.12.2011, at 11:37, Paul Mackerras wrote:
> This adds code to measure "stolen" time per virtual core in units of
> timebase ticks, and to report the stolen time to the guest using the
> dispatch trace log (DTL). The guest can register an area of memory
> for the DTL for a given vcpu. The DTL is a ring buffer where KVM
> fills in one entry every time it enters the guest for that vcpu.
>
> Stolen time is measured as time when the virtual core is not running,
> either because the vcore is not runnable (e.g. some of its vcpus are
> executing elsewhere in the kernel or in userspace), or when the vcpu
> thread that is running the vcore is preempted. This includes time
> when all the vcpus are idle (i.e. have executed the H_CEDE hypercall),
> which is OK because the guest accounts stolen time while idle as idle
> time.
>
> Each vcpu keeps a record of how much stolen time has been reported to
> the guest for that vcpu so far. When we are about to enter the guest,
> we create a new DTL entry (if the guest vcpu has a DTL) and report the
> difference between total stolen time for the vcore and stolen time
> reported so far for the vcpu as the "enqueue to dispatch" time in the
> DTL entry.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch makes sense and looks good to me :)
Alex
^ permalink raw reply
* Re: [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h
From: Alexander Graf @ 2012-01-16 13:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Avi Kivity, kvm-ppc, kvm
In-Reply-To: <20120113060951.GB15875@drongo>
On 13.01.2012, at 07:09, Paul Mackerras wrote:
> This moves __gfn_to_memslot() and search_memslots() from kvm_main.c to
> kvm_host.h to reduce the code duplication caused by the need for
> non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c to call
> gfn_to_memslot() in real mode.
>
> Rather than putting gfn_to_memslot() itself in a header, which would
> lead to increased code size, this puts __gfn_to_memslot() in a header.
> Then, the non-modular uses of gfn_to_memslot() are changed to call
> __gfn_to_memslot() instead. This way there is only one place in the
> source code that needs to be changed should the gfn_to_memslot()
> implementation need to be modified.
>
> On powerpc, the Book3S HV style of KVM has code that is called from
> real mode which needs to call gfn_to_memslot() and thus needs this.
> (Module code is allocated in the vmalloc region, which can't be
> accessed in real mode.)
>
> With this, we can remove builtin_gfn_to_memslot() from book3s_hv_rm_mmu.c.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Avi?
Alex
^ permalink raw reply
* Re: [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h
From: Avi Kivity @ 2012-01-16 13:21 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, Paul Mackerras, kvm, kvm-ppc
In-Reply-To: <2F423C68-0AAD-4FC4-999B-DEEECC4C631F@suse.de>
On 01/16/2012 03:18 PM, Alexander Graf wrote:
> Avi?
ACK!
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h
From: Alexander Graf @ 2012-01-16 13:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Avi Kivity, kvm-ppc, kvm
In-Reply-To: <20120113060951.GB15875@drongo>
On 13.01.2012, at 07:09, Paul Mackerras wrote:
> This moves __gfn_to_memslot() and search_memslots() from kvm_main.c to
> kvm_host.h to reduce the code duplication caused by the need for
> non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c to call
> gfn_to_memslot() in real mode.
>=20
> Rather than putting gfn_to_memslot() itself in a header, which would
> lead to increased code size, this puts __gfn_to_memslot() in a header.
> Then, the non-modular uses of gfn_to_memslot() are changed to call
> __gfn_to_memslot() instead. This way there is only one place in the
> source code that needs to be changed should the gfn_to_memslot()
> implementation need to be modified.
>=20
> On powerpc, the Book3S HV style of KVM has code that is called from
> real mode which needs to call gfn_to_memslot() and thus needs this.
> (Module code is allocated in the vmalloc region, which can't be
> accessed in real mode.)
>=20
> With this, we can remove builtin_gfn_to_memslot() from =
book3s_hv_rm_mmu.c.
Which tree is this against? I got this diff between your patch and the =
patch when applied on my tree:
-@@ -97,7 +78,7 @@ static void remove_revmap_chain(struct kvm *kvm, long =
pte_index,
- rev =3D real_vmalloc_addr(&kvm->arch.revmap[pte_index]);
- ptel =3D rev->guest_rpte;
+@@ -99,7 +80,7 @@ static void remove_revmap_chain(struct kvm *kvm, long =
pte_index,
+ rcbits =3D hpte_r & (HPTE_R_R | HPTE_R_C);
+ ptel =3D rev->guest_rpte |=3D rcbits;
Since this is completely unrelated to the actual change, I'll apply the =
patch either way. It'd just be interesting to know.
Alex
^ permalink raw reply
* Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Timur Tabi @ 2012-01-16 16:12 UTC (permalink / raw)
To: Michael Neuling
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
Florian Tobias Schandinat
In-Reply-To: <21370.1326683320@neuling.org>
Michael Neuling wrote:
> drivers/video/fsl-diu-fb.c: In function 'fsl_diu_suspend':
> drivers/video/fsl-diu-fb.c:1435: error: incompatible type for argument 1 of 'disable_lcdc'
> drivers/video/fsl-diu-fb.c:592: note: expected 'struct fb_info *' but argument is of type 'struct fb_info'
> drivers/video/fsl-diu-fb.c: In function 'fsl_diu_resume':
> drivers/video/fsl-diu-fb.c:1445: error: incompatible type for argument 1 of 'enable_lcdc'
> drivers/video/fsl-diu-fb.c:583: note: expected 'struct fb_info *' but argument is of type 'struct fb_info'
I figured out what the problem is. I never compiled a configuration with
CONFIG_PM enabled. For some reason, CONFIG_PM is disabled when SMP is
enabled, and I only tested with mpc85xx_smp_defconfig.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Timur Tabi @ 2012-01-16 16:12 UTC (permalink / raw)
To: Michael Neuling, Florian Tobias Schandinat
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org
In-Reply-To: <21370.1326683320@neuling.org>
Michael Neuling wrote:
> From: Michael Neuling <mikey@neuling.org>
>
> [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
>
> Fix a compiler errors introduced in:
> commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
> Author: Timur Tabi <timur@freescale.com>
> drivers/video: fsl-diu-fb: merge all allocated data into one block
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Kumar Gala @ 2012-01-16 19:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <1326435694.23910.229.camel@pasglop>
On Jan 13, 2012, at 12:21 AM, Benjamin Herrenschmidt wrote:
> Hi Linus !
>=20
> Please pull this couple of important bug fixes (a commit
> that went in breaks booting on some machines, this fixes
> it properly).
>=20
> Thanks !
>=20
> Cheers,
> Ben.
>=20
> The following changes since commit =
7b3480f8b701170c046e1ed362946f5f0d005e13:
>=20
> Merge tag 'for-linus-3.3' of git://git.infradead.org/mtd-2.6 =
(2012-01-10 13:45:22 -0800)
>=20
> are available in the git repository at:
>=20
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>=20
> Anton Blanchard (1):
> powerpc: Fix RCU idle and hcall tracing
>=20
> Li Zhong (1):
> powerpc: Fix unpaired __trace_hcall_entry and __trace_hcall_exit
>=20
> arch/powerpc/kernel/idle.c | 12 ++----------
> arch/powerpc/platforms/pseries/hvCall.S | 3 ++-
> arch/powerpc/platforms/pseries/lpar.c | 14 ++++++++++----
> 3 files changed, 14 insertions(+), 15 deletions(-)
Ben,
This doesnt appear to have the compile fix for p1022_ds.c.
- k=
^ permalink raw reply
* Re: [PATCH 1/2 v2] powerpc/85xx: Add dts for P1021RDB-PC board
From: Scott Wood @ 2012-01-16 19:36 UTC (permalink / raw)
To: Xu Jiucheng; +Cc: Matthew McClintock, linuxppc-dev
In-Reply-To: <1326697208-1519-1-git-send-email-B37781@freescale.com>
On 01/16/2012 01:00 AM, Xu Jiucheng wrote:
> + mdio@24000 {
> + phy0: ethernet-phy@0 {
> + interrupt-parent = <&mpic>;
> + interrupts = <3 1>;
> + reg = <0x0>;
> + };
> +
> + phy1: ethernet-phy@1 {
> + interrupt-parent = <&mpic>;
> + interrupts = <2 1>;
> + reg = <0x1>;
> + };
pq3-mpic.dtsi (included by p1021si-post.dtsi) uses 4-cell interrupt
specifiers, so they need to be used everywhere.
-Scott
^ permalink raw reply
* Re: Cannot wake-up from standby with MPC8313
From: Scott Wood @ 2012-01-16 20:22 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4F103C17.3080003@aimvalley.nl>
On 01/13/2012 08:13 AM, Norbert van Bolhuis wrote:
> I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
> but they do not change just before entering standby (via
> mpc6xx_enter_standby
> which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
> not pending.
>
> I tried to log to physical memory to see what's going on whenever the
> board fails to wake-up.
> (I can examine physical memory after CPU is stuck in sleep, by connecting
> a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
> re-configured)
Are you sure this isn't going to disturb anything? Why does U-Boot need
to be involved, and the SDRAM reconfigured?
> It looks like an interupt does occur, but do_IRQ seems to be stuck
> in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.
Stuck as in the load never completes, or as in ipic_get_irq() gets
called repeatedly? If the latter, what value is it reading out? Is the
interrupt pending in SIPNR at this point?
-Scott
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-01-16 20:27 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <5742F9CB-77C0-40AF-9719-B55AB2C17D8C@kernel.crashing.org>
On Mon, 2012-01-16 at 13:21 -0600, Kumar Gala wrote:
> This doesnt appear to have the compile fix for p1022_ds.c.
I must have pulled it into the wrong branch or something... I'll do a
new one after LCA.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Michael Bohan @ 2012-01-17 2:43 UTC (permalink / raw)
To: Rob Herring
Cc: sfr, Russell King, linux-kernel, linux-arm-msm, Thomas Gleixner,
linuxppc-dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <4F0F7B60.5040701@gmail.com>
On 1/12/2012 4:31 PM, Rob Herring wrote:
> You have removed the irq_alloc_descs call from the GIC which is a step
> backwards. Several of the ARM DT enabled platforms are at the point they
> can fully support dynamic virq base for each irqchip. I changed the
> domain from legacy to linear and got things working. The issue with
> linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
> all nr_irqs are allocated at boot time before any controller is
> initialized. The only platform with a GIC and requiring SPARSE_IRQ is
> shmobile, but it is also the only one that calls irq_alloc_desc
> functions for it's interrupts. So I think we are okay there. The problem
> occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
> with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
> should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
> on ARM for platforms that don't require it. All the platforms with a GIC
> have active work to convert to DT (except shmobile which I think is
> okay), so it's a temporary issue.
I thought I would chime in here since this is very relevant to what
we're doing on arm-msm. We are using Device Tree with the GIC. We also
have several other interrupt chips, including one for a device that
supports up to 32768 sparsely populated interrupts. Hence we are using
SPARSE_IRQ to only allocate irq_descs on demand for this device.
To support this, I had to modify irq_domain_add() to not 'register' the
domain. Eg. simply add the domain to the list, but do not initialize the
hwirq values in the irq_data structure. This is because our irq_descs
are allocated later based on Device Tree topology. This information is
not available during of_irq_init().
But then I was left with the problem of managing irq_bases for multiple
chip drivers. The problem with irq_alloc_desc() is that it doesn't allow
you to allocate a range without allocating its corresponding resources.
Meaning, I'd like to reserve a chunk of virqs, but not utilize any
resources for them until I know they're necessary. This is where
irq_domains comes in.
In order to support this properly, I decided it made sense to add a new
API called irq_domain_find_free_range(). This walks the irq domains
list, now sorted by domain->irq_base, to find the first available range
of the size specified. Thus every irq chip then only needs to know the
worst case number of interrupts it could ever support. The framework
takes care of finding the specific virq base. And all of this
information is available at of_irq_init() time. This all assumes that
every chip driver registers with irq_domains.
I was planning on sending these patches out, but it seems like with
Grant's patches, they may no longer be up to date. I was curious if any
thought was given to supporting configurations like this the one I
mentioned with the advent of these patches. I am happy to help test if
you can steer me in the right direction.
Thanks,
Mike
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Benjamin Herrenschmidt @ 2012-01-17 3:42 UTC (permalink / raw)
To: Michael Bohan
Cc: sfr, Russell King, linux-arm-msm, linux-kernel, Rob Herring,
Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4F14E05C.30207@codeaurora.org>
On Mon, 2012-01-16 at 18:43 -0800, Michael Bohan wrote:
>
> I was planning on sending these patches out, but it seems like with
> Grant's patches, they may no longer be up to date. I was curious if any
> thought was given to supporting configurations like this the one I
> mentioned with the advent of these patches. I am happy to help test if
> you can steer me in the right direction.
I haven't had a chance to look in detail at what Grant is doing in his
latest series, but the ppc domain scheme that he's basing it on has the
concept of sparse interrupt domains.
For these, we use a radix tree for the reverse map (we do not rely on a
linear range) and we "allocate" linux IRQ numbers on-demand as we create
mapping for individual HW interrupts.
Cheers,
Ben.
^ permalink raw reply
* AUTO: Michael Barry is out of the office (returning 18/01/2012)
From: Michael Barry @ 2012-01-17 4:01 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 18/01/2012.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 89, Issue 49" sent on 17/1/2012 1:00:02.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* Re: [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h
From: Paul Mackerras @ 2012-01-17 5:02 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, Avi Kivity, kvm-ppc, kvm
In-Reply-To: <E1127F8D-E42E-44C7-B869-2B46C2812C8F@suse.de>
On Mon, Jan 16, 2012 at 02:30:41PM +0100, Alexander Graf wrote:
> Which tree is this against? I got this diff between your patch and the patch when applied on my tree:
It's against your tree (previously) plus my first 13-patch series, but
not the second series of 5 patches, which presumably why you got the
difference. Sounds like you got it applied OK; if not let me know and
I'll rebase against your current tree.
Paul.
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Paul Mackerras @ 2012-01-17 5:56 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <1A57B98F-A4C7-457D-A52A-4F67D5902E32@suse.de>
On Mon, Jan 16, 2012 at 02:04:29PM +0100, Alexander Graf wrote:
>
> On 20.12.2011, at 11:22, Paul Mackerras wrote:
> > @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct kvm_vcpu *vcpu,
> > flags &= 7;
> > if (flags == 0 || flags == 4)
>
> This could probably use a new variable name. Also, what do 0 and 4 mean? Constant defines would be nice here.
Those constants are defined in PAPR as being a subfunction code
indicating what sort of area and whether it is to be registered or
unregistered. I'll make up some names for them.
> [pasted from real source]
> > va = kvmppc_pin_guest_page(kvm, vpa, &nb);
>
> Here you're pinning the page, setting va to that temporarily available address.
Well, it's not just temporarily available, it's available until we
unpin it, since we increment the page count, which inhibits migration.
> > len = *(unsigned int *)(va + 4);
>
> va + 4 isn't really descriptive. Is this a defined struct? Why not actually define one which you can just read data from? Or at least make this a define too. Reading random numbers in code is barely readable.
It's not really a struct, at least not one that is used for anything
else. PAPR defines that the length of the buffer has to be placed in
the second 32-bit word at registration time.
>
> > + free_va = va;
>
> Now free_va is the temporarily available address.
...
> > + free_va = tvcpu->arch.next_vpa;
> > + tvcpu->arch.next_vpa = va;
>
> Now you're setting next_vpa to this temporarily available address? But next_vpa will be used after va is getting free'd, no? Or is that why you have free_va?
Yes; here we are freeing any previously-set value of next_vpa. The
idea of free_va is that it is initially set to va so that we correctly
unpin va if any error occurs. But if there is no error, va gets put
into next_vpa and we free anything that was previously in next_vpa
instead.
>
> Wouldn't it be easier to just map it every time we actually use it and only shove the GPA around? We could basically save ourselves a lot of the logic here.
There are fields in the VPA that we really want to be able to access
from real mode, for instance the fields that indicate whether we need
to save the FPR and/or VR values. As far as the DTL is concerned, we
could in fact use copy_to_user to access it, so it doesn't strictly
need to be pinned. We don't currently use the slb_shadow buffer, but
if we did we would need to access it from real mode, since we would be
reading it in order to set up guest SLB entries.
The other thing is that the VPA registration/unregistration is only
done a few times in the life of the guest, whereas we use the VPAs
constantly while the guest is running. So it is more efficient to do
more of the work at registration time to make it quicker to access the
VPAs.
I'll send revised patches. There's a small change I want to make to
patch 2 to avoid putting a very large stolen time value in the first
entry that gets put in after the DTL is registered, which can happen
currently if the DTL gets registered some time after the guest started
running.
Paul.
^ permalink raw reply
* Re: [PATCH 1/2 v2] powerpc/85xx: Add dts for P1021RDB-PC board
From: Xu Jiucheng @ 2012-01-17 7:30 UTC (permalink / raw)
To: Scott Wood; +Cc: Matthew McClintock, linuxppc-dev
In-Reply-To: <4F147C49.40008@freescale.com>
On Mon, 2012-01-16 at 13:36 -0600, Scott Wood wrote:
> On 01/16/2012 01:00 AM, Xu Jiucheng wrote:
> > + mdio@24000 {
> > + phy0: ethernet-phy@0 {
> > + interrupt-parent = <&mpic>;
> > + interrupts = <3 1>;
> > + reg = <0x0>;
> > + };
> > +
> > + phy1: ethernet-phy@1 {
> > + interrupt-parent = <&mpic>;
> > + interrupts = <2 1>;
> > + reg = <0x1>;
> > + };
>
> pq3-mpic.dtsi (included by p1021si-post.dtsi) uses 4-cell interrupt
> specifiers, so they need to be used everywhere.
>
> -Scott
ok.
Thanks,
Jiucheng
^ permalink raw reply
* [PATCH 2/2 v3] powerpc/85xx: Added P1021RDB-PC Platform support
From: Xu Jiucheng @ 2012-01-17 8:01 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Xu Jiucheng
In-Reply-To: <1326787291-8922-1-git-send-email-B37781@freescale.com>
Signed-off-by: Xu Jiucheng <B37781@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index ccf520e..1273381 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -90,6 +90,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
machine_device_initcall(p2020_rdb, mpc85xx_common_publish_devices);
machine_device_initcall(p1020_rdb, mpc85xx_common_publish_devices);
+machine_device_initcall(p1021_rdb_pc, mpc85xx_common_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -112,6 +113,15 @@ static int __init p1020_rdb_probe(void)
return 0;
}
+static int __init p1021_rdb_pc_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,P1021RDB-PC"))
+ return 1;
+ return 0;
+}
+
define_machine(p2020_rdb) {
.name = "P2020 RDB",
.probe = p2020_rdb_probe,
@@ -139,3 +149,17 @@ define_machine(p1020_rdb) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(p1021_rdb_pc) {
+ .name = "P1021 RDB-PC",
+ .probe = p1021_rdb_pc_probe,
+ .setup_arch = mpc85xx_rdb_setup_arch,
+ .init_IRQ = mpc85xx_rdb_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.6.4
^ permalink raw reply related
* [PATCH 1/2 v3] powerpc/85xx: Added dts for P1021RDB-PC board
From: Xu Jiucheng @ 2012-01-17 8:01 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Matthew McClintock, Xu Jiucheng
P1021RDB-PC Overview
-----------------
1Gbyte DDR3 (on board DDR)
16Mbyte NOR flash
32Mbyte eSLC NAND Flash
256 Kbit M24256 I2C EEPROM
128 Mbit SPI Flash memory
Real-time clock on I2C bus
SD/MMC connector to interface with the SD memory card
PCIex
- x1 PCIe slot or x1 PCIe to dual SATA controller
- x1 mini-PCIe slot
USB 2.0
- ULPI PHY interface: SMSC USB3300 USB PHY and Genesys Logic=E2=80=99=
s GL850A
- Two USB2.0 Type A receptacles
- One USB2.0 signal to Mini PCIe slot
eTSEC1: Connected to RGMII PHY VSC7385
eTSEC2: Connected to SGMII PHY VSC8221
eTSEC3: Connected to SGMII PHY AR8021
DUART interface: supports two UARTs up to 115200 bps for console display
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Xu Jiucheng <B37781@freescale.com>
---
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 4 +
arch/powerpc/boot/dts/p1021rdb.dts | 96 +++++++++++
arch/powerpc/boot/dts/p1021rdb.dtsi | 236 +++++++++++++++++++++=
++++++
arch/powerpc/boot/dts/p1021rdb_36b.dts | 96 +++++++++++
4 files changed, 432 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1021rdb.dts
create mode 100644 arch/powerpc/boot/dts/p1021rdb.dtsi
create mode 100644 arch/powerpc/boot/dts/p1021rdb_36b.dts
diff --git a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi b/arch/powerpc/b=
oot/dts/fsl/p1021si-post.dtsi
index 38ba54d..b7929c9 100644
--- a/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
@@ -144,6 +144,10 @@
/include/ "pq3-usb2-dr-0.dtsi"
=20
/include/ "pq3-esdhc-0.dtsi"
+ sdhc@2e000 {
+ sdhci,auto-cmd12;
+ };
+
/include/ "pq3-sec3.3-0.dtsi"
=20
/include/ "pq3-mpic.dtsi"
diff --git a/arch/powerpc/boot/dts/p1021rdb.dts b/arch/powerpc/boot/dts/p=
1021rdb.dts
new file mode 100644
index 0000000..90b6b4c
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb.dts
@@ -0,0 +1,96 @@
+/*
+ * P1021 RDB Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in=
the
+ * documentation and/or other materials provided with the distribu=
tion.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote pro=
ducts
+ * derived from this software without specific prior written permi=
ssion.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1021si-pre.dtsi"
+/ {
+ model =3D "fsl,P1021RDB";
+ compatible =3D "fsl,P1021RDB-PC";
+
+ memory {
+ device_type =3D "memory";
+ };
+
+ lbc: localbus@ffe05000 {
+ reg =3D <0 0xffe05000 0 0x1000>;
+
+ /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+ ranges =3D <0x0 0x0 0x0 0xef000000 0x01000000
+ 0x1 0x0 0x0 0xff800000 0x00040000
+ 0x2 0x0 0x0 0xffb00000 0x00020000>;
+ };
+
+ soc: soc@ffe00000 {
+ ranges =3D <0x0 0x0 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@ffe09000 {
+ ranges =3D <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+ reg =3D <0 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges =3D <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ reg =3D <0 0xffe0a000 0 0x1000>;
+ ranges =3D <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges =3D <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ qe: qe@ffe80000 {
+ ranges =3D <0x0 0x0 0xffe80000 0x40000>;
+ reg =3D <0 0xffe80000 0 0x480>;
+ brg-frequency =3D <0>;
+ bus-frequency =3D <0>;
+ };
+};
+
+/include/ "p1021rdb.dtsi"
+/include/ "fsl/p1021si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1021rdb.dtsi b/arch/powerpc/boot/dts/=
p1021rdb.dtsi
new file mode 100644
index 0000000..afb6906
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb.dtsi
@@ -0,0 +1,236 @@
+/*
+ * P1021 RDB Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in=
the
+ * documentation and/or other materials provided with the distribu=
tion.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote pro=
ducts
+ * derived from this software without specific prior written permi=
ssion.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND AN=
Y
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+ nor@0,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "cfi-flash";
+ reg =3D <0x0 0x0 0x1000000>;
+ bank-width =3D <2>;
+ device-width =3D <1>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385 Switch firmware */
+ reg =3D <0x0 0x00040000>;
+ label =3D "NOR Vitesse-7385 Firmware";
+ read-only;
+ };
+
+ partition@40000 {
+ /* 256KB for DTB Image */
+ reg =3D <0x00040000 0x00040000>;
+ label =3D "NOR DTB Image";
+ };
+
+ partition@80000 {
+ /* 3.5 MB for Linux Kernel Image */
+ reg =3D <0x00080000 0x00380000>;
+ label =3D "NOR Linux Kernel Image";
+ };
+
+ partition@400000 {
+ /* 11MB for JFFS2 based Root file System */
+ reg =3D <0x00400000 0x00b00000>;
+ label =3D "NOR JFFS2 Root File System";
+ };
+
+ partition@f00000 {
+ /* This location must not be altered */
+ /* 512KB for u-boot Bootloader Image */
+ /* 512KB for u-boot Environment Variables */
+ reg =3D <0x00f00000 0x00100000>;
+ label =3D "NOR U-Boot Image";
+ };
+ };
+
+ nand@1,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "fsl,p1021-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg =3D <0x1 0x0 0x40000>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg =3D <0x0 0x00100000>;
+ label =3D "NAND U-Boot Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 1MB for DTB Image */
+ reg =3D <0x00100000 0x00100000>;
+ label =3D "NAND DTB Image";
+ };
+
+ partition@200000 {
+ /* 4MB for Linux Kernel Image */
+ reg =3D <0x00200000 0x00400000>;
+ label =3D "NAND Linux Kernel Image";
+ };
+
+ partition@600000 {
+ /* 4MB for Compressed Root file System Image */
+ reg =3D <0x00600000 0x00400000>;
+ label =3D "NAND Compressed RFS Image";
+ };
+
+ partition@a00000 {
+ /* 7MB for JFFS2 based Root file System */
+ reg =3D <0x00a00000 0x00700000>;
+ label =3D "NAND JFFS2 Root File System";
+ };
+
+ partition@1100000 {
+ /* 15MB for User Writable Area */
+ reg =3D <0x01100000 0x00f00000>;
+ label =3D "NAND Writable User area";
+ };
+ };
+
+ L2switch@2,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "vitesse-7385";
+ reg =3D <0x2 0x0 0x20000>;
+ };
+};
+
+&soc {
+ i2c@3000 {
+ rtc@68 {
+ compatible =3D "pericom,pt7c4338";
+ reg =3D <0x68>;
+ };
+ };
+
+ spi@7000 {
+ flash@0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "spansion,s25sl12801";
+ reg =3D <0>;
+ spi-max-frequency =3D <40000000>; /* input clock */
+
+ partition@u-boot {
+ /* 512KB for u-boot Bootloader Image */
+ reg =3D <0x0 0x00080000>;
+ label =3D "SPI Flash U-Boot Image";
+ read-only;
+ };
+
+ partition@dtb {
+ /* 512KB for DTB Image */
+ reg =3D <0x00080000 0x00080000>;
+ label =3D "SPI Flash DTB Image";
+ };
+
+ partition@kernel {
+ /* 4MB for Linux Kernel Image */
+ reg =3D <0x00100000 0x00400000>;
+ label =3D "SPI Flash Linux Kernel Image";
+ };
+
+ partition@fs {
+ /* 4MB for Compressed RFS Image */
+ reg =3D <0x00500000 0x00400000>;
+ label =3D "SPI Flash Compressed RFSImage";
+ };
+
+ partition@jffs-fs {
+ /* 7MB for JFFS2 based RFS */
+ reg =3D <0x00900000 0x00700000>;
+ label =3D "SPI Flash JFFS2 RFS";
+ };
+ };
+ };
+
+ usb@22000 {
+ phy_type =3D "ulpi";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupt-parent =3D <&mpic>;
+ interrupts =3D <3 1 0 0>;
+ reg =3D <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ interrupt-parent =3D <&mpic>;
+ interrupts =3D <2 1 0 0>;
+ reg =3D <0x1>;
+ };
+
+ tbi0: tbi-phy@11 {
+ reg =3D <0x11>;
+ device_type =3D "tbi-phy";
+ };
+ };
+
+ mdio@25000 {
+ tbi1: tbi-phy@11 {
+ reg =3D <0x11>;
+ device_type =3D "tbi-phy";
+ };
+ };
+
+ mdio@26000 {
+ tbi2: tbi-phy@11 {
+ reg =3D <0x11>;
+ device_type =3D "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@b0000 {
+ fixed-link =3D <1 1 1000 0 0>;
+ phy-connection-type =3D "rgmii-id";
+
+ };
+
+ enet1: ethernet@b1000 {
+ phy-handle =3D <&phy0>;
+ tbi-handle =3D <&tbi1>;
+ phy-connection-type =3D "sgmii";
+ };
+
+ enet2: ethernet@b2000 {
+ phy-handle =3D <&phy1>;
+ tbi-handle =3D <&tbi2>;
+ phy-connection-type =3D "rgmii-id";
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1021rdb_36b.dts b/arch/powerpc/boot/d=
ts/p1021rdb_36b.dts
new file mode 100644
index 0000000..ea6d8b5
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1021rdb_36b.dts
@@ -0,0 +1,96 @@
+/*
+ * P1021 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in=
the
+ * documentation and/or other materials provided with the distribu=
tion.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote pro=
ducts
+ * derived from this software without specific prior written permi=
ssion.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1021si-pre.dtsi"
+/ {
+ model =3D "fsl,P1021RDB";
+ compatible =3D "fsl,P1021RDB-PC";
+
+ memory {
+ device_type =3D "memory";
+ };
+
+ lbc: localbus@fffe05000 {
+ reg =3D <0xf 0xffe05000 0 0x1000>;
+
+ /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+ ranges =3D <0x0 0x0 0xf 0xef000000 0x01000000
+ 0x1 0x0 0xf 0xff800000 0x00040000
+ 0x2 0x0 0xf 0xffb00000 0x00020000>;
+ };
+
+ soc: soc@fffe00000 {
+ ranges =3D <0x0 0xf 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@fffe09000 {
+ ranges =3D <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+ reg =3D <0xf 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges =3D <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@fffe0a000 {
+ reg =3D <0xf 0xffe0a000 0 0x1000>;
+ ranges =3D <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges =3D <0x2000000 0x0 0xc0000000
+ 0x2000000 0x0 0xc0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ qe: qe@fffe80000 {
+ ranges =3D <0x0 0xf 0xffe80000 0x40000>;
+ reg =3D <0xf 0xffe80000 0 0x480>;
+ brg-frequency =3D <0>;
+ bus-frequency =3D <0>;
+ };
+};
+
+/include/ "p1021rdb.dtsi"
+/include/ "fsl/p1021si-post.dtsi"
--=20
1.6.4
^ permalink raw reply related
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Alexander Graf @ 2012-01-17 9:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <20120117055654.GB9170@drongo>
On 17.01.2012, at 06:56, Paul Mackerras <paulus@samba.org> wrote:
> On Mon, Jan 16, 2012 at 02:04:29PM +0100, Alexander Graf wrote:
>>=20
>> On 20.12.2011, at 11:22, Paul Mackerras wrote:
>=20
>>> @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct kvm_vc=
pu *vcpu,
>>> flags &=3D 7;
>>> if (flags =3D=3D 0 || flags =3D=3D 4)
>>=20
>> This could probably use a new variable name. Also, what do 0 and 4 mean? C=
onstant defines would be nice here.
>=20
> Those constants are defined in PAPR as being a subfunction code
> indicating what sort of area and whether it is to be registered or
> unregistered. I'll make up some names for them.
>=20
>> [pasted from real source]
>>> va =3D kvmppc_pin_guest_page(kvm, vpa, &nb);
>>=20
>> Here you're pinning the page, setting va to that temporarily available ad=
dress.
>=20
> Well, it's not just temporarily available, it's available until we
> unpin it, since we increment the page count, which inhibits migration.
>=20
>>> len =3D *(unsigned int *)(va + 4);
>>=20
>> va + 4 isn't really descriptive. Is this a defined struct? Why not actual=
ly define one which you can just read data from? Or at least make this a def=
ine too. Reading random numbers in code is barely readable.
>=20
> It's not really a struct, at least not one that is used for anything
> else. PAPR defines that the length of the buffer has to be placed in
> the second 32-bit word at registration time.
>=20
>>=20
>>> + free_va =3D va;
>>=20
>> Now free_va is the temporarily available address.
> ...
>>> + free_va =3D tvcpu->arch.next_vpa;
>>> + tvcpu->arch.next_vpa =3D va;
>>=20
>> Now you're setting next_vpa to this temporarily available address? But ne=
xt_vpa will be used after va is getting free'd, no? Or is that why you have f=
ree_va?
>=20
> Yes; here we are freeing any previously-set value of next_vpa. The
> idea of free_va is that it is initially set to va so that we correctly
> unpin va if any error occurs. But if there is no error, va gets put
> into next_vpa and we free anything that was previously in next_vpa
> instead.
>=20
>>=20
>> Wouldn't it be easier to just map it every time we actually use it and on=
ly shove the GPA around? We could basically save ourselves a lot of the logi=
c here.
>=20
> There are fields in the VPA that we really want to be able to access
> from real mode, for instance the fields that indicate whether we need
> to save the FPR and/or VR values. As far as the DTL is concerned, we
> could in fact use copy_to_user to access it, so it doesn't strictly
> need to be pinned. We don't currently use the slb_shadow buffer, but
> if we did we would need to access it from real mode, since we would be
> reading it in order to set up guest SLB entries.
>=20
> The other thing is that the VPA registration/unregistration is only
> done a few times in the life of the guest, whereas we use the VPAs
> constantly while the guest is running. So it is more efficient to do
> more of the work at registration time to make it quicker to access the
> VPAs.
The thing I was getting at was not the map during the lifetime, but the map d=
uring registration. Currently we have:
1) Set VPA to x
2) Assign feature y to VPA
3) Use VPA
1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to be fast=
. 1 and 2 don't matter that much wrt performance.
You are currently mapping the VPA at /, which gets you into this map/unmap m=
ess trying to free the previous mapping. If you moved the map to step 2 and o=
nly stored the GPA at step 1, all map+unmap operations except for final unma=
ps would be in one spot, so you wouldn't need to construct this big complex s=
tate machine.
I hope that makes it more clear :)
Alex
>=20
> I'll send revised patches. There's a small change I want to make to
> patch 2 to avoid putting a very large stolen time value in the first
> entry that gets put in after the DTL is registered, which can happen
> currently if the DTL gets registered some time after the guest started
> running.
>=20
> Paul.
^ permalink raw reply
* [PATCH 1/2] powerpc/dts: Add some DTS nodes and attributes for mpc8536ds
From: Xie Xiaobo @ 2012-01-17 9:59 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Xie Xiaobo
1. Add partitions for NOR and NAND Flash.
2. Additional attributes for sdhc.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 5 ++
arch/powerpc/boot/dts/mpc8536ds.dts | 6 ++-
arch/powerpc/boot/dts/mpc8536ds.dtsi | 93 +++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8536ds_36b.dts | 8 ++-
4 files changed, 109 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
index 89af626..3ebfda3 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
@@ -236,6 +236,11 @@
};
/include/ "pq3-esdhc-0.dtsi"
+
+ sdhc@2e000 {
+ compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
+ };
+
/include/ "pq3-sec3.0-0.dtsi"
/include/ "pq3-mpic.dtsi"
/include/ "pq3-mpic-timer-B.dtsi"
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts b/arch/powerpc/boot/dts/mpc8536ds.dts
index c158815..1973622 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -1,7 +1,7 @@
/*
* MPC8536 DS Device Tree Source
*
- * Copyright 2008 Freescale Semiconductor, Inc.
+ * Copyright 2008, 2011 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -34,6 +34,10 @@
lbc: localbus@ffe05000 {
reg = <0 0xffe05000 0 0x1000>;
+
+ ranges = <0x0 0x0 0x0 0xe8000000 0x08000000
+ 0x2 0x0 0x0 0xffa00000 0x00040000
+ 0x3 0x0 0x0 0xffdf0000 0x00008000>;
};
board_soc: soc: soc@ffe00000 {
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dtsi b/arch/powerpc/boot/dts/mpc8536ds.dtsi
index 1462e4c..cc46dbd 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8536ds.dtsi
@@ -32,6 +32,99 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+&lbc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ reg = <0x0 0x03000000>;
+ label = "ramdisk-nor";
+ };
+
+ partition@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ label = "diagnostic-nor";
+ read-only;
+ };
+
+ partition@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ label = "dink-nor";
+ read-only;
+ };
+
+ partition@4000000 {
+ reg = <0x04000000 0x00400000>;
+ label = "kernel-nor";
+ };
+
+ partition@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ label = "fs-nor";
+ };
+
+ partition@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ label = "dtb-nor";
+ };
+
+ partition@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ label = "u-boot-nor";
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8536-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ partition@0 {
+ reg = <0x0 0x02000000>;
+ label = "u-boot-nand";
+ read-only;
+ };
+
+ partition@2000000 {
+ reg = <0x02000000 0x10000000>;
+ label = "fs-nand";
+ };
+
+ partition@12000000 {
+ reg = <0x12000000 0x08000000>;
+ label = "ramdisk-nand";
+ };
+
+ partition@1a000000 {
+ reg = <0x1a000000 0x04000000>;
+ label = "kernel-nand";
+ };
+
+ partition@1e000000 {
+ reg = <0x1e000000 0x01000000>;
+ label = "dtb-nand";
+ };
+
+ partition@1f000000 {
+ reg = <0x1f000000 0x21000000>;
+ label = "empty-nand";
+ };
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,mpc8536ds-fpga-pixis";
+ reg = <0x3 0x0 0x8000>;
+ };
+};
+
&board_soc {
i2c@3100 {
rtc@68 {
diff --git a/arch/powerpc/boot/dts/mpc8536ds_36b.dts b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
index 8f4b929..f8a3b34 100644
--- a/arch/powerpc/boot/dts/mpc8536ds_36b.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
@@ -1,7 +1,7 @@
/*
* MPC8536DS Device Tree Source (36-bit address map)
*
- * Copyright 2008-2009 Freescale Semiconductor, Inc.
+ * Copyright 2008-2009, 2011 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -33,7 +33,11 @@
};
lbc: localbus@ffe05000 {
- reg = <0 0xffe05000 0 0x1000>;
+ reg = <0xf 0xffe05000 0 0x1000>;
+
+ ranges = <0x0 0x0 0xf 0xe8000000 0x08000000
+ 0x2 0x0 0xf 0xffa00000 0x00040000
+ 0x3 0x0 0xf 0xffdf0000 0x00008000>;
};
board_soc: soc: soc@fffe00000 {
--
1.7.5.1
^ permalink raw reply related
* [PATCH 2/2] powerpc/dts: Add magic-packet properties for etsec
From: Xie Xiaobo @ 2012-01-17 9:59 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Xie Xiaobo
In-Reply-To: <1326794391-6105-1-git-send-email-X.Xie@freescale.com>
The properties indicates that the hardware supports waking up via magic packet.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi | 3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
index a1979ae..3b0650a 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x24000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@24000 {
compatible = "gianfar";
reg = <0x24000 0x1000>;
ranges = <0x0 0x24000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <29 2 0 0 30 2 0 0 34 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
index 4c4fdde..96693b4 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x25000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@25000 {
compatible = "gianfar";
reg = <0x25000 0x1000>;
ranges = <0x0 0x25000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <35 2 0 0 36 2 0 0 40 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
index 4b8ab43..6b3fab1 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x26000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@26000 {
compatible = "gianfar";
reg = <0x26000 0x1000>;
ranges = <0x0 0x26000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <31 2 0 0 32 2 0 0 33 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
index 40c9137..0da592d 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
@@ -1,7 +1,7 @@
/*
* PQ3 eTSEC device tree stub [ @ offsets 0x27000 ]
*
- * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -41,6 +41,7 @@ ethernet@27000 {
compatible = "gianfar";
reg = <0x27000 0x1000>;
ranges = <0x0 0x27000 0x1000>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <37 2 0 0 38 2 0 0 39 2 0 0>;
};
--
1.7.5.1
^ permalink raw reply related
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Paul Mackerras @ 2012-01-17 11:31 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <6D049B19-8A91-445A-9FBB-E4851D4F586E@suse.de>
On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote:
> The thing I was getting at was not the map during the lifetime, but
> the map during registration. Currently we have:
>
> 1) Set VPA to x
> 2) Assign feature y to VPA
> 3) Use VPA
>
> 1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to
> be fast. 1 and 2 don't matter that much wrt performance.
>
> You are currently mapping the VPA at /, which gets you into this
> map/unmap mess trying to free the previous mapping. If you moved the
> map to step 2 and only stored the GPA at step 1, all map+unmap
> operations except for final unmaps would be in one spot, so you
> wouldn't need to construct this big complex state machine.
That might simplify things - I'll try it and see. The worry with
doing the map/pin at 2 is that if anything goes wrong we no longer
have the opportunity to return an error for the H_REGISTER_VPA call,
so I'll have to at least do some checking in 1, leading to possibly
more code overall.
Paul.
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Alexander Graf @ 2012-01-17 12:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <20120117113140.GA9093@bloggs.ozlabs.ibm.com>
On 17.01.2012, at 12:31, Paul Mackerras wrote:
> On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote:
>=20
>> The thing I was getting at was not the map during the lifetime, but
>> the map during registration. Currently we have:
>>=20
>> 1) Set VPA to x
>> 2) Assign feature y to VPA
>> 3) Use VPA
>>=20
>> 1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to
>> be fast. 1 and 2 don't matter that much wrt performance.
>>=20
>> You are currently mapping the VPA at /, which gets you into this
>> map/unmap mess trying to free the previous mapping. If you moved the
>> map to step 2 and only stored the GPA at step 1, all map+unmap
>> operations except for final unmaps would be in one spot, so you
>> wouldn't need to construct this big complex state machine.
>=20
> That might simplify things - I'll try it and see. The worry with
> doing the map/pin at 2 is that if anything goes wrong we no longer
> have the opportunity to return an error for the H_REGISTER_VPA call,
> so I'll have to at least do some checking in 1, leading to possibly
> more code overall.
Well, then map and unmap it in step 1 and map it in step 2 again. We're =
in the slow path so performance isn't critical. Readability and =
maintainability however are :)
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