date:20201023

Re: [External] Re: [RFC 0/4] Introduce VDUSE - vDPA Device in Userspace

2020-10-23 Thread Jason Wang



On 2020/10/23 上午10:55, Yongji Xie wrote:



On Tue, Oct 20, 2020 at 5:13 PM Jason Wang > wrote:



On 2020/10/20 下午4:35, Yongji Xie wrote:
>
>
> On Tue, Oct 20, 2020 at 4:01 PM Jason Wang mailto:jasow...@redhat.com>
> >> wrote:
>
>
>     On 2020/10/20 下午3:39, Yongji Xie wrote:
>     >
>     >
>     > On Tue, Oct 20, 2020 at 11:20 AM Jason Wang
mailto:jasow...@redhat.com>
>     >
>     > 
     >
>     >
>     >     On 2020/10/19 下午10:56, Xie Yongji wrote:
>     >     > This series introduces a framework, which can be used to
>     implement
>     >     > vDPA Devices in a userspace program. To implement
it, the work
>     >     > consist of two parts: control path emulating and
data path
>     >     offloading.
>     >     >
>     >     > In the control path, the VDUSE driver will make use
of message
>     >     > mechnism to forward the actions (get/set features,
get/st
>     status,
>     >     > get/set config space and set virtqueue states) from
>     virtio-vdpa
>     >     > driver to userspace. Userspace can use read()/write() to
>     >     > receive/reply to those control messages.
>     >     >
>     >     > In the data path, the VDUSE driver implements a
MMU-based
>     >     > on-chip IOMMU driver which supports both direct
mapping and
>     >     > indirect mapping with bounce buffer. Then userspace
can access
>     >     > those iova space via mmap(). Besides, eventfd
mechnism is
>     used to
>     >     > trigger interrupts and forward virtqueue kicks.
>     >
>     >
>     >     This is pretty interesting!
>     >
>     >     For vhost-vdpa, it should work, but for virtio-vdpa, I
think we
>     >     should
>     >     carefully deal with the IOMMU/DMA ops stuffs.
>     >
>     >
>     >     I notice that neither dma_map nor set_map is
implemented in
>     >     vduse_vdpa_config_ops, this means you want to let
vhost-vDPA
>     to deal
>     >     with IOMMU domains stuffs.  Any reason for doing that?
>     >
>     > Actually, this series only focus on virtio-vdpa case now. To
>     support
>     > vhost-vdpa,  as you said, we need to implement
>     dma_map/dma_unmap. But
>     > there is a limit that vm's memory can't be anonymous pages
which
>     are
>     > forbidden in vm_insert_page(). Maybe we need to add some
limits on
>     > vhost-vdpa?
>
>
>     I'm not sure I get this, any reason that you want to use
>     vm_insert_page() to VM's memory. Or do you mean you want to
implement
>     some kind of zero-copy?
>
>
>
> If my understanding is right, we will have a QEMU (VM) process
and a
> device emulation process in the vhost-vdpa case, right? When I/O
> happens, the virtio driver in VM will put the IOVA to vring and
device
> emulation process will get the IOVA from vring. Then the device
> emulation process will translate the IOVA to its VA to access
the dma
> buffer which resides in VM's memory. That means the device
emulation
> process needs to access VM's memory, so we should use
vm_insert_page()
> to build the page table of the device emulation process.


Ok, I get you now. So it looks to me the that the real issue is
not the
limitation to anonymous page but see the comments above
vm_insert_page():

"

  * The page has to be a nice clean _individual_ kernel allocation.
"

So I suspect that using vm_insert_page() to share pages between
processes is legal. We need inputs from MM experts.


Yes,  vm_insert_page() can't be used in this case. So could we add the 
shmfd into the vhost iotlb msg and pass it to the device emulation 
process as a new iova_domain, just like vhost-user does.


Thanks,
Yongji



I think vhost-user did that via SET_MEM_TABLE which is not supported by 
vDPA. Note that the current IOTLB message will be used when vIOMMU is 
enabled.


This needs more thought. Will come back if I had any thought.

Thanks







>
>     I guess from the software device implemention in user space it
>     only need
>     to receive IOVA ranges and map them in its own address space.
>
>
> How to map them in its own address space if we don't use
vm_insert_page()?



___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V3 2/3] vhost: vdpa: report iova range

2020-10-23 Thread Jason Wang



On 2020/10/23 下午1:28, kernel test robot wrote:

Hi Jason,

I love your patch! Perhaps something to improve:

