Re: [PATCH] gianfar:localized filer table

[David Miller]

From: Jiajun Wu 
Date: Wed, 8 Jun 2011 15:46:51 +0800

> Each eTSEC device should own localized filer table.
> 
> Signed-off-by: Jiajun Wu 

Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Arnd Bergmann]

On Thursday 09 June 2011 00:45:54 Timur Tabi wrote:
> +struct fsl_hv_ioctl_memcpy {
> +   __u32 ret;
> +   __u32 source;
> +   __u32 target;
> +   __u64 local_vaddr;
> +   __u64 remote_paddr;
> +   __u64 count;
> +};

> +struct fsl_hv_ioctl_prop {
> +   __u32 ret;
> +   __u32 handle;
> +   __u64 path;
> +   __u64 propname;
> +   __u64 propval;
> +   __u32 proplen;
> +};

These structures have implied padding. Better make it explicit by
adding the appropriate __u32 __pad1 members or similar.

> +/*
> + * ioctl commands.
> + */
> +enum {
> +   FSL_HV_IOCTL_PARTITION_RESTART = 1, /* Boot another partition */
> +   FSL_HV_IOCTL_PARTITION_GET_STATUS = 2, /* Boot another partition */
> +   FSL_HV_IOCTL_PARTITION_START = 3, /* Boot another partition */
> +   FSL_HV_IOCTL_PARTITION_STOP = 4, /* Stop this or another partition */
> +   FSL_HV_IOCTL_MEMCPY = 5, /* Copy data from one partition to another */
> +   FSL_HV_IOCTL_DOORBELL = 6, /* Ring a doorbell */
> +
> +   /* Get a property from another guest's device tree */
> +   FSL_HV_IOCTL_GETPROP = 7,
> +
> +   /* Set a property in another guest's device tree */
> +   FSL_HV_IOCTL_SETPROP = 8,
> +};

As discussed before, this one should really be using the _IOC macros to define
the commands that you use based on the structure definitions above, e.g.

#define FSL_HV_IOCTL_GETPROP _IORW(FSL_HV, 8, struct fsl_hv_ioctl_prop)

Then get rid of all the code that takes apart the ioctl command numbers
again and just do a switch/case based on the command.

Arnd

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Arnd Bergmann]

On Thursday 09 June 2011 01:10:09 Randy Dunlap wrote:
> On Wed, 8 Jun 2011 17:45:54 -0500 Timur Tabi wrote:
> 
> > Add the drivers/virt directory, which houses drivers that support
> > virtualization environments, and add the Freescale hypervisor management
> > driver.
> 
> It can't go in linux/virt or linux/virt/fsl instead?  why drivers/ ?
> 
> or maybe linux/virt should be drivers/virt ?

See discussion for v2 of this patch. I suggested that drivers/firmware and virt/
as options, the counterarguments were that drivers/firmware is for passive
firmware as opposed to firmware that acts as a hypervisor, and that virt/ is
for the host side of hypervisors like kvm, not for guests.

The driver in here most closely resembles the xen dom0 model, where a
priviledged guest controls other guests, but unlike xen there is a single
driver file, so there is no need to have drivers/fsl-hv directory just
for this one file. We do have a number of other hypervisors that fit in the
same category, so they can be added here later.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [openmcapi-dev] [PATCH v3 0/2] powerpc: define and implement MPIC message register support

[Meador Inge]

On 05/31/2011 02:19 PM, Meador Inge wrote:

> This patch set defines a binding for FSL MPIC message registers and implements
> an API for accessing those message registers.  Testing was done on a MPC8572DS
> in an Linux-Linux AMP setup using OpenMCAPI (www.openmcapi.org) to communicate
> between OS instances.  The message register API is used by the OpenMCAPI 
> shared 
> memory driver to send notifications between cores.
> 
> * v3 - Clarified a point in the binding concerning the length of the
>'interrupts' property.  Pointed out by Scott Wood.
> 
> * v2 - Incorporate feedback from Scott Wood
>* Make binding less implementation specific.
>* Add 'mpic-' prefix to message register node properties and aliases.
>* Remove 'interrupt-parent' from binding.
>* Fixed some example bugs with receive masks.
> 
> Signed-off-by: Meador Inge 
> Cc: Hollis Blanchard 
> 
> Meador Inge (2):
>   powerpc: document the FSL MPIC message register binding

The binding has been acked (Thanks Scott).

>   powerpc: add support for MPIC message register API

Scott, Kumar, are you all OK with the
implementation: http://patchwork.ozlabs.org/patch/98075/ ?


-- 
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] [RFC][V3] bluegene: use MMU feature flag to conditionalize L1 writethrough code

[Eric Van Hensbergen]

On Tue, Jun 7, 2011 at 7:47 PM, Benjamin Herrenschmidt
 wrote:
> On Tue, 2011-06-07 at 16:36 -0500, Eric Van Hensbergen wrote:
>
>> open to alternatives.  jimix also suggested changing NEED_L1_WRITETHROUGH
>> to DCBZ_BROKEN, which I'm open to if you think appropriate, or maybe
>> DCBZ_BROKEN_DAMNIT would be more apt.
>
> :-)
>
> I think NEED_L1_WRITETHROUGH isn't great since we are dealing with more
> than just that here. Let's call it 44x_SMP since afaik, all
> implementations, whether it's BG or other variants of the same hack
> (AMCC/APM has one too) need the same stuff here, no ?
>
> Let's not use more than one feature bit, it's not needed in practice, a
> better name is all we need. Might even call it MMU_FTR_BLUEGENE_44x_SMP
> if you want.
>

I've got it as MMU_FTR_44x_SMP now, just wanted to bounce off of Josh to
make sure he's okay with it since he owns the 44x stuff.  If he'd
rather, I'll change
it to MMU_FTR_BGP_44x_SMP.

