Re: [PATCH 1/1] Add vhost_blk driver

2018-11-03 Thread Michael S. Tsirkin
On Fri, Nov 02, 2018 at 03:24:13PM -0400, Vitaly Mayatskih wrote: > On Fri, Nov 2, 2018 at 2:36 PM Michael S. Tsirkin wrote: > > > > + if (type == VIRTIO_BLK_T_GET_ID) { > > > + char s[] = "vhost_blk"; > > > > Isn't this supposed to return the serial #? > > Yes, that gets a bit

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Al Viro
On Fri, Nov 02, 2018 at 10:15:56AM -0700, Linus Torvalds wrote: > On Fri, Nov 2, 2018 at 10:10 AM Linus Torvalds > wrote: > > > > Don't you take over the VM with "use_mm()" when you do the copies? So > > yes, it's a kernel thread, but it has a user VM, and though that > > should have the user

[PATCH 4.14 091/143] x86/paravirt: Fix some warning messages

2018-11-03 Thread Greg Kroah-Hartman
4.14-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit 571d0563c8881595f4ab027aef9ed1c55e3e7b7c ] The first argument to WARN_ONCE() is a condition. Fixes: 5800dc5c19f3 ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests")

[PATCH 4.18 073/150] x86/paravirt: Fix some warning messages

2018-11-03 Thread Greg Kroah-Hartman
4.18-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit 571d0563c8881595f4ab027aef9ed1c55e3e7b7c ] The first argument to WARN_ONCE() is a condition. Fixes: 5800dc5c19f3 ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests")

Re: [PATCH 1/1] Add vhost_blk driver

2018-11-03 Thread Michael S. Tsirkin
On Fri, Nov 02, 2018 at 06:21:23PM +, Vitaly Mayatskikh wrote: > This driver accelerates host side of virtio-blk. > > Signed-off-by: Vitaly Mayatskikh > --- > drivers/vhost/Kconfig | 13 ++ > drivers/vhost/Makefile | 3 + > drivers/vhost/blk.c| 510

Re: [PATCH 0/1] vhost: add vhost_blk driver

2018-11-03 Thread Michael S. Tsirkin
On Fri, Nov 02, 2018 at 06:21:22PM +, Vitaly Mayatskikh wrote: > vhost_blk is a host-side kernel mode accelerator for virtio-blk. The > driver allows VM to reach a near bare-metal disk performance. See IOPS > numbers below (fio --rw=randread --bs=4k). > > This implementation uses kiocb

Re: [PATCH v9] virtio_blk: add discard and write zeroes support

2018-11-03 Thread Daniel Verkamp
Hi Dongli, Unfortunately, I am not aware of any in-progress implementation of this feature for qemu. It hopefully should not be too difficult to wire up in the qemu virtio-blk model, but I haven't looked into it in detail. Thanks, -- Daniel On Thu, Nov 1, 2018 at 4:42 PM Dongli Zhang wrote: > >

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Michael S. Tsirkin
On Fri, Nov 02, 2018 at 11:02:35AM -0700, Linus Torvalds wrote: > On Fri, Nov 2, 2018 at 10:21 AM Michael S. Tsirkin wrote: > > > > it seems that it depends on current not on the active mm. > > Yes, see my other suggestion to just fix "use_mm()" to update the address > range. > > Would you

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Linus Torvalds
On Fri, Nov 2, 2018 at 10:21 AM Michael S. Tsirkin wrote: > > it seems that it depends on current not on the active mm. Yes, see my other suggestion to just fix "use_mm()" to update the address range. Would you mind testing that? Because that would seem to be the *much* less error-prone

Re: [PATCH 0/2] i8253: Fix PIT shutdown quirk on Hyper-V

2018-11-03 Thread Thomas Gleixner
On Fri, 2 Nov 2018, Juergen Gross wrote: > On 01/11/2018 18:30, Michael Kelley wrote: > > pit_shutdown() doesn't work on Hyper-V because of a quirk in the > > PIT emulation. This problem exists in all versions of Hyper-V and > > had not been noticed previously. When the counter register is set > >

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Linus Torvalds
On Fri, Nov 2, 2018 at 9:59 AM Michael S. Tsirkin wrote: > > Just for completeness I'd like to point out for vhost the copies are > done from the kernel thread. So yes we can switch to copy_to/from_user > but for e.g. 32-bit userspace running on top of a 64 bit kernel it is > IIUC not sufficient

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Linus Torvalds
On Fri, Nov 2, 2018 at 10:10 AM Linus Torvalds wrote: > > Don't you take over the VM with "use_mm()" when you do the copies? So > yes, it's a kernel thread, but it has a user VM, and though that > should have the user limits. Oooh. *Just* as I sent this, I realized that "use_mm()" doesn't update

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Michael S. Tsirkin
On Fri, Nov 02, 2018 at 10:10:45AM -0700, Linus Torvalds wrote: > On Fri, Nov 2, 2018 at 9:59 AM Michael S. Tsirkin wrote: > > > > Just for completeness I'd like to point out for vhost the copies are > > done from the kernel thread. So yes we can switch to copy_to/from_user > > but for e.g.

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Michael S. Tsirkin
On Fri, Nov 02, 2018 at 09:14:51AM -0700, Linus Torvalds wrote: > On Fri, Nov 2, 2018 at 6:04 AM Michael S. Tsirkin wrote: > > > > I've tried making access_ok mask the parameter it gets. > > PLEASE don't do this. Okay. > Just use "copy_to/from_user()". Just for completeness I'd like to point

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Linus Torvalds
On Fri, Nov 2, 2018 at 6:04 AM Michael S. Tsirkin wrote: > > I've tried making access_ok mask the parameter it gets. PLEASE don't do this. Just use "copy_to/from_user()". We have had lots of bugs because code bitrots. And no, the access_ok() checks aren't expensive, not even in a loop. They

Re: [PATCH 2/5] drm/virtio: add uapi for in and out explicit fences

2018-11-03 Thread Emil Velikov
On Thu, 1 Nov 2018 at 12:56, Robert Foss wrote: > On 2018-10-31 10:38, Emil Velikov wrote: > > Hi Rob, > > > > On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote: > >> > >> Add a new field called fence_fd that will be used by userspace to send > >> in-fences to the kernel and receive out-fences

Re: [PULL] vhost: cleanups and fixes

2018-11-03 Thread Michael S. Tsirkin
On Fri, Nov 02, 2018 at 11:46:36AM +, Mark Rutland wrote: > On Thu, Nov 01, 2018 at 04:06:19PM -0700, Linus Torvalds wrote: > > On Thu, Nov 1, 2018 at 4:00 PM Kees Cook wrote: > > > > > > + memset(, 0, sizeof(rsp)); > > > + rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED; > > > +