[auto build test WARNING on vhost/linux-next]
[also build test WARNING on linus/master v5.9 next-20201023]
[cannot apply to linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Jason-Wang/vDPA-API-for-reporting-IOVA-range/20201023-102708
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: m68k-randconfig-r034-20201022 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # 
https://github.com/0day-ci/linux/commit/446e7b97838ebf87f1acd61580137716fdad104a
 git remote add linux-review https://github.com/0day-ci/linux
 git fetch --no-tags linux-review 
Jason-Wang/vDPA-API-for-reporting-IOVA-range/20201023-102708
 git checkout 446e7b97838ebf87f1acd61580137716fdad104a
 # save the attached .config to linux build tree
 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=m68k

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

drivers/vhost/vdpa.c: In function 'vhost_vdpa_setup_vq_irq':
drivers/vhost/vdpa.c:94:6: warning: variable 'ret' set but not used 
[-Wunused-but-set-variable]
   94 |  int ret, irq;
  |  ^~~
drivers/vhost/vdpa.c: In function 'vhost_vdpa_unlocked_ioctl':



This looks like another issue that needs to be fixed.



drivers/vhost/vdpa.c:483:5: warning: this statement may fall through 
[-Wimplicit-fallthrough=]

  483 |   r = copy_to_user(featurep, &features, sizeof(features));
  |   ~~^
drivers/vhost/vdpa.c:484:2: note: here
  484 |  case VHOST_VDPA_GET_IOVA_RANGE:
  |  ^~~~

vim +483 drivers/vhost/vdpa.c



My bad. V4 is on the road.

Thanks




4c8cf31885f69e8 Tiwei Bie2020-03-26  426
4c8cf31885f69e8 Tiwei Bie2020-03-26  427  static long 
vhost_vdpa_unlocked_ioctl(struct file *filep,
4c8cf31885f69e8 Tiwei Bie2020-03-26  428  
unsigned int cmd, unsigned long arg)
4c8cf31885f69e8 Tiwei Bie2020-03-26  429  {
4c8cf31885f69e8 Tiwei Bie2020-03-26  430struct vhost_vdpa *v = 
filep->private_data;
4c8cf31885f69e8 Tiwei Bie2020-03-26  431struct vhost_dev *d = &v->vdev;
4c8cf31885f69e8 Tiwei Bie2020-03-26  432void __user *argp = (void 
__user *)arg;
a127c5bbb6a8eee Jason Wang   2020-09-07  433u64 __user *featurep = argp;
a127c5bbb6a8eee Jason Wang   2020-09-07  434u64 features;
4c8cf31885f69e8 Tiwei Bie2020-03-26  435long r;
4c8cf31885f69e8 Tiwei Bie2020-03-26  436
a127c5bbb6a8eee Jason Wang   2020-09-07  437if (cmd == 
VHOST_SET_BACKEND_FEATURES) {
a127c5bbb6a8eee Jason Wang   2020-09-07  438r = 
copy_from_user(&features, featurep, sizeof(features));
a127c5bbb6a8eee Jason Wang   2020-09-07  439if (r)
a127c5bbb6a8eee Jason Wang   2020-09-07  440return r;
a127c5bbb6a8eee Jason Wang   2020-09-07  441if (features & 
~VHOST_VDPA_BACKEND_FEATURES)
a127c5bbb6a8eee Jason Wang   2020-09-07  442return 
-EOPNOTSUPP;
a127c5bbb6a8eee Jason Wang   2020-09-07  443
vhost_set_backend_features(&v->vdev, features);
a127c5bbb6a8eee Jason Wang   2020-09-07  444return 0;
a127c5bbb6a8eee Jason Wang   2020-09-07  445}
a127c5bbb6a8eee Jason Wang   2020-09-07  446
4c8cf31885f69e8 Tiwei Bie2020-03-26  447mutex_lock(&d->mutex);
4c8cf31885f69e8 Tiwei Bie2020-03-26  448
4c8cf31885f69e8 Tiwei Bie2020-03-26  449switch (cmd) {
4c8cf31885f69e8 Tiwei Bie2020-03-26  450case VHOST_VDPA_GET_DEVICE_ID:
4c8cf31885f69e8 Tiwei Bie2020-03-26  451r = 
vhost_vdpa_get_device_id(v, argp);
4c8cf31885f69e8 Tiwei Bie2020-03-26  452break;
4c8cf31885f69e8 Tiwei Bie2020-03-26  453case VHOST_VDPA_GET_STATUS:
4c8cf31885f69e8 Tiwei Bie2020-03-26  454r = 
vhost_vdpa_get_status(v, argp);
4c8cf31885f69e8 Tiwei Bie2020-03-26  455break;
4c8cf31885f69e8 Tiwei Bie2020-03-26  456case VHOST_VDPA_SET_STATUS:
4c8cf31885f69e8 Tiwei Bie2020-03-26  457r = 
vhost_vdpa_set_status(v, argp);
4c8cf31885f69e8 Tiwei Bie2020-03-26  458break;
4c8cf31885f69e8 Tiwei Bie2020-03-26  459case VHOST_VDPA_GET_CONFIG:
4c8cf31885f69e8 Tiwei Bie2020-03-26  460r = 
vhost_vdpa_

[PATCH V4 2/3] vhost: vdpa: report iova range

2020-10-23 Thread Jason Wang

This patch introduces a new ioctl for vhost-vdpa device that can
report the iova range by the device.

For device that implements get_iova_range() method, we fetch it from
the vDPA device. If device doesn't implement get_iova_range() but
depends on platform IOMMU, we will query via DOMAIN_ATTR_GEOMETRY,
otherwise [0, ULLONG_MAX] is assumed.

For safety, this patch also rules out the map request which is not in
the valid range.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c | 41 
 include/uapi/linux/vhost.h   |  4 
 include/uapi/linux/vhost_types.h |  9 +++
 3 files changed, 54 insertions(+)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index a2dbc85e0b0d..846de69d9c01 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -47,6 +47,7 @@ struct vhost_vdpa {
int minor;
struct eventfd_ctx *config_ctx;
int in_batch;
+   struct vdpa_iova_range range;
 };
 
 static DEFINE_IDA(vhost_vdpa_ida);
@@ -337,6 +338,16 @@ static long vhost_vdpa_set_config_call(struct vhost_vdpa 
*v, u32 __user *argp)
return 0;
 }
 
+static long vhost_vdpa_get_iova_range(struct vhost_vdpa *v, u32 __user *argp)
+{
+   struct vhost_vdpa_iova_range range = {
+   .first = v->range.first,
+   .last = v->range.last,
+   };
+
+   return copy_to_user(argp, &range, sizeof(range));
+}
+
 static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd,
   void __user *argp)
 {
@@ -471,6 +482,9 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
features = VHOST_VDPA_BACKEND_FEATURES;
r = copy_to_user(featurep, &features, sizeof(features));
break;
+   case VHOST_VDPA_GET_IOVA_RANGE:
+   r = vhost_vdpa_get_iova_range(v, argp);
+   break;
default:
r = vhost_dev_ioctl(&v->vdev, cmd, argp);
if (r == -ENOIOCTLCMD)
@@ -597,6 +611,10 @@ static int vhost_vdpa_process_iotlb_update(struct 
vhost_vdpa *v,
long pinned;
int ret = 0;
 
+   if (msg->iova < v->range.first ||
+   msg->iova + msg->size - 1 > v->range.last)
+   return -EINVAL;
+
if (vhost_iotlb_itree_first(iotlb, msg->iova,
msg->iova + msg->size - 1))
return -EEXIST;
@@ -783,6 +801,27 @@ static void vhost_vdpa_free_domain(struct vhost_vdpa *v)
v->domain = NULL;
 }
 
+static void vhost_vdpa_set_iova_range(struct vhost_vdpa *v)
+{
+   struct vdpa_iova_range *range = &v->range;
+   struct iommu_domain_geometry geo;
+   struct vdpa_device *vdpa = v->vdpa;
+   const struct vdpa_config_ops *ops = vdpa->config;
+
+   if (ops->get_iova_range) {
+   *range = ops->get_iova_range(vdpa);
+   } else if (v->domain &&
+  !iommu_domain_get_attr(v->domain,
+  DOMAIN_ATTR_GEOMETRY, &geo) &&
+  geo.force_aperture) {
+   range->first = geo.aperture_start;
+   range->last = geo.aperture_end;
+   } else {
+   range->first = 0;
+   range->last = ULLONG_MAX;
+   }
+}
+
 static int vhost_vdpa_open(struct inode *inode, struct file *filep)
 {
struct vhost_vdpa *v;
@@ -823,6 +862,8 @@ static int vhost_vdpa_open(struct inode *inode, struct file 
*filep)
if (r)
goto err_init_iotlb;
 
+   vhost_vdpa_set_iova_range(v);
+
filep->private_data = v;
 
return 0;
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 75232185324a..c998860d7bbc 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -146,4 +146,8 @@
 
 /* Set event fd for config interrupt*/
 #define VHOST_VDPA_SET_CONFIG_CALL _IOW(VHOST_VIRTIO, 0x77, int)
+
+/* Get the valid iova range */
+#define VHOST_VDPA_GET_IOVA_RANGE  _IOR(VHOST_VIRTIO, 0x78, \
+struct vhost_vdpa_iova_range)
 #endif
diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h
index 9a269a88a6ff..f7f6a3a28977 100644
--- a/include/uapi/linux/vhost_types.h
+++ b/include/uapi/linux/vhost_types.h
@@ -138,6 +138,15 @@ struct vhost_vdpa_config {
__u8 buf[0];
 };
 
+/* vhost vdpa IOVA range
+ * @first: First address that can be mapped by vhost-vDPA
+ * @last: Last address that can be mapped by vhost-vDPA
+ */
+struct vhost_vdpa_iova_range {
+   __u64 first;
+   __u64 last;
+};
+
 /* Feature bits */
 /* Log all write descriptors. Can be changed while device is active. */
 #define VHOST_F_LOG_ALL 26
-- 
2.20.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH V4 0/3] vDPA: API for reporting IOVA range

2020-10-23 Thread Jason Wang

Hi All:

This series introduces API for reporing IOVA range. This is a must for
userspace to work correclty:

- for the process that uses vhost-vDPA directly, the IOVA must be
  allocated from this range.
- for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out
  of range
- for VM(qemu), when vIOMMU is enabled, determine a valid guest
  address width and then guest IOVA allocator can behave correctly.

Please review.

Changes from V3:

- really silent build warnings

Changes from V2:

- silent build warnings

Changes from V1:

- do not mandate get_iova_range() for device with its own DMA
  translation logic and assume a [0, ULLONG_MAX] range
- mandate IOVA range only for IOMMU that forcing aperture
- forbid the map which is out of the IOVA range in vhost-vDPA

Jason Wang (3):
  vdpa: introduce config op to get valid iova range
  vhost: vdpa: report iova range
  vdpa_sim: implement get_iova_range()

 drivers/vdpa/vdpa_sim/vdpa_sim.c | 12 ++
 drivers/vhost/vdpa.c | 41 
 include/linux/vdpa.h | 15 
 include/uapi/linux/vhost.h   |  4 
 include/uapi/linux/vhost_types.h |  9 +++
 5 files changed, 81 insertions(+)

-- 
2.20.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH V4 3/3] vdpa_sim: implement get_iova_range()