>
> I'll add comments inline:
>
>>  #define PPC44x_MMUCR_TID     0x00ff
>>  #define PPC44x_MMUCR_STS     0x0001
>> +#define PPC44x_MMUCR_U2              0x0020
>
> Please document in a comment what is the effect of U2 on the BG/P ASIC
> caches.
>

Is a comment sufficient, or would you rather also have something along
the lines of
+#define PPC44x_MMUCR_U2              0x0020
+#define PPC44x_MMUCR_U2_SWOAE   PPC44x_MMUCR_U2 /* store without allocation */

or even...
+#define PPC44x_MMUCR_U2_BGP_SWOAE   PPC44x_MMUCR_U2 /* store without
allocation on BGP */

Seems like its getting a bit too verbose, maybe that's not a bad
thing.  As long as I don't have to type it
too many times :)

>
> BTW. Care to explain to me why you have U2 -both- in the arguments to
> tlbwe and in MMUCR ? That doesn't look right to me... which one is used
> where and when ?
>

My reading of the databook is that U2SWOAE is an enable bit that lets the U2
storage attribute control the behavior.

>> @@ -814,7 +829,15 @@ skpinv:  addi    r4,r4,1                         /* 
>> Increment */
>>       /* attrib fields */
>>       /* Added guarded bit to protect against speculative loads/stores */
>>       li      r5,0
>> -     ori     r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | 
>> PPC44x_TLB_G)
>> +BEGIN_MMU_FTR_SECTION
>> +     ori     r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | \
>> +                                             PPC44x_TLB_G | PPC44x_TLB_U2)
>> +     oris    r5,r5,PPC44x_TLB_WL1@h
>> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_L1_WRITETHROUGH)
>> +BEGIN_MMU_FTR_SECTION
>> +     ori     r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | \
>> +                     PPC44x_TLB_G)
>> +END_MMU_FTR_SECTION_IFCLR(MMU_FTR_NEED_L1_WRITETHROUGH)
>>
>>          li      r0,63                    /* TLB slot 63 */
>
> This isn't going to work. This happens before the CPU feature bits are
> established.
>
> I see two ways out of that dilemna:
>
>  - One is you find a way to identify the BG case at runtime from that
> very early asm code. It's a bit tricky since we never added the MMU type
> information to the device-tree blob header (but we're adding it to ePAPR
> via a register iirc, so we could hijack that), or maybe via inspecting
> what the FW left behind in the TLB...
>

Well, if we are using the u-boot scenario, I can control how the
bootloader sets up the device tree and add markers that we can use to
let us do this.



>> diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
>> index 998a100..b54e2e8 100644
>> --- a/arch/powerpc/kernel/misc_32.S
>> +++ b/arch/powerpc/kernel/misc_32.S
>> @@ -506,7 +506,27 @@ _GLOBAL(clear_pages)
>>       li      r0,PAGE_SIZE/L1_CACHE_BYTES
>>       slw     r0,r0,r4
>>       mtctr   r0
>> -1:   dcbz    0,r3
>> +     li      r4, 0
>> +1:
>> +BEGIN_MMU_FTR_SECTION
>> +     /* assuming 32 byte cacheline */
>> +     stw     r4, 0(r3)
>> +     stw     r4, 4(r3)
>> +     stw     r4, 8(r3)
>> +     stw     r4, 12(r3)
>> +     stw     r4, 16(r3)
>> +     stw     r4, 20(r3)
>> +     stw     r4, 24(r3)
>> +     stw     r4, 28(r3)
>> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_L1_WRITETHROUGH)
>> +/*
>> + * would have used an ELSE_MMU_FTR_SECTION here but it
>> + * broke the code with Error: non-constant expression in ".if" statement
>> + *
>> + */
>> +BEGIN_MMU_FTR_SECTION
>> +     dcbz    0,r3
>> +END_MMU_FTR_SECTION_IFCLR(MMU_FTR_NEED_L1_WRITETHROUGH)
>>       addi    r3,r3,L1_CACHE_BYTES
>>       bdnz    1b
>>       blr
>> @@ -550,7 +570,9 @@ _GLOBAL(copy_page)
>>       mtctr   r0
>>  1:
>>       dcbt    r11,r4
>> +BEGIN_MMU_FTR_SECTION
>>       dcbz    r5,r3
>> +END_MMU_FTR_SECTION_IFCLR(MMU_FTR_NEED_L1_WRITETHROUGH)
>>       COPY_16_BYTES
>>  #if L1_CACHE_BYTES >= 32
>>       COPY_16_BYTES
>
> Instead here I would just do a single feature section as the first
> instruction of clear_pages() that covers a branch out of line to an
> alternate implementation of the whole function.
>
> _GLOBAL(clear_pages)
> BEGIN_MMU_FTR_SECTION
> 

Re: [PATCH] ppc/85xx: specify interrupt for pq3-localbus devices

[Dmitry Eremin-Solenikov]

Sorry, if I'm being too noisy, what about this patch?

On 6/1/11, Dmitry Eremin-Solenikov  wrote:
> fsl-lbc driver requires an interrupt to bind to localbus device.
> Populate 85xx boards' dts trees with lbc interrupt info.
>
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
>  arch/powerpc/boot/dts/mpc8568mds.dts   |2 ++
>  arch/powerpc/boot/dts/socrates.dts |2 ++
>  arch/powerpc/boot/dts/tqm8540.dts  |2 ++
>  arch/powerpc/boot/dts/tqm8548-bigflash.dts |2 ++
>  arch/powerpc/boot/dts/tqm8548.dts  |2 ++
>  arch/powerpc/boot/dts/tqm8560.dts  |2 ++
>  arch/powerpc/boot/dts/xpedite5200.dts  |2 ++
>  arch/powerpc/boot/dts/xpedite5200_xmon.dts |2 ++
>  8 files changed, 16 insertions(+), 0 deletions(-)


