summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds2014-01-2421-968/+6647
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull crypto update from Herbert Xu: "Here is the crypto update for 3.14: - Improved crypto_memneq helper - Use cyprto_memneq in arch-specific crypto code - Replaced orphaned DCP driver with Freescale MXS DCP driver - Added AVX/AVX2 version of AESNI-GCM encode and decode - Added AMD Cryptographic Coprocessor (CCP) driver - Misc fixes" * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (41 commits) crypto: aesni - fix build on x86 (32bit) crypto: mxs - Fix sparse non static symbol warning crypto: ccp - CCP device enabled/disabled changes crypto: ccp - Cleanup hash invocation calls crypto: ccp - Change data length declarations to u64 crypto: ccp - Check for caller result area before using it crypto: ccp - Cleanup scatterlist usage crypto: ccp - Apply appropriate gfp_t type to memory allocations crypto: drivers - Sort drivers/crypto/Makefile ARM: mxs: dts: Enable DCP for MXS crypto: mxs - Add Freescale MXS DCP driver crypto: mxs - Remove the old DCP driver crypto: ahash - Fully restore ahash request before completing crypto: aesni - fix build on x86 (32bit) crypto: talitos - Remove redundant dev_set_drvdata crypto: ccp - Remove redundant dev_set_drvdata crypto: crypto4xx - Remove redundant dev_set_drvdata crypto: caam - simplify and harden key parsing crypto: omap-sham - Fix Polling mode for larger blocks crypto: tcrypt - Added speed tests for AEAD crypto alogrithms in tcrypt test suite ...
| * crypto: mxs - Fix sparse non static symbol warningWei Yongjun2014-01-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | Fixes the following sparse warning: drivers/crypto/mxs-dcp.c:103:1: warning: symbol 'global_mutex' was not declared. Should it be static? Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - CCP device enabled/disabled changesTom Lendacky2014-01-152-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | The CCP cannot be hot-plugged so it will either be there or it won't. Do not allow the driver to stay loaded if the CCP does not successfully initialize. Provide stub routines in the ccp.h file that return -ENODEV if the CCP has not been configured in the build. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - Cleanup hash invocation callsTom Lendacky2014-01-152-3/+7
| | | | | | | | | | | | | | | | Cleanup the ahash digest invocations to check the init return code and make use of the finup routine. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - Change data length declarations to u64Tom Lendacky2014-01-154-33/+53
| | | | | | | | | | | | | | | | | | | | | | When performing a hash operation if the amount of data buffered and a request at or near the maximum data length is received then the length calcuation could wrap causing an error in executing the hash operation. Fix this by using a u64 type for the input and output data lengths in all CCP operations. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - Check for caller result area before using itTom Lendacky2014-01-152-3/+8
| | | | | | | | | | | | | | | | | | For a hash operation, the caller doesn't have to supply a result area on every call so don't use it / update it if it hasn't been supplied. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - Cleanup scatterlist usageTom Lendacky2014-01-152-26/+33
| | | | | | | | | | | | | | | | Cleanup up the usage of scatterlists to make the code cleaner and avoid extra memory allocations when not needed. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - Apply appropriate gfp_t type to memory allocationsTom Lendacky2014-01-152-2/+8
| | | | | | | | | | | | | | | | Fix some memory allocations to use the appropriate gfp_t type based on the CRYPTO_TFM_REQ_MAY_SLEEP flag. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: drivers - Sort drivers/crypto/MakefileMarek Vasut2014-01-051-17/+17
| | | | | | | | | | | | | | | | | | | | The order in the Makefile was a mess, sort it. Signed-off-by: Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: mxs - Add Freescale MXS DCP driverMarek Vasut2014-01-053-0/+1118
| | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the MXS DCP block. The driver currently supports SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard CRC32 is not yet supported. Signed-off-by: Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: devicetree@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: mxs - Remove the old DCP driverMarek Vasut2014-01-053-914/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the old DCP driver as it had multiple severe issues. The driver will be replaced by a more robust implementation. Here is a short list of problems with this driver: 1) It only supports AES_CBC 2) The driver was apparently never ran behind anyone working with MXS. ie.: -> Restarting the DCP block is not done via mxs_reset_block() -> The DT name is not "fsl,dcp" or "fsl,mxs-dcp" as other MXS drivers 3) Introduces new ad-hoc IOCTLs 4) The IRQ handler can't use usual completion() in the driver because that'd trigger "scheduling while atomic" oops, yes? Signed-off-by: Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: talitos - Remove redundant dev_set_drvdataSachin Kamat2013-12-301-2/+0
| | | | | | | | | | | | | | Driver core sets it to NULL upon probe failure or release. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - Remove redundant dev_set_drvdataSachin Kamat2013-12-301-2/+0
| | | | | | | | | | | | | | Driver core sets it to NULL upon probe failure or release. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: crypto4xx - Remove redundant dev_set_drvdataSachin Kamat2013-12-301-1/+0
| | | | | | | | | | | | | | Driver core sets it to NULL upon probe failure or release. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: caam - simplify and harden key parsingHoria Geanta2013-12-201-23/+13
| | | | | | | | | | | | | | | | | | | | Use the common helper function crypto_authenc_extractkeys() for key parsing. Also fix the key buffer overflow condition: use split key pad length instead of authentication key length. Signed-off-by: Horia Geanta <horia.geanta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: omap-sham - Fix Polling mode for larger blocksLokesh Vutla2013-12-201-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Command "tcrypt sec=1 mode=403" give the follwoing error for Polling mode: root@am335x-evm:/# insmod tcrypt.ko sec=1 mode=403 [...] [ 346.982754] test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 4352 opers/sec, 17825792 bytes/sec [ 347.992661] test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 7095 opers/sec, 29061120 bytes/sec [ 349.002667] test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): [ 349.010882] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 349.020037] pgd = ddeac000 [ 349.022884] [00000000] *pgd=9dcb4831, *pte=00000000, *ppte=00000000 [ 349.029816] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 349.035482] Modules linked in: tcrypt(+) [ 349.039617] CPU: 0 PID: 1473 Comm: insmod Not tainted 3.12.4-01566-g6279006-dirty #38 [ 349.047832] task: dda91540 ti: ddcd2000 task.ti: ddcd2000 [ 349.053517] PC is at omap_sham_xmit_dma+0x6c/0x238 [ 349.058544] LR is at omap_sham_xmit_dma+0x38/0x238 [ 349.063570] pc : [<c04eb7cc>] lr : [<c04eb798>] psr: 20000013 [ 349.063570] sp : ddcd3c78 ip : 00000000 fp : 9d8980b8 [ 349.075610] r10: 00000000 r9 : 00000000 r8 : 00000000 [ 349.081090] r7 : 00001000 r6 : dd898000 r5 : 00000040 r4 : ddb10550 [ 349.087935] r3 : 00000004 r2 : 00000010 r1 : 53100080 r0 : 00000000 [ 349.094783] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 349.102268] Control: 10c5387d Table: 9deac019 DAC: 00000015 [ 349.108294] Process insmod (pid: 1473, stack limit = 0xddcd2248) [...] This is because polling_mode is not enabled for ctx without FLAGS_FINUP. For polling mode the bufcnt is made 0 unconditionally. But it should be made 0 only if it is a final update or a total is not zero(This condition is similar to what is done in DMA case). Because of this wrong hashes are produced. Fixing the same. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - Remove user triggerable pr_err callsTom Lendacky2013-12-203-21/+7
| | | | | | | | | | | | | | | | | | Remove the pr_err calls that are issued during parameter checking in some AES operations. This will eliminate the possibility of filling up syslog through these paths. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - CCP Kconfig fixesTom Lendacky2013-12-202-1/+2
| | | | | | | | | | | | | | | | | | | | Update the Kconfig to include PCI on the 'depends on' and add 'select HW_RANDOM' to insure the necessary PCI and HW_RANDOM functions are available/included in the build. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - Fix sparse warnings in ccp-crypto-sha.cTom Lendacky2013-12-202-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The sha initialization data generated the following sparse warnings: sparse: incorrect type in initializer (different base types) expected unsigned int got restricted __be32 [usertype] <noident> Change the initialization data type from u32 to __be32. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crytpo: ccp - fix coccinelle warningsFengguang Wu2013-12-093-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | drivers/crypto/ccp/ccp-crypto-aes.c:344:1-7: Replace memcpy with struct assignment drivers/crypto/ccp/ccp-crypto-sha.c:398:1-7: Replace memcpy with struct assignment drivers/crypto/ccp/ccp-dev.c:578:2-3: Unneeded semicolon /c/kernel-tests/src/cocci/drivers/crypto/ccp/ccp-dev.c:565:2-3: Unneeded semicolon Generated by: coccinelle/misc/memcpy-assign.cocci CC: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: omap-aes - add error check for pm_runtime_get_syncNishanth Menon2013-12-051-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | The AES driver currently assumes that pm_runtime_get_sync will always succeed, which may not always be true, so add error handling for the same. This scenario was reported in the following bug: place. https://bugzilla.kernel.org/show_bug.cgi?id=66441 Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: talitos - fix locating offending descriptor in error pathHoria Geanta2013-12-051-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3e721aeb3df3816e283ab18e327cd4652972e213 ("crypto: talitos - handle descriptor not found in error path") tried to address the fact that CDPR (Current Descriptor Pointer Register) is unreliable. As it turns out, there are still issues in the function detecting the offending descriptor: -only 32 bits of the descriptor address are read, however the address is 36-bit - since reset_channel() initializes channels with EAE (extended address) bit set -reading CDPR can return zero in cur_desc; when searching the channel fifo for this address, cur_desc == dma_desc (= 0) case might happen, leading to an oops when trying to return desc->hdr (desc is zero) -read channel's .tail only once; the tail is a moving target; use a local variable for the end of search condition Signed-off-by: Lei Xu <Lei.Xu@freescale.com> Signed-off-by: Horia Geanta <horia.geanta@freescale.com> Tested-by: Kalyani Chowdhury <Kalyani.Chowdhury@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: omap-sham - Only release DMA channel if successfully requestedMark A. Greer2013-12-051-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In omap_sham_probe() and omap_sham_remove(), 'dd->dma_lch' is released without checking to see if it was successfully requested or not. This is a bug and was identified and reported by Dan Carpenter here: http://www.spinics.net/lists/devicetree/msg11023.html Add code to only release 'dd->dma_lch' when its not NULL (that is, when it was successfully requested). Reported-by: Dan Carpenter <dan.carpenter@oracle.com> CC: Joel Fernandes <joelf@ti.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crytpo: ccp - CCP device driver build filesTom Lendacky2013-12-054-0/+46
| | | | | | | | | | | | | | | | These files provide the ability to configure and build the AMD CCP device driver and crypto API support. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - CCP SHA crypto API supportTom Lendacky2013-12-051-0/+497
| | | | | | | | | | | | | | | | These routines provide crypto API support for SHA1, SHA224 and SHA256 on the AMD CCP. HMAC support for these SHA modes is also provided. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - CCP XTS-AES crypto API supportTom Lendacky2013-12-051-0/+285
| | | | | | | | | | | | | | | | These routines provide crypto API support for the XTS-AES mode of AES on the AMD CCP. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - CCP AES CMAC mode crypto API supportTom Lendacky2013-12-051-0/+355
| | | | | | | | | | | | | | | | These routines provide crypto API support for the CMAC mode of AES on the AMD CCP. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - CCP AES crypto API supportTom Lendacky2013-12-051-0/+375
| | | | | | | | | | | | | | | | | | These routines provide crypto API support for AES on the AMD CCP. Support for AES modes: ECB, CBC, OFB, CFB and CTR Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - crypto API interface to the CCP device driverTom Lendacky2013-12-052-0/+623
| | | | | | | | | | | | | | | | | | These routines provide the support for the interface between the crypto API and the AMD CCP. This includes insuring that requests associated with a given tfm on the same cpu are processed in the order received. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccp - CCP device driver and interface supportTom Lendacky2013-12-054-0/+3234
| | | | | | | | | | | | | | | | These routines provide the device driver support for the AMD Cryptographic Coprocessor (CCP). Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | Merge git://git.infradead.org/users/eparis/auditLinus Torvalds2014-01-241-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull audit update from Eric Paris: "Again we stayed pretty well contained inside the audit system. Venturing out was fixing a couple of function prototypes which were inconsistent (didn't hurt anything, but we used the same value as an int, uint, u32, and I think even a long in a couple of places). We also made a couple of minor changes to when a couple of LSMs called the audit system. We hoped to add aarch64 audit support this go round, but it wasn't ready. I'm disappearing on vacation on Thursday. I should have internet access, but it'll be spotty. If anything goes wrong please be sure to cc rgb@redhat.com. He'll make fixing things his top priority" * git://git.infradead.org/users/eparis/audit: (50 commits) audit: whitespace fix in kernel-parameters.txt audit: fix location of __net_initdata for audit_net_ops audit: remove pr_info for every network namespace audit: Modify a set of system calls in audit class definitions audit: Convert int limit uses to u32 audit: Use more current logging style audit: Use hex_byte_pack_upper audit: correct a type mismatch in audit_syscall_exit() audit: reorder AUDIT_TTY_SET arguments audit: rework AUDIT_TTY_SET to only grab spin_lock once audit: remove needless switch in AUDIT_SET audit: use define's for audit version audit: documentation of audit= kernel parameter audit: wait_for_auditd rework for readability audit: update MAINTAINERS audit: log task info on feature change audit: fix incorrect set of audit_sock audit: print error message when fail to create audit socket audit: fix dangling keywords in audit_log_set_loginuid() output audit: log on errors from filter user rules ...
| * | audit: convert all sessionid declaration to unsigned intEric Paris2014-01-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Right now the sessionid value in the kernel is a combination of u32, int, and unsigned int. Just use unsigned int throughout. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
* | | Merge tag 'virtio-next-for-linus' of ↵Linus Torvalds2014-01-233-4/+15
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull virtio update from Rusty Russell: "A few simple fixes. Quiet cycle" * tag 'virtio-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: drivers: virtio: Mark function virtballoon_migratepage() as static in virtio_balloon.c virtio-scsi: Fix hotcpu_notifier use-after-free with virtscsi_freeze virtio: pci: remove unnecessary pci_set_drvdata()
| * | | drivers: virtio: Mark function virtballoon_migratepage() as static in ↵Rashika Kheria2014-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virtio_balloon.c Mark the function virtballoon_migratepage() as static in virtio_balloon.c because it is not used outside this file. This eliminates the following warning in virtio_balloon.c: drivers/virtio/virtio_balloon.c:372:5: warning: no previous prototype for ‘virtballoon_migratepage’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * | | virtio-scsi: Fix hotcpu_notifier use-after-free with virtscsi_freezeAsias He2014-01-161-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vqs are freed in virtscsi_freeze but the hotcpu_notifier is not unregistered. We will have a use-after-free usage when the notifier callback is called after virtscsi_freeze. Fixes: 285e71ea6f3583a85e27cb2b9a7d8c35d4c0d558 ("virtio-scsi: reset virtqueue affinity when doing cpu hotplug") Cc: stable@vger.kernel.org Signed-off-by: Asias He <asias.hejun@gmail.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * | | virtio: pci: remove unnecessary pci_set_drvdata()Jingoo Han2013-12-041-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* | | | Merge tag 'stable/for-linus-3.14-rc0-tag' of ↵Linus Torvalds2014-01-2322-555/+1348
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull Xen updates from Konrad Rzeszutek Wilk: "Two major features that Xen community is excited about: The first is event channel scalability by David Vrabel - we switch over from an two-level per-cpu bitmap of events (IRQs) - to an FIFO queue with priorities. This lets us be able to handle more events, have lower latency, and better scalability. Good stuff. The other is PVH by Mukesh Rathor. In short, PV is a mode where the kernel lets the hypervisor program page-tables, segments, etc. With EPT/NPT capabilities in current processors, the overhead of doing this in an HVM (Hardware Virtual Machine) container is much lower than the hypervisor doing it for us. In short we let a PV guest run without doing page-table, segment, syscall, etc updates through the hypervisor - instead it is all done within the guest container. It is a "hybrid" PV - hence the 'PVH' name - a PV guest within an HVM container. The major benefits are less code to deal with - for example we only use one function from the the pv_mmu_ops (which has 39 function calls); faster performance for syscall (no context switches into the hypervisor); less traps on various operations; etc. It is still being baked - the ABI is not yet set in stone. But it is pretty awesome and we are excited about it. Lastly, there are some changes to ARM code - you should get a simple conflict which has been resolved in #linux-next. In short, this pull has awesome features. Features: - FIFO event channels. Key advantages: support for over 100,000 events (2^17), 16 different event priorities, improved fairness in event latency through the use of FIFOs. - Xen PVH support. "It’s a fully PV kernel mode, running with paravirtualized disk and network, paravirtualized interrupts and timers, no emulated devices of any kind (and thus no qemu), no BIOS or legacy boot — but instead of requiring PV MMU, it uses the HVM hardware extensions to virtualize the pagetables, as well as system calls and other privileged operations." (from "The Paravirtualization Spectrum, Part 2: From poles to a spectrum") Bug-fixes: - Fixes in balloon driver (refactor and make it work under ARM) - Allow xenfb to be used in HVM guests. - Allow xen_platform_pci=0 to work properly. - Refactors in event channels" * tag 'stable/for-linus-3.14-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: (52 commits) xen/pvh: Set X86_CR0_WP and others in CR0 (v2) MAINTAINERS: add git repository for Xen xen/pvh: Use 'depend' instead of 'select'. xen: delete new instances of __cpuinit usage xen/fb: allow xenfb initialization for hvm guests xen/evtchn_fifo: fix error return code in evtchn_fifo_setup() xen-platform: fix error return code in platform_pci_init() xen/pvh: remove duplicated include from enlighten.c xen/pvh: Fix compile issues with xen_pvh_domain() xen: Use dev_is_pci() to check whether it is pci device xen/grant-table: Force to use v1 of grants. xen/pvh: Support ParaVirtualized Hardware extensions (v3). xen/pvh: Piggyback on PVHVM XenBus. xen/pvh: Piggyback on PVHVM for grant driver (v4) xen/grant: Implement an grant frame array struct (v3). xen/grant-table: Refactor gnttab_init xen/grants: Remove gnttab_max_grant_frames dependency on gnttab_init. xen/pvh: Piggyback on PVHVM for event channels (v2) xen/pvh: Update E820 to work with PVH (v2) xen/pvh: Secondary VCPU bringup (non-bootup CPUs) ...
| * | | | xen: delete new instances of __cpuinit usagePaul Gortmaker2014-01-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 1fe565517b57676884349dccfd6ce853ec338636 ("xen/events: use the FIFO-based ABI if available") added new instances of __cpuinit macro usage. We removed this a couple versions ago; we now want to remove the compat no-op stubs. Introducing new users is not what we want to see at this point in time, as it will break once the stubs are gone. Cc: David Vrabel <david.vrabel@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| * | | | xen/fb: allow xenfb initialization for hvm guestsStefano Stabellini2014-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no reasons why an HVM guest shouldn't be allowed to use xenfb. As a matter of fact ARM guests, HVM from Linux POV, can use xenfb. Given that no Xen toolstacks configure a xenfb backend for x86 HVM guests, they are not affected. Please note that at this time QEMU needs few outstanding fixes to provide xenfb on ARM: http://marc.info/?l=qemu-devel&m=138739419700837&w=2 Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: David Vrabel <david.vrabel@citrix.com> CC: boris.ostrovsky@oracle.com CC: plagnioj@jcrosoft.com CC: tomi.valkeinen@ti.com CC: linux-fbdev@vger.kernel.org CC: konrad.wilk@oracle.com Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | | xen/evtchn_fifo: fix error return code in evtchn_fifo_setup()Wei Yongjun2014-01-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix to return -ENOMEM from the error handling case instead of 0 (overwrited to 0 by the HYPERVISOR_event_channel_op call), otherwise the error condition cann't be reflected from the return value. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
| * | | | xen-platform: fix error return code in platform_pci_init()Wei Yongjun2014-01-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix to return a negative error code from the error handling case instead of 0, otherwise the error condition cann't be reflected from the return value. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
| * | | | xen: Use dev_is_pci() to check whether it is pci deviceYijing Wang2014-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use PCI standard marco dev_is_pci() instead of directly compare pci_bus_type to check whether it is pci device. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Jan Beulich <JBeulich@suse.com>
| * | | | xen/grant-table: Force to use v1 of grants.Konrad Rzeszutek Wilk2014-01-061-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have the framework to use v2, but there are no backends that actually use it. The end result is that on PV we use v2 grants and on PVHVM v1. The v1 has a capacity of 512 grants per page while the v2 has 256 grants per page. This means we lose about 50% capacity - and if we want more than 16 VIFs (each VIF takes 512 grants), then we are hitting the max per guest of 32. Oracle-bug: 16039922 CC: annie.li@oracle.com CC: msw@amazon.com Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
| * | | | xen/pvh: Piggyback on PVHVM XenBus.Mukesh Rathor2014-01-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PVH is a PV guest with a twist - there are certain things that work in it like HVM and some like PV. For the XenBus mechanism we want to use the PVHVM mechanism. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
| * | | | xen/pvh: Piggyback on PVHVM for grant driver (v4)Konrad Rzeszutek Wilk2014-01-062-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In PVH the shared grant frame is the PFN and not MFN, hence its mapped via the same code path as HVM. The allocation of the grant frame is done differently - we do not use the early platform-pci driver and have an ioremap area - instead we use balloon memory and stitch all of the non-contingous pages in a virtualized area. That means when we call the hypervisor to replace the GMFN with a XENMAPSPACE_grant_table type, we need to lookup the old PFN for every iteration instead of assuming a flat contingous PFN allocation. Lastly, we only use v1 for grants. This is because PVHVM is not able to use v2 due to no XENMEM_add_to_physmap calls on the error status page (see commit 69e8f430e243d657c2053f097efebc2e2cd559f0 xen/granttable: Disable grant v2 for HVM domains.) Until that is implemented this workaround has to be in place. Also per suggestions by Stefano utilize the PVHVM paths as they share common functionality. v2 of this patch moves most of the PVH code out in the arch/x86/xen/grant-table driver and touches only minimally the generic driver. v3, v4: fixes us some of the code due to earlier patches. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
| * | | | xen/grant: Implement an grant frame array struct (v3).Konrad Rzeszutek Wilk2014-01-062-10/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'xen_hvm_resume_frames' used to be an 'unsigned long' and contain the virtual address of the grants. That was OK for most architectures (PVHVM, ARM) were the grants are contiguous in memory. That however is not the case for PVH - in which case we will have to do a lookup for each virtual address for the PFN. Instead of doing that, lets make it a structure which will contain the array of PFNs, the virtual address and the count of said PFNs. Also provide a generic functions: gnttab_setup_auto_xlat_frames and gnttab_free_auto_xlat_frames to populate said structure with appropriate values for PVHVM and ARM. To round it off, change the name from 'xen_hvm_resume_frames' to a more descriptive one - 'xen_auto_xlat_grant_frames'. For PVH, in patch "xen/pvh: Piggyback on PVHVM for grant driver" we will populate the 'xen_auto_xlat_grant_frames' by ourselves. v2 moves the xen_remap in the gnttab_setup_auto_xlat_frames and also introduces xen_unmap for gnttab_free_auto_xlat_frames. Suggested-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [v3: Based on top of 'asm/xen/page.h: remove redundant semicolon'] Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
| * | | | xen/grant-table: Refactor gnttab_initKonrad Rzeszutek Wilk2014-01-061-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have this odd scenario of where for PV paths we take a shortcut but for the HVM paths we first ioremap xen_hvm_resume_frames, then assign it to gnttab_shared.addr. This is needed because gnttab_map uses gnttab_shared.addr. Instead of having: if (pv) return gnttab_map if (hvm) ... gnttab_map Lets move the HVM part before the gnttab_map and remove the first call to gnttab_map. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
| * | | | xen/grants: Remove gnttab_max_grant_frames dependency on gnttab_init.Konrad Rzeszutek Wilk2014-01-061-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function gnttab_max_grant_frames() returns the maximum amount of frames (pages) of grants we can have. Unfortunatly it was dependent on gnttab_init() having been run before to initialize the boot max value (boot_max_nr_grant_frames). This meant that users of gnttab_max_grant_frames would always get a zero value if they called before gnttab_init() - such as 'platform_pci_init' (drivers/xen/platform-pci.c). Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
| * | | | xen/pvh: Piggyback on PVHVM for event channels (v2)Mukesh Rathor2014-01-061-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PVH is a PV guest with a twist - there are certain things that work in it like HVM and some like PV. There is a similar mode - PVHVM where we run in HVM mode with PV code enabled - and this patch explores that. The most notable PV interfaces are the XenBus and event channels. We will piggyback on how the event channel mechanism is used in PVHVM - that is we want the normal native IRQ mechanism and we will install a vector (hvm callback) for which we will call the event channel mechanism. This means that from a pvops perspective, we can use native_irq_ops instead of the Xen PV specific. Albeit in the future we could support pirq_eoi_map. But that is a feature request that can be shared with PVHVM. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
| * | | | xen/events: use the FIFO-based ABI if availableDavid Vrabel2014-01-064-1/+448
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement all the event channel port ops for the FIFO-based ABI. If the hypervisor supports the FIFO-based ABI, enable it by initializing the control block for the boot VCPU and subsequent VCPUs as they are brought up and on resume. The event array is expanded as required when event ports are setup. The 'xen.fifo_events=0' command line option may be used to disable use of the FIFO-based ABI. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>