2020-10-23 Thread Jason Wang

This implements a sample get_iova_range() for the simulator which
advertise [0, ULLONG_MAX] as the valid range.

Signed-off-by: Jason Wang 
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 62d640327145..ff6c9fd8d879 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -574,6 +574,16 @@ static u32 vdpasim_get_generation(struct vdpa_device *vdpa)
return vdpasim->generation;
 }
 
+static struct vdpa_iova_range vdpasim_get_iova_range(struct vdpa_device *vdpa)
+{
+   struct vdpa_iova_range range = {
+   .first = 0ULL,
+   .last = ULLONG_MAX,
+   };
+
+   return range;
+}
+
 static int vdpasim_set_map(struct vdpa_device *vdpa,
   struct vhost_iotlb *iotlb)
 {
@@ -657,6 +667,7 @@ static const struct vdpa_config_ops vdpasim_net_config_ops 
= {
.get_config = vdpasim_get_config,
.set_config = vdpasim_set_config,
.get_generation = vdpasim_get_generation,
+   .get_iova_range = vdpasim_get_iova_range,
.dma_map= vdpasim_dma_map,
.dma_unmap  = vdpasim_dma_unmap,
.free   = vdpasim_free,
@@ -683,6 +694,7 @@ static const struct vdpa_config_ops 
vdpasim_net_batch_config_ops = {
.get_config = vdpasim_get_config,
.set_config = vdpasim_set_config,
.get_generation = vdpasim_get_generation,
+   .get_iova_range = vdpasim_get_iova_range,
.set_map= vdpasim_set_map,
.free   = vdpasim_free,
 };
-- 
2.20.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH V4 1/3] vdpa: introduce config op to get valid iova range

2020-10-23 Thread Jason Wang

This patch introduce a config op to get valid iova range from the vDPA
device.

Signed-off-by: Jason Wang 
---
 include/linux/vdpa.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index eae0bfd87d91..30bc7a7223bb 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -52,6 +52,16 @@ struct vdpa_device {
int nvqs;
 };
 
+/**
+ * vDPA IOVA range - the IOVA range support by the device
+ * @first: start of the IOVA range
+ * @last: end of the IOVA range
+ */
+struct vdpa_iova_range {
+   u64 first;
+   u64 last;
+};
+
 /**
  * vDPA_config_ops - operations for configuring a vDPA device.
  * Note: vDPA device drivers are required to implement all of the
@@ -151,6 +161,10 @@ struct vdpa_device {
  * @get_generation:Get device config generation (optional)
  * @vdev: vdpa device
  * Returns u32: device generation
+ * @get_iova_range:Get supported iova range (optional)
+ * @vdev: vdpa device
+ * Returns the iova range supported by
+ * the device.
  * @set_map:   Set device memory mapping (optional)
  * Needed for device that using device
  * specific DMA translation (on-chip IOMMU)
@@ -216,6 +230,7 @@ struct vdpa_config_ops {
void (*set_config)(struct vdpa_device *vdev, unsigned int offset,
   const void *buf, unsigned int len);
u32 (*get_generation)(struct vdpa_device *vdev);
+   struct vdpa_iova_range (*get_iova_range)(struct vdpa_device *vdev);
 
/* DMA ops */
int (*set_map)(struct vdpa_device *vdev, struct vhost_iotlb *iotlb);
-- 
2.20.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

2020-10-23 Thread Sebastian Hofmann

> Michael S. Tsirkin  hat am 22.10.2020 13:39 geschrieben:
> 
>  
> On Wed, Oct 21, 2020 at 05:14:25PM +0200, Sebastian Hofmann wrote:
> > virtio_ring does not work with active memory encryption because the host 
> > cannot read it. Fix this by enforcing the use of DMA which uses shared 
> > (unencrypted) memory pages.
> > 
> > Signed-off-by: Sebastian Hofmann 
> 
> 
> Sorry, no.
> host which can not access all of driver memory must set 
> VIRTIO_F_ACCESS_PLATFORM.
> 
> Not worth it to work around broken hosts.
> 
> Xen is an exception we carry around since it predates the
> introduction of VIRTIO_F_ACCESS_PLATFORM.
> 
> 

Thanks for pointing out VIRTIO_F_ACCESS_PLATFORM which I was not aware of. 
Maybe that patch was a bit naïve.

Basically I'm looking for a way to use vsock with qemu on AMD SEV. When I try 
to use IOMMU for vsock I get an EOPNOTSUPP out of vhost_vsock_set_features.

Is there a reason why vhost_vsock_set_features doesn't use 
vhost_init_device_iotlb as done in the net device? Because that would have been 
my next attempt.
I would appreciate a short comment on this idea or a recommendation for another 
solution that is better than the patch below.

> > ---
> >  drivers/virtio/virtio_ring.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index becc77697960..8c68c475ec21 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #ifdef DEBUG
> >  /* For development, we want to crash whenever the ring is screwed. */
> > @@ -255,6 +256,10 @@ static bool vring_use_dma_api(struct virtio_device 
> > *vdev)
> > if (xen_domain())
> > return true;
> >  
> > +   /* Memory encryption requires DMA */
> > +   if (mem_encrypt_active())
> > +   return true;
> > +
> > return false;
> >  }
> >  
> > -- 
> > 2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