-- 
With best wishes
Dmitry
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 00:38, Arnd Bergmann wrote:
> On Thursday 09 June 2011 01:10:09 Randy Dunlap wrote:
>> On Wed, 8 Jun 2011 17:45:54 -0500 Timur Tabi wrote:
>>
>>> Add the drivers/virt directory, which houses drivers that support
>>> virtualization environments, and add the Freescale hypervisor management
>>> driver.
>>
>> It can't go in linux/virt or linux/virt/fsl instead?  why drivers/ ?
>>
>> or maybe linux/virt should be drivers/virt ?
> 
> See discussion for v2 of this patch. I suggested that drivers/firmware and 
> virt/
> as options, the counterarguments were that drivers/firmware is for passive
> firmware as opposed to firmware that acts as a hypervisor, and that virt/ is
> for the host side of hypervisors like kvm, not for guests.

OK, I read that thread.  Didn't see a real consensus there.

If you were not the drivers/misc/ maintainer, would you mind if this
driver lived in drivers/misc/?  I wouldn't.

But it sounds like virt/ needs virt/host/ and virt/guest/ to me.


> The driver in here most closely resembles the xen dom0 model, where a
> priviledged guest controls other guests, but unlike xen there is a single
> driver file, so there is no need to have drivers/fsl-hv directory just
> for this one file. We do have a number of other hypervisors that fit in the
> same category, so they can be added here later.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Randy Dunlap wrote:
> But it sounds like virt/ needs virt/host/ and virt/guest/ to me.

I'm okay with that idea, except there's a consensus that drivers should be in
drivers/.

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 09:36, Timur Tabi wrote:
> Randy Dunlap wrote:
>> But it sounds like virt/ needs virt/host/ and virt/guest/ to me.
> 
> I'm okay with that idea, except there's a consensus that drivers should be in
> drivers/.
> 

Like sound/ ?

but what makes it a "driver"?

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Randy Dunlap wrote:
>> > I'm okay with that idea, except there's a consensus that drivers should be 
>> > in
>> > drivers/.
>> > 
> Like sound/ ?

My understanding is that this is something that's considered broken and should
be fixed, but I don't know what the holdup is.

> but what makes it a "driver"?

That's a good point.

Ok, so maybe I don't have any really good answers here. :-)

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Arnd Bergmann wrote:
> Then get rid of all the code that takes apart the ioctl command numbers
> again and just do a switch/case based on the command.

I still need to keep that code to maintain binary compatibility with existing
applications that pass the union as a parameter.

I'll fix that after we've updated the applications.  But we have a
chicken-or-the-egg problem where we need the same application to work with the
new and old ioctl interface for a period of time.

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Add the drivers/virt directory, which houses drivers that support
virtualization environments, and add the Freescale hypervisor management
driver.

The Freescale hypervisor management driver provides several services to
drivers and applications related to the Freescale hypervisor:

1. An ioctl interface for querying and managing partitions

2. A file interface to reading incoming doorbells

3. An interrupt handler for shutting down the partition upon receiving the
   shutdown doorbell from a manager partition

4. A kernel interface for receiving callbacks when a managed partition
   shuts down.

Signed-off-by: Timur Tabi 
---
 drivers/Kconfig|2 +
 drivers/Makefile   |3 +
 drivers/virt/Kconfig   |   32 ++
 drivers/virt/Makefile  |5 +
 drivers/virt/fsl_hypervisor.c  |  983 
 include/linux/Kbuild   |1 +
 include/linux/fsl_hypervisor.h |  231 ++
 7 files changed, 1257 insertions(+), 0 deletions(-)
 create mode 100644 drivers/virt/Kconfig
 create mode 100644 drivers/virt/Makefile
 create mode 100644 drivers/virt/fsl_hypervisor.c
 create mode 100644 include/linux/fsl_hypervisor.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 557a469..0371680 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -122,4 +122,6 @@ source "drivers/hwspinlock/Kconfig"
 
 source "drivers/clocksource/Kconfig"
 
+source "drivers/virt/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 3f135b6..bbe2918 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -119,3 +119,6 @@ obj-y   += ieee802154/
 obj-y  += clk/
 
 obj-$(CONFIG_HWSPINLOCK)   += hwspinlock/
