similar to: [PATCH] MAINTAINERS: Update PARAVIRT_OPS_INTERFACE and VMWARE_HYPERVISOR_INTERFACE

Alok Kataria will be handing over VMware's maintainership of these interfaces to Thomas Hellstr?m, with pv-drivers as backup contact. Cc: Juergen Gross <jgross at suse.com> Cc: virtualization at lists.linux-foundation.org Cc: x86 at kernel.org Cc: tglx at linutronix.de Cc: mingo at redhat.com Cc: hpa at zytor.com Cc: linux-kernel at vger.kernel.org Cc: Alok Kataria <akataria at

On 17.04.20 01:45, Deep Shah wrote: > Thomas Hellstrom will be handing over VMware's maintainership of these > interfaces to Deep Shah. > > Signed-off-by: Deep Shah <sdeep at vmware.com> > Acked-by: Thomas Hellstrom <thellstrom at vmware.com> Acked-by: Juergen Gross <jgross at suse.com> Juergen

These macros will be used by multiple VMWare modules for handling host communication. v2: * Keeping only the minimal common platform defines * added vmware_platform() check function v3: * Added new field to handle different hypervisor magic values Signed-off-by: Sinclair Yeh <syeh at vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom at vmware.com> Reviewed-by: Alok N Kataria

These macros will be used by multiple VMWare modules for handling host communication. v2: * Keeping only the minimal common platform defines * added vmware_platform() check function v3: * Added new field to handle different hypervisor magic values Signed-off-by: Sinclair Yeh <syeh at vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom at vmware.com> Reviewed-by: Alok N Kataria

Hello, This patchset introduces steal time accounting support for the VMware guest. The idea and implementation of guest steal time support is similar to KVM ones and it is based on steal clock. The steal clock is a per CPU structure in a shared memory between hypervisor and guest, initialized by each CPU through hypercall. Steal clock is got updated by the hypervisor and read by the guest. The

Updated VMWARE_BALLOON_CMD to use the common VMW_PORT macro. Doing this rather than replacing all instances of VMWARE_BALLOON_CMD to minimize code change. Signed-off-by: Sinclair Yeh <syeh at vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom at vmware.com> Reviewed-by: Alok N Kataria <akataria at vmware.com> Acked-by: Xavier Deguillard <xdeguillard at vmware.com> Cc:

Updated VMWARE_BALLOON_CMD to use the common VMW_PORT macro. Doing this rather than replacing all instances of VMWARE_BALLOON_CMD to minimize code change. Signed-off-by: Sinclair Yeh <syeh at vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom at vmware.com> Reviewed-by: Alok N Kataria <akataria at vmware.com> Acked-by: Xavier Deguillard <xdeguillard at vmware.com> Cc:

On Tue, Dec 01, 2015 at 02:18:49PM -0800, Sinclair Yeh wrote: > v2: > Instead of replacing existing VMMOUSE defines, only modify enough > to use the new VMW_PORT define. > > v3: > Use updated VMWARE_PORT() which requires hypervisor magic as an added > parameter > > Signed-off-by: Sinclair Yeh <syeh at vmware.com> > Reviewed-by: Thomas Hellstrom <thellstrom

On Tue, Dec 01, 2015 at 02:18:49PM -0800, Sinclair Yeh wrote: > v2: > Instead of replacing existing VMMOUSE defines, only modify enough > to use the new VMW_PORT define. > > v3: > Use updated VMWARE_PORT() which requires hypervisor magic as an added > parameter > > Signed-off-by: Sinclair Yeh <syeh at vmware.com> > Reviewed-by: Thomas Hellstrom <thellstrom

From: Ville Syrjälä <ville.syrjala at linux.intel.com> This series first unifies all users of drm_atomic_helper_check_plane_state() to populate the clip rectangle with drm_mode_get_hv_timing(), and once everything is unified the clip rectangle handling is sucked into drm_atomic_helper_check_plane_state() away from driver code. Entire series available here:

ttm_bo_delayed_delete has a race condition, because after we do: kref_put(&nentry->list_kref, ttm_bo_release_list); we are not holding the list lock and not holding any reference to objects, and thus every bo in the list can be removed and freed at this point. However, we then use the next pointer we stored, which is not guaranteed to be valid. This was apparently the cause of some

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> Here are again the last (?) bits of eliminating the plane->fb/crtc usage for atomic drivers. I've pushed everything else (thanks to everyone who reviewed them). Deepak said he'd tested the vmwgfx stuff, so I think it should be safe to land. Just missing a bit of review... Cc: Alex Deucher <alexander.deucher at

It's dead code because this is now handled in the core. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Boris Brezillon <boris.brezillon at free-electrons.com> Cc: Daniel Vetter <daniel.vetter at intel.com> Cc: Jani Nikula <jani.nikula at linux.intel.com> Cc: Sean Paul <seanpaul at chromium.org> Cc: David Airlie <airlied at linux.ie> Cc: Ben

In the vsock vmci_transport driver, sock_put wasn't safe to call in interrupt context, since that may call the vsock destructor which in turn calls several functions that should only be called from process context. This change defers the callling of these functions to a worker thread. All these functions were deallocation of resources related to the transport itself. Furthermore, an unused

In the vsock vmci_transport driver, sock_put wasn't safe to call in interrupt context, since that may call the vsock destructor which in turn calls several functions that should only be called from process context. This change defers the callling of these functions to a worker thread. All these functions were deallocation of resources related to the transport itself. Furthermore, an unused

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes and so far it's looking good. Everything else is just compile tested. Entire series

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes and so far it's looking good. Everything else is just compile tested. Entire series

We already have __drm_atomic_helper_connector_reset() and __drm_atomic_helper_plane_reset(), extend this to crtc as well. Most drivers already have a gpu reset hook, correct it. Nouveau already implemented its own __drm_atomic_helper_crtc_reset(), convert it to the common one. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc: Harry Wentland <harry.wentland at

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_plane_set_property. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Liviu Dudau <liviu.dudau at arm.com> Cc: Brian Starkey <brian.starkey at arm.com> Cc: Mali DP Maintainers <malidp at foss.arm.com> Cc: Boris Brezillon <boris.brezillon at

From: Ville Syrjälä <ville.syrjala at linux.intel.com> Move the plane clip rectangle handling into drm_atomic_helper_check_plane_state(). Drivers no longer have to worry about such mundane details. v2: Convert armada, rcar, and sun4i as well Cc: Liviu Dudau <liviu.dudau at arm.com> Cc: Brian Starkey <brian.starkey at arm.com> Cc: Mali DP Maintainers <malidp at