2020-10-23 Thread Jason Wang



On 2020/10/23 下午5:00, Sebastian Hofmann wrote:

Michael S. Tsirkin  hat am 22.10.2020 13:39 geschrieben:

  
On Wed, Oct 21, 2020 at 05:14:25PM +0200, Sebastian Hofmann wrote:

virtio_ring does not work with active memory encryption because the host cannot 
read it. Fix this by enforcing the use of DMA which uses shared (unencrypted) 
memory pages.

Signed-off-by: Sebastian Hofmann 


Sorry, no.
host which can not access all of driver memory must set 
VIRTIO_F_ACCESS_PLATFORM.

Not worth it to work around broken hosts.

Xen is an exception we carry around since it predates the
introduction of VIRTIO_F_ACCESS_PLATFORM.



Thanks for pointing out VIRTIO_F_ACCESS_PLATFORM which I was not aware of. 
Maybe that patch was a bit naïve.

Basically I'm looking for a way to use vsock with qemu on AMD SEV. When I try 
to use IOMMU for vsock I get an EOPNOTSUPP out of vhost_vsock_set_features.

Is there a reason why vhost_vsock_set_features doesn't use 
vhost_init_device_iotlb as done in the net device?



It's just because it has been implemented. In addition to implement 
IOTLB, the virtio-vsock-pci must advertise ATS capability as well.




Because that would have been my next attempt.
I would appreciate a short comment on this idea or a recommendation for another 
solution that is better than the patch below.



A question, is vIOMMU a must for making SEV work?

Thanks





---
  drivers/virtio/virtio_ring.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index becc77697960..8c68c475ec21 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -12,6 +12,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #ifdef DEBUG

  /* For development, we want to crash whenever the ring is screwed. */
@@ -255,6 +256,10 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
if (xen_domain())
return true;
  
+	/* Memory encryption requires DMA */

+   if (mem_encrypt_active())
+   return true;
+
return false;
  }
  
--

2.25.1


___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

2020-10-23 Thread Sebastian Hofmann


> Jason Wang  hat am 23.10.2020 11:10 geschrieben:
> 
>  
> On 2020/10/23 下午5:00, Sebastian Hofmann wrote:
> >> Michael S. Tsirkin  hat am 22.10.2020 13:39 geschrieben:
> >>
> >>   
> >> On Wed, Oct 21, 2020 at 05:14:25PM +0200, Sebastian Hofmann wrote:
> >>> virtio_ring does not work with active memory encryption because the host 
> >>> cannot read it. Fix this by enforcing the use of DMA which uses shared 
> >>> (unencrypted) memory pages.
> >>>
> >>> Signed-off-by: Sebastian Hofmann 
> >>
> >> Sorry, no.
> >> host which can not access all of driver memory must set 
> >> VIRTIO_F_ACCESS_PLATFORM.
> >>
> >> Not worth it to work around broken hosts.
> >>
> >> Xen is an exception we carry around since it predates the
> >> introduction of VIRTIO_F_ACCESS_PLATFORM.
> >>
> >>
> > Thanks for pointing out VIRTIO_F_ACCESS_PLATFORM which I was not aware of. 
> > Maybe that patch was a bit naïve.
> >
> > Basically I'm looking for a way to use vsock with qemu on AMD SEV. When I 
> > try to use IOMMU for vsock I get an EOPNOTSUPP out of 
> > vhost_vsock_set_features.
> >
> > Is there a reason why vhost_vsock_set_features doesn't use 
> > vhost_init_device_iotlb as done in the net device?
> 
> 
> It's just because it has been implemented. In addition to implement 
> IOTLB, the virtio-vsock-pci must advertise ATS capability as well.
> 
> 
> > Because that would have been my next attempt.
> > I would appreciate a short comment on this idea or a recommendation for 
> > another solution that is better than the patch below.
> 
> 
> A question, is vIOMMU a must for making SEV work?

Based on the demo code from AMD where they just use "-device 
virtio-scsi-pci,id=scsi,disable-legacy=on,iommu_platform=true" and my 
understanding of IOMMU: no, I don't think so.

The ATS capability is only required for vIOMMU, right?

> 
> Thanks
> 
> 
> >
> >>> ---
> >>>   drivers/virtio/virtio_ring.c | 5 +
> >>>   1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> >>> index becc77697960..8c68c475ec21 100644
> >>> --- a/drivers/virtio/virtio_ring.c
> >>> +++ b/drivers/virtio/virtio_ring.c
> >>> @@ -12,6 +12,7 @@
> >>>   #include 
> >>>   #include 
> >>>   #include 
> >>> +#include 
> >>>   
> >>>   #ifdef DEBUG
> >>>   /* For development, we want to crash whenever the ring is screwed. */
> >>> @@ -255,6 +256,10 @@ static bool vring_use_dma_api(struct virtio_device 
> >>> *vdev)
> >>>   if (xen_domain())
> >>>   return true;
> >>>   
> >>> + /* Memory encryption requires DMA */
> >>> + if (mem_encrypt_active())
> >>> + return true;
> >>> +
> >>>   return false;
> >>>   }
> >>>   
> >>> -- 
> >>> 2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH net] vhost_vdpa: Return -EFUALT if copy_from_user() fails

2020-10-23 Thread Dan Carpenter

The copy_to/from_user() functions return the number of bytes which we
weren't able to copy but the ioctl should return -EFAULT if they fail.