+
+# Virtualization drivers
+obj-$(CONFIG_VIRT_DRIVERS) += virt/
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
new file mode 100644
index 000..2dcdbc9
--- /dev/null
+++ b/drivers/virt/Kconfig
@@ -0,0 +1,32 @@
+#
+# Virtualization support drivers
+#
+
+menuconfig VIRT_DRIVERS
+   bool "Virtualization drivers"
+   ---help---
+ Say Y here to get to see options for device drivers that support
+ virtualization environments.
+
+ If you say N, all options in this submenu will be skipped and 
disabled.
+
+if VIRT_DRIVERS
+
+config FSL_HV_MANAGER
+   tristate "Freescale hypervisor management driver"
+   depends on FSL_SOC
+   help
+  The Freescale hypervisor management driver provides several services
+ to drivers and applications related to the Freescale hypervisor:
+
+  1) An ioctl interface for querying and managing partitions.
+
+  2) A file interface to reading incoming doorbells.
+
+  3) An interrupt handler for shutting down the partition upon
+receiving the shutdown doorbell from a manager partition.
+
+  4) A kernel interface for receiving callbacks when a managed
+partition shuts down.
+
+endif
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
new file mode 100644
index 000..c47f04d
--- /dev/null
+++ b/drivers/virt/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for drivers that support virtualization
+#
+
+obj-$(CONFIG_FSL_HV_MANAGER)   += fsl_hypervisor.o
diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
new file mode 100644
index 000..086085f
--- /dev/null
+++ b/drivers/virt/fsl_hypervisor.c
@@ -0,0 +1,983 @@
+/*
+ * Freescale Hypervisor Management Driver
+
+ * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Author: Timur Tabi 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * The Freescale hypervisor management driver provides several services to
+ * drivers and applications related to the Freescale hypervisor:
+ *
+ * 1. An ioctl interface for querying and managing partitions.
+ *
+ * 2. A file interface to reading incoming doorbells.
+ *
+ * 3. An interrupt handler for shutting down the partition upon receiving the
+ *shutdown doorbell from a manager partition.
+ *
+ * 4. A kernel interface for receiving callbacks when a managed partition
+ *shuts down.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+static BLOCKING_NOTIFIER_HEAD(failover_subscribers);
+
+/*
+ * Ioctl interface for FSL_HV_IOCTL_PARTITION_RESTART
+ *
+ * Restart a running partition
+ */
+static long ioctl_restart(struct fsl_hv_ioctl_restart __user *p)
+{
+   struct fsl_hv_ioctl_restart param;
+
+   /* Get the parameters from the user */
+   if (copy_from_user(¶m, p, sizeof(struct fsl_hv_ioctl_restart)))
+   return -EFAULT;
+
+   param.ret = fh_partition_restart(param.partition);
+
+   if 

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On Thu, 9 Jun 2011 14:13:14 -0500 Timur Tabi wrote:

> Add the drivers/virt directory, which houses drivers that support
> virtualization environments, and add the Freescale hypervisor management
> driver.
> 
> The Freescale hypervisor management driver provides several services to
> drivers and applications related to the Freescale hypervisor:
> 
> 1. An ioctl interface for querying and managing partitions
> 
> 2. A file interface to reading incoming doorbells
> 
> 3. An interrupt handler for shutting down the partition upon receiving the
>shutdown doorbell from a manager partition
> 
> 4. A kernel interface for receiving callbacks when a managed partition
>shuts down.
> 
> Signed-off-by: Timur Tabi 
> ---
>  drivers/Kconfig|2 +
>  drivers/Makefile   |3 +
>  drivers/virt/Kconfig   |   32 ++
>  drivers/virt/Makefile  |5 +
>  drivers/virt/fsl_hypervisor.c  |  983 
> 
>  include/linux/Kbuild   |1 +
>  include/linux/fsl_hypervisor.h |  231 ++
>  7 files changed, 1257 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/virt/Kconfig
>  create mode 100644 drivers/virt/Makefile
>  create mode 100644 drivers/virt/fsl_hypervisor.c
>  create mode 100644 include/linux/fsl_hypervisor.h

> diff --git a/include/linux/fsl_hypervisor.h b/include/linux/fsl_hypervisor.h
> new file mode 100644
> index 000..d1ca2b1
> --- /dev/null
> +++ b/include/linux/fsl_hypervisor.h
> @@ -0,0 +1,231 @@

[snip]

> +/**
> + * enum fsl_hv_ioctl_cmd - ioctl commands
> + * @FSL_HV_IOCTL_PARTITION_RESTART: restart another partition
> + * @FSL_HV_IOCTL_PARTITION_GET_STATUS: get a partition's status
> + * @FSL_HV_IOCTL_PARTITION_START: boot another partition
> + * @FSL_HV_IOCTL_PARTITION_STOP: stop this or another partition
> + * @FSL_HV_IOCTL_MEMCPY: copy data from one partition to another
> + * @FSL_HV_IOCTL_DOORBELL: ring a doorbell
> + * @FSL_HV_IOCTL_GETPROP: get a property from another guest's device tree
> + * @FSL_HV_IOCTL_SETPROP: set a property in another guest's device tree
> + *
> + * This enum lists the available ioctl commands for the Freescale hypervisor
> + * management driver.  The meaning
> + */
> +enum fsl_hv_ioctl_cmd {
> + FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
> fsl_hv_ioctl_restart),
> + FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
> fsl_hv_ioctl_status),
> + FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
> + FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
> + FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
> + FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
> + FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
> + FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
> +};

Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with conflict!).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Randy Dunlap wrote:
>> > +enum fsl_hv_ioctl_cmd {
>> > +  FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
>> > fsl_hv_ioctl_restart),
>> > +  FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
>> > fsl_hv_ioctl_status),
>> > +  FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
>> > +  FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
>> > +  FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
>> > +  FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
>> > +  FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
>> > +  FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
>> > +};

> Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with 
> conflict!).

If I change it from 0, I'm going to break binary compatibility with our apps.  I
agree that maybe I shouldn't have picked 0, but considering how many conflicts
there already are, I wonder what the point is.  Even if I pick a number that is
currently not listed in the chart, that doesn't mean that it's actually not
being used, or that it won't conflict in the future.

So is it okay to stick with 0, or do I need to pick a new number?

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 12:47, Timur Tabi wrote:
> Randy Dunlap wrote:
 +enum fsl_hv_ioctl_cmd {
 +  FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
 fsl_hv_ioctl_restart),
 +  FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
 fsl_hv_ioctl_status),
 +  FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
 +  FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
 +  FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
 +  FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
 +  FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
 +  FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
 +};
> 
>> Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with 
>> conflict!).
> 
> If I change it from 0, I'm going to break binary compatibility with our apps. 
>  I
> agree that maybe I shouldn't have picked 0, but considering how many conflicts
> there already are, I wonder what the point is.  Even if I pick a number that 
> is
> currently not listed in the chart, that doesn't mean that it's actually not
> being used, or that it won't conflict in the future.

Yes, I understood that.

> So is it okay to stick with 0, or do I need to pick a new number?

I wasn't suggesting that you change the 0, just note that it has conflicts,
like other ioctls do.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Arnd Bergmann]

Hi Timur, thanks for addressing the issues I pointed out. Unfortunately, I
have found a few more now:

