summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mvpp2x fixmcbinRussell King5 days1-6/+4
|
* Dont-Auto-BuildRussell King5 days1-0/+1
| | | | This commit is to tell the 0-day builder to avoid building this branch.
* usb: host: xhci: mvebu: add reset on resume quirkOfer Heifetz5 days1-0/+10
| | | | | | | | | | | | The resume operation of mvebu xHCI host have some issues, so The XHCI_RESET_ON_RESUME quirk is added for it. Signed-off-by: Ofer Heifetz <oferh@marvell.com> Tested-by: Nadav Haklai <nadavh@marvell.com> Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> Reviewed-by: Lior Amsalem <alior@marvell.com> Tested-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: hacks and debugging from initial mcbin bringupRussell King5 days1-0/+127
| | | | Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: dts: marvell: mcbin: workaround wrongly wired i2c1 busRussell King5 days3-2/+29
| | | | | | | | The I2C1 bus on early mcbin hardware is mis-wired, swapping SCL and SDA. Work around this by using the i2c-gpio driver instead. XXX Caught early and this commit should be removed for mainline. XXX Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: switch to using in-band negotiation with mvpp2x driverRussell King5 days2-1/+5
| | | | Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: dts: marvell: mcbin: use sfp+ compatible for sfp+ slotsRussell King5 days1-2/+2
| | | | Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: dts: marvell: mcbin: update 10G PHYs definitionsRussell King5 days1-0/+38
| | | | | | Add the pinctrl settings and interrupts for the 10G PHYs. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: dts: marvell: mcbin: add mvpp2x ethernet supportRussell King5 days3-0/+182
| | | | | | | | Add support for the Marvell MVPP2x driver for Macchiatobin. The mainline MVPP2 driver can be selected by defining MCBIN_USE_MVPP2_DRIVER. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: dts: marvell: cp110: add Marvell mvpp2x ethernetRussell King5 days1-0/+78
| | | | | | Add mdio and ethernet controllers on CP110. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* net: mvpp2x: update mvpp2x for phylink changes [to be merged down]Russell King5 days2-12/+22
| | | | Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* net: marvell: mvpp2x: avoid link status floodRussell King5 days1-1/+1
| | | | | | | | | | | | eth2 on the Macchiatobin board floods the system with link status interrupts whilethe link is down. This appears to be caused by the AN bypass logic causing spurious link status change interrupts, despite the port status register indicating that the link remains down. Avoid this by not setting the AN bypass bit for SGMII links. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* net: marvell: mvpp2x: add eee supportRussell King5 days3-0/+42
| | | | | | Add EEE support to the Marvell PP2x ethernet driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* net: marvell: mvpp2x: convert to gmacRussell King5 days4-184/+23
|
* net: mvgmac: support different hw versionsRussell King5 days3-13/+106
| | | | Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* net: mvneta: split out GMACRussell King5 days5-242/+402
| | | | | | | Split out the code handling the GMAC from the rest of the driver. This block appears to be shared amongst several revisions of the IP. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: dts: marvell: mcbin: wire up fan control as a gpio pinRussell King5 days1-1/+4
| | | | | | | This at least allows userspace to control whether the fans run or not. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: dts: marvell: mcbin: add remainder of pinctrlsRussell King5 days1-1/+14
| | | | | | | Add several pinctrls for functions brought out to connectors but not yet usable with the core DT description. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* arm64: dts: marvell: mcbin: add comments about unused MPP pinsRussell King5 days1-0/+2
| | | | | | Comment about the use of currently unconfigured MPP pins. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
*-. Merge branches 'mvebu', 'mvpp2' and 'phy' into mcbinRussell King5 days11-61/+498
|\ \
| | * net: sfp: add quirks for two GPON modulesphyRussell King5 days1-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Marc Micalizzi reports that Huawei MA5671A and Alcatel/Lucent G010SP modules are capable of 2500base-X, but incorrectly report their capabilities in the EEPROM. Let's fix these modules by adding some quirks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * net: sfp: add support for module quirksRussell King5 days1-0/+47
| | | | | | | | | | | | | | | | | | | | | Add support for applying module quirks to the list of supported ethtool link modes. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * sfp: more cotsworks fixesRussell King5 days1-7/+8
| | | | | | | | | | | | | | | | | | Cotsworks also gets the date code wrong. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * sfp: display SFP module informationRussell King5 days1-3/+258
| | | | | | | | | | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * sfp: add sfp+ compatibleRussell King5 days1-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Add a compatible for SFP+ cages. SFP+ cages are backwards compatible, but the ethernet device behind them may not support the slower speeds of SFP modules. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * net: phy: marvell10g: add SFP+ supportRussell King5 days1-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for SFP+ cages to the Marvell 10G PHY driver. This is slightly complicated by the way phylib works in that we need to use a multi-step process to attach the SFP bus, and we also need to track the phylink state machine to know when the module's transmit disable signal should change state. With appropriate DT changes, this allows the SFP+ canges on the Macchiatobin platform to be functional. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * net: phy: marvell10g: allow PHY to probe without firmwareRussell King5 days1-5/+22
| | | | | | | | | | | | | | | | | | | | | | | | Allow the PHY to probe when there is no firmware, but do not allow the link to come up by forcing the PHY state to PHY_HALTED in a similar way to phy_error(). Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * net: phy: add core phylib sfp supportRussell King5 days3-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | Add core phylib help for supporting SFP sockets on PHYs. This provides a mechanism to inform the SFP layer about PHY up/down events, and also unregister the SFP bus when the PHY is going away. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * net: phy: provide phy driver start/stop hooksRussell King5 days2-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide phy driver start/stop hooks so that the PHY driver knows when the network driver is starting or stopping. This will be used for the Marvell 10G driver so that we can sanely refuse to start if the PHYs firmware is not present, and also so that we can sanely support SFPs behind the PHY. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * net: sfp: move fwnode parsing into sfp-bus layerRussell King5 days3-43/+53
| | | | | | | | | | | | | | | | | | | | | | | | Rather than parsing the sfp firmware node in phylink, parse it in the sfp-bus code, so we can re-use this code for PHYs without having to duplicate the parsing. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * net: phylink: use more linkmode_*Russell King5 days2-5/+8
| | | | | | | | | | | | | | | | | | | | | Use more linkmode_* helpers rather than open-coding the bitmap operations. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| | * net: phylink: clarify where phylink should be usedRussell King5 days1-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Update the phylink documentation to make it clear that phylink is designed to be used on the MAC facing side of the link, rather than between a SFP and PHY. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
| * | net: marvell: mvpp2: phylink requires the link interruptmvpp2Russell King2019-07-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | phylink requires the MAC to report when its link status changes when operating in inband modes. Failure to report link status changes means that phylink has no idea when the link events happen, which results in either the network interface's carrier remaining up or remaining permanently down. For example, with a fiber module, if the interface is brought up and link is initially established, taking the link down at the far end will cut the optical power. The SFP module's LOS asserts, we deactivate the link, and the network interface reports no carrier. When the far end is brought back up, the SFP module's LOS deasserts, but the MAC may be slower to establish link. If this happens (which in my tests is a certainty) then phylink never hears that the MAC has established link with the far end, and the network interface is stuck reporting no carrier. This means the interface is non-functional. Avoiding the link interrupt when we have phylink is basically not an option, so remove the !port->phylink from the test. Tested-by: Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | net: marvell: mvpp2x: update mvpp2x's comphy supportRussell King5 days3-81/+38
| | | | | | | | | | | | Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | net: marvell: mvpp2x: allow jumbo frames to be configuredRussell King5 days1-22/+4
| | | | | | | | | | | | | | | | | | | | | The driver fails to configure the minimum and maximum mtu sizes, for jumbo frame operation, so fill these in. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | net: marvell: mvpp2x: hack around dma_to_phys() removalRussell King5 days1-0/+11
| | | | | | | | | | | | Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | net: marvell: mvpp2x: set network device of_nodeRussell King5 days1-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Allow of_find_net_device_by_node() (required by SFP and other subsystems) to find this network device by initialising the of_node pointer. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | net: marvell: mvpp2x: convert to use mainline mvebu-comphy driverRussell King5 days2-8/+22
| | | | | | | | | | | | | | | | | | | | | Switch the Marvell MVPP2x driver to use the mainline mvebu-comphy driver instead of the Marvell comphy driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | net: marvell: mvpp2x: support for switching protocolsRussell King5 days1-1/+128
| | | | | | | | | | | | | | | | | | Add support for switching protocols on the serdes lines. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | net: marvell: mvpp2x: start converting to phylinkRussell King5 days4-24/+515
| | | | | | | | | | | | | | | | | | Start converting mvpp2x to phylink - this is work in progress! Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | net: marvell: add mvpp2x driverRussell King5 days14-0/+23078
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the Marvell PP2x driver as of faf69e0d635f in Marvell's tree, along with fixups for subsequent kernels: - mv_pp2x_get_stats64() now returns void - remove napi_hash_add() - formatting cleanups - replace XFI/SFI/KR phy modes with 10GKR mode - build warning fixes: drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_ethtool.c: In function 'mv_pp2x_ethtool_valid_coalesce': drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_ethtool.c:166:91: warning: integer overflow in expression [-Woverflow] drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_ethtool.c:172:91: warning: integer overflow in expression [-Woverflow] drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_ethtool.c:176:14: warning: integer overflow in expression [-Woverflow] drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c: In function 'mv_pp2x_rx_time_coal_set': drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c:3483:30: warning: integer overflow in expression [-Woverflow] drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_ethtool.c: In function 'mv_pp2x_ethtool_valid_coalesce': drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_ethtool.c:169:3: warning: format '%ld' expects argument of type 'long int', but argument 2 has type '__u32' [-Wformat=] drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_ethtool.c:178:3: warning: format '%ld' expects argument of type 'long int', but argument 2 has type '__u32' [-Wformat=] - 10GBASE-KR only uses one serdes lane, not two - avoid calling pp21 event handler on pp22 hw - fix 2.5G SGMII handling to key off the 2.5G flag not the speed and make GOP queries return the correct speed - correct placement of dev_err() - rename driver so it does not conflict with the mvpp2 driver - fix oops when all ports fail to find PHYs - update for ethtool ksettings - build error fixes: drivers/net/ethernet/marvell/mvpp2x/mv_pp2x.h:562:24: error: field 'tx_done_tasklet' has incomplete type drivers/net/ethernet/marvell/mvpp2x/mv_pp2x.h:597:24: error: field 'link_change_tasklet' has incomplete type - further build error fixes: In file included from drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c:29:0: drivers/net/ethernet/marvell/mvpp2x/mv_pp2x.h:253:2: error: unknown type name 'phy_interface_t' phy_interface_t phy_mode; /* RXAUI, SGMII, etc. */ ^ drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c: In function 'mv_pp21_port_mii_set': drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c:3738:7: error: 'PHY_INTERFACE_MODE_SGMII' undeclared (first use in this function) case PHY_INTERFACE_MODE_SGMII: ^ drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c:3738:7: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c:3741:7: error: 'PHY_INTERFACE_MODE_RGMII' undeclared (first use in this function) case PHY_INTERFACE_MODE_RGMII: ^ drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c: In function 'mv_pp21_port_loopback_set': drivers/net/ethernet/marvell/mvpp2x/mv_pp2x_hw.c:3800:33: error: 'PHY_INTERFACE_MODE_SGMII' undeclared (first use in this function) if (port->mac_data.phy_mode == PHY_INTERFACE_MODE_SGMII) ^ - fix memset of classifier data Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | | phy: warn if phy_power_off() is called before PHY has been poweredRussell King5 days1-0/+5
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling phy_power_off() before the PHY has been powered results in the phy's power_count going negative, which causes a subsequent call to phy_power_on() to be ignored. Moreover, we end up calling phy_pm_runtime_put() and potentially regulator_disable() unbalancing the runtime PM count and the regulator subsystems as well. Avoid this, and print a warning when it happens. This is an alternative solution to Marvell's "phy: update power_count only if phy actually was powered off/on" commit, which IMHO is papering over the bug. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
* | Linux 5.3HEADmvnetamasterLinus Torvalds6 days1-1/+1
| |
* | Revert "ext4: make __ext4_get_inode_loc plug"Linus Torvalds6 days1-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit b03755ad6f33b7b8cd7312a3596a2dbf496de6e7. This is sad, and done for all the wrong reasons. Because that commit is good, and does exactly what it says: avoids a lot of small disk requests for the inode table read-ahead. However, it turns out that it causes an entirely unrelated problem: the getrandom() system call was introduced back in 2014 by commit c6e9d6f38894 ("random: introduce getrandom(2) system call"), and people use it as a convenient source of good random numbers. But part of the current semantics for getrandom() is that it waits for the entropy pool to fill at least partially (unlike /dev/urandom). And at least ArchLinux apparently has a systemd that uses getrandom() at boot time, and the improvements in IO patterns means that existing installations suddenly start hanging, waiting for entropy that will never happen. It seems to be an unlucky combination of not _quite_ enough entropy, together with a particular systemd version and configuration. Lennart says that the systemd-random-seed process (which is what does this early access) is supposed to not block any other boot activity, but sadly that doesn't actually seem to be the case (possibly due bogus dependencies on cryptsetup for encrypted swapspace). The correct fix is to fix getrandom() to not block when it's not appropriate, but that fix is going to take a lot more discussion. Do we just make it act like /dev/urandom by default, and add a new flag for "wait for entropy"? Do we add a boot-time option? Or do we just limit the amount of time it will wait for entropy? So in the meantime, we do the revert to give us time to discuss the eventual fix for the fundamental problem, at which point we can re-apply the ext4 inode table access optimization. Reported-by: Ahmed S. Darwish <darwish.07@gmail.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Willy Tarreau <w@1wt.eu> Cc: Alexander E. Patrakov <patrakov@gmail.com> Cc: Lennart Poettering <mzxreary@0pointer.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds7 days6-4/+124
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull kvm fixes from Paolo Bonzini: "The main change here is a revert of reverts. We recently simplified some code that was thought unnecessary; however, since then KVM has grown quite a few cond_resched()s and for that reason the simplified code is prone to livelocks---one CPUs tries to empty a list of guest page tables while the others keep adding to them. This adds back the generation-based zapping of guest page tables, which was not unnecessary after all. On top of this, there is a fix for a kernel memory leak and a couple of s390 fixlets as well" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86/mmu: Reintroduce fast invalidate/zap for flushing memslot KVM: x86: work around leak of uninitialized stack contents KVM: nVMX: handle page fault in vmread KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()
| * \ Merge tag 'kvm-s390-master-5.3-1' of ↵Paolo Bonzini7 days2-1/+13
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master KVM: s390: Fixes for 5.3 - prevent a user triggerable oops in the migration code - do not leak kernel stack content
| | * | KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctlThomas Huth9 days2-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject an interrupt, we convert them from the legacy struct kvm_s390_interrupt to the new struct kvm_s390_irq via the s390int_to_s390irq() function. However, this function does not take care of all types of interrupts that we can inject into the guest later (see do_inject_vcpu()). Since we do not clear out the s390irq values before calling s390int_to_s390irq(), there is a chance that we copy random data from the kernel stack which could be leaked to the userspace later. Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT interrupt: s390int_to_s390irq() does not handle it, and the function __inject_pfault_init() later copies irq->u.ext which contains the random kernel stack data. This data can then be leaked either to the guest memory in __deliver_pfault_init(), or the userspace might retrieve it directly with the KVM_S390_GET_IRQ_STATE ioctl. Fix it by handling that interrupt type in s390int_to_s390irq(), too, and by making sure that the s390irq struct is properly pre-initialized. And while we're at it, make sure that s390int_to_s390irq() now directly returns -EINVAL for unknown interrupt types, so that we immediately get a proper error code in case we add more interrupt types to do_inject_vcpu() without updating s390int_to_s390irq() sometime in the future. Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/kvm/20190912115438.25761-1-thuth@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
| | * | KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it ↵Igor Mammedov9 days1-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as target for memset() If userspace doesn't set KVM_MEM_LOG_DIRTY_PAGES on memslot before calling kvm_s390_vm_start_migration(), kernel will oops with: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000483 Fault in home space mode while using kernel ASCE. AS:0000000002a2000b R2:00000001bff8c00b R3:00000001bff88007 S:00000001bff91000 P:000000000000003d Oops: 0004 ilc:2 [#1] SMP ... Call Trace: ([<001fffff804ec552>] kvm_s390_vm_set_attr+0x347a/0x3828 [kvm]) [<001fffff804ecfc0>] kvm_arch_vm_ioctl+0x6c0/0x1998 [kvm] [<001fffff804b67e4>] kvm_vm_ioctl+0x51c/0x11a8 [kvm] [<00000000008ba572>] do_vfs_ioctl+0x1d2/0xe58 [<00000000008bb284>] ksys_ioctl+0x8c/0xb8 [<00000000008bb2e2>] sys_ioctl+0x32/0x40 [<000000000175552c>] system_call+0x2b8/0x2d8 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000000000dbaf60>] __memset+0xc/0xa0 due to ms->dirty_bitmap being NULL, which might crash the host. Make sure that ms->dirty_bitmap is set before using it or return -EINVAL otherwise. Cc: <stable@vger.kernel.org> Fixes: afdad61615cc ("KVM: s390: Fix storage attributes migration with memory slots") Signed-off-by: Igor Mammedov <imammedo@redhat.com> Link: https://lore.kernel.org/kvm/20190911075218.29153-1-imammedo@redhat.com/ Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
| * | | KVM: x86/mmu: Reintroduce fast invalidate/zap for flushing memslotSean Christopherson7 days2-2/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | James Harvey reported a livelock that was introduced by commit d012a06ab1d23 ("Revert "KVM: x86/mmu: Zap only the relevant pages when removing a memslot""). The livelock occurs because kvm_mmu_zap_all() as it exists today will voluntarily reschedule and drop KVM's mmu_lock, which allows other vCPUs to add shadow pages. With enough vCPUs, kvm_mmu_zap_all() can get stuck in an infinite loop as it can never zap all pages before observing lock contention or the need to reschedule. The equivalent of kvm_mmu_zap_all() that was in use at the time of the reverted commit (4e103134b8623, "KVM: x86/mmu: Zap only the relevant pages when removing a memslot") employed a fast invalidate mechanism and was not susceptible to the above livelock. There are three ways to fix the livelock: - Reverting the revert (commit d012a06ab1d23) is not a viable option as the revert is needed to fix a regression that occurs when the guest has one or more assigned devices. It's unlikely we'll root cause the device assignment regression soon enough to fix the regression timely. - Remove the conditional reschedule from kvm_mmu_zap_all(). However, although removing the reschedule would be a smaller code change, it's less safe in the sense that the resulting kvm_mmu_zap_all() hasn't been used in the wild for flushing memslots since the fast invalidate mechanism was introduced by commit 6ca18b6950f8d ("KVM: x86: use the fast way to invalidate all pages"), back in 2013. - Reintroduce the fast invalidate mechanism and use it when zapping shadow pages in response to a memslot being deleted/moved, which is what this patch does. For all intents and purposes, this is a revert of commit ea145aacf4ae8 ("Revert "KVM: MMU: fast invalidate all pages"") and a partial revert of commit 7390de1e99a70 ("Revert "KVM: x86: use the fast way to invalidate all pages""), i.e. restores the behavior of commit 5304b8d37c2a5 ("KVM: MMU: fast invalidate all pages") and commit 6ca18b6950f8d ("KVM: x86: use the fast way to invalidate all pages") respectively. Fixes: d012a06ab1d23 ("Revert "KVM: x86/mmu: Zap only the relevant pages when removing a memslot"") Reported-by: James Harvey <jamespharvey20@gmail.com> Cc: Alex Willamson <alex.williamson@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * | | KVM: x86: work around leak of uninitialized stack contentsFuqian Huang7 days1-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Emulation of VMPTRST can incorrectly inject a page fault when passed an operand that points to an MMIO address. The page fault will use uninitialized kernel stack memory as the CR2 and error code. The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR exit to userspace; however, it is not an easy fix, so for now just ensure that the error code and CR2 are zero. Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com> Cc: stable@vger.kernel.org [add comment] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>