Fixes: a127c5bbb6a8 ("vhost-vdpa: fix backend feature ioctls")
Signed-off-by: Dan Carpenter 
---
 drivers/vhost/vdpa.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 62a9bb0efc55..c94a97b6bd6d 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -428,12 +428,11 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
void __user *argp = (void __user *)arg;
u64 __user *featurep = argp;
u64 features;
-   long r;
+   long r = 0;
 
if (cmd == VHOST_SET_BACKEND_FEATURES) {
-   r = copy_from_user(&features, featurep, sizeof(features));
-   if (r)
-   return r;
+   if (copy_from_user(&features, featurep, sizeof(features)))
+   return -EFAULT;
if (features & ~VHOST_VDPA_BACKEND_FEATURES)
return -EOPNOTSUPP;
vhost_set_backend_features(&v->vdev, features);
@@ -476,7 +475,8 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
break;
case VHOST_GET_BACKEND_FEATURES:
features = VHOST_VDPA_BACKEND_FEATURES;
-   r = copy_to_user(featurep, &features, sizeof(features));
+   if (copy_to_user(featurep, &features, sizeof(features)))
+   r = -EFAULT;
break;
default:
r = vhost_dev_ioctl(&v->vdev, cmd, argp);
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 5/5] drm/: Constify struct drm_driver

2020-10-23 Thread Daniel Vetter

Only the following drivers aren't converted:
- amdgpu, because of the driver_feature mangling due to virt support
- nouveau, because DRIVER_ATOMIC uapi is still not the default on the
  platforms where it's supported (i.e. again driver_feature mangling)
- vc4, again because of driver_feature mangling
- qxl, because the ioctl table is somewhere else and moving that is
  maybe a bit too much, hence the num_ioctls assignment prevents a
  const driver structure.

Note that for armada I also went ahead and made the ioctl array const.

Only cc'ing the driver people who've not been converted (everyone else
is way too much).

Signed-off-by: Daniel Vetter 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: virtualization@lists.linux-foundation.org
Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Eric Anholt 
Cc: Maxime Ripard 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c  | 2 +-
 drivers/gpu/drm/arm/hdlcd_drv.c  | 2 +-
 drivers/gpu/drm/arm/malidp_drv.c | 2 +-
 drivers/gpu/drm/armada/armada_drv.c  | 7 +++
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c  | 2 +-
 drivers/gpu/drm/ast/ast_drv.c| 2 +-
 drivers/gpu/drm/ast/ast_drv.h| 2 +-
 drivers/gpu/drm/ast/ast_main.c   | 2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
 drivers/gpu/drm/bochs/bochs_drv.c| 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  | 2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++---
 drivers/gpu/drm/gma500/psb_drv.c | 4 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 2 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 2 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h  | 2 +-
 drivers/gpu/drm/i915/i915_drv.c  | 4 ++--
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
 drivers/gpu/drm/imx/dcss/dcss-kms.c  | 2 +-
 drivers/gpu/drm/imx/imx-drm-core.c   | 2 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +-
 drivers/gpu/drm/lima/lima_drv.c  | 2 +-
 drivers/gpu/drm/mcde/mcde_drv.c  | 2 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   | 2 +-
 drivers/gpu/drm/meson/meson_drv.c| 2 +-
 drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +-
 drivers/gpu/drm/msm/msm_drv.c| 4 ++--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   | 2 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c  | 2 +-
 drivers/gpu/drm/pl111/pl111_drv.c| 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c  | 4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  | 4 ++--
 drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
 drivers/gpu/drm/sti/sti_drv.c| 2 +-
 drivers/gpu/drm/stm/drv.c| 2 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +-
 drivers/gpu/drm/tegra/drm.c  | 5 ++---
 drivers/gpu/drm/tidss/tidss_drv.c| 2 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 4 ++--
 drivers/gpu/drm/tiny/cirrus.c| 2 +-
 drivers/gpu/drm/tiny/gm12u320.c  | 2 +-
 drivers/gpu/drm/tiny/hx8357d.c   | 2 +-
 drivers/gpu/drm/tiny/ili9225.c   | 2 +-
 drivers/gpu/drm/tiny/ili9341.c   | 2 +-
 drivers/gpu/drm/tiny/ili9486.c   | 2 +-
 drivers/gpu/drm/tiny/mi0283qt.c  | 2 +-
 drivers/gpu/drm/tiny/repaper.c   | 2 +-
 drivers/gpu/drm/tiny/st7586.c| 2 +-
 drivers/gpu/drm/tiny/st7735r.c   | 2 +-
 drivers/gpu/drm/tve200/tve200_drv.c  | 2 +-
 drivers/gpu/drm/udl/udl_drv.c| 2 +-
 drivers/gpu/drm/v3d/v3d_drv.c| 2 +-
 drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++--
 drivers/gpu/drm/vgem/vgem_drv.c  | 2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++--
 drivers/gpu/drm/vkms/vkms_drv.c  | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  | 2 +-
 drivers/gpu/drm/xen/xen_drm_front.c  | 2 +-
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c  | 2 +-
 drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
 63 files changed, 75 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index cc5b5915bc5e..d04008f3e31a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -58,7 +58,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void *data)
return status;
 }
 
-static struct drm_driver kom

Re: [Intel-gfx] [PATCH 5/5] drm/: Constify struct drm_driver

2020-10-23 Thread kernel test robot

Hi Daniel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next 
linus/master v5.9 next-20201023]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-radeon-Stop-changing-the-drm_driver-struct/20201023-203020
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: arm64-randconfig-r011-20201022 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/9e2fdb03c9047a5d4b24b3e95f0370bcc59eec5e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Daniel-Vetter/drm-radeon-Stop-changing-the-drm_driver-struct/20201023-203020
git checkout 9e2fdb03c9047a5d4b24b3e95f0370bcc59eec5e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c:921:1: warning: 'static' is 
>> not at beginning of declaration [-Wold-style-declaration]
 921 | const static struct drm_driver ade_driver = {
 | ^

vim +/static +921 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c

   920  
 > 921  const static struct drm_driver ade_driver = {
   922  .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
   923  .fops = &ade_fops,
   924  DRM_GEM_CMA_DRIVER_OPS,
   925  .name = "kirin",
   926  .desc = "Hisilicon Kirin620 SoC DRM Driver",
   927  .date = "20150718",
   928  .major = 1,
   929  .minor = 0,
   930  };
   931  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH net] vhost_vdpa: Return -EFUALT if copy_from_user() fails

2020-10-23 Thread Michael S. Tsirkin

