Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

On Wed, 27 Feb 2019 20:26:02 -0500, Michael S. Tsirkin wrote: > On Wed, Feb 27, 2019 at 04:52:05PM -0800, Jakub Kicinski wrote: > > On Wed, 27 Feb 2019 19:41:32 -0500, Michael S. Tsirkin wrote: > > > > As this scheme adds much complexity to the kernel naming convention > > > > (currently it's

Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

On Wed, 27 Feb 2019 19:41:32 -0500, Michael S. Tsirkin wrote: > > As this scheme adds much complexity to the kernel naming convention > > (currently it's just ethX names) that no userspace can understand. > > Anything that pokes at slaves needs to be specially designed anyway. > Naming seems

Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

On Wed, Feb 27, 2019 at 04:38:00PM -0800, si-wei liu wrote: > > > On 2/27/2019 3:50 PM, Michael S. Tsirkin wrote: > > On Wed, Feb 27, 2019 at 03:34:56PM -0800, si-wei liu wrote: > > > > > > On 2/27/2019 2:38 PM, Michael S. Tsirkin wrote: > > > > On Tue, Feb 26, 2019 at 04:17:21PM -0800, si-wei

Regression with "arm64: KVM: Skip MMIO insn after emulation" on 4.4 stable

Hello, In my testing of crosvm[1] with Linux 4.4.175, I am observing failures on a 'kevin' Chromebook (RK3399) device - the guest kernel does not even get to the point of printing its first messages, and the host seems to be spinning at 100% CPU in KVM_RUN. I narrowed this down to the 4.4 stable

Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

On Wed, Feb 27, 2019 at 04:03:42PM -0800, Stephen Hemminger wrote: > > With this approach kernel will deny attempts by userspace to rename > > slaves. Slaves will always be named XXXnsby and XXnpry. Master renames > > will rename both slaves. > > > > It seems pretty solid to me, the only issue

Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

On Wed, 27 Feb 2019 18:50:44 -0500 "Michael S. Tsirkin" wrote: > On Wed, Feb 27, 2019 at 03:34:56PM -0800, si-wei liu wrote: > > > > > > On 2/27/2019 2:38 PM, Michael S. Tsirkin wrote: > > > On Tue, Feb 26, 2019 at 04:17:21PM -0800, si-wei liu wrote: > > > > > > > > On 2/25/2019 6:08 PM,

Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

On Wed, Feb 27, 2019 at 03:34:56PM -0800, si-wei liu wrote: > > > On 2/27/2019 2:38 PM, Michael S. Tsirkin wrote: > > On Tue, Feb 26, 2019 at 04:17:21PM -0800, si-wei liu wrote: > > > > > > On 2/25/2019 6:08 PM, Michael S. Tsirkin wrote: > > > > On Mon, Feb 25, 2019 at 04:58:07PM -0800, si-wei

Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

On Tue, Feb 26, 2019 at 04:17:21PM -0800, si-wei liu wrote: > > > On 2/25/2019 6:08 PM, Michael S. Tsirkin wrote: > > On Mon, Feb 25, 2019 at 04:58:07PM -0800, si-wei liu wrote: > > > > > > On 2/22/2019 7:14 AM, Michael S. Tsirkin wrote: > > > > On Thu, Feb 21, 2019 at 11:55:11PM -0800, si-wei

Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework)

On Tue, 26 Feb 2019 16:17:21 -0800 si-wei liu wrote: > On 2/25/2019 6:08 PM, Michael S. Tsirkin wrote: > > On Mon, Feb 25, 2019 at 04:58:07PM -0800, si-wei liu wrote: > >> > >> On 2/22/2019 7:14 AM, Michael S. Tsirkin wrote: > >>> On Thu, Feb 21, 2019 at 11:55:11PM -0800, si-wei liu wrote:

Re: [PATCH 3/3] drm/virtio: implement prime export

Den 27.02.2019 15.44, skrev Gerd Hoffmann: > Just run drm_prime_pages_to_sg() on the ttm pages list to get an > sg_table for export. The pages list is created at object initialization > time, so there should be no need to handle an unpopulated page list. > Add a sanity check nevertheless. > >

Re: [PATCH 1/3] drm/virtio: implement prime mmap

Den 27.02.2019 15.44, skrev Gerd Hoffmann: > Sync gem vm_node.start with ttm vm_node.start, > then we can just call drm_gem_prime_mmap(). > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ Virtualization mailing list

Re: [PATCH 2/3] drm/virtio: implement prime pin/unpin

Den 27.02.2019 15.44, skrev Gerd Hoffmann: > virtio-gpu objects never move around, so effectively they are pinned > all the time. This makes the the implementation pretty easy ;) > > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/virtio/virtgpu_prime.c | 6 +++--- > 1 file changed, 3

[PATCH 1/3] drm/virtio: implement prime mmap

Sync gem vm_node.start with ttm vm_node.start, then we can just call drm_gem_prime_mmap(). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_prime.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c

[PATCH 3/3] drm/virtio: implement prime export

Just run drm_prime_pages_to_sg() on the ttm pages list to get an sg_table for export. The pages list is created at object initialization time, so there should be no need to handle an unpopulated page list. Add a sanity check nevertheless. Signed-off-by: Gerd Hoffmann ---

[PATCH 2/3] drm/virtio: implement prime pin/unpin

virtio-gpu objects never move around, so effectively they are pinned all the time. This makes the the implementation pretty easy ;) Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_prime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git