On Thursday 09 June 2011 21:13:14 Timur Tabi wrote:
> +   /* Make sure the application is called the right driver. */
> +   if (_IOC_TYPE(cmd) != 0) {
> +   pr_debug("fsl-hv: ioctl type %u should be 0\n", 
> _IOC_TYPE(cmd));
> +   return -EINVAL;
> +   }
> +
> +   /* Make sure the application set the direction flag correctly. */
> +   if (_IOC_DIR(cmd) != (_IOC_READ | _IOC_WRITE)) {
> +   pr_debug("fsl-hv: ioctl direction should be _IOWR\n");
> +   return -EINVAL;
> +   }
> +
> +   /*
> +* Make sure the application is passing the right structure to us.
> +* For backwards compatibility with older applications, we only check
> +* if the size is too small, rather than unequal.
> +*/
> +
> +   switch (_IOC_NR(cmd)) {
> +   case (_IOC_NR(FSL_HV_IOCTL_PARTITION_RESTART)):
> +   size = sizeof(struct fsl_hv_ioctl_restart);
> +   if (_IOC_SIZE(cmd) < size)
> +   goto size_error;
> +   ret = ioctl_restart(arg);
> +   break;

As mentioned, it would be easier and more readable to just do

switch(cmd) {
case FSL_HV_IOCTL_PARTITION_RESTART:
...

case FSL_HV_IOCTL_PARTITION_GET_STATUS;
...

There is no need to check the bits individually when you can simply
compare the command number.

> +/**
> + * enum fsl_hv_ioctl_cmd - ioctl commands
> + * @FSL_HV_IOCTL_PARTITION_RESTART: restart another partition
> + * @FSL_HV_IOCTL_PARTITION_GET_STATUS: get a partition's status
> + * @FSL_HV_IOCTL_PARTITION_START: boot another partition
> + * @FSL_HV_IOCTL_PARTITION_STOP: stop this or another partition
> + * @FSL_HV_IOCTL_MEMCPY: copy data from one partition to another
> + * @FSL_HV_IOCTL_DOORBELL: ring a doorbell
> + * @FSL_HV_IOCTL_GETPROP: get a property from another guest's device tree
> + * @FSL_HV_IOCTL_SETPROP: set a property in another guest's device tree
> + *
> + * This enum lists the available ioctl commands for the Freescale hypervisor
> + * management driver.  The meaning
> + */
> +enum fsl_hv_ioctl_cmd {
> +   FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
> fsl_hv_ioctl_restart),
> +   FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
> fsl_hv_ioctl_status),
> +   FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
> +   FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
> +   FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
> +   FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
> +   FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
> +   FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
> +};

Using a #define here is usually preferred because then you can use #ifdef in a 
user
application to check if a given value has been assigned.

More importantly, the code you have chose (0) conflicts with existing drivers
(frame buffer, scsi and wavefront among others). Please chose a free one and
add it to Documentation/ioctl/ioctl-number.txt in the same patch.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Arnd Bergmann wrote:
> As mentioned, it would be easier and more readable to just do
> 
>   switch(cmd) {
>   case FSL_HV_IOCTL_PARTITION_RESTART:
>   ...
> 
>   case FSL_HV_IOCTL_PARTITION_GET_STATUS;
>   ...
> 
> There is no need to check the bits individually when you can simply
> compare the command number.

But this will break backwards compatibility with older applications that used
the union as the size parameter.  Although these applications won't compile with
the new header file, older already-compiled applications still work.

I will eventually update the applications to use the new header file, and at
that point I will modify the switch statement as you suggest.  But until then,
I'd like to keep the code as-is.

>> > +enum fsl_hv_ioctl_cmd {
>> > +   FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
>> > fsl_hv_ioctl_restart),
>> > +   FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
>> > fsl_hv_ioctl_status),
>> > +   FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct 
>> > fsl_hv_ioctl_start),
>> > +   FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct 
>> > fsl_hv_ioctl_stop),
>> > +   FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
>> > +   FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
>> > +   FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
>> > +   FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
>> > +};

> Using a #define here is usually preferred because then you can use #ifdef in 
> a user
> application to check if a given value has been assigned.

You're right -- I had enum on the brain.

> More importantly, the code you have chose (0) conflicts with existing drivers
> (frame buffer, scsi and wavefront among others). Please chose a free one and
> add it to Documentation/ioctl/ioctl-number.txt in the same patch.

Ok, I was really hoping to avoid doing this.  Like I said, binary compatibility
is important, and changing the type will break my existing apps.  Are you
insisting that I pick a new number?

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Arnd Bergmann]

On Thursday 09 June 2011 20:55:17 Timur Tabi wrote:
> Arnd Bergmann wrote:
> > Then get rid of all the code that takes apart the ioctl command numbers
> > again and just do a switch/case based on the command.
> 
> I still need to keep that code to maintain binary compatibility with existing
> applications that pass the union as a parameter.
> 
> I'll fix that after we've updated the applications.  But we have a
> chicken-or-the-egg problem where we need the same application to work with the
> new and old ioctl interface for a period of time.

The lesson to learn here is obviously not to ship binaries of applications
to customers before the driver has been merged in a mainline kernel.

The best way out that I can see is to make the driver carry the proper
interface in the upstream version, but to have a private patch to support
both interface versions in the kernel you ship on machines that require
backwards compatibility. Once you have phased out the user application,
you can then drop that patch and use the upstream version of the
interfaces.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Arnd Bergmann wrote:
> The lesson to learn here is obviously not to ship binaries of applications
> to customers before the driver has been merged in a mainline kernel.

Believe me, I know this, but unfortunately I have no control over every aspect
of our development cycle.

> The best way out that I can see is to make the driver carry the proper
> interface in the upstream version, but to have a private patch to support
> both interface versions in the kernel you ship on machines that require
> backwards compatibility. Once you have phased out the user application,
> you can then drop that patch and use the upstream version of the
> interfaces.

I think I can make that work.

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Arnd Bergmann]

On Thursday 09 June 2011 21:48:58 Randy Dunlap wrote:
> > So is it okay to stick with 0, or do I need to pick a new number?
> 
> I wasn't suggesting that you change the 0, just note that it has conflicts,
> like other ioctls do.

We normally don't try to maintain binary compatibility with out of tree
kernel patches. That only leads to inferior interfaces finding their way
into the kernel.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Greg KH]

On Thu, Jun 09, 2011 at 03:18:28PM -0500, Timur Tabi wrote:
> > More importantly, the code you have chose (0) conflicts with existing 
> > drivers
> > (frame buffer, scsi and wavefront among others). Please chose a free one and
> > add it to Documentation/ioctl/ioctl-number.txt in the same patch.
> 
> Ok, I was really hoping to avoid doing this.  Like I said, binary 
> compatibility
> is important, and changing the type will break my existing apps.  Are you
> insisting that I pick a new number?

Why is binary compatibility important?  Isn't this a brand new driver
for a brand new system?  What userspace tools are out there in the wild
for such a thing?

confused,

greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Arnd Bergmann]

On Thursday 09 June 2011 22:18:28 Timur Tabi wrote:
> > More importantly, the code you have chose (0) conflicts with existing 
> > drivers
> > (frame buffer, scsi and wavefront among others). Please chose a free one and
> > add it to Documentation/ioctl/ioctl-number.txt in the same patch.
> 
> Ok, I was really hoping to avoid doing this.  Like I said, binary 
> compatibility
> is important, and changing the type will break my existing apps.  Are you
> insisting that I pick a new number?

I definitely insist that you have a proper interface in the driver at the
time that it gets merged, and that probably includes a collision-free
ioctl code.

You can probably make the driver support both the traditional and the
new interface, but I would prefer if you kept that as a private patch
on top a clean kernel driver. It's also a good idea to keep the header
file clean and only define the new interface there, to ensure that all
applications that are built in the future have to use the new interface.

When you make the patch to add backwards compat support, just add it
to the driver itself, not to the header.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Greg KH wrote:
> Why is binary compatibility important?  Isn't this a brand new driver
> for a brand new system?  What userspace tools are out there in the wild
> for such a thing?

This driver (and the hypervisor it talks to, plus the apps, etc) has been in
internal development for three years.  There hasn't been a lot of effort
internally to release this software upstream until recently.

I personally have been complaining about it for quite some time, but I have no
control over our internal release process.  Even when the hardware has been
announced and available for purchase, the BSP is sometimes only available under
NDA.  Eventually, everything is publicly released, and most of the code is
pushed upstream, but it's a long and painful struggle at times.

My concern has been dealing with the headaches of bug reports from customers,
etc as they upgrade their kernel but not their apps, and then wonder why nothing
works.

But as Arnd pointed out, it really isn't as big of deal as I make it out to be.
 I can maintain compatibility internally.  I blame my allergy medicine.

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[git pull] Please pull powerpc.git merge branch

[Benjamin Herrenschmidt]

Hi Linus !

Here are a small batch of fixes for powerpc.

Just one note: I just noticed a mistake while fixing a bug in "powerpc:
Force page alignment for initrd reserved memory". Bloody "citool"
changed the authorchip to me. The real author is Dave Carroll
. (it's a nasty mis-feature of ci-tool that
overrides the author when doing an amend of an existing commit).

I didn't want to rebase the branch for that tho.

Cheers,
Ben.

The following changes since commit 06e86849cf4019945a106913adb9ff0abcc01770:

  Merge branch 'pm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6 (2011-06-08 
15:58:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

Benjamin Herrenschmidt (1): (Dave Carroll really)
  powerpc: Force page alignment for initrd reserved memory

Kumar Gala (2):
  powerpc/fsl_rio: Fix compile error when CONFIG_FSL_RIO not set
  powerpc/book3e: Fix CPU feature handling on e5500 in 32-bit mode

Shaohui Xie (1):
  powerpc/85xx: fix race bug of calling request_irq after enable elbc 
interrupts

Wolfram Sang (1):
  dtc/powerpc: remove obsolete .gitignore entries

 arch/powerpc/boot/.gitignore |1 -
 arch/powerpc/boot/dtc-src/.gitignore |3 ---
 arch/powerpc/include/asm/rio.h   |2 +-
 arch/powerpc/kernel/cputable.c   |2 +-
 arch/powerpc/kernel/prom.c   |   27 ---
 arch/powerpc/mm/init_32.c|   15 ---
 arch/powerpc/mm/init_64.c|   14 --
 arch/powerpc/mm/mem.c|   19 +++
 arch/powerpc/sysdev/fsl_lbc.c|6 +++---
 9 files changed, 48 insertions(+), 41 deletions(-)
 delete mode 100644 arch/powerpc/boot/dtc-src/.gitignore


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ppc/85xx: specify interrupt for pq3-localbus devices

[Benjamin Herrenschmidt]

On Thu, 2011-06-09 at 19:01 +0400, Dmitry Eremin-Solenikov wrote:
> Sorry, if I'm being too noisy, what about this patch?

Just wait til somebody has a chance to pick it up. I have been too busy
lately and it looks like others as well. It shouldn't get lost, it's
tracked on patchwork.

Cheers,
Ben.

> On 6/1/11, Dmitry Eremin-Solenikov  wrote:
> > fsl-lbc driver requires an interrupt to bind to localbus device.
> > Populate 85xx boards' dts trees with lbc interrupt info.
> >
> > Signed-off-by: Dmitry Eremin-Solenikov 
> > ---
> >  arch/powerpc/boot/dts/mpc8568mds.dts   |2 ++
> >  arch/powerpc/boot/dts/socrates.dts |2 ++
> >  arch/powerpc/boot/dts/tqm8540.dts  |2 ++
> >  arch/powerpc/boot/dts/tqm8548-bigflash.dts |2 ++
> >  arch/powerpc/boot/dts/tqm8548.dts  |2 ++
> >  arch/powerpc/boot/dts/tqm8560.dts  |2 ++
> >  arch/powerpc/boot/dts/xpedite5200.dts  |2 ++
> >  arch/powerpc/boot/dts/xpedite5200_xmon.dts |2 ++
> >  8 files changed, 16 insertions(+), 0 deletions(-)
> 
> 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 7/7] [v6] drivers/virt: introduce Freescale hypervisor management driver

[Timur Tabi]

Add the drivers/virt directory, which houses drivers that support
virtualization environments, and add the Freescale hypervisor management
driver.

The Freescale hypervisor management driver provides several services to
drivers and applications related to the Freescale hypervisor:

1. An ioctl interface for querying and managing partitions

2. A file interface to reading incoming doorbells

3. An interrupt handler for shutting down the partition upon receiving the
   shutdown doorbell from a manager partition

4. A kernel interface for receiving callbacks when a managed partition
   shuts down.

Signed-off-by: Timur Tabi 
---
 Documentation/ioctl/ioctl-number.txt |1 +
 drivers/Kconfig  |2 +
 drivers/Makefile |3 +
 drivers/virt/Kconfig |   32 ++
 drivers/virt/Makefile|5 +
 drivers/virt/fsl_hypervisor.c|  937 ++
 include/linux/Kbuild |1 +
 include/linux/fsl_hypervisor.h   |  241 +
 8 files changed, 1222 insertions(+), 0 deletions(-)
 create mode 100644 drivers/virt/Kconfig
 create mode 100644 drivers/virt/Makefile
 create mode 100644 drivers/virt/fsl_hypervisor.c
 create mode 100644 include/linux/fsl_hypervisor.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index a0a5d82..9b8a8bd 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -301,6 +301,7 @@ Code  Seq#(hex) Include FileComments

 0xAE   all linux/kvm.h Kernel-based Virtual Machine

+0xAF   00-1F   linux/fsl_hypervisor.h  Freescale hypervisor
 0xB0   all RATIO devices   in development:

 0xB1   00-1F   PPPoX   
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 557a469..0371680 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -122,4 +122,6 @@ source "drivers/hwspinlock/Kconfig"
 
 source "drivers/clocksource/Kconfig"
 
+source "drivers/virt/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 3f135b6..bbe2918 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -119,3 +119,6 @@ obj-y   += ieee802154/
 obj-y  += clk/
 
 obj-$(CONFIG_HWSPINLOCK)   += hwspinlock/
+
+# Virtualization drivers
+obj-$(CONFIG_VIRT_DRIVERS) += virt/
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
new file mode 100644
index 000..2dcdbc9
--- /dev/null
+++ b/drivers/virt/Kconfig
@@ -0,0 +1,32 @@
+#
+# Virtualization support drivers
+#
+
+menuconfig VIRT_DRIVERS
+   bool "Virtualization drivers"
+   ---help---
+ Say Y here to get to see options for device drivers that support
+ virtualization environments.
+
+ If you say N, all options in this submenu will be skipped and 
disabled.
+
+if VIRT_DRIVERS
+
+config FSL_HV_MANAGER
+   tristate "Freescale hypervisor management driver"
+   depends on FSL_SOC
+   help
+  The Freescale hypervisor management driver provides several services
+ to drivers and applications related to the Freescale hypervisor:
+
+  1) An ioctl interface for querying and managing partitions.
+
+  2) A file interface to reading incoming doorbells.
+
+  3) An interrupt handler for shutting down the partition upon
+receiving the shutdown doorbell from a manager partition.
+
+  4) A kernel interface for receiving callbacks when a managed
+partition shuts down.
+
+endif
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
new file mode 100644
index 000..c47f04d
--- /dev/null
+++ b/drivers/virt/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for drivers that support virtualization
+#
+
+obj-$(CONFIG_FSL_HV_MANAGER)   += fsl_hypervisor.o
diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
new file mode 100644
index 000..1d3b8eb
--- /dev/null
+++ b/drivers/virt/fsl_hypervisor.c
@@ -0,0 +1,937 @@
+/*
+ * Freescale Hypervisor Management Driver
+
+ * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Author: Timur Tabi 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * The Freescale hypervisor management driver provides several services to
+ * drivers and applications related to the Freescale hypervisor:
+ *
+ * 1. An ioctl interface for querying and managing partitions.
+ *
+ * 2. A file interface to reading incoming doorbells.
+ *
+ * 3. An interrupt handler for shutting down the partition upon receiving the
+ *shutdown doorbell fro

Re: [PATCH 7/7] [v6] drivers/virt: introduce Freescale hypervisor management driver

[Arnd Bergmann]

On Thursday 09 June 2011 22:52:06 Timur Tabi wrote:
> Add the drivers/virt directory, which houses drivers that support
> virtualization environments, and add the Freescale hypervisor management
> driver.
> 
> The Freescale hypervisor management driver provides several services to
> drivers and applications related to the Freescale hypervisor:
> 
> 1. An ioctl interface for querying and managing partitions
> 
> 2. A file interface to reading incoming doorbells
> 
> 3. An interrupt handler for shutting down the partition upon receiving the
>shutdown doorbell from a manager partition
> 
> 4. A kernel interface for receiving callbacks when a managed partition
>shuts down.
> 
> Signed-off-by: Timur Tabi 

Acked-by: Arnd Bergmann 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] [RFC][V3] bluegene: use MMU feature flag to conditionalize L1 writethrough code

[Benjamin Herrenschmidt]

On Thu, 2011-06-09 at 09:58 -0500, Eric Van Hensbergen wrote:
> On Tue, Jun 7, 2011 at 7:47 PM, Benjamin Herrenschmidt
>  wrote:
> > On Tue, 2011-06-07 at 16:36 -0500, Eric Van Hensbergen wrote:
> >
> >> open to alternatives.  jimix also suggested changing NEED_L1_WRITETHROUGH
> >> to DCBZ_BROKEN, which I'm open to if you think appropriate, or maybe
> >> DCBZ_BROKEN_DAMNIT would be more apt.
> >
> > :-)
> >
> > I think NEED_L1_WRITETHROUGH isn't great since we are dealing with more
> > than just that here. Let's call it 44x_SMP since afaik, all
> > implementations, whether it's BG or other variants of the same hack
> > (AMCC/APM has one too) need the same stuff here, no ?
> >
> > Let's not use more than one feature bit, it's not needed in practice, a
> > better name is all we need. Might even call it MMU_FTR_BLUEGENE_44x_SMP
> > if you want.
> >
> 
> I've got it as MMU_FTR_44x_SMP now, 

Keep it BGP for now as my understanding is that some of those TLB bits
are quite specific to the way the BGP ASIC operates. AFAIK The only
possible other user of that is that dual 464 chip from AMCC/APM but I
yet have to see them try to get SMP on that, and I don't know how their
caches work at this point.

> just wanted to bounce off of Josh to
> make sure he's okay with it since he owns the 44x stuff.  If he'd
> rather, I'll change
> it to MMU_FTR_BGP_44x_SMP.
> 
> >
> > I'll add comments inline:
> >
> >>  #define PPC44x_MMUCR_TID 0x00ff
> >>  #define PPC44x_MMUCR_STS 0x0001
> >> +#define PPC44x_MMUCR_U2  0x0020
> >
> > Please document in a comment what is the effect of U2 on the BG/P ASIC
> > caches.
> >
> 
> Is a comment sufficient, or would you rather also have something along
> the lines of
> +#define PPC44x_MMUCR_U2  0x0020
> +#define PPC44x_MMUCR_U2_SWOAE   PPC44x_MMUCR_U2 /* store without allocation 
> */
>
> or even...
> +#define PPC44x_MMUCR_U2_BGP_SWOAE   PPC44x_MMUCR_U2 /* store without
> allocation on BGP */