On Fri, Oct 23, 2020 at 03:08:53PM +0300, Dan Carpenter wrote:
> The copy_to/from_user() functions return the number of bytes which we
> weren't able to copy but the ioctl should return -EFAULT if they fail.
> 
> Fixes: a127c5bbb6a8 ("vhost-vdpa: fix backend feature ioctls")
> Signed-off-by: Dan Carpenter 

Acked-by: Michael S. Tsirkin 
Needed for stable I guess.

> ---
>  drivers/vhost/vdpa.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index 62a9bb0efc55..c94a97b6bd6d 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -428,12 +428,11 @@ static long vhost_vdpa_unlocked_ioctl(struct file 
> *filep,
>   void __user *argp = (void __user *)arg;
>   u64 __user *featurep = argp;
>   u64 features;
> - long r;
> + long r = 0;
>  
>   if (cmd == VHOST_SET_BACKEND_FEATURES) {
> - r = copy_from_user(&features, featurep, sizeof(features));
> - if (r)
> - return r;
> + if (copy_from_user(&features, featurep, sizeof(features)))
> + return -EFAULT;
>   if (features & ~VHOST_VDPA_BACKEND_FEATURES)
>   return -EOPNOTSUPP;
>   vhost_set_backend_features(&v->vdev, features);
> @@ -476,7 +475,8 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
>   break;
>   case VHOST_GET_BACKEND_FEATURES:
>   features = VHOST_VDPA_BACKEND_FEATURES;
> - r = copy_to_user(featurep, &features, sizeof(features));
> + if (copy_to_user(featurep, &features, sizeof(features)))
> + r = -EFAULT;
>   break;
>   default:
>   r = vhost_dev_ioctl(&v->vdev, cmd, argp);

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[GIT PULL] vhost,vdpa,virtio: cleanups, fixes

2020-10-23 Thread Michael S. Tsirkin

Was holding out for a couple of big new features including vop and rpmsg
support for 1.0, but it looks like they won't make it in time.
virtio i2c might be ready soon but that's a new driver so
if it's ready soon it's probably ok to merge outside the merge
window ... we'll see.

The following changes since commit bbf5c979011a099af5dc76498918ed7df445635b:

  Linux 5.9 (2020-10-11 14:15:50 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

for you to fetch changes up to 88a0d60c6445f315fbcfff3db792021bb3a67b28:

  MAINTAINERS: add URL for virtio-mem (2020-10-21 10:48:11 -0400)


vhost,vdpa,virtio: cleanups, fixes

A very quiet cycle, no new features.

Signed-off-by: Michael S. Tsirkin 


David Hildenbrand (1):
  MAINTAINERS: add URL for virtio-mem

Eli Cohen (3):
  vdpa/mlx5: Make use of a specific 16 bit endianness API
  vdpa/mlx5: Fix failure to bring link up
  vdpa/mlx5: Setup driver only if VIRTIO_CONFIG_S_DRIVER_OK

Li Wang (1):
  vhost: reduce stack usage in log_used

Pierre Morel (2):
  virtio: let arch advertise guest's memory access restrictions
  s390: virtio: PV needs VIRTIO I/O device protection

Rikard Falkeborn (3):
  virtio-balloon: Constify id_table
  virtio_input: Constify id_table
  virtio-mem: Constify mem_id_table

Stefano Garzarella (1):
  vringh: fix __vringh_iov() when riov and wiov are different

Tian Tao (1):
  vhost_vdpa: Fix duplicate included kernel.h

Zhu Lingshan (1):
  vhost_vdpa: remove unnecessary spin_lock in vhost_vring_call

 MAINTAINERS   |  1 +
 arch/s390/Kconfig |  1 +
 arch/s390/mm/init.c   | 11 +++
 drivers/vdpa/mlx5/net/mlx5_vnet.c | 12 ++--
 drivers/vhost/vdpa.c  |  9 +
 drivers/vhost/vhost.c |  5 +
 drivers/vhost/vhost.h |  2 +-
 drivers/vhost/vringh.c|  9 +
 drivers/virtio/Kconfig|  6 ++
 drivers/virtio/virtio.c   | 15 +++
 drivers/virtio/virtio_balloon.c   |  2 +-
 drivers/virtio/virtio_input.c |  2 +-
 drivers/virtio/virtio_mem.c   |  2 +-
 include/linux/virtio_config.h | 10 ++
 14 files changed, 65 insertions(+), 22 deletions(-)

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 14/16] vhost: poll support support multiple workers

2020-10-23 Thread Michael S. Tsirkin

On Thu, Oct 08, 2020 at 08:46:42AM +0800, kernel test robot wrote:
> Hi Mike,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on vhost/linux-next]
> [also build test ERROR on next-20201007]
> [cannot apply to v5.9-rc8]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:
> https://github.com/0day-ci/linux/commits/Mike-Christie/vhost-fix-scsi-cmd-handling-and-IOPs/20201008-045802
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
> linux-next
> config: m68k-allyesconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://github.com/0day-ci/linux/commit/c9bcafefcac3c32ade0ba533609d7b1ddc343c54
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Mike-Christie/vhost-fix-scsi-cmd-handling-and-IOPs/20201008-045802
> git checkout c9bcafefcac3c32ade0ba533609d7b1ddc343c54
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
> ARCH=m68k 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
> >> m68k-linux-ld: drivers/vhost/scsi.o:(.bss+0x0): multiple definition of 
> >> `vq'; drivers/vhost/net.o:(.bss+0x0): first defined here
>m68k-linux-ld: drivers/vhost/vsock.o:(.bss+0x0): multiple definition of 
> `vq'; drivers/vhost/net.o:(.bss+0x0): first defined here
>m68k-linux-ld: drivers/vhost/vdpa.o:(.bss+0x0): multiple definition of 
> `vq'; drivers/vhost/net.o:(.bss+0x0): first defined here
>m68k-linux-ld: drivers/vhost/vhost.o:(.bss+0x0): multiple definition of 
> `vq'; drivers/vhost/net.o:(.bss+0x0): first defined here

Mike, what's going on with these failures?
Can you figure it out pls?

> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 00/16 V2] vhost: fix scsi cmd handling and IOPs

2020-10-23 Thread Michael S. Tsirkin

