Re: [PATCH] virtio_balloon: clear modern features under legacy

2020-07-12 Thread Jason Wang 


On 2020/7/10 下午7:31, Michael S. Tsirkin wrote:

Page reporting features were never supported by legacy hypervisors.
Supporting them poses a problem: should we use native endian-ness (like
current code assumes)? Or little endian-ness like the virtio spec says?
Rather than try to figure out, and since results of
incorrect endian-ness are dire, let's just block this configuration.

Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
---
  drivers/virtio/virtio_balloon.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 5d4b891bf84f..b9bc03345157 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -1107,6 +1107,15 @@ static int virtballoon_restore(struct virtio_device 
*vdev)
  
  static int virtballoon_validate(struct virtio_device *vdev)

  {
+   /*
+* Legacy devices never specified how modern features should behave.
+* E.g. which endian-ness to use? Better not to assume anything.
+*/
+   if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
+   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
+   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_REPORTING);
+   }
/*
 * Inform the hypervisor that our pages are poisoned or
 * initialized. If we cannot do that then we should disable



Acked-by: Jason Wang 


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

Re: [PATCH] virtio_ring: sparse warning fixup

2020-07-12 Thread Jason Wang 


On 2020/7/10 下午6:49, Michael S. Tsirkin wrote:

virtio_store_mb was built with split ring in mind so it accepts
__virtio16 arguments. Packed ring uses __le16 values, so sparse
complains.  It's just a store with some barriers so let's convert it to
a macro, we don't loose too much type safety by doing that.

Signed-off-by: Michael S. Tsirkin 
---
  include/linux/virtio_ring.h | 19 +--
  1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 3dc70adfe5f5..b485b13fa50b 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -46,16 +46,15 @@ static inline void virtio_wmb(bool weak_barriers)
dma_wmb();
  }
  
-static inline void virtio_store_mb(bool weak_barriers,

-  __virtio16 *p, __virtio16 v)
-{
-   if (weak_barriers) {
-   virt_store_mb(*p, v);
-   } else {
-   WRITE_ONCE(*p, v);
-   mb();
-   }
-}
+#define virtio_store_mb(weak_barriers, p, v) \
+do { \
+   if (weak_barriers) { \
+   virt_store_mb(*p, v); \
+   } else { \
+   WRITE_ONCE(*p, v); \
+   mb(); \
+   } \
+} while (0) \
  
  struct virtio_device;

  struct virtqueue;



Acked-by: Jason Wang 


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

Re: [PATCH] vhost/scsi: fix up req type endian-ness

2020-07-12 Thread Jason Wang 


On 2020/7/10 下午6:48, Michael S. Tsirkin wrote:

vhost/scsi doesn't handle type conversion correctly
for request type when using virtio 1.0 and up for BE,
or cross-endian platforms.

Fix it up using vhost_32_to_cpu.

Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
---
  drivers/vhost/scsi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 6fb4d7ecfa19..b22adf03f584 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1215,7 +1215,7 @@ vhost_scsi_ctl_handle_vq(struct vhost_scsi *vs, struct 
vhost_virtqueue *vq)
continue;
}
  
-		switch (v_req.type) {

+   switch (vhost32_to_cpu(vq, v_req.type)) {
case VIRTIO_SCSI_T_TMF:
vc.req = _req.tmf;
vc.req_size = sizeof(struct virtio_scsi_ctrl_tmf_req);



Acked-by: Jason Wang 


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

Re: [PATCH] virtio_balloon: fix sparse warning

2020-07-12 Thread Jason Wang 


On 2020/7/10 下午6:48, Michael S. Tsirkin wrote:

balloon uses virtio32_to_cpu instead of cpu_to_virtio32
to convert a native endian number to virtio.
No practical difference but makes sparse warn.
Fix it up.

Signed-off-by: Michael S. Tsirkin 
---
  drivers/virtio/virtio_balloon.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index fc7301406540..5d4b891bf84f 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -596,7 +596,7 @@ static int send_cmd_id_start(struct virtio_balloon *vb)
while (virtqueue_get_buf(vq, ))
;
  
-	vb->cmd_id_active = virtio32_to_cpu(vb->vdev,

+   vb->cmd_id_active = cpu_to_virtio32(vb->vdev,
virtio_balloon_cmd_id_received(vb));
sg_init_one(, >cmd_id_active, sizeof(vb->cmd_id_active));
err = virtqueue_add_outbuf(vq, , 1, >cmd_id_active, GFP_KERNEL);



Acked-by: Jason Wang 


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

RE: [PATCH] xen: introduce xen_vring_use_dma

2020-07-12 Thread Peng Fan 
> Subject: Re: [PATCH] xen: introduce xen_vring_use_dma
> 
> Sorry for the late reply -- a couple of conferences kept me busy.
> 
> 
> On Wed, 1 Jul 2020, Michael S. Tsirkin wrote:
> > On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> > > Would you be in favor of a more flexible check along the lines of
> > > the one proposed in the patch that started this thread:
> > >
> > > if (xen_vring_use_dma())
> > > return true;
> > >
> > >
> > > xen_vring_use_dma would be implemented so that it returns true when
> > > xen_swiotlb is required and false otherwise.
> >
> > Just to stress - with a patch like this virtio can *still* use DMA API
> > if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms
> > as you seem to be saying, you guys should fix it before doing
> > something like this..
> 
> Yes, DMA API is broken with some interfaces (specifically: rpmesg and trusty),
> but for them PLATFORM_ACCESS is never set. That is why the errors weren't
> reported before. Xen special case aside, there is no problem under normal
> circumstances.
> 
> 
> If you are OK with this patch (after a little bit of clean-up), Peng, are you 
> OK
> with sending an update or do you want me to?

If you could help, that would be great. You have more expertise in knowing
the whole picture.

Thanks,
Peng.

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

Re: [PATCH 2/7] kvm/vfio: detect assigned device via irqbypass manager

2020-07-12 Thread Michael S. Tsirkin 
On Sun, Jul 12, 2020 at 10:49:21PM +0800, Zhu Lingshan wrote:
> We used to detect assigned device via VFIO manipulated device
> conters. This is less flexible consider VFIO is not the only
> interface for assigned device. vDPA devices has dedicated
> backed hardware as well. So this patch tries to detect
> the assigned device via irqbypass manager.
> 
> We will increase/decrease the assigned device counter in kvm/x86.
> Both vDPA and VFIO would go through this code path.
> 
> This code path only affect x86 for now.
> 
> Signed-off-by: Zhu Lingshan 


I think it's best to leave VFIO alone. Add appropriate APIs for VDPA,
worry about converting existing users later.

> ---
>  arch/x86/kvm/x86.c | 10 --
>  virt/kvm/vfio.c|  2 --
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 00c88c2..20c07d3 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10624,11 +10624,17 @@ int kvm_arch_irq_bypass_add_producer(struct 
> irq_bypass_consumer *cons,
>  {
>   struct kvm_kernel_irqfd *irqfd =
>   container_of(cons, struct kvm_kernel_irqfd, consumer);
> + int ret;
>  
>   irqfd->producer = prod;
> + kvm_arch_start_assignment(irqfd->kvm);
> + ret = kvm_x86_ops.update_pi_irte(irqfd->kvm,
> +  prod->irq, irqfd->gsi, 1);
> +
> + if (ret)
> + kvm_arch_end_assignment(irqfd->kvm);
>  
> - return kvm_x86_ops.update_pi_irte(irqfd->kvm,
> -prod->irq, irqfd->gsi, 1);
> + return ret;
>  }
>  
>  void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index 8fcbc50..111da52 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -226,7 +226,6 @@ static int kvm_vfio_set_group(struct kvm_device *dev, 
> long attr, u64 arg)
>   list_add_tail(>node, >group_list);
>   kvg->vfio_group = vfio_group;
>  
> - kvm_arch_start_assignment(dev->kvm);
>  
>   mutex_unlock(>lock);
>  
> @@ -254,7 +253,6 @@ static int kvm_vfio_set_group(struct kvm_device *dev, 
> long attr, u64 arg)
>   continue;
>  
>   list_del(>node);
> - kvm_arch_end_assignment(dev->kvm);
>  #ifdef CONFIG_SPAPR_TCE_IOMMU
>   kvm_spapr_tce_release_vfio_group(dev->kvm,
>kvg->vfio_group);
> -- 
> 1.8.3.1

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

[vhost:config-endian 38/39] drivers/platform/mellanox/mlxbf-tmfifo.c:1237:2: error: invalid preprocessing directive #defined; did you mean

2020-07-12 Thread kernel test robot 
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
config-endian
head:   d8ede9b5e734748613d3e3108a4026244aa8e41f
commit: 392755e77e260e8a173b228e8ecc17917f97d5eb [38/39] fixup! virtio_net: 
correct tags for config space fields
config: arm64-allyesconfig (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
git checkout 392755e77e260e8a173b228e8ecc17917f97d5eb
# 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 errors (new ones prefixed by >>):

   drivers/platform/mellanox/mlxbf-tmfifo.c: In function 'mlxbf_tmfifo_probe':
>> drivers/platform/mellanox/mlxbf-tmfifo.c:1237:2: error: invalid 
>> preprocessing directive #defined; did you mean #define?
1237 | #defined MLXBF_TMFIFO_LITTLE_ENDIAN 
(virtio_legacy_is_little_endian() ||
 |  ^~~
 |  define
   drivers/platform/mellanox/mlxbf-tmfifo.c:1238:4: warning: statement with no 
effect [-Wunused-value]
1238 |(MLXBF_TMFIFO_NET_FEATURES & (1ULL << VIRTIO_F_VERSION_1)))
 |^
>> drivers/platform/mellanox/mlxbf-tmfifo.c:1238:62: error: expected ';' before 
>> ')' token
1238 |(MLXBF_TMFIFO_NET_FEATURES & (1ULL << VIRTIO_F_VERSION_1)))
 |  ^
 |  ;
>> drivers/platform/mellanox/mlxbf-tmfifo.c:1238:62: error: expected statement 
>> before ')' token
>> drivers/platform/mellanox/mlxbf-tmfifo.c:1240:37: error: 
>> 'MLXBF_TMFIFO_LITTLE_ENDIAN' undeclared (first use in this function); did 
>> you mean 'MLXBF_TMFIFO_NET_L2_OVERHEAD'?
1240 |  net_config.mtu = __cpu_to_virtio16(MLXBF_TMFIFO_LITTLE_ENDIAN,
 | ^~
 | MLXBF_TMFIFO_NET_L2_OVERHEAD
   drivers/platform/mellanox/mlxbf-tmfifo.c:1240:37: note: each undeclared 
identifier is reported only once for each function it appears in

vim +1237 drivers/platform/mellanox/mlxbf-tmfifo.c

  1181  
  1182  /* Probe the TMFIFO. */
  1183  static int mlxbf_tmfifo_probe(struct platform_device *pdev)
  1184  {
  1185  struct virtio_net_config net_config;
  1186  struct device *dev = >dev;
  1187  struct mlxbf_tmfifo *fifo;
  1188  int i, rc;
  1189  
  1190  fifo = devm_kzalloc(dev, sizeof(*fifo), GFP_KERNEL);
  1191  if (!fifo)
  1192  return -ENOMEM;
  1193  
  1194  spin_lock_init(>spin_lock[0]);
  1195  spin_lock_init(>spin_lock[1]);
  1196  INIT_WORK(>work, mlxbf_tmfifo_work_handler);
  1197  mutex_init(>lock);
  1198  
  1199  /* Get the resource of the Rx FIFO. */
  1200  fifo->rx_base = devm_platform_ioremap_resource(pdev, 0);
  1201  if (IS_ERR(fifo->rx_base))
  1202  return PTR_ERR(fifo->rx_base);
  1203  
  1204  /* Get the resource of the Tx FIFO. */
  1205  fifo->tx_base = devm_platform_ioremap_resource(pdev, 1);
  1206  if (IS_ERR(fifo->tx_base))
  1207  return PTR_ERR(fifo->tx_base);
  1208  
  1209  platform_set_drvdata(pdev, fifo);
  1210  
  1211  timer_setup(>timer, mlxbf_tmfifo_timer, 0);
  1212  
  1213  for (i = 0; i < MLXBF_TM_MAX_IRQ; i++) {
  1214  fifo->irq_info[i].index = i;
  1215  fifo->irq_info[i].fifo = fifo;
  1216  fifo->irq_info[i].irq = platform_get_irq(pdev, i);
  1217  rc = devm_request_irq(dev, fifo->irq_info[i].irq,
  1218mlxbf_tmfifo_irq_handler, 0,
  1219"tmfifo", >irq_info[i]);
  1220  if (rc) {
  1221  dev_err(dev, "devm_request_irq failed\n");
  1222  fifo->irq_info[i].irq = 0;
  1223  return rc;
  1224  }
  1225  }
  1226  
  1227  mlxbf_tmfifo_set_threshold(fifo);
  1228  
  1229  /* Create the console vdev. */
  1230  rc = mlxbf_tmfifo_create_vdev(dev, fifo, VIRTIO_ID_CONSOLE, 0, 
NULL, 0);
  1231  if (rc)
  1232  goto fail;
  1233  
  1234  /* Create the network vdev. */
  1235  memset(_config, 0, sizeof(net_config));
  1236  
> 1237  #defined MLXBF_TMFIFO_LITTLE_ENDIAN (virtio_legacy_is_little_endian() ||
> 1238  (MLXBF_TMFIFO_NET_FEATURES & (1ULL << 
> VIRTIO_F_VERSION_1)))
  1239  
> 1240  net_config.mtu = __cpu_to_virtio16(MLXBF_TMFIFO_LITTLE_ENDIAN,
  1241

Re: [PATCH 2/7] kvm/vfio: detect assigned device via irqbypass manager

2020-07-12 Thread Alex Williamson 
On Sun, 12 Jul 2020 22:49:21 +0800
Zhu Lingshan  wrote:

> We used to detect assigned device via VFIO manipulated device
> conters. This is less flexible consider VFIO is not the only
> interface for assigned device. vDPA devices has dedicated
> backed hardware as well. So this patch tries to detect
> the assigned device via irqbypass manager.
> 
> We will increase/decrease the assigned device counter in kvm/x86.
> Both vDPA and VFIO would go through this code path.
> 
> This code path only affect x86 for now.

No it doesn't, it only adds VFIO support to x86, but it removes it from
architecture neutral code.  Also a VFIO device does not necessarily
make use of the irqbypass manager, this depends on platform support and
enablement of this feature.   Therefore, NAK.  Thanks,

Alex
 
> Signed-off-by: Zhu Lingshan 
> ---
>  arch/x86/kvm/x86.c | 10 --
>  virt/kvm/vfio.c|  2 --
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 00c88c2..20c07d3 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10624,11 +10624,17 @@ int kvm_arch_irq_bypass_add_producer(struct 
> irq_bypass_consumer *cons,
>  {
>   struct kvm_kernel_irqfd *irqfd =
>   container_of(cons, struct kvm_kernel_irqfd, consumer);
> + int ret;
>  
>   irqfd->producer = prod;
> + kvm_arch_start_assignment(irqfd->kvm);
> + ret = kvm_x86_ops.update_pi_irte(irqfd->kvm,
> +  prod->irq, irqfd->gsi, 1);
> +
> + if (ret)
> + kvm_arch_end_assignment(irqfd->kvm);
>  
> - return kvm_x86_ops.update_pi_irte(irqfd->kvm,
> -prod->irq, irqfd->gsi, 1);
> + return ret;
>  }
>  
>  void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index 8fcbc50..111da52 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -226,7 +226,6 @@ static int kvm_vfio_set_group(struct kvm_device *dev, 
> long attr, u64 arg)
>   list_add_tail(>node, >group_list);
>   kvg->vfio_group = vfio_group;
>  
> - kvm_arch_start_assignment(dev->kvm);
>  
>   mutex_unlock(>lock);
>  
> @@ -254,7 +253,6 @@ static int kvm_vfio_set_group(struct kvm_device *dev, 
> long attr, u64 arg)
>   continue;
>  
>   list_del(>node);
> - kvm_arch_end_assignment(dev->kvm);
>  #ifdef CONFIG_SPAPR_TCE_IOMMU
>   kvm_spapr_tce_release_vfio_group(dev->kvm,
>kvg->vfio_group);

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

Re: [PATCH] virtio_balloon: clear modern features under legacy

2020-07-12 Thread Michael S. Tsirkin 
On Fri, Jul 10, 2020 at 09:13:41AM -0700, Alexander Duyck wrote:
> On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin  wrote:
> >
> > Page reporting features were never supported by legacy hypervisors.
> > Supporting them poses a problem: should we use native endian-ness (like
> > current code assumes)? Or little endian-ness like the virtio spec says?
> > Rather than try to figure out, and since results of
> > incorrect endian-ness are dire, let's just block this configuration.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Michael S. Tsirkin 
> 
> So I am not sure about the patch description. In the case of page
> poison and free page reporting I don't think we are defining anything
> that doesn't already have a definition of how to use in legacy.
> Specifically the virtio_balloon_config is already defined as having
> all fields as little endian in legacy mode, and there is a definition
> for all of the fields in a virtqueue and how they behave in legacy
> mode.
> 
> As far as I can see the only item that may be an issue is the command
> ID being supplied via the virtqueue for free page hinting, which
> appears to be in native endian-ness. Otherwise it would have fallen
> into the same category since it is making use of virtio_balloon_config
> and a virtqueue for supplying the page location and length.



So as you point out correctly balloon spec says all fields are little
endian.  Fair enough.
Problem is when virtio 1 is not negotiated, then this is not what the
driver assumes for any except a handlful of fields.

But yes it mostly works out.

For example:


static void update_balloon_size(struct virtio_balloon *vb)
{
u32 actual = vb->num_pages;

/* Legacy balloon config space is LE, unlike all other devices. */
if (!virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1))
actual = (__force u32)cpu_to_le32(actual);

virtio_cwrite(vb->vdev, struct virtio_balloon_config, actual,
  );
}


this is LE even without VIRTIO_F_VERSION_1, so matches spec.

/* Start with poison val of 0 representing general init */
__u32 poison_val = 0;

/*
 * Let the hypervisor know that we are expecting a
 * specific value to be written back in balloon pages.
 */
if (!want_init_on_free())
memset(_val, PAGE_POISON, sizeof(poison_val));

virtio_cwrite(vb->vdev, struct virtio_balloon_config,
  poison_val, _val);


actually this writes a native endian-ness value. All bytes happen to be
the same though, and host only cares about 0 or non 0 ATM.

As you say correctly the command id is actually assumed native endian:


static u32 virtio_balloon_cmd_id_received(struct virtio_balloon *vb)
{
if (test_and_clear_bit(VIRTIO_BALLOON_CONFIG_READ_CMD_ID,
   >config_read_bitmap))
virtio_cread(vb->vdev, struct virtio_balloon_config,
 free_page_hint_cmd_id,
 >cmd_id_received_cache);

return vb->cmd_id_received_cache;
}


So guest assumes native, host assumes LE.




> > ---
> >  drivers/virtio/virtio_balloon.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/virtio/virtio_balloon.c 
> > b/drivers/virtio/virtio_balloon.c
> > index 5d4b891bf84f..b9bc03345157 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -1107,6 +1107,15 @@ static int virtballoon_restore(struct virtio_device 
> > *vdev)
> >
> >  static int virtballoon_validate(struct virtio_device *vdev)
> >  {
> > +   /*
> > +* Legacy devices never specified how modern features should behave.
> > +* E.g. which endian-ness to use? Better not to assume anything.
> > +*/
> > +   if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> > +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
> > +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> > +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_REPORTING);
> > +   }
> > /*
> >  * Inform the hypervisor that our pages are poisoned or
> >  * initialized. If we cannot do that then we should disable
> 
> The patch content itself I am fine with since odds are nobody would
> expect to use these features with a legacy device.
> 
> Acked-by: Alexander Duyck 

Hmm so now you pointed out it's just cmd id, maybe I should just fix it
instead? what do you say?

-- 
MST

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

ICITS'21 - 4th Int. Conference on Information Technology & Systems, Santa Elena, Ecuador

2020-07-12 Thread Maria 
* Published by Springer, in a book of the AISC series
** Indexed in Scopus, ISI, DBLP, Ei-Compendex, etc


--   --   ---
ICITS'21 - 4th International Conference on Information Technology & Systems
4 - 6 February 2021 | Peninsula de Santa Elena, Ecuador
http://www.icits.me/ 

--   --   
-

ICITS'21 - The 2021 International Conference on Information Technology & 
Systems, to be held in Península de Santa Elena, Ecuador, 4 - 6 February 2021, 
is an international forum for researchers and practitioners to present and 
discuss the most recent innovations, trends, results, experiences and concerns 
in the several perspectives of Information Technology & Systems.

We are pleased to invite you to submit your papers to ICITS'21. They can be 
written in English, Spanish or Portuguese. All submissions will be reviewed on 
the basis of relevance, originality, importance and clarity.





TOPICS


Submitted papers should be related with one or more of the main themes proposed 
for the Conference:

A) Information and Knowledge Management (IKM);
B) Organizational Models and Information Systems (OMIS);
C) Software and Systems Modeling (SSM);
D) Software Systems, Architectures, Applications and Tools (SSAAT);
E) Multimedia Systems and Applications (MSA);
F) Computer Networks, Mobility and Pervasive Systems (CNMPS);
G) Intelligent and Decision Support Systems (IDSS);
H) Big Data Analytics and Applications (BDAA);
I) Human-Computer Interaction (HCI);
J) Ethics, Computers and Security (ECS)
K) Health Informatics (HIS);
L) Information Technologies in Education (ITE);


SUBMISSION AND DECISION

Submitted papers written in English (until 10-page limit) must comply with the 
format of Advances in Intelligent Systems and Computing series (see 
Instructions for Authors at Springer Website), must not have been published 
before, not be under review for any other conference or publication and not 
include any information leading to the authors’ identification. Therefore, the 
authors’ names and affiliations should not be included in the version for 
evaluation by the Scientific Committee. This information should only be 
included in the camera-ready version, saved in Word or Latex format and also in 
PDF format. These files must be accompanied by the Consent to Publish form 
filled out, in a ZIP file, and uploaded at the conference management system.

Submitted papers written in Spanish or Portuguese (until 15-page limit) must 
comply with the format of RISTI - Revista Ibérica de Sistemas e Tecnologias de 
Informação (download instructions/template for authors in Spanish or 
Portuguese), must not have been published before, not be under review for any 
other conference or publication and not include any information leading to the 
authors’ identification. Therefore, the authors’ names and affiliations should 
not be included in the version for evaluation by the Scientific Committee. This 
information should only be included in the camera-ready version, saved in Word. 
These files must be uploaded at the conference management system in a ZIP file.

All papers will be subjected to a “double-blind review” by at least two members 
of the Scientific Committee.

Based on Scientific Committee evaluation, a paper can be rejected or accepted 
by the Conference Chairs. In the later case, it can be accepted as paper or 
poster.

The authors of papers accepted as posters must build and print a poster to be 
exhibited during the Conference. This poster must follow an A1 or A2 vertical 
format. The Conference can include Work Sessions where these posters are 
presented and orally discussed, with a 7 minute limit per poster.

The authors of accepted papers will have 15 minutes to present their work in a 
Conference Work Session; approximately 5 minutes of discussion will follow each 
presentation.


PUBLICATION AND INDEXING

Papers accepted as posters are not published; they are only exhibited, 
presented and discussed during the conference.

To ensure that a paper accepted as paper is published, at least one of the 
authors must be fully registered by the 6th of November 2020, and the paper 
must comply with the suggested layout and page-limit. Additionally, all 
recommended changes must be addressed by the authors before they submit the 
camera-ready version.

No more than one paper per registration will be published. An extra fee must be 
paid for publication of additional papers, with a maximum of one additional 
paper per registration. One registration permits only the participation of one 
author in the conference.

Papers written in English and accepted and registered will be published in 
Proceedings by Springer, in a book of the Advances in Intelligent Systems and 
Computing series, will  be submitted for indexation by ISI, EI-Compendex, 
SCOPUS and DBLP, among others, and

[vhost:config-endian 22/36] ./usr/include/linux/virtio_9p.h:39:2: error: unknown type name '__virtio16'

2020-07-12 Thread kernel test robot 
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git 
config-endian
head:   6aef2378a564fea8e69c0419d94dc3ad9b4b7a99
commit: 8edd653e47e7e5ef253699fb1d0bb587941434d9 [22/36] virtio_9p: correct 
tags for config space fields
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0

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

All errors (new ones prefixed by >>):

   In file included from :32:
>> ./usr/include/linux/virtio_9p.h:39:2: error: unknown type name '__virtio16'
  39 |  __virtio16 tag_len;
 |  ^~

---
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: [RFC]: mm,power: introduce MADV_WIPEONSUSPEND

2020-07-12 Thread Pavel Machek 
On Tue 2020-07-07 12:00:41, Colm MacCarthaigh wrote:
> 
> 
> On 7 Jul 2020, at 9:37, Pavel Machek wrote:
> > Please go through the thread and try to understand it.
> > 
> > You'd need syscalls per get_randomness(), not per migration.
> 
> I think one check per get_randomness() is sufficient, though putting it at
> the end of the critical section rather than the beginning helps.

Yeah, well, one syscall is still enough to make it useless.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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