My point was more like: You have U2, that other W1 bit etc... it's
unclear which does what here and a blurb explaining how the caches
operate on this setup would be useful.

I don't care much about the name of the constants, "SWOAE" isn't very
informative either, I'm really talking about adding a nice comment
explaining what they do :-)

> Seems like its getting a bit too verbose, maybe that's not a bad
> thing.  As long as I don't have to type it
> too many times :)

Right, don't make the constant horrible, just explain what it does.

> > BTW. Care to explain to me why you have U2 -both- in the arguments to
> > tlbwe and in MMUCR ? That doesn't look right to me... which one is used
> > where and when ?
> >
> 
> My reading of the databook is that U2SWOAE is an enable bit that lets the U2
> storage attribute control the behavior.

You mean the MMUCR variant ?

> >> @@ -814,7 +829,15 @@ skpinv:  addir4,r4,1 /* 
> >> Increment */
> >>   /* attrib fields */
> >>   /* Added guarded bit to protect against speculative loads/stores */
> >>   li  r5,0
> >> - ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | 
> >> PPC44x_TLB_G)
> >> +BEGIN_MMU_FTR_SECTION
> >> + ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | \
> >> + PPC44x_TLB_G | PPC44x_TLB_U2)
> >> + orisr5,r5,PPC44x_TLB_WL1@h
> >> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_L1_WRITETHROUGH)
> >> +BEGIN_MMU_FTR_SECTION
> >> + ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | \
> >> + PPC44x_TLB_G)
> >> +END_MMU_FTR_SECTION_IFCLR(MMU_FTR_NEED_L1_WRITETHROUGH)
> >>
> >>  li  r0,63/* TLB slot 63 */
> >
> > This isn't going to work. This happens before the CPU feature bits are
> > established.
> >
> > I see two ways out of that dilemna:
> >
> >  - One is you find a way to identify the BG case at runtime from that
> > very early asm code. It's a bit tricky since we never added the MMU type
> > information to the device-tree blob header (but we're adding it to ePAPR
> > via a register iirc, so we could hijack that), or maybe via inspecting
> > what the FW left behind in the TLB...
> >
> 
> Well, if we are using the u-boot scenario, I can control how the
> bootloader sets up the device tree and add markers that we can use to
> let us do this.

Well, point is, parsing the device-tree from early boot asm is nasty,
unless you start extending the header but that sucks. That's why I'm
thinking it might be a good idea to look at what it takes to "convert"
the initial entry instead, even if that involves some cache flushing
(provided that's workable at all of course).

Cheers
Ben.



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] [RFC][V3] bluegene: use MMU feature flag to conditionalize L1 writethrough code

[Eric Van Hensbergen]

On Thu, Jun 9, 2011 at 6:42 PM, Benjamin Herrenschmidt
 wrote:
> On Thu, 2011-06-09 at 09:58 -0500, Eric Van Hensbergen wrote:
>> On Tue, Jun 7, 2011 at 7:47 PM, Benjamin Herrenschmidt
>>  wrote:
>> > BTW. Care to explain to me why you have U2 -both- in the arguments to
>> > tlbwe and in MMUCR ? That doesn't look right to me... which one is used
>> > where and when ?
>> >
>>
>> My reading of the databook is that U2SWOAE is an enable bit that lets the U2
>> storage attribute control the behavior.
>
> You mean the MMUCR variant ?
>

Yeah, the MMCR variant acts as an enable/mask for the U2 storage attribute.

>
> Well, point is, parsing the device-tree from early boot asm is nasty,
> unless you start extending the header but that sucks. That's why I'm
> thinking it might be a good idea to look at what it takes to "convert"
> the initial entry instead, even if that involves some cache flushing
> (provided that's workable at all of course).
>

ah, okay.  I guess if its happening before the secondary cpus come up
then that should be workable.   I guess it doesn't hurt to try.

   -eric
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev