1. 23 9月, 2014 1 次提交
    • J
      xen-scsiback: Add Xen PV SCSI backend driver · d9d660f6
      Juergen Gross 提交于
      Introduces the Xen pvSCSI backend. With pvSCSI it is possible for a
      Xen domU to issue SCSI commands to a SCSI LUN assigned to that
      domU. The SCSI commands are passed to the pvSCSI backend in a driver
      domain (usually Dom0) which is owner of the physical device. This
      allows e.g. to use SCSI tape drives in a Xen domU.
      
      The code is taken from the pvSCSI implementation in Xen done by
      Fujitsu based on Linux kernel 2.6.18.
      
      Changes from the original version are:
      - port to upstream kernel
      - put all code in just one source file
      - adapt to Linux style guide
      - use target core infrastructure instead doing pure pass-through
      - enable module unloading
      - support SG-list in grant page(s)
      - support task abort
      - remove redundant struct backend
      - allocate resources dynamically
      - correct minor error in scsiback_fast_flush_area
      - free allocated resources in case of error during I/O preparation
      - remove CDB emulation, now handled by target core infrastructure
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Reviewed-by: NNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      d9d660f6
  2. 19 7月, 2014 1 次提交
    • D
      xen: Put EFI machinery in place · be81c8a1
      Daniel Kiper 提交于
      This patch enables EFI usage under Xen dom0. Standard EFI Linux
      Kernel infrastructure cannot be used because it requires direct
      access to EFI data and code. However, in dom0 case it is not possible
      because above mentioned EFI stuff is fully owned and controlled
      by Xen hypervisor. In this case all calls from dom0 to EFI must
      be requested via special hypercall which in turn executes relevant
      EFI code in behalf of dom0.
      
      When dom0 kernel boots it checks for EFI availability on a machine.
      If it is detected then artificial EFI system table is filled.
      Native EFI callas are replaced by functions which mimics them
      by calling relevant hypercall. Later pointer to EFI system table
      is passed to standard EFI machinery and it continues EFI subsystem
      initialization taking into account that there is no direct access
      to EFI boot services, runtime, tables, structures, etc. After that
      system runs as usual.
      
      This patch is based on Jan Beulich and Tang Liang work.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NTang Liang <liang.tang@oracle.com>
      Signed-off-by: NDaniel Kiper <daniel.kiper@oracle.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      be81c8a1
  3. 06 1月, 2014 1 次提交
    • I
      xen: balloon: enable for ARM · 72f28071
      Ian Campbell 提交于
      Since c275a57f "xen/balloon: Set balloon's initial state to number of
      existing RAM pages" the balloon driver appears to work fine on ARM as far as I
      can tell. Prior to that commit it was broken because on ARM RAM doesn't
      typically start at zero, effectively leaving a big MMIO hole at the start.
      This would cause the balloon driver to give away all of RAM at start of day,
      which is rather inconvenient.
      
      It was already enabled (or rather not excluded) on ARM64. The
      c1d15f5c
      "xen/balloon: Seperate the auto-translate logic properly (v2)"
      added in the proper plumbing to work with ARM and PVH type guests.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      [v2: Added the bit about PVH]
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      72f28071
  4. 02 12月, 2013 1 次提交
  5. 10 10月, 2013 1 次提交
    • S
      xen/arm,arm64: enable SWIOTLB_XEN · 83862ccf
      Stefano Stabellini 提交于
      Xen on arm and arm64 needs SWIOTLB_XEN: when running on Xen we need to
      program the hardware with mfns rather than pfns for dma addresses.
      Remove SWIOTLB_XEN dependency on X86 and PCI and make XEN select
      SWIOTLB_XEN on arm and arm64.
      
      At the moment always rely on swiotlb-xen, but when Xen starts supporting
      hardware IOMMUs we'll be able to avoid it conditionally on the presence
      of an IOMMU on the platform.
      
      Implement xen_create_contiguous_region on arm and arm64: for the moment
      we assume that dom0 has been mapped 1:1 (physical addresses == machine
      addresses) therefore we don't need to call XENMEM_exchange. Simply
      return the physical address as dma address.
      
      Initialize the xen-swiotlb from xen_early_init (before the native
      dma_ops are initialized), set xen_dma_ops to &xen_swiotlb_dma_ops.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      
      
      Changes in v8:
      - assume dom0 is mapped 1:1, no need to call XENMEM_exchange.
      
      Changes in v7:
      - call __set_phys_to_machine_multi from xen_create_contiguous_region and
      xen_destroy_contiguous_region to update the P2M;
      - don't call XENMEM_unpin, it has been removed;
      - call XENMEM_exchange instead of XENMEM_exchange_and_pin;
      - set nr_exchanged to 0 before calling the hypercall.
      
      Changes in v6:
      - introduce and export xen_dma_ops;
      - call xen_mm_init from as arch_initcall.
      
      Changes in v4:
      - remove redefinition of DMA_ERROR_CODE;
      - update the code to use XENMEM_exchange_and_pin and XENMEM_unpin;
      - add a note about hardware IOMMU in the commit message.
      
      Changes in v3:
      - code style changes;
      - warn on XENMEM_put_dma_buf failures.
      83862ccf
  6. 31 7月, 2013 1 次提交
  7. 15 5月, 2013 2 次提交
  8. 08 5月, 2013 1 次提交
  9. 01 5月, 2013 1 次提交
    • D
      xen: tmem: enable Xen tmem shim to be built/loaded as a module · 10a7a077
      Dan Magenheimer 提交于
      Allow Xen tmem shim to be built/loaded as a module.  Xen self-ballooning
      and frontswap-selfshrinking are now also "lazily" initialized when the
      Xen tmem shim is loaded as a module, unless explicitly disabled by
      module parameters.
      
      Note runtime dependency disallows loading if cleancache/frontswap lazy
      initialization patches are not present.
      
      If built-in (not built as a module), the original mechanism of enabling
      via a kernel boot parameter is retained, but this should be considered
      deprecated.
      
      Note that module unload is explicitly not yet supported.
      
      [v1: Removed the [CLEANCACHE|FRONTSWAP]_HAS_LAZY_INIT ifdef]
      [v2: Squashed the xen/tmem: Remove the subsys call patch in]
      [akpm@linux-foundation.org: fix build (disable_frontswap_selfshrinking undeclared)]
      Signed-off-by: NDan Magenheimer <dan.magenheimer@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NBob Liu <lliubbo@gmail.com>
      Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
      Cc: Andor Daam <andor.daam@googlemail.com>
      Cc: Florian Schmaus <fschmaus@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Stefan Hengelein <ilendir@googlemail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      10a7a077
  10. 28 3月, 2013 1 次提交
    • K
      xen/acpi-stub: Disable it b/c the acpi_processor_add is no longer called. · 76fc2537
      Konrad Rzeszutek Wilk 提交于
      With the Xen ACPI stub code (CONFIG_XEN_STUB=y) enabled, the power
      C and P states are no longer uploaded to the hypervisor.
      
      The reason is that the Xen CPU hotplug code: xen-acpi-cpuhotplug.c
      and the xen-acpi-stub.c register themselves as the "processor" type object.
      
      That means the generic processor (processor_driver.c) stops
      working and it does not call (acpi_processor_add) which populates the
      
               per_cpu(processors, pr->id) = pr;
      
      structure. The 'pr' is gathered from the acpi_processor_get_info function
      which does the job of finding the C-states and figuring out PBLK address.
      
      The 'processors->pr' is then later used by xen-acpi-processor.c (the one that
      uploads C and P states to the hypervisor). Since it is NULL, we end
      skip the gathering of _PSD, _PSS, _PCT, etc and never upload the power
      management data.
      
      The end result is that enabling the CONFIG_XEN_STUB in the build means that
      xen-acpi-processor is not working anymore.
      
      This temporary patch fixes it by marking the XEN_STUB driver as
      BROKEN until this can be properly fixed.
      
      CC: jinsong.liu@intel.com
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      76fc2537
  11. 20 2月, 2013 3 次提交
    • L
      xen/acpi: ACPI cpu hotplug · 39adc483
      Liu Jinsong 提交于
      This patch implement real Xen ACPI cpu hotplug driver as module.
      When loaded, it replaces Xen stub driver.
      
      For booting existed cpus, the driver enumerates them.
      For hotadded cpus, which added at runtime and notify OS via
      device or container event, the driver is invoked to add them,
      parsing cpu information, hypercalling to Xen hypervisor to add
      them, and finally setting up new /sys interface for them.
      Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      39adc483
    • L
      xen/acpi: ACPI memory hotplug · ef92e7ca
      Liu Jinsong 提交于
      This patch implements real Xen acpi memory hotplug driver as module.
      When loaded, it replaces Xen stub driver.
      
      When an acpi memory device hotadd event occurs, it notifies OS and
      invokes notification callback, adding related memory device and parsing
      memory information, finally hypercall to xen hypervisor to add memory.
      Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ef92e7ca
    • L
      xen/stub: driver for memory hotplug · dcb93b96
      Liu Jinsong 提交于
      This patch create a file (xen-stub.c) for Xen stub drivers.
      Xen stub drivers are used to reserve space for Xen drivers, i.e.
      memory hotplug and cpu hotplug, and to block native drivers loaded,
      so that real Xen drivers can be modular and loaded on demand.
      
      This patch is specific for Xen memory hotplug (other Xen logic
      can add stub drivers on their own). The xen stub driver will
      occupied earlier via subsys_initcall (than native memory hotplug
      driver via module_init and so blocking native). Later real Xen
      memory hotplug logic will unregister the stub driver and register
      itself to take effect on demand.
      Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      dcb93b96
  12. 29 11月, 2012 1 次提交
  13. 10 10月, 2012 1 次提交
    • A
      ARM: Xen: fix initial build problems · f880b67d
      Arnd Bergmann 提交于
      * The XEN_BALLOON code requires the balloon infrastructure that is not
        getting built on ARM.
      
      * The tmem hypercall is not available on ARM
      
      * ARMv6 does not support cmpxchg on 16-bit words that are used in the
        Xen grant table code, so we must ensure that Xen support is only
        built on ARMv7-only kernels not combined ARMv6/v7 kernels.
      
      * sys-hypervisor.c needs to include linux/err.h in order to use the
        IS_ERR/PTR_ERR/ERR_PTR family of functions.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: xen-devel@lists.xensource.com
      f880b67d
  14. 20 7月, 2012 1 次提交
  15. 08 5月, 2012 1 次提交
  16. 16 4月, 2012 1 次提交
  17. 24 3月, 2012 1 次提交
    • K
      xen/acpi: Fix Kconfig dependency on CPU_FREQ · df7a3ee2
      Konrad Rzeszutek Wilk 提交于
      The functions: "acpi_processor_*" sound like they depend on CONFIG_ACPI_PROCESSOR
      but in reality they are exposed when CONFIG_CPU_FREQ=[y|m]. As such
      update the Kconfig to have this dependency and fix compile issues:
      
      ERROR: "acpi_processor_unregister_performance" [drivers/xen/xen-acpi-processor.ko] undefined!
      ERROR: "acpi_processor_notify_smm" [drivers/xen/xen-acpi-processor.ko] undefined!
      ERROR: "acpi_processor_register_performance" [drivers/xen/xen-acpi-processor.ko] undefined!
      ERROR: "acpi_processor_preregister_performance" [drivers/xen/xen-acpi-processor.ko] undefined!
      
      Note: We still need the CONFIG_ACPI
      Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      df7a3ee2
  18. 21 3月, 2012 1 次提交
  19. 15 3月, 2012 1 次提交
    • K
      xen/acpi-processor: C and P-state driver that uploads said data to hypervisor. · 59a56802
      Konrad Rzeszutek Wilk 提交于
      This driver solves three problems:
       1). Parse and upload ACPI0007 (or PROCESSOR_TYPE) information to the
           hypervisor - aka P-states (cpufreq data).
       2). Upload the the Cx state information (cpuidle data).
       3). Inhibit CPU frequency scaling drivers from loading.
      
      The reason for wanting to solve 1) and 2) is such that the Xen hypervisor
      is the only one that knows the CPU usage of different guests and can
      make the proper decision of when to put CPUs and packages in proper states.
      Unfortunately the hypervisor has no support to parse ACPI DSDT tables, hence it
      needs help from the initial domain to provide this information. The reason
      for 3) is that we do not want the initial domain to change P-states while the
      hypervisor is doing it as well - it causes rather some funny cases of P-states
      transitions.
      
      For this to work, the driver parses the Power Management data and uploads said
      information to the Xen hypervisor. It also calls acpi_processor_notify_smm()
      to inhibit the other CPU frequency scaling drivers from being loaded.
      
      Everything revolves around the 'struct acpi_processor' structure which
      gets updated during the bootup cycle in different stages. At the startup, when
      the ACPI parser starts, the C-state information is processed (processor_idle)
      and saved in said structure as 'power' element. Later on, the CPU frequency
      scaling driver (powernow-k8 or acpi_cpufreq), would call the the
      acpi_processor_* (processor_perflib functions) to parse P-states information
      and populate in the said structure the 'performance' element.
      
      Since we do not want the CPU frequency scaling drivers from loading
      we have to call the acpi_processor_* functions to parse the P-states and
      call "acpi_processor_notify_smm" to stop them from loading.
      
      There is also one oddity in this driver which is that under Xen, the
      physical online CPU count can be different from the virtual online CPU count.
      Meaning that the macros 'for_[online|possible]_cpu' would process only
      up to virtual online CPU count. We on the other hand want to process
      the full amount of physical CPUs. For that, the driver checks if the ACPI IDs
      count is different from the APIC ID count - which can happen if the user
      choose to use dom0_max_vcpu argument. In such a case a backup of the PM
      structure is used and uploaded to the hypervisor.
      
      [v1-v2: Initial RFC implementations that were posted]
      [v3: Changed the name to passthru suggested by Pasi Kärkkäinen <pasik@iki.fi>]
      [v4: Added vCPU != pCPU support - aka dom0_max_vcpus support]
      [v5: Cleaned up the driver, fix bug under Athlon XP]
      [v6: Changed the driver to a CPU frequency governor]
      [v7: Jan Beulich <jbeulich@suse.com> suggestion to make it a cpufreq scaling driver
           made me rework it as driver that inhibits cpufreq scaling driver]
      [v8: Per Jan's review comments, fixed up the driver]
      [v9: Allow to continue even if acpi_processor_preregister_perf.. fails]
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      59a56802
  20. 17 12月, 2011 1 次提交
  21. 29 9月, 2011 1 次提交
  22. 04 8月, 2011 1 次提交
  23. 26 7月, 2011 1 次提交
    • D
      xen/balloon: memory hotplug support for Xen balloon driver · 080e2be7
      Daniel Kiper 提交于
      Memory hotplug support for Xen balloon driver.  It should be mentioned
      that hotplugged memory is not onlined automatically.  It should be onlined
      by user through standard sysfs interface.
      
      Memory could be hotplugged in following steps:
      
        1) dom0: xl mem-max <domU> <maxmem>
           where <maxmem> is >= requested memory size,
      
        2) dom0: xl mem-set <domU> <memory>
           where <memory> is requested memory size; alternatively memory
           could be added by writing proper value to
           /sys/devices/system/xen_memory/xen_memory0/target or
           /sys/devices/system/xen_memory/xen_memory0/target_kb on dumU,
      
        3) domU: for i in /sys/devices/system/memory/memory*/state; do \
                   [ "`cat "$i"`" = offline ] && echo online > "$i"; done
      
      Memory could be onlined automatically on domU by adding following line to
      udev rules:
      
        SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f /sys$devpath/state ] && echo online > /sys$devpath/state'"
      
      In that case step 3 should be omitted.
      Signed-off-by: NDaniel Kiper <dkiper@net-space.pl>
      Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      080e2be7
  24. 20 7月, 2011 3 次提交
    • K
      xen/pciback: Have 'passthrough' option instead of XEN_PCIDEV_BACKEND_PASS and... · 2ebdc426
      Konrad Rzeszutek Wilk 提交于
      xen/pciback: Have 'passthrough' option instead of XEN_PCIDEV_BACKEND_PASS and XEN_PCIDEV_BACKEND_VPCI
      
      .. compile options. This way the user can decide during runtime whether they
      want the default 'vpci' (virtual pci passthrough) or where the PCI devices
      are passed in without any BDF renumbering. The option 'passthrough' allows
      the user to toggle the it from 0 (vpci) to 1 (passthrough).
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2ebdc426
    • K
      xen/pciback: Remove the DEBUG option. · 77899970
      Konrad Rzeszutek Wilk 提交于
      The latter is easily fixed - by the developer compiling the
      module with -DDEBUG. And during runtime - the loglvl provides
      quite a lot of useful data.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      77899970
    • K
      xen/pciback: xen pci backend driver. · 30edc14b
      Konrad Rzeszutek Wilk 提交于
      This is the host side counterpart to the frontend driver in
      drivers/pci/xen-pcifront.c. The PV protocol is also implemented by
      frontend drivers in other OSes too, such as the BSDs.
      
      The PV protocol is rather simple. There is page shared with the guest,
      which has the 'struct xen_pci_sharedinfo' embossed in it. The backend
      has a thread that is kicked every-time the structure is changed and
      based on the operation field it performs specific tasks:
      
       XEN_PCI_OP_conf_[read|write]:
         Read/Write 0xCF8/0xCFC filtered data. (conf_space*.c)
         Based on which field is probed, we either enable/disable the PCI
         device, change power state, read VPD, etc. The major goal of this
         call is to provide a Physical IRQ (PIRQ) to the guest.
      
         The PIRQ is Xen hypervisor global IRQ value irrespective of the IRQ
         is tied in to the IO-APIC, or is a vector. For GSI type
         interrupts, the PIRQ==GSI holds. For MSI/MSI-X the
         PIRQ value != Linux IRQ number (thought PIRQ==vector).
      
         Please note, that with Xen, all interrupts (except those level shared ones)
         are injected directly to the guest - there is no host interaction.
      
       XEN_PCI_OP_[enable|disable]_msi[|x] (pciback_ops.c)
         Enables/disables the MSI/MSI-X capability of the device. These operations
         setup the MSI/MSI-X vectors for the guest and pass them to the frontend.
      
         When the device is activated, the interrupts are directly injected in the
         guest without involving the host.
      
       XEN_PCI_OP_aer_[detected|resume|mmio|slotreset]: In case of failure,
        perform the appropriate AER commands on the guest. Right now that is
        a cop-out - we just kill the guest.
      
      Besides implementing those commands, it can also
      
       - hide a PCI device from the host. When booting up, the user can specify
         xen-pciback.hide=(1:0:0)(BDF..) so that host does not try to use the
         device.
      
      The driver was lifted from linux-2.6.18.hg tree and fixed up
      so that it could compile under v3.0. Per suggestion from Jesse Barnes
      moved the driver to drivers/xen/xen-pciback.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      30edc14b
  25. 09 7月, 2011 1 次提交
    • D
      xen: tmem: self-ballooning and frontswap-selfshrinking · a50777c7
      Dan Magenheimer 提交于
      This patch introduces two in-kernel drivers for Xen transcendent memory
      ("tmem") functionality that complement cleancache and frontswap.  Both
      use control theory to dynamically adjust and optimize memory utilization.
      Selfballooning controls the in-kernel Xen balloon driver, targeting a goal
      value (vm_committed_as), thus pushing less frequently used clean
      page cache pages (through the cleancache code) into Xen tmem where
      Xen can balance needs across all VMs residing on the physical machine.
      Frontswap-selfshrinking controls the number of pages in frontswap,
      driving it towards zero (effectively doing a partial swapoff) when
      in-kernel memory pressure subsides, freeing up RAM for other VMs.
      
      More detail is provided in the header comment of xen-selfballooning.c.
      Signed-off-by: NDan Magenheimer <dan.magenheimer@oracle.com>
      
      [v8: konrad.wilk@oracle.com: set default enablement depending on frontswap]
      [v7: konrad.wilk@oracle.com: fix capitalization and punctuation in comments]
      [v6: fix frontswap-selfshrinking initialization]
      [v6: konrad.wilk@oracle.com: fix init pr_infos; add comments about swap]
      [v5: konrad.wilk@oracle.com: add NULL to attr list; move inits up to decls]
      [v4: dkiper@net-space.pl: use strict_strtoul plus a few syntactic nits]
      [v3: konrad.wilk@oracle.com: fix potential divides-by-zero]
      [v3: konrad.wilk@oracle.com: add many more comments, fix nits]
      [v2: rebased to linux-3.0-rc1]
      [v2: Ian.Campbell@citrix.com: reorganize as new file (xen-selfballoon.c)]
      [v2: dkiper@net-space.pl: proper access to vm_committed_as]
      [v2: dkiper@net-space.pl: accounting fixes]
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: <xen-devel@lists.xensource.com>
      a50777c7
  26. 18 6月, 2011 1 次提交
  27. 19 4月, 2011 1 次提交
  28. 15 4月, 2011 1 次提交
  29. 16 2月, 2011 1 次提交
  30. 15 2月, 2011 1 次提交
  31. 13 1月, 2011 1 次提交
  32. 12 1月, 2011 1 次提交
  33. 06 1月, 2011 3 次提交