On Wed, Oct 07, 2020 at 03:54:45PM -0500, Mike Christie wrote:
> The following patches were made over Michael's vhost branch here:
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/log/?h=vhost
>  
> The patches also apply to Linus's or Martin's trees if you apply
> https://patchwork.kernel.org/patch/11790681/
> which was merged into mst's tree already.
> 
> The following patches are a follow up to this post:
> https://patchwork.kernel.org/cover/11790763/
> which originally was fixing how vhost-scsi handled cmds so we would
> not get IO errors when sending more than 256 cmds.
> 
> In that patchset I needed to detect if a vq was in use and for this
> patch:
> https://patchwork.kernel.org/patch/11790685/
> it was suggested to add support for VHOST_RING_ENABLE. While doing
> that though I hit a couple problems:
> 
> 1. The patches moved how vhost-scsi allocated cmds from per lio
> session to per vhost vq. To support both VHOST_RING_ENABLE and
> where userspace didn't support it, I would have to keep around the
> old per session/device cmd allocator/completion and then also maintain
> the new code. Or, I would still have to use this patch
> patchwork.kernel.org/cover/11790763/ for the compat case so there
> adding the new ioctl would not help much.
> 
> 2. For vhost-scsi I also wanted to prevent where we allocate iovecs
> for 128 vqs even though we normally use a couple. To do this, I needed
> something similar to #1, but the problem is that the VHOST_RING_ENABLE
> call would come too late.
> 
> To try and balance #1 and #2, these patches just allow vhost-scsi
> to setup a vq when userspace starts to config it. This allows the
> driver to only fully setup (we still waste some memory to support older
> setups but do not have to preallocate everything like before) what
> is used plus I do not need to maintain 2 code paths.
> 
> Note that in this posting I am also including additional patches
> that create multiple vhost worker threads, because I wanted to see
> if people felt that maybe to support that and for this enablement
> issue we want a completely a new ioctl.
> 
> 
> V2:
> - fix use before set cpu var errors
> - drop vhost_vq_is_setup
> - include patches to do a worker thread per scsi IO vq

Stefan, Paolo, Jason any input?

-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

2020-10-23 Thread Michael S. Tsirkin

On Fri, Oct 23, 2020 at 11:00:54AM +0200, Sebastian Hofmann wrote:
> > Michael S. Tsirkin  hat am 22.10.2020 13:39 geschrieben:
> > 
> >  
> > On Wed, Oct 21, 2020 at 05:14:25PM +0200, Sebastian Hofmann wrote:
> > > virtio_ring does not work with active memory encryption because the host 
> > > cannot read it. Fix this by enforcing the use of DMA which uses shared 
> > > (unencrypted) memory pages.
> > > 
> > > Signed-off-by: Sebastian Hofmann 
> > 
> > 
> > Sorry, no.
> > host which can not access all of driver memory must set 
> > VIRTIO_F_ACCESS_PLATFORM.
> > 
> > Not worth it to work around broken hosts.
> > 
> > Xen is an exception we carry around since it predates the
> > introduction of VIRTIO_F_ACCESS_PLATFORM.
> > 
> > 
> 
> Thanks for pointing out VIRTIO_F_ACCESS_PLATFORM which I was not aware of. 
> Maybe that patch was a bit naÃ¯ve.
> 
> Basically I'm looking for a way to use vsock with qemu on AMD SEV. When I try 
> to use IOMMU for vsock I get an EOPNOTSUPP out of vhost_vsock_set_features.
> 
> Is there a reason why vhost_vsock_set_features doesn't use 
> vhost_init_device_iotlb as done in the net device? Because that would have 
> been my next attempt.
> I would appreciate a short comment on this idea or a recommendation for 
> another solution that is better than the patch below.

Not sure I understand the problem. Are you using qemu? If so just add
iommu_platform=on and you are done.


> > > ---
> > >  drivers/virtio/virtio_ring.c | 5 +
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > index becc77697960..8c68c475ec21 100644
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -12,6 +12,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  #ifdef DEBUG
> > >  /* For development, we want to crash whenever the ring is screwed. */
> > > @@ -255,6 +256,10 @@ static bool vring_use_dma_api(struct virtio_device 
> > > *vdev)
> > >   if (xen_domain())
> > >   return true;
> > >  
> > > + /* Memory encryption requires DMA */
> > > + if (mem_encrypt_active())
> > > + return true;
> > > +
> > >   return false;
> > >  }
> > >  
> > > -- 
> > > 2.25.1

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 04/16] vhost: prep vhost_dev_init users to handle failures

2020-10-23 Thread Michael S. Tsirkin

On Fri, Oct 09, 2020 at 02:41:26PM +0300, Dan Carpenter wrote:
> Hi Mike,
> 
> url:
> https://github.com/0day-ci/linux/commits/Mike-Christie/vhost-fix-scsi-cmd-handling-and-IOPs/20201008-045802
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
> linux-next
> config: x86_64-randconfig-m001-20201008 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> Reported-by: Dan Carpenter 
> 
> New smatch warnings:
> drivers/vhost/vdpa.c:844 vhost_vdpa_open() error: uninitialized symbol 'r'.
> 
> Old smatch warnings:
> drivers/vhost/vdpa.c:436 vhost_vdpa_unlocked_ioctl() warn: maybe return 
> -EFAULT instead of the bytes remaining?
> drivers/vhost/vdpa.c:489 vhost_vdpa_unlocked_ioctl() warn: maybe return 
> -EFAULT instead of the bytes remaining?
> 
> vim +/r +844 drivers/vhost/vdpa.c
> 
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  793  static int 
> vhost_vdpa_open(struct inode *inode, struct file *filep)
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  794  {
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  795 struct vhost_vdpa *v;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  796 struct vhost_dev *dev;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  797 struct vhost_virtqueue 
> **vqs;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  798 int nvqs, i, r, opened;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  799  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  800 v = 
> container_of(inode->i_cdev, struct vhost_vdpa, cdev);
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  801  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  802 opened = 
> atomic_cmpxchg(&v->opened, 0, 1);
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  803 if (opened)
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  804 return -EBUSY;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  805  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  806 nvqs = v->nvqs;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  807 vhost_vdpa_reset(v);
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  808  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  809 vqs = 
> kmalloc_array(nvqs, sizeof(*vqs), GFP_KERNEL);
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  810 if (!vqs) {
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  811 r = -ENOMEM;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  812 goto err;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  813 }
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  814  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  815 dev = &v->vdev;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  816 for (i = 0; i < nvqs; 
> i++) {
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  817 vqs[i] = 
> &v->vqs[i];
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  818 
> vqs[i]->handle_kick = handle_vq_kick;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  819 }
> 7dc4d1082d406f3 Mike Christie 2020-10-07  820 if (vhost_dev_init(dev, 
> vqs, nvqs, 0, 0, 0, false,
> 7dc4d1082d406f3 Mike Christie 2020-10-07  821
> vhost_vdpa_process_iotlb_msg))
> 7dc4d1082d406f3 Mike Christie 2020-10-07  822 goto 
> err_dev_init;
> 
> "r" not set on this error path.
> 
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  823  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  824 dev->iotlb = 
> vhost_iotlb_alloc(0, 0);
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  825 if (!dev->iotlb) {
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  826 r = -ENOMEM;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  827 goto 
> err_init_iotlb;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  828 }
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  829  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  830 r = 
> vhost_vdpa_alloc_domain(v);
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  831 if (r)
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  832 goto 
> err_init_iotlb;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  833  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  834 filep->private_data = v;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  835  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  836 return 0;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  837  
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  838  err_init_iotlb:
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  839 
> vhost_dev_cleanup(&v->vdev);
> 7dc4d1082d406f3 Mike Christie 2020-10-07  840  err_dev_init:
> 37787e9f81e2e58 Mike Christie 2020-09-21  841 kfree(vqs);
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  842  err:
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  843 atomic_dec(&v->opened);
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26 @844 return r;
> 4c8cf31885f69e8 Tiwei Bie 2020-03-26  845  }


