- Mar 28, 2015
-
-
git://git.linux-mips.org/pub/scm/ralf/upstream-sfrJames Hogan authored
MIPS FP/MSA fixes from the MIPS tree. Includes a fix to ensure that the FPU is properly disabled by lose_fpu() when MSA is in use, and Paul Burton's "FP/MSA fixes" patchset which is required for FP/MSA support in KVM: > This series fixes a bunch of bugs, both build & runtime, with FP & MSA > support. Most of them only affect systems with the new FP modes & MSA > support enabled but patch 6 in particular is more general, fixing > problems for mips64 systems.
-
James Hogan authored
The maximum word size is 64-bits since MSA state is saved using st.d which stores two 64-bit words, therefore reimplement FPR_IDX using xor, and only within each 64-bit word. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9169/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
James Hogan authored
This reverts commit 02987633 . The basic premise of the patch was incorrect since MSA context (including FP state) is saved using st.d which stores two consecutive 64-bit words in memory rather than a single 128-bit word. This means that even with big endian MSA, the FP state is still in the first 64-bit word. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9168/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
The expected semantics of __enable_fpu are for the FPU to be enabled in the given mode if possible, otherwise for the FPU to be left disabled and SIGFPE returned. The FPU was incorrectly being left enabled in cases where the desired value for FR was unavailable. Without ensuring the FPU is disabled in this case, it would be possible for userland to go on to execute further FP instructions natively in the incorrect mode, rather than those instructions being trapped & emulated as they need to be. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9167/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
If a ptracee has not used the FPU and the ptracer sets its FP context using PTRACE_POKEUSR, PTRACE_SETFPREGS or PTRACE_SETREGSET then that context will be discarded upon either the ptracee using the FPU or a further write to the context via ptrace. Prevent this loss by recording that the task has "used" math once its FP context has been written to. The context initialisation code that was present for the PTRACE_POKEUSR case is reused for the other 2 cases to provide consistent behaviour for the different ptrace requests. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9166/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
When running the emulator to handle an instruction that raised an FP unimplemented operation exception, the FCSR cause bits were being cleared. This is done to ensure that the kernel does not take an FP exception when later restoring FP context to registers. However, this was not being done when the emulator is invoked in response to a coprocessor unusable exception. This happens in 2 cases: - There is no FPU present in the system. In this case things were OK, since the FP context is never restored to hardware registers and thus no FP exception may be raised when restoring FCSR. - The FPU could not be configured to the mode required by the task. In this case it would be possible for the emulator to set cause bits which are later restored to hardware if the task migrates to a CPU whose associated FPU does support its mode requirements, or if the tasks FP mode requirements change. Consistently clear the cause bits after invoking the emulator, by moving the clearing to process_fpemu_return and ensuring this is always called before the tasks FP context is restored. This will make it easier to catch further paths invoking the emulator in future, as will be introduced in further patches. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9165/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
Much like for traditional scalar FP exceptions, the cause bits in the MSACSR register need to be cleared following an MSA FP exception. Without doing so the exception will simply be raised again whenever the kernel restores MSACSR from a tasks saved context, leading to undesirable spurious exceptions. Clear the cause bits from the handle_msa_fpe function, mirroring the way handle_fpe clears the cause bits in FCSR. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9164/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
Uses of the cfcmsa & ctcmsa instructions were not being wrapped by a macro in the case where the toolchain supports MSA, since the arguments exactly match a typical use of the instructions. However using current toolchains this leads to errors such as: arch/mips/kernel/genex.S:437: Error: opcode not supported on this processor: mips32r2 (mips32r2) `cfcmsa $5,1' Thus uses of the instructions must be in the context of a ".set msa" directive, however doing that from the users of the instructions would be messy due to the possibility that the toolchain does not support MSA. Fix this by renaming the macros (prepending an underscore) in order to avoid recursion when attempting to emit the instructions, and provide implementations for the TOOLCHAIN_SUPPORTS_MSA case which ".set msa" as appropriate. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9163/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
Recursive macros made the code more concise & worked great for the case where the toolchain doesn't support MSA. However, with toolchains which do support MSA they lead to build failures such as: arch/mips/kernel/r4k_switch.S: Assembler messages: arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[2],$1' arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[3],$1' arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[2],$1' arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[3],$1' ... Drop the recursion from msa_init_all_upper invoking the msa_init_upper macro explicitly for each vector register. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9162/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
Assuming at ($1) as the source or destination register of copy or insert instructions: - Simplifies the macros providing those instructions for toolchains without MSA support. - Avoids an unnecessary move instruction when at is used as the source or destination register anyway. - Is sufficient for the uses to be introduced in the kernel by a subsequent patch. Note that due to a patch ordering snafu on my part this also fixes the currently broken build with MSA support enabled. The build has been broken since commit c9017757 "MIPS: init upper 64b of vector registers when MSA is first used", which this patch should have preceeded. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9161/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
The {save,restore}_fp_context{,32} functions require that the assembler allows the use of sdc instructions on any FP register, and this is acomplished by setting the arch to mips64r2 or mips64r6 (using MIPS_ISA_ARCH_LEVEL_RAW). However this has the effect of enabling the assembler to use mips64 instructions in the expansion of pseudo-instructions. This was done in the (now-reverted) commit eec43a22 "MIPS: Save/restore MSA context around signals" which led to my mistakenly believing that there was an assembler bug, when in reality the assembler was just emitting mips64 instructions. Avoid the issue for future commits which will add code to r4k_fpu.S by pushing the .set MIPS_ISA_ARCH_LEVEL_RAW directives into the functions that require it, and remove the spurious assertion declaring the assembler bug. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> [james.hogan@imgtec.com: Rebase on v4.0-rc1 and reword commit message to reflect use of MIPS_ISA_ARCH_LEVEL_RAW] Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9612/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
James Hogan authored
The lose_fpu() function only disables the FPU in CP0_Status.CU1 if the FPU is in use and MSA isn't enabled. This isn't necessarily a problem because KSTK_STATUS(current), the version of CP0_Status stored on the kernel stack on entry from user mode, does always get updated and gets restored when returning to user mode, but I don't think it was intended, and it is inconsistent with the case of only the FPU being in use. Sometimes leaving the FPU enabled may also mask kernel bugs where FPU operations are executed when the FPU might not be enabled. So lets disable the FPU in the MSA case too. Fixes: 33c771ba ("MIPS: save/disable MSA in lose_fpu") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9323/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
- Mar 27, 2015
-
-
Jan Kiszka authored
If the guest CPU is supposed to support rdtscp and the host has rdtscp enabled in the secondary execution controls, we can also expose this feature to L1. Just extend nested_vmx_exit_handled to properly route EXIT_REASON_RDTSCP. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- Mar 24, 2015
-
-
Radim Krčmář authored
An overhead from function call is not appropriate for its size and frequency of execution. Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Marcelo Tosatti authored
Merge tag 'kvm-s390-next-20150318' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into queue KVM: s390: Features and fixes for 4.1 (kvm/next) 1. Fixes 2. Implement access register mode in KVM 3. Provide a userspace post handler for the STSI instruction 4. Provide an interface for compliant memory accesses 5. Provide an interface for getting/setting the guest storage key 6. Fixup for the vector facility patches: do not announce the vector facility in the guest for old QEMUs. 1-5 were initially shown as RFC in http://www.spinics.net/lists/kvm/msg114720.html some small review changes - added some ACKs - have the AR mode patches first - get rid of unnecessary AR_INVAL define - typos and language 6. two new patches The two new patches fixup the vector support patches that were introduced in the last pull request for QEMU versions that dont know about vector support and guests that do. (We announce the facility bit, but dont enable the facility so vector aware guests will crash on vector instructions).
-
Marcelo Tosatti authored
The following point: 2. per-CPU pvclock time info is updated if the underlying CPU changes. Is not true anymore since "KVM: x86: update pvclock area conditionally, on cpu migration". Add task migration notification back. Problem noticed by Andy Lutomirski. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> CC: stable@kernel.org # 3.11+
-
- Mar 19, 2015
-
-
Takuya Yoshikawa authored
When all bits in mask are not set, kvm_arch_mmu_enable_log_dirty_pt_masked() has nothing to do. But since it needs to be called from the generic code, it cannot be inlined, and a few function calls, two when PML is enabled, are wasted. Since it is common to see many pages remain clean, e.g. framebuffers can stay calm for a long time, it is worth eliminating this overhead. Signed-off-by:
Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Bandan Das authored
I hit this path on a AMD box and thought someone was playing a April Fool's joke on me. Signed-off-by:
Bandan Das <bsd@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- Mar 18, 2015
-
-
Xiubo Li authored
This patch fix the following sparse warnings: for arch/x86/kvm/x86.c: warning: symbol 'emulator_read_write' was not declared. Should it be static? warning: symbol 'emulator_write_emulated' was not declared. Should it be static? warning: symbol 'emulator_get_dr' was not declared. Should it be static? warning: symbol 'emulator_set_dr' was not declared. Should it be static? for arch/x86/kvm/pmu.c: warning: symbol 'fixed_pmc_events' was not declared. Should it be static? Signed-off-by:
Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Xiubo Li authored
This patch fix the following sparse warning: for file arch/x86/kvm/x86.c: warning: Using plain integer as NULL pointer Signed-off-by:
Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- Mar 17, 2015
-
-
Michael Mueller authored
The patch represents capability KVM_CAP_S390_VECTOR_REGISTERS by means of the SIMD facility bit. This allows to a) disable the use of SIMD when used in conjunction with a not-SIMD-aware QEMU, b) to enable SIMD when used with a SIMD-aware version of QEMU and c) finally by means of a QEMU version using the future cpu model ioctls. Signed-off-by:
Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by:
Eric Farman <farman@linux.vnet.ibm.com> Tested-by:
Eric Farman <farman@linux.vnet.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Michael Mueller authored
Setting the SIMD bit in the KVM mask is an issue because it makes the facility visible but not usable to the guest, thus it needs to be removed again. Signed-off-by:
Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by:
Eric Farman <farman@linux.vnet.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Jason J. Herne authored
Provide the KVM_S390_GET_SKEYS and KVM_S390_SET_SKEYS ioctl which can be used to get/set guest storage keys. This functionality is needed for live migration of s390 guests that use storage keys. Signed-off-by:
Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Ekaterina Tumanova authored
The Store System Information (STSI) instruction currently collects all information it relays to the caller in the kernel. Some information, however, is only available in user space. An example of this is the guest name: The kernel always sets "KVMGuest", but user space knows the actual guest name. This patch introduces a new exit, KVM_EXIT_S390_STSI, guarded by a capability that can be enabled by user space if it wants to be able to insert such data. User space will be provided with the target buffer and the requested STSI function code. Reviewed-by:
Eric Farman <farman@linux.vnet.ibm.com> Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Thomas Huth authored
On s390, we've got to make sure to hold the IPTE lock while accessing logical memory. So let's add an ioctl for reading and writing logical memory to provide this feature for userspace, too. The maximum transfer size of this call is limited to 64kB to prevent that the guest can trigger huge copy_from/to_user transfers. QEMU currently only requests up to one or two pages so far, so 16*4kB seems to be a reasonable limit here. Signed-off-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Alexander Yarygin authored
Access register mode is one of the modes that control dynamic address translation. In this mode the address space is specified by values of the access registers. The effective address-space-control element is obtained from the result of the access register translation. See the "Access-Register Introduction" section of the chapter 5 "Program Execution" in "Principles of Operations" for more details. Signed-off-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Reviewed-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Alexander Yarygin authored
During dynamic address translation the get_vcpu_asce() function can be invoked several times. It's ok for usual modes, but will be slow if CPUs are in AR mode. Let's call the get_vcpu_asce() once and pass the result to the called functions. Signed-off-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Reviewed-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Acked-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Alexander Yarygin authored
In access register mode, the write_guest() read_guest() and other functions will invoke the access register translation, which requires an ar, designated by one of the instruction fields. Signed-off-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Reviewed-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Acked-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Alexander Yarygin authored
The kvm_s390_check_low_addr_protection() function is used only with real addresses. According to the POP (the "Low-Address Protection" paragraph in chapter 3), if the effective address is real or absolute, the low-address protection procedure should raise a PROTECTION exception only when the low-address protection is enabled in the control register 0 and the address is low. This patch removes ASCE checks from the function and renames it to better reflect its behavior. Cc: Thomas Huth <thuth@linux.vnet.ibm.com> Signed-off-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Reviewed-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Acked-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Dominik Dingel authored
As all cleanup functions can handle their respective NULL case there is no need to have more than one error jump label. Signed-off-by:
Dominik Dingel <dingel@linux.vnet.ibm.com> Acked-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Message-Id: <1425932832-6244-1-git-send-email-geert+renesas@glider.be> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
- Mar 14, 2015
-
-
Jan Kiszka authored
While in L2, leave all #UD to L2 and do not try to emulate it. If L1 is interested in doing this, it reports its interest via the exception bitmap, and we never get into handle_exception of L0 anyway. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Jan Kiszka authored
For a very long time (since 2b3d2a20 ), the path handling a vmmcall instruction of the guest on an Intel host only applied the patch but no longer handled the hypercall. The reverse case, vmcall on AMD hosts, is fine. As both em_vmcall and em_vmmcall actually have to do the same, we can fix the issue by consolidating both into the same handler. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- Mar 13, 2015
-
-
David Kaplan authored
Another patch in my war on emulate_on_interception() use as a svm exit handler. These were pulled out of a larger patch at the suggestion of Radim Krcmar, see https://lkml.org/lkml/2015/2/25/559 Changes since v1: * fixed typo introduced after test, retested Signed-off-by:
David Kaplan <david.kaplan@amd.com> [separated out just cr_interception part from larger removal of INTERCEPT_CR0_WRITE, forward ported, tested] Signed-off-by:
Joel Schopp <joel.schopp@amd.com> Reviewed-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Marcelo Tosatti authored
Merge tag 'kvm-s390-next-20150306' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into queue KVM: s390: Features and Fixes for 4.1 (kvm/next) 1. Several Fixes and enhancements --------------------------------- - These 3 patches have cc stable: b75f4c9a KVM: s390: Zero out current VMDB of STSI before including level3 data. 261520dc KVM: s390: fix handling of write errors in the tpi handler 15462e37 KVM: s390: reinjection of irqs can fail in the tpi handler 2. SIMD support the kernel part (introduced with z13) ----------------------------------------------------- - two KVM-generic changes in kvm.h: 1. New capability that can be enabled: KVM_CAP_S390_VECTOR_REGISTERS 2. increased padding size for sync regs in struct kvm_run to clarify that sync regs can be larger than 1k. This is fine as this is the last element in the structure.
-
Christian Borntraeger authored
The KVM list should be CCed on changes for arch/x86/kernel/kvm.c and arch/x86/kernel/kvmclock.c Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- Mar 11, 2015
-
-
David Kaplan authored
No need to re-decode WBINVD since we know what it is from the intercept. Signed-off-by:
David Kaplan <David.Kaplan@amd.com> [extracted from larger unlrelated patch, forward ported, tested,style cleanup] Signed-off-by:
Joel Schopp <joel.schopp@amd.com> Reviewed-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Joel Schopp authored
Currently kvm_emulate() skips the instruction but kvm_emulate_* sometimes don't. The end reult is the caller ends up doing the skip themselves. Let's make them consistant. Signed-off-by:
Joel Schopp <joel.schopp@amd.com> Reviewed-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- Mar 10, 2015
-
-
Xiubo Li authored
WARNING: Prefer [subsystem eg: netdev]_info([subsystem]dev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ... + printk(KERN_INFO "kvm: exiting hardware virtualization\n"); WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ... + printk(KERN_ERR "kvm: misc device register failed\n"); Signed-off-by:
Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Xiubo Li authored
ERROR: code indent should use tabs where possible + const struct kvm_io_range *r2)$ WARNING: please, no spaces at the start of a line + const struct kvm_io_range *r2)$ This patch fixes this ERROR & WARNING to reduce noise when checking new patches in kvm_main.c. Signed-off-by:
Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-