Yes looks like it would use r uninitialized ...
Mike?

> ---
> 0-DAY CI Kernel Test Service, I

[PATCH] drm/: Constify struct drm_driver

2020-10-23 Thread Daniel Vetter

Only the following drivers aren't converted:
- amdgpu, because of the driver_feature mangling due to virt support
- nouveau, because DRIVER_ATOMIC uapi is still not the default on the
  platforms where it's supported (i.e. again driver_feature mangling)
- vc4, again because of driver_feature mangling
- qxl, because the ioctl table is somewhere else and moving that is
  maybe a bit too much, hence the num_ioctls assignment prevents a
  const driver structure.

Note that for armada I also went ahead and made the ioctl array const.

Only cc'ing the driver people who've not been converted (everyone else
is way too much).

v2: Fix one misplaced const static, should be static const (0day)

Cc: kernel test robot 
Acked-by: Maxime Ripard 
Signed-off-by: Daniel Vetter 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: virtualization@lists.linux-foundation.org
Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Eric Anholt 
Cc: Maxime Ripard 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c  | 2 +-
 drivers/gpu/drm/arm/hdlcd_drv.c  | 2 +-
 drivers/gpu/drm/arm/malidp_drv.c | 2 +-
 drivers/gpu/drm/armada/armada_drv.c  | 7 +++
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c  | 2 +-
 drivers/gpu/drm/ast/ast_drv.c| 2 +-
 drivers/gpu/drm/ast/ast_drv.h| 2 +-
 drivers/gpu/drm/ast/ast_main.c   | 2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
 drivers/gpu/drm/bochs/bochs_drv.c| 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  | 2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++---
 drivers/gpu/drm/gma500/psb_drv.c | 4 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 2 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 2 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h  | 2 +-
 drivers/gpu/drm/i915/i915_drv.c  | 4 ++--
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
 drivers/gpu/drm/imx/dcss/dcss-kms.c  | 2 +-
 drivers/gpu/drm/imx/imx-drm-core.c   | 2 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +-
 drivers/gpu/drm/lima/lima_drv.c  | 2 +-
 drivers/gpu/drm/mcde/mcde_drv.c  | 2 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   | 2 +-
 drivers/gpu/drm/meson/meson_drv.c| 2 +-
 drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +-
 drivers/gpu/drm/msm/msm_drv.c| 4 ++--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   | 2 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c  | 2 +-
 drivers/gpu/drm/pl111/pl111_drv.c| 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c  | 4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  | 4 ++--
 drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
 drivers/gpu/drm/sti/sti_drv.c| 2 +-
 drivers/gpu/drm/stm/drv.c| 2 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +-
 drivers/gpu/drm/tegra/drm.c  | 5 ++---
 drivers/gpu/drm/tidss/tidss_drv.c| 2 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 4 ++--
 drivers/gpu/drm/tiny/cirrus.c| 2 +-
 drivers/gpu/drm/tiny/gm12u320.c  | 2 +-
 drivers/gpu/drm/tiny/hx8357d.c   | 2 +-
 drivers/gpu/drm/tiny/ili9225.c   | 2 +-
 drivers/gpu/drm/tiny/ili9341.c   | 2 +-
 drivers/gpu/drm/tiny/ili9486.c   | 2 +-
 drivers/gpu/drm/tiny/mi0283qt.c  | 2 +-
 drivers/gpu/drm/tiny/repaper.c   | 2 +-
 drivers/gpu/drm/tiny/st7586.c| 2 +-
 drivers/gpu/drm/tiny/st7735r.c   | 2 +-
 drivers/gpu/drm/tve200/tve200_drv.c  | 2 +-
 drivers/gpu/drm/udl/udl_drv.c| 2 +-
 drivers/gpu/drm/v3d/v3d_drv.c| 2 +-
 drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++--
 drivers/gpu/drm/vgem/vgem_drv.c  | 2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++--
 drivers/gpu/drm/vkms/vkms_drv.c  | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  | 2 +-
 drivers/gpu/drm/xen/xen_drm_front.c  | 2 +-
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c  | 2 +-
 drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
 63 files changed, 75 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index cc5b5915bc5e..d04008f3e31a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -58,7 +58,7 @@ stati

Re: [GIT PULL] vhost,vdpa,virtio: cleanups, fixes

2020-10-23 Thread pr-tracker-bot

The pull request you sent on Fri, 23 Oct 2020 11:38:32 -0400:

> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9313f8026328d0309d093f6774be4b8f5340c0e5

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [External] Re: [RFC 0/4] Introduce VDUSE - vDPA Device in Userspace

Re: [PATCH V3 2/3] vhost: vdpa: report iova range

[PATCH V4 2/3] vhost: vdpa: report iova range

[PATCH V4 0/3] vDPA: API for reporting IOVA range

[PATCH V4 3/3] vdpa_sim: implement get_iova_range()

[PATCH V4 1/3] vdpa: introduce config op to get valid iova range

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

[PATCH net] vhost_vdpa: Return -EFUALT if copy_from_user() fails

[PATCH 5/5] drm/: Constify struct drm_driver

Re: [Intel-gfx] [PATCH 5/5] drm/: Constify struct drm_driver

Re: [PATCH net] vhost_vdpa: Return -EFUALT if copy_from_user() fails

[GIT PULL] vhost,vdpa,virtio: cleanups, fixes

Re: [PATCH 14/16] vhost: poll support support multiple workers

Re: [PATCH 00/16 V2] vhost: fix scsi cmd handling and IOPs

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

Re: [PATCH 04/16] vhost: prep vhost_dev_init users to handle failures

[PATCH] drm/: Constify struct drm_driver

Re: [GIT PULL] vhost,vdpa,virtio: cleanups, fixes

20 matches

Site Navigation

Mail list logo

Footer information