Re: [Xen-devel] [PATCH] xen/scsifront: don't advance ring request pointer in case of error

[David Vrabel]

On 29/11/16 11:19, Juergen Gross wrote:
> On 29/11/16 12:14, Jan Beulich wrote:
> On 29.11.16 at 11:50,  wrote:
>>> --- a/drivers/scsi/xen-scsifront.c
>>> +++ b/drivers/scsi/xen-scsifront.c
>>> @@ -184,8 +184,6 @@ static struct vscsiif_request *scsifront_pre_req(struct 
>>> vscsifrnt_info *info)
>>>  
>>> ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
>>>  
>>> -   ring->req_prod_pvt++;
>>
>> Please note the "_pvt" suffix, which stands for "private": This field is
>> not visible to the backend. Only ring->sring fields are shared, and
>> the updating of the shared field happens in RING_PUSH_REQUESTS()
>> and RING_PUSH_REQUESTS_AND_CHECK_NOTIFY().
> 
> Sure, but RING_PUSH_REQUESTS() will copy req_prod_pvt to req_prod. In
> the case corrected this would advance req_prod by two after the error
> case before, even if only one request would have made it to the ring.
> 
> As an alternative I could have decremented req_prod_pvt in case of an
> error, but I like my current solution better.

FWIW, I found the commit message a bit misleading and also came to the
same conclusion as Jan initially.

Perhaps,

"When adding a new request to the ring, an error may cause the
(partially constructed) request to be discarded and used for the next.
Thus ring->req_prod_pvt should not be advanced until we know the request
will be successfully added to the ring."

Or similar.

David

Re: [Xen-devel] [PATCH] xen/scsifront: don't advance ring request pointer in case of error

[David Vrabel]

On 29/11/16 11:19, Juergen Gross wrote:
> On 29/11/16 12:14, Jan Beulich wrote:
> On 29.11.16 at 11:50,  wrote:
>>> --- a/drivers/scsi/xen-scsifront.c
>>> +++ b/drivers/scsi/xen-scsifront.c
>>> @@ -184,8 +184,6 @@ static struct vscsiif_request *scsifront_pre_req(struct 
>>> vscsifrnt_info *info)
>>>  
>>> ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
>>>  
>>> -   ring->req_prod_pvt++;
>>
>> Please note the "_pvt" suffix, which stands for "private": This field is
>> not visible to the backend. Only ring->sring fields are shared, and
>> the updating of the shared field happens in RING_PUSH_REQUESTS()
>> and RING_PUSH_REQUESTS_AND_CHECK_NOTIFY().
> 
> Sure, but RING_PUSH_REQUESTS() will copy req_prod_pvt to req_prod. In
> the case corrected this would advance req_prod by two after the error
> case before, even if only one request would have made it to the ring.
> 
> As an alternative I could have decremented req_prod_pvt in case of an
> error, but I like my current solution better.

FWIW, I found the commit message a bit misleading and also came to the
same conclusion as Jan initially.

Perhaps,

"When adding a new request to the ring, an error may cause the
(partially constructed) request to be discarded and used for the next.
Thus ring->req_prod_pvt should not be advanced until we know the request
will be successfully added to the ring."

Or similar.

David

Re: [Xen-devel] [PATCH] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

[David Vrabel]

On 16/11/16 17:02, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
> 
> It was discovered recently this this flag may cause page allocation
> failures with the following stack:

It's not an allocation failure.

"It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT."

> check_vma_flags
> __get_user_pages
> __get_user_pages_locked
> __get_user_pages_unlocked
> get_user_pages_fast
> iov_iter_get_pages
> dio_refill_pages
> do_direct_IO
> do_blockdev_direct_IO
> do_blockdev_direct_IO
> ext4_direct_IO_read
> generic_file_read_iter
> aio_run_iocb
> 
> (which can happen if guest's vdisk has direct-io-safe option).
> 
> To avoid this, instead of setting VM_IO use mempolicy that prohibits page
> migration (i.e. clear policy's MPOL_F_MOF|MPOL_F_MORON)

Reviewed-by: David Vrabel <david.vra...@citrix.com>

With the corrected commit message.

David

Re: [Xen-devel] [PATCH] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

[David Vrabel]

On 16/11/16 17:02, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
> 
> It was discovered recently this this flag may cause page allocation
> failures with the following stack:

It's not an allocation failure.

"It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT."

> check_vma_flags
> __get_user_pages
> __get_user_pages_locked
> __get_user_pages_unlocked
> get_user_pages_fast
> iov_iter_get_pages
> dio_refill_pages
> do_direct_IO
> do_blockdev_direct_IO
> do_blockdev_direct_IO
> ext4_direct_IO_read
> generic_file_read_iter
> aio_run_iocb
> 
> (which can happen if guest's vdisk has direct-io-safe option).
> 
> To avoid this, instead of setting VM_IO use mempolicy that prohibits page
> migration (i.e. clear policy's MPOL_F_MOF|MPOL_F_MORON)

Reviewed-by: David Vrabel 

With the corrected commit message.

David

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[David Vrabel]

On 10/11/16 17:47, Olaf Hering wrote:
> On Thu, Nov 10, Boris Ostrovsky wrote:
> 
>> Are you sure it's this patch that causes the failure?
>>
>> I commented out '| VM_IO' and still unable to boot with this option.
> 
> Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:
> 
> +++ b/drivers/xen/gntdev.c
> @@ -804,7 +804,7 @@ static int gntdev_mmap(struct file *flip, struct 
> vm_area_struct *vma)
>  
> vma->vm_ops = _vmops;
>  
> -   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
> +   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP /*| VM_IO*/;
>  
> if (use_ptemod)
> vma->vm_flags |= VM_DONTCOPY;

I think we need a custom policy for this VMA with MPOL_F_MOF cleared.

David

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

[David Vrabel]

On 10/11/16 17:47, Olaf Hering wrote:
> On Thu, Nov 10, Boris Ostrovsky wrote:
> 
>> Are you sure it's this patch that causes the failure?
>>
>> I commented out '| VM_IO' and still unable to boot with this option.
> 
> Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based:
> 
> +++ b/drivers/xen/gntdev.c
> @@ -804,7 +804,7 @@ static int gntdev_mmap(struct file *flip, struct 
> vm_area_struct *vma)
>  
> vma->vm_ops = _vmops;
>  
> -   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
> +   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP /*| VM_IO*/;
>  
> if (use_ptemod)
> vma->vm_flags |= VM_DONTCOPY;

I think we need a custom policy for this VMA with MPOL_F_MOF cleared.

David

Re: [PATCH 00/12] xen: add common function for reading optional value

[David Vrabel]

On 31/10/16 16:48, Juergen Gross wrote:
> There are multiple instances of code reading an optional unsigned
> parameter from Xenstore via xenbus_scanf(). Instead of repeating the
> same code over and over add a service function doing the job and
> replace the call of xenbus_scanf() with the call of the new function
> where appropriate.

Acked-by: David Vrabel <david.vra...@citrix.com>

Please queue for the next release.

David

Re: [PATCH 00/12] xen: add common function for reading optional value

[David Vrabel]

On 31/10/16 16:48, Juergen Gross wrote:
> There are multiple instances of code reading an optional unsigned
> parameter from Xenstore via xenbus_scanf(). Instead of repeating the
> same code over and over add a service function doing the job and
> replace the call of xenbus_scanf() with the call of the new function
> where appropriate.

Acked-by: David Vrabel 

Please queue for the next release.

David

Re: [Xen-devel] [PATCH 01/12] xen: introduce xenbus_read_unsigned()

[David Vrabel]

On 31/10/16 16:48, Juergen Gross wrote:
> There are multiple instances of code reading an optional unsigned
> parameter from Xenstore via xenbus_scanf(). Instead of repeating the
> same code over and over add a service function doing the job.

Reviewed-by: David Vrabel <david.vra...@citrix.com>

David

Re: [Xen-devel] [PATCH 01/12] xen: introduce xenbus_read_unsigned()

[David Vrabel]

On 31/10/16 16:48, Juergen Gross wrote:
> There are multiple instances of code reading an optional unsigned
> parameter from Xenstore via xenbus_scanf(). Instead of repeating the
> same code over and over add a service function doing the job.

Reviewed-by: David Vrabel 

David

[PATCHv4 2/3] xenfs: replace xenbus and privcmd with symlinks

[David Vrabel]

/proc/xen/xenbus does not work correctly.  A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates.  This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.

/proc/xen/xenbus is supposed to be identical to the character device
/dev/xen/xenbus so replace the file with a symlink.

Similarly, replace /proc/xen/privcmd with a symlink since it should be
the same as /dev/xen/privcmd.

Signed-off-by: David Vrabel <david.vra...@citrix.com>
---
v4:
- Make xen_xenbus_fops and xen_privcmd_fops static.
---
 drivers/xen/privcmd.c|  5 +
 drivers/xen/privcmd.h|  3 ---
 drivers/xen/xenbus/xenbus_comms.h|  2 --
 drivers/xen/xenbus/xenbus_dev_frontend.c |  3 +--
 drivers/xen/xenfs/super.c| 10 --
 5 files changed, 6 insertions(+), 17 deletions(-)
 delete mode 100644 drivers/xen/privcmd.h

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 702040f..12ece8d 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -37,8 +37,6 @@
 #include 
 #include 
 
-#include "privcmd.h"
-
 MODULE_LICENSE("GPL");
 
 #define PRIV_VMA_LOCKED ((void *)1)
@@ -644,12 +642,11 @@ static int privcmd_vma_range_is_mapped(
   is_mapped_fn, NULL) != 0;
 }
 
-const struct file_operations xen_privcmd_fops = {
+const static struct file_operations xen_privcmd_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = privcmd_ioctl,
.mmap = privcmd_mmap,
 };
-EXPORT_SYMBOL_GPL(xen_privcmd_fops);
 
 static struct miscdevice privcmd_dev = {
.minor = MISC_DYNAMIC_MINOR,
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
deleted file mode 100644
index 14facae..000
--- a/drivers/xen/privcmd.h
+++ /dev/null
@@ -1,3 +0,0 @@
-#include 
-
-extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenbus/xenbus_comms.h 
b/drivers/xen/xenbus/xenbus_comms.h
index e74f9c1..39efb85 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -47,6 +47,4 @@ extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 extern enum xenstore_init xen_store_domain_type;
 
-extern const struct file_operations xen_xenbus_fops;
-
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index c1010f01..a45e7f2 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -598,7 +598,7 @@ static unsigned int xenbus_file_poll(struct file *file, 
poll_table *wait)
return 0;
 }
 
-const struct file_operations xen_xenbus_fops = {
+const static struct file_operations xen_xenbus_fops = {
.read = xenbus_file_read,
.write = xenbus_file_write,
.open = xenbus_file_open,
@@ -606,7 +606,6 @@ const struct file_operations xen_xenbus_fops = {
.poll = xenbus_file_poll,
.llseek = no_llseek,
 };
-EXPORT_SYMBOL_GPL(xen_xenbus_fops);
 
 static struct miscdevice xenbus_dev = {
.minor = MISC_DYNAMIC_MINOR,
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..0f2e2cd 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -18,8 +18,6 @@
 #include 
 
 #include "xenfs.h"
-#include "../privcmd.h"
-#include "../xenbus/xenbus_comms.h"
 
 #include 
 
@@ -45,16 +43,16 @@ static const struct file_operations capabilities_file_ops = 
{
 static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
static struct tree_descr xenfs_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{""},
};
 
static struct tree_descr xenfs_init_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
 #ifdef CONFIG_XEN_SYMS
-- 
2.1.4

[PATCHv4 2/3] xenfs: replace xenbus and privcmd with symlinks

[David Vrabel]

/proc/xen/xenbus does not work correctly.  A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates.  This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.

/proc/xen/xenbus is supposed to be identical to the character device
/dev/xen/xenbus so replace the file with a symlink.

Similarly, replace /proc/xen/privcmd with a symlink since it should be
the same as /dev/xen/privcmd.

Signed-off-by: David Vrabel 
---
v4:
- Make xen_xenbus_fops and xen_privcmd_fops static.
---
 drivers/xen/privcmd.c|  5 +
 drivers/xen/privcmd.h|  3 ---
 drivers/xen/xenbus/xenbus_comms.h|  2 --
 drivers/xen/xenbus/xenbus_dev_frontend.c |  3 +--
 drivers/xen/xenfs/super.c| 10 --
 5 files changed, 6 insertions(+), 17 deletions(-)
 delete mode 100644 drivers/xen/privcmd.h

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 702040f..12ece8d 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -37,8 +37,6 @@
 #include 
 #include 
 
-#include "privcmd.h"
-
 MODULE_LICENSE("GPL");
 
 #define PRIV_VMA_LOCKED ((void *)1)
@@ -644,12 +642,11 @@ static int privcmd_vma_range_is_mapped(
   is_mapped_fn, NULL) != 0;
 }
 
-const struct file_operations xen_privcmd_fops = {
+const static struct file_operations xen_privcmd_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = privcmd_ioctl,
.mmap = privcmd_mmap,
 };
-EXPORT_SYMBOL_GPL(xen_privcmd_fops);
 
 static struct miscdevice privcmd_dev = {
.minor = MISC_DYNAMIC_MINOR,
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
deleted file mode 100644
index 14facae..000
--- a/drivers/xen/privcmd.h
+++ /dev/null
@@ -1,3 +0,0 @@
-#include 
-
-extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenbus/xenbus_comms.h 
b/drivers/xen/xenbus/xenbus_comms.h
index e74f9c1..39efb85 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -47,6 +47,4 @@ extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 extern enum xenstore_init xen_store_domain_type;
 
-extern const struct file_operations xen_xenbus_fops;
-
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index c1010f01..a45e7f2 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -598,7 +598,7 @@ static unsigned int xenbus_file_poll(struct file *file, 
poll_table *wait)
return 0;
 }
 
-const struct file_operations xen_xenbus_fops = {
+const static struct file_operations xen_xenbus_fops = {
.read = xenbus_file_read,
.write = xenbus_file_write,
.open = xenbus_file_open,
@@ -606,7 +606,6 @@ const struct file_operations xen_xenbus_fops = {
.poll = xenbus_file_poll,
.llseek = no_llseek,
 };
-EXPORT_SYMBOL_GPL(xen_xenbus_fops);
 
 static struct miscdevice xenbus_dev = {
.minor = MISC_DYNAMIC_MINOR,
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..0f2e2cd 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -18,8 +18,6 @@
 #include 
 
 #include "xenfs.h"
-#include "../privcmd.h"
-#include "../xenbus/xenbus_comms.h"
 
 #include 
 
@@ -45,16 +43,16 @@ static const struct file_operations capabilities_file_ops = 
{
 static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
static struct tree_descr xenfs_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{""},
};
 
static struct tree_descr xenfs_init_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
 #ifdef CONFIG_XEN_SYMS
-- 
2.1.4

[PATCHv4 1/3] libfs: allow simple_fill_super() to add symlinks

[David Vrabel]

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.

Signed-off-by: David Vrabel <david.vra...@citrix.com>
---
v4:
- Use switch for file type.

v2:
- simplified.
---
 fs/libfs.c | 27 ---
 include/linux/fs.h |  2 +-
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/fs/libfs.c b/fs/libfs.c
index 48826d4..8eabcb1 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -509,6 +509,7 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
struct dentry *root;
struct dentry *dentry;
int i;
+   int ret = -ENOMEM;
 
s->s_blocksize = PAGE_SIZE;
s->s_blocksize_bits = PAGE_SHIFT;
@@ -550,9 +551,29 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
dput(dentry);
goto out;
}
-   inode->i_mode = S_IFREG | files->mode;
+   switch (files->mode & S_IFMT) {
+   case S_IFLNK:
+   inode->i_mode = files->mode;
+   inode->i_op = _symlink_inode_operations;
+   inode->i_link = kstrdup(files->link, GFP_KERNEL);
+   if (!inode->i_link) {
+   iput(inode);
+   dput(dentry);
+   goto out;
+   }
+   break;
+   case S_IFREG:
+   case 0:
+   inode->i_mode = S_IFREG | files->mode;
+   inode->i_fop = files->ops;
+   break;
+   default:
+   iput(inode);
+   dput(dentry);
+   ret = -EINVAL;
+   goto out;
+   }
inode->i_atime = inode->i_mtime = inode->i_ctime = 
current_time(inode);
-   inode->i_fop = files->ops;
inode->i_ino = i;
d_add(dentry, inode);
}
@@ -562,7 +583,7 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
d_genocide(root);
shrink_dcache_parent(root);
dput(root);
-   return -ENOMEM;
+   return ret;
 }
 EXPORT_SYMBOL(simple_fill_super);
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 16d2b6e..4b64fbb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2988,7 +2988,7 @@ extern const struct file_operations simple_dir_operations;
 extern const struct inode_operations simple_dir_inode_operations;
 extern void make_empty_dir_inode(struct inode *inode);
 extern bool is_empty_dir_inode(struct inode *inode);
-struct tree_descr { char *name; const struct file_operations *ops; int mode; };
+struct tree_descr { char *name; const struct file_operations *ops; int mode; 
char *link; };
 struct dentry *d_alloc_name(struct dentry *, const char *);
 extern int simple_fill_super(struct super_block *, unsigned long, struct 
tree_descr *);
 extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, 
int *count);
-- 
2.1.4

[PATCHv4 3/3] xenfs: Use proc_create_mount_point() to create /proc/xen

[David Vrabel]

From: Seth Forshee <seth.fors...@canonical.com>

Mounting proc in user namespace containers fails if the xenbus
filesystem is mounted on /proc/xen because this directory fails
the "permanently empty" test. proc_create_mount_point() exists
specifically to create such mountpoints in proc but is currently
proc-internal. Export this interface to modules, then use it in
xenbus when creating /proc/xen.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
Signed-off-by: David Vrabel <david.vra...@citrix.com>
---
 drivers/xen/xenbus/xenbus_probe.c | 2 +-
 fs/proc/generic.c | 1 +
 fs/proc/internal.h| 1 -
 include/linux/proc_fs.h   | 2 ++
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index 33a31cf..b5c1dec 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -826,7 +826,7 @@ static int __init xenbus_init(void)
 * Create xenfs mountpoint in /proc for compatibility with
 * utilities that expect to find "xenbus" under "/proc/xen".
 */
-   proc_mkdir("xen", NULL);
+   proc_create_mount_point("xen");
 #endif
 
 out_error:
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 5f2dc20..7eb3cef 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -479,6 +479,7 @@ struct proc_dir_entry *proc_create_mount_point(const char 
*name)
}
return ent;
 }
+EXPORT_SYMBOL(proc_create_mount_point);
 
 struct proc_dir_entry *proc_create_data(const char *name, umode_t mode,
struct proc_dir_entry *parent,
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 5378441..7de6795 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -195,7 +195,6 @@ static inline bool is_empty_pde(const struct proc_dir_entry 
*pde)
 {
return S_ISDIR(pde->mode) && !pde->proc_iops;
 }
-struct proc_dir_entry *proc_create_mount_point(const char *name);
 
 /*
  * inode.c
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index b97bf2e..8bd2f72 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -21,6 +21,7 @@ extern struct proc_dir_entry *proc_mkdir_data(const char *, 
umode_t,
  struct proc_dir_entry *, void *);
 extern struct proc_dir_entry *proc_mkdir_mode(const char *, umode_t,
  struct proc_dir_entry *);
+struct proc_dir_entry *proc_create_mount_point(const char *name);
  
 extern struct proc_dir_entry *proc_create_data(const char *, umode_t,
   struct proc_dir_entry *,
@@ -56,6 +57,7 @@ static inline struct proc_dir_entry *proc_symlink(const char 
*name,
struct proc_dir_entry *parent,const char *dest) { return NULL;}
 static inline struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent) {return NULL;}
+static inline struct proc_dir_entry *proc_create_mount_point(const char *name) 
{ return NULL; }
 static inline struct proc_dir_entry *proc_mkdir_data(const char *name,
umode_t mode, struct proc_dir_entry *parent, void *data) { return NULL; 
}
 static inline struct proc_dir_entry *proc_mkdir_mode(const char *name,
-- 
2.1.4

[PATCH v4 0/3] libfs,xenfs: replace /proc/xen/xenbus with a symlink

[David Vrabel]

Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file.  This is easiest to achive by making it a symlink to the
existing /dev/xen/xenbus device.

This requires extending simple_fill_super() to add symlinks as well as
regular files.

David

Changes in v4:
- Switch on file type in simple_fill_super()
- Make xen_xenus_fops and xen_privcmd_fops static
- Rebased on v4.9-rc2.
- Add patch from Seth for namespace support.

Changes in v3:
- Rebased on v4.7-rc5.

Changes in v2:
- Simplified simple_fill_super() change.

[PATCHv4 3/3] xenfs: Use proc_create_mount_point() to create /proc/xen

[David Vrabel]

From: Seth Forshee 

Mounting proc in user namespace containers fails if the xenbus
filesystem is mounted on /proc/xen because this directory fails
the "permanently empty" test. proc_create_mount_point() exists
specifically to create such mountpoints in proc but is currently
proc-internal. Export this interface to modules, then use it in
xenbus when creating /proc/xen.

Signed-off-by: Seth Forshee 
Signed-off-by: David Vrabel 
---
 drivers/xen/xenbus/xenbus_probe.c | 2 +-
 fs/proc/generic.c | 1 +
 fs/proc/internal.h| 1 -
 include/linux/proc_fs.h   | 2 ++
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index 33a31cf..b5c1dec 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -826,7 +826,7 @@ static int __init xenbus_init(void)
 * Create xenfs mountpoint in /proc for compatibility with
 * utilities that expect to find "xenbus" under "/proc/xen".
 */
-   proc_mkdir("xen", NULL);
+   proc_create_mount_point("xen");
 #endif
 
 out_error:
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 5f2dc20..7eb3cef 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -479,6 +479,7 @@ struct proc_dir_entry *proc_create_mount_point(const char 
*name)
}
return ent;
 }
+EXPORT_SYMBOL(proc_create_mount_point);
 
 struct proc_dir_entry *proc_create_data(const char *name, umode_t mode,
struct proc_dir_entry *parent,
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 5378441..7de6795 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -195,7 +195,6 @@ static inline bool is_empty_pde(const struct proc_dir_entry 
*pde)
 {
return S_ISDIR(pde->mode) && !pde->proc_iops;
 }
-struct proc_dir_entry *proc_create_mount_point(const char *name);
 
 /*
  * inode.c
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index b97bf2e..8bd2f72 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -21,6 +21,7 @@ extern struct proc_dir_entry *proc_mkdir_data(const char *, 
umode_t,
  struct proc_dir_entry *, void *);
 extern struct proc_dir_entry *proc_mkdir_mode(const char *, umode_t,
  struct proc_dir_entry *);
+struct proc_dir_entry *proc_create_mount_point(const char *name);
  
 extern struct proc_dir_entry *proc_create_data(const char *, umode_t,
   struct proc_dir_entry *,
@@ -56,6 +57,7 @@ static inline struct proc_dir_entry *proc_symlink(const char 
*name,
struct proc_dir_entry *parent,const char *dest) { return NULL;}
 static inline struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent) {return NULL;}
+static inline struct proc_dir_entry *proc_create_mount_point(const char *name) 
{ return NULL; }
 static inline struct proc_dir_entry *proc_mkdir_data(const char *name,
umode_t mode, struct proc_dir_entry *parent, void *data) { return NULL; 
}
 static inline struct proc_dir_entry *proc_mkdir_mode(const char *name,
-- 
2.1.4

[PATCH v4 0/3] libfs,xenfs: replace /proc/xen/xenbus with a symlink

[David Vrabel]

Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file.  This is easiest to achive by making it a symlink to the
existing /dev/xen/xenbus device.

This requires extending simple_fill_super() to add symlinks as well as
regular files.

David

Changes in v4:
- Switch on file type in simple_fill_super()
- Make xen_xenus_fops and xen_privcmd_fops static
- Rebased on v4.9-rc2.
- Add patch from Seth for namespace support.

Changes in v3:
- Rebased on v4.7-rc5.

Changes in v2:
- Simplified simple_fill_super() change.

[PATCHv4 1/3] libfs: allow simple_fill_super() to add symlinks

[David Vrabel]

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.

Signed-off-by: David Vrabel 
---
v4:
- Use switch for file type.

v2:
- simplified.
---
 fs/libfs.c | 27 ---
 include/linux/fs.h |  2 +-
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/fs/libfs.c b/fs/libfs.c
index 48826d4..8eabcb1 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -509,6 +509,7 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
struct dentry *root;
struct dentry *dentry;
int i;
+   int ret = -ENOMEM;
 
s->s_blocksize = PAGE_SIZE;
s->s_blocksize_bits = PAGE_SHIFT;
@@ -550,9 +551,29 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
dput(dentry);
goto out;
}
-   inode->i_mode = S_IFREG | files->mode;
+   switch (files->mode & S_IFMT) {
+   case S_IFLNK:
+   inode->i_mode = files->mode;
+   inode->i_op = _symlink_inode_operations;
+   inode->i_link = kstrdup(files->link, GFP_KERNEL);
+   if (!inode->i_link) {
+   iput(inode);
+   dput(dentry);
+   goto out;
+   }
+   break;
+   case S_IFREG:
+   case 0:
+   inode->i_mode = S_IFREG | files->mode;
+   inode->i_fop = files->ops;
+   break;
+   default:
+   iput(inode);
+   dput(dentry);
+   ret = -EINVAL;
+   goto out;
+   }
inode->i_atime = inode->i_mtime = inode->i_ctime = 
current_time(inode);
-   inode->i_fop = files->ops;
inode->i_ino = i;
d_add(dentry, inode);
}
@@ -562,7 +583,7 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
d_genocide(root);
shrink_dcache_parent(root);
dput(root);
-   return -ENOMEM;
+   return ret;
 }
 EXPORT_SYMBOL(simple_fill_super);
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 16d2b6e..4b64fbb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2988,7 +2988,7 @@ extern const struct file_operations simple_dir_operations;
 extern const struct inode_operations simple_dir_inode_operations;
 extern void make_empty_dir_inode(struct inode *inode);
 extern bool is_empty_dir_inode(struct inode *inode);
-struct tree_descr { char *name; const struct file_operations *ops; int mode; };
+struct tree_descr { char *name; const struct file_operations *ops; int mode; 
char *link; };
 struct dentry *d_alloc_name(struct dentry *, const char *);
 extern int simple_fill_super(struct super_block *, unsigned long, struct 
tree_descr *);
 extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, 
int *count);
-- 
2.1.4

[GIT PULL] xen: xenfs fixes for 4.9-rc2

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.9-fs-rc2-tag

I have separated these fixes out from the previous set because they
contain changes to generic filesystem code.  Despite reposts and pings,
these changes got no response from the relevant maintainer.

I think the changes are trivial and uncontroversial.  Please consider
merging.

xen: xenfs fixes for 4.9-rc2

- - Fix issues with simultaneous writes and reads to /proc/xen/xenbus.
- - Fix /proc/xen inside filesystem namespaces.

Thanks.

David

 drivers/xen/privcmd.c|  5 +
 drivers/xen/privcmd.h|  3 ---
 drivers/xen/xenbus/xenbus_comms.h|  2 --
 drivers/xen/xenbus/xenbus_dev_frontend.c |  3 +--
 drivers/xen/xenbus/xenbus_probe.c|  2 +-
 drivers/xen/xenfs/super.c| 10 --
 fs/libfs.c   | 15 +--
 fs/proc/generic.c|  1 +
 fs/proc/internal.h   |  1 -
 include/linux/fs.h   |  2 +-
 include/linux/proc_fs.h  |  2 ++
 11 files changed, 24 insertions(+), 22 deletions(-)

David Vrabel (2):
  libfs: allow simple_fill_super() to add symlinks
  xenfs: replace xenbus and privcmd with symlinks

Seth Forshee (1):
  xenbus: Use proc_create_mount_point() to create /proc/xen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYDjixAAoJEFxbo/MsZsTR2mcH/ik/YMQkQvrFkQpYSjhDJQ1b
xROWMLdN13bNDQiKTd/BdM1rWh4d/Rj/4iVMcYoJuhlpQ6TU8DHJCH77tA5noA5g
Rpaafmp5jFzKrTIAUSHo+7nZYJLLxOVC2PYHqBcMy5wEY7zaGf6KxLmqOzgghW0v
t/rOMFFNrSMzjmOYx+rv4VCIiwdkRpXPi0r+u38JuFzCGMbscrgqyGLEIe56xLJC
8iZe6uqBQNILox2Tgf7MQeZML8XtzzHHcgq1FxaVdWZMZ/PoIsx78v1ZMTepcCu/
JYiH2AE4fIYTi7v6IhEzVeNPvWfoX87O238rpobSXMLcophn6qSOKuF+hsxN3Yg=
=Q8rr
-END PGP SIGNATURE-

[GIT PULL] xen: xenfs fixes for 4.9-rc2

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.9-fs-rc2-tag

I have separated these fixes out from the previous set because they
contain changes to generic filesystem code.  Despite reposts and pings,
these changes got no response from the relevant maintainer.

I think the changes are trivial and uncontroversial.  Please consider
merging.

xen: xenfs fixes for 4.9-rc2

- - Fix issues with simultaneous writes and reads to /proc/xen/xenbus.
- - Fix /proc/xen inside filesystem namespaces.

Thanks.

David

 drivers/xen/privcmd.c|  5 +
 drivers/xen/privcmd.h|  3 ---
 drivers/xen/xenbus/xenbus_comms.h|  2 --
 drivers/xen/xenbus/xenbus_dev_frontend.c |  3 +--
 drivers/xen/xenbus/xenbus_probe.c|  2 +-
 drivers/xen/xenfs/super.c| 10 --
 fs/libfs.c   | 15 +--
 fs/proc/generic.c|  1 +
 fs/proc/internal.h   |  1 -
 include/linux/fs.h   |  2 +-
 include/linux/proc_fs.h  |  2 ++
 11 files changed, 24 insertions(+), 22 deletions(-)

David Vrabel (2):
  libfs: allow simple_fill_super() to add symlinks
  xenfs: replace xenbus and privcmd with symlinks

Seth Forshee (1):
  xenbus: Use proc_create_mount_point() to create /proc/xen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYDjixAAoJEFxbo/MsZsTR2mcH/ik/YMQkQvrFkQpYSjhDJQ1b
xROWMLdN13bNDQiKTd/BdM1rWh4d/Rj/4iVMcYoJuhlpQ6TU8DHJCH77tA5noA5g
Rpaafmp5jFzKrTIAUSHo+7nZYJLLxOVC2PYHqBcMy5wEY7zaGf6KxLmqOzgghW0v
t/rOMFFNrSMzjmOYx+rv4VCIiwdkRpXPi0r+u38JuFzCGMbscrgqyGLEIe56xLJC
8iZe6uqBQNILox2Tgf7MQeZML8XtzzHHcgq1FxaVdWZMZ/PoIsx78v1ZMTepcCu/
JYiH2AE4fIYTi7v6IhEzVeNPvWfoX87O238rpobSXMLcophn6qSOKuF+hsxN3Yg=
=Q8rr
-END PGP SIGNATURE-

[GIT PULL] xen: fixes for 4.9-rc2

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc2-tag

xen: fixes for 4.9-rc2

- - Advertise control feature flags in xenstore.
- - Fix x86 build when XEN_PVHVM is disabled.

Thanks.

David

 arch/x86/xen/enlighten.c   |  2 ++
 drivers/xen/manage.c   | 45 +++---
 drivers/xen/xenbus/xenbus_dev_frontend.c   |  4 +--
 drivers/xen/xenbus/xenbus_probe_frontend.c |  4 ++-
 4 files changed, 36 insertions(+), 19 deletions(-)

Arnd Bergmann (1):
  x86: xen: move cpu_up functions out of ifdef

Jan Beulich (2):
  xenbus: prefer list_for_each()
  xenbus: check return value of xenbus_scanf()

Juergen Gross (1):
  xenbus: advertise control feature flags
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYDjYbAAoJEFxbo/MsZsTR61cIAI7Vmu03kik1GHH7/vtJSqJ4
3Anq8N5kPesoJf4Gwlv8Sm+QY2tJZg64xoZVcqnbMrf4hbCY7TxJ71tTJCi5GPll
nqyLbLDSSFnBxlodaGnITKagdGCEKJFuoB6tJYfEHMF1KSYv3rm+EIeYzN1Jw0g1
wrXNmVrjzIH6wh46wy93N5R1CmQsXP9a4SLjnjHmp9ebmBhVPnz2A1plKt4NHE6p
8qQDBSJPgWKohXRhFfteNcO4z84DgtzNPflJor3R+CV9n9OKBcRw7oom31Pp68YB
32chj/q9xyccQ1sMgFFma4W+gNXnOPFShyD+Umo32GrBntMMuQIcD0CFBEqsi88=
=99+e
-END PGP SIGNATURE-

[GIT PULL] xen: fixes for 4.9-rc2

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc2-tag

xen: fixes for 4.9-rc2

- - Advertise control feature flags in xenstore.
- - Fix x86 build when XEN_PVHVM is disabled.

Thanks.

David

 arch/x86/xen/enlighten.c   |  2 ++
 drivers/xen/manage.c   | 45 +++---
 drivers/xen/xenbus/xenbus_dev_frontend.c   |  4 +--
 drivers/xen/xenbus/xenbus_probe_frontend.c |  4 ++-
 4 files changed, 36 insertions(+), 19 deletions(-)

Arnd Bergmann (1):
  x86: xen: move cpu_up functions out of ifdef

Jan Beulich (2):
  xenbus: prefer list_for_each()
  xenbus: check return value of xenbus_scanf()

Juergen Gross (1):
  xenbus: advertise control feature flags
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYDjYbAAoJEFxbo/MsZsTR61cIAI7Vmu03kik1GHH7/vtJSqJ4
3Anq8N5kPesoJf4Gwlv8Sm+QY2tJZg64xoZVcqnbMrf4hbCY7TxJ71tTJCi5GPll
nqyLbLDSSFnBxlodaGnITKagdGCEKJFuoB6tJYfEHMF1KSYv3rm+EIeYzN1Jw0g1
wrXNmVrjzIH6wh46wy93N5R1CmQsXP9a4SLjnjHmp9ebmBhVPnz2A1plKt4NHE6p
8qQDBSJPgWKohXRhFfteNcO4z84DgtzNPflJor3R+CV9n9OKBcRw7oom31Pp68YB
32chj/q9xyccQ1sMgFFma4W+gNXnOPFShyD+Umo32GrBntMMuQIcD0CFBEqsi88=
=99+e
-END PGP SIGNATURE-

Re: [PATCH v3] xenbus: advertize control feature flags

[David Vrabel]

On 11/10/16 11:53, Juergen Gross wrote:
> On 10/10/16 12:13, Paul Durrant wrote:
>> The Xen docs specify several flags which a guest can set to advertize
>> which values of the xenstore control/shutdown key it will recognize.
>> This patch adds code to write all the relevant feature-flag keys.
>>
>> Signed-off-by: Paul Durrant <paul.durr...@citrix.com>
>> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
>> Cc: David Vrabel <david.vra...@citrix.com>
>> Cc: Juergen Gross <jgr...@suse.com>
> 
> Hmm, I'd prefer node[] allocated on the stack over dynamic allocation.
> 
> What about something like the following? It will at least issue build
> warnings in case the size is too small, will use less memory and less
> coding.

You still want snprintf() just to be sure.  You can add a Reviewed-by
David Vrabel <david.vra...@citrix.com> if you make this change.

David

Re: [PATCH v3] xenbus: advertize control feature flags

[David Vrabel]

On 11/10/16 11:53, Juergen Gross wrote:
> On 10/10/16 12:13, Paul Durrant wrote:
>> The Xen docs specify several flags which a guest can set to advertize
>> which values of the xenstore control/shutdown key it will recognize.
>> This patch adds code to write all the relevant feature-flag keys.
>>
>> Signed-off-by: Paul Durrant 
>> Cc: Boris Ostrovsky 
>> Cc: David Vrabel 
>> Cc: Juergen Gross 
> 
> Hmm, I'd prefer node[] allocated on the stack over dynamic allocation.
> 
> What about something like the following? It will at least issue build
> warnings in case the size is too small, will use less memory and less
> coding.

You still want snprintf() just to be sure.  You can add a Reviewed-by
David Vrabel  if you make this change.

David

Re: [PATCH v2] xenbus: advertize control feature flags

[David Vrabel]

On 10/10/16 10:43, Paul Durrant wrote:
> The Xen docs specify several flags which a guest can set to advertize
> which values of the xenstore control/shutdown key it will recognize.
> This patch adds code to write all the relevant feature-flag keys.
[...]
>  static int setup_shutdown_watcher(void)
>  {
> + static struct shutdown_handler *handler;
>   int err;
>  
> + for (handler = _handlers[0]; handler->command; handler++) {
> + char *node;

char node[20];

and avoid the allocation and resulting error path.

As Juergen notes, the 'flag' field isn't used anywhere now.  Can you
please test your patches and verify the correct keys are being created?

David

Re: [PATCH v2] xenbus: advertize control feature flags

[David Vrabel]

On 10/10/16 10:43, Paul Durrant wrote:
> The Xen docs specify several flags which a guest can set to advertize
> which values of the xenstore control/shutdown key it will recognize.
> This patch adds code to write all the relevant feature-flag keys.
[...]
>  static int setup_shutdown_watcher(void)
>  {
> + static struct shutdown_handler *handler;
>   int err;
>  
> + for (handler = _handlers[0]; handler->command; handler++) {
> + char *node;

char node[20];

and avoid the allocation and resulting error path.

As Juergen notes, the 'flag' field isn't used anywhere now.  Can you
please test your patches and verify the correct keys are being created?

David

Re: [Xen-devel] [PATCH] xen/x86: Update topology map for PV VCPUs

[David Vrabel]

On 05/10/16 18:09, Boris Ostrovsky wrote:
> Early during boot topology_update_package_map() computes
> logical_pkg_ids for all present processors.
> 
> Later, when processors are brought up, identify_cpu() updates
> these values based on phys_pkg_id which is a function of
> initial_apicid. On PV guests the latter may point to a
> non-existing node, causing logical_pkg_ids to be set to -1.
> 
> Intel's RAPL uses logical_pkg_id (as topology_logical_package_id())
> to index its arrays and therefore in this case will point to index
> 65535 (since logical_pkg_id is a u16). This could lead to either a
> crash or may actually access random memory location.
> 
> As a workaround, we recompute topology during CPU bringup to reset
> logical_pkg_id to a valid value.
> 
> (The reason for initial_apicid being bogus is because it is
> initial_apicid of the processor from which the guest is launched.
> This value is CPUID(1).EBX[31:24])

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH] xen/x86: Update topology map for PV VCPUs

[David Vrabel]

On 05/10/16 18:09, Boris Ostrovsky wrote:
> Early during boot topology_update_package_map() computes
> logical_pkg_ids for all present processors.
> 
> Later, when processors are brought up, identify_cpu() updates
> these values based on phys_pkg_id which is a function of
> initial_apicid. On PV guests the latter may point to a
> non-existing node, causing logical_pkg_ids to be set to -1.
> 
> Intel's RAPL uses logical_pkg_id (as topology_logical_package_id())
> to index its arrays and therefore in this case will point to index
> 65535 (since logical_pkg_id is a u16). This could lead to either a
> crash or may actually access random memory location.
> 
> As a workaround, we recompute topology during CPU bringup to reset
> logical_pkg_id to a valid value.
> 
> (The reason for initial_apicid being bogus is because it is
> initial_apicid of the processor from which the guest is launched.
> This value is CPUID(1).EBX[31:24])

Applied to for-linus-4.9, thanks.

David

[GIT PULL] xen: features and fixes for 4.9-rc0

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc0-tag

xen: features and fixes for 4.9-rc0

- - Switch to new CPU hotplug mechanism.
- - Support driver_override in pciback.
- - Require vector callback for HVM guests (the alternate mechanism via
  the platform device has been broken for ages).

Thanks.

David

 arch/x86/include/asm/xen/events.h  |  11 
 arch/x86/pci/xen.c |   2 +-
 arch/x86/xen/enlighten.c   |  94 -
 arch/x86/xen/grant-table.c |   2 +-
 arch/x86/xen/platform-pci-unplug.c |   2 +-
 arch/x86/xen/pmu.c |   7 ++-
 arch/x86/xen/smp.c |  53 +++--
 arch/x86/xen/smp.h |  13 +
 arch/x86/xen/time.c|   5 --
 drivers/xen/events/events_base.c   |  26 +++--
 drivers/xen/events/events_fifo.c   |  34 ---
 drivers/xen/platform-pci.c |  64 
 drivers/xen/sys-hypervisor.c   |  12 ++--
 drivers/xen/xen-pciback/pci_stub.c | 117 +
 include/linux/cpuhotplug.h |   2 +
 include/xen/xen.h  |   3 +-
 16 files changed, 208 insertions(+), 239 deletions(-)

Boris Ostrovsky (5):
  xen/x86: Move irq allocation from Xen smp_op.cpu_up()
  hotplug: Prevent alloc/free of irq descriptors during cpu up/down (again)
  xen/x86: Convert to hotplug state machine
  xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier
  xen/x86: Update topology map for PV VCPUs

Colin Ian King (1):
  x86/xen: add missing \n at end of printk warning message

Juergen Gross (5):
  xen: rename xen_pmu_init() in sys-hypervisor.c
  xen: Make VPMU init message look less scary
  xen/pciback: simplify pcistub device handling
  xen/pciback: avoid multiple entries in slot list
  xen/pciback: support driver_override

KarimAllah Ahmed (1):
  xen: Remove event channel notification through Xen PCI platform device

Markus Elfring (1):
  xen/grant-table: Use kmalloc_array() in arch_gnttab_valloc()

Sebastian Andrzej Siewior (1):
  xen/events: Convert to hotplug state machine
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX9ltNAAoJEFxbo/MsZsTRjW4H/Rl5NJOyDQ4Kl7So0ScUhB4Z
vZZfTTo9UcQZKBFNQeMgCScI69UYDXr9Uu6h/XqFEiJXzN/QvGoJkrSxYVNqQORp
O6Ncz87zccAMM5vz7VrTtob2QIpkphfRsgG1NemlUeHZHUeu3gJdsk79PIOPCd3Q
BBPK6UKycHl9gwvK3vXDQLJqa6AoqSBsy8FiSiFxWXXi/j0qP+C2dxTErHyeWhXE
bEc4Fitk7sn9ASlPxZMZ+gQNUa3lvcM63VoFi9WSivHThcQdlPwVtk7iIwwggpy7
AXeIgs5me2QjLoRGbX9vFXAqrbgALR8vE1wYc7/NemZJua6yekDh8nmgOk24wmk=
=KGnZ
-END PGP SIGNATURE-

[GIT PULL] xen: features and fixes for 4.9-rc0

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc0-tag

xen: features and fixes for 4.9-rc0

- - Switch to new CPU hotplug mechanism.
- - Support driver_override in pciback.
- - Require vector callback for HVM guests (the alternate mechanism via
  the platform device has been broken for ages).

Thanks.

David

 arch/x86/include/asm/xen/events.h  |  11 
 arch/x86/pci/xen.c |   2 +-
 arch/x86/xen/enlighten.c   |  94 -
 arch/x86/xen/grant-table.c |   2 +-
 arch/x86/xen/platform-pci-unplug.c |   2 +-
 arch/x86/xen/pmu.c |   7 ++-
 arch/x86/xen/smp.c |  53 +++--
 arch/x86/xen/smp.h |  13 +
 arch/x86/xen/time.c|   5 --
 drivers/xen/events/events_base.c   |  26 +++--
 drivers/xen/events/events_fifo.c   |  34 ---
 drivers/xen/platform-pci.c |  64 
 drivers/xen/sys-hypervisor.c   |  12 ++--
 drivers/xen/xen-pciback/pci_stub.c | 117 +
 include/linux/cpuhotplug.h |   2 +
 include/xen/xen.h  |   3 +-
 16 files changed, 208 insertions(+), 239 deletions(-)

Boris Ostrovsky (5):
  xen/x86: Move irq allocation from Xen smp_op.cpu_up()
  hotplug: Prevent alloc/free of irq descriptors during cpu up/down (again)
  xen/x86: Convert to hotplug state machine
  xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier
  xen/x86: Update topology map for PV VCPUs

Colin Ian King (1):
  x86/xen: add missing \n at end of printk warning message

Juergen Gross (5):
  xen: rename xen_pmu_init() in sys-hypervisor.c
  xen: Make VPMU init message look less scary
  xen/pciback: simplify pcistub device handling
  xen/pciback: avoid multiple entries in slot list
  xen/pciback: support driver_override

KarimAllah Ahmed (1):
  xen: Remove event channel notification through Xen PCI platform device

Markus Elfring (1):
  xen/grant-table: Use kmalloc_array() in arch_gnttab_valloc()

Sebastian Andrzej Siewior (1):
  xen/events: Convert to hotplug state machine
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX9ltNAAoJEFxbo/MsZsTRjW4H/Rl5NJOyDQ4Kl7So0ScUhB4Z
vZZfTTo9UcQZKBFNQeMgCScI69UYDXr9Uu6h/XqFEiJXzN/QvGoJkrSxYVNqQORp
O6Ncz87zccAMM5vz7VrTtob2QIpkphfRsgG1NemlUeHZHUeu3gJdsk79PIOPCd3Q
BBPK6UKycHl9gwvK3vXDQLJqa6AoqSBsy8FiSiFxWXXi/j0qP+C2dxTErHyeWhXE
bEc4Fitk7sn9ASlPxZMZ+gQNUa3lvcM63VoFi9WSivHThcQdlPwVtk7iIwwggpy7
AXeIgs5me2QjLoRGbX9vFXAqrbgALR8vE1wYc7/NemZJua6yekDh8nmgOk24wmk=
=KGnZ
-END PGP SIGNATURE-

Re: [Xen-devel] [PATCH] xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier

[David Vrabel]

On 02/10/16 23:45, Boris Ostrovsky wrote:
> xen_cpuhp_setup() calls mutex_lock() which, when CONFIG_DEBUG_MUTEXES
> is defined, ends up calling xen_save_fl(). That routine expects
> per_cpu(xen_vcpu, 0) to be already initialized.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH] xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier

[David Vrabel]

On 02/10/16 23:45, Boris Ostrovsky wrote:
> xen_cpuhp_setup() calls mutex_lock() which, when CONFIG_DEBUG_MUTEXES
> is defined, ends up calling xen_save_fl(). That routine expects
> per_cpu(xen_vcpu, 0) to be already initialized.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v3 0/3] xen/pciback: support driver_override

[David Vrabel]

On 22/09/16 09:45, Juergen Gross wrote:
> Support the driver_override scheme introduced with commit 782a985d7af2
> ("PCI: Introduce new device binding path using pci_dev.driver_override")

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v3 0/3] xen/pciback: support driver_override

[David Vrabel]

On 22/09/16 09:45, Juergen Gross wrote:
> Support the driver_override scheme introduced with commit 782a985d7af2
> ("PCI: Introduce new device binding path using pci_dev.driver_override")

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v2 0/2] Convert to new CPU hotplug framework

[David Vrabel]

On 07/09/16 18:18, Boris Ostrovsky wrote:
> New CPU hotplug framework was introduced recently. These patches convert Xen
> CPU hotplug code to this infrastructure.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v2 0/2] Convert to new CPU hotplug framework

[David Vrabel]

On 07/09/16 18:18, Boris Ostrovsky wrote:
> New CPU hotplug framework was introduced recently. These patches convert Xen
> CPU hotplug code to this infrastructure.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device

[David Vrabel]

On 26/08/16 22:55, KarimAllah Ahmed wrote:
> Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches
> from old kernel") using the INTx interrupt from Xen PCI platform device for
> event channel notification would just lockup the guest during bootup.
> postcore_initcall now calls xs_reset_watches which will eventually try to read
> a value from XenStore and will get stuck on read_reply at XenBus forever since
> the platform driver is not probed yet and its INTx interrupt handler is not
> registered yet. That means that the guest can not be notified at this moment 
> of
> any pending event channels and none of the per-event handlers will ever be
> invoked (including the XenStore one) and the reply will never be picked up by
> the kernel.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device

[David Vrabel]

On 26/08/16 22:55, KarimAllah Ahmed wrote:
> Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches
> from old kernel") using the INTx interrupt from Xen PCI platform device for
> event channel notification would just lockup the guest during bootup.
> postcore_initcall now calls xs_reset_watches which will eventually try to read
> a value from XenStore and will get stuck on read_reply at XenBus forever since
> the platform driver is not probed yet and its INTx interrupt handler is not
> registered yet. That means that the guest can not be notified at this moment 
> of
> any pending event channels and none of the per-event handlers will ever be
> invoked (including the XenStore one) and the reply will never be picked up by
> the kernel.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v3 2/3] xen/pciback: avoid multiple entries in slot list

[David Vrabel]

On 22/09/16 22:02, Boris Ostrovsky wrote:
> On 09/22/2016 04:45 AM, Juergen Gross wrote:
>> The Xen pciback driver has a list of all pci devices it is ready to
>> seize. There is no check whether a to be added entry already exists.
>> While this might be no problem in the common case it might confuse
>> those which consume the list via sysfs.
>>
>> Modify the handling of this list by not adding an entry which already
>> exists. As this will be needed later split out the list handling into
>> a separate function.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  drivers/xen/xen-pciback/pci_stub.c | 39 
>> ++
>>  1 file changed, 31 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
>> b/drivers/xen/xen-pciback/pci_stub.c
>> index 79a9e4d..0179333 100644
>> --- a/drivers/xen/xen-pciback/pci_stub.c
>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>> @@ -478,6 +478,36 @@ static int __init pcistub_init_devices_late(void)
>>  return 0;
>>  }
>>  
>> +static void pcistub_device_id_add_list(struct pcistub_device_id *new,
>> +   int domain, int bus, unsigned int devfn)

I think this should allocate the new pcistub_device_id if needed.  You
can pass in GFP flags if needed.

Then it can return the newly allocated one, or the existing one.

static struct pcistub_device_id *pcistub_device_id_add_list(
int domain, int bus, unsigned int devfn)

David

Re: [Xen-devel] [PATCH v3 2/3] xen/pciback: avoid multiple entries in slot list

[David Vrabel]

On 22/09/16 22:02, Boris Ostrovsky wrote:
> On 09/22/2016 04:45 AM, Juergen Gross wrote:
>> The Xen pciback driver has a list of all pci devices it is ready to
>> seize. There is no check whether a to be added entry already exists.
>> While this might be no problem in the common case it might confuse
>> those which consume the list via sysfs.
>>
>> Modify the handling of this list by not adding an entry which already
>> exists. As this will be needed later split out the list handling into
>> a separate function.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  drivers/xen/xen-pciback/pci_stub.c | 39 
>> ++
>>  1 file changed, 31 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
>> b/drivers/xen/xen-pciback/pci_stub.c
>> index 79a9e4d..0179333 100644
>> --- a/drivers/xen/xen-pciback/pci_stub.c
>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>> @@ -478,6 +478,36 @@ static int __init pcistub_init_devices_late(void)
>>  return 0;
>>  }
>>  
>> +static void pcistub_device_id_add_list(struct pcistub_device_id *new,
>> +   int domain, int bus, unsigned int devfn)

I think this should allocate the new pcistub_device_id if needed.  You
can pass in GFP flags if needed.

Then it can return the newly allocated one, or the existing one.

static struct pcistub_device_id *pcistub_device_id_add_list(
int domain, int bus, unsigned int devfn)

David

Re: [PATCH net-next RESEND] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Vrabel]

On 19/09/16 11:22, Vitaly Kuznetsov wrote:
> David Miller  writes:
> 
>> From: Vitaly Kuznetsov 
>> Date: Fri, 16 Sep 2016 12:59:14 +0200
>>
>>> @@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb, 
>>> struct net_device *dev)
>>> offset = offset_in_page(skb->data);
>>> len = skb_headlen(skb);
>>>  
>>> +   /* The first req should be at least ETH_HLEN size or the packet will be
>>> +* dropped by netback.
>>> +*/
>>> +   if (unlikely(PAGE_SIZE - offset < ETH_HLEN)) {
>>> +   nskb = skb_copy(skb, GFP_ATOMIC);
>>> +   if (!nskb)
>>> +   goto drop;
>>> +   dev_kfree_skb_any(skb);
>>> +   skb = nskb;
>>> +   page = virt_to_page(skb->data);
>>> +   offset = offset_in_page(skb->data);
>>> +   }
>>> +
>>> spin_lock_irqsave(>tx_lock, flags);
>>
>> I think you also have to recalculate 'len' in this case too, as
>> skb_headlen() will definitely be different for nskb.
>>
>> In fact, I can't see how this code can work properly without that fix.
> 
> Thank you for your feedback David,
> 
> in my testing (even when I tried doing skb_copy() for all skbs
> unconditionally) skb_headlen(nskb) always equals 'len' so I was under an
> impression that both 'skb->len' and 'skb->data_len' remain the same when
> we do skb_copy(). However, in case you think there are cases when
> headlen changes, I see no problem with re-calculating 'len' as it won't
> bring any significant performace penalty compared to the already added
> skb_copy().

I think you can move the len = skb_headlen(skb) after the if, no need to
recalculate it.

David

Re: [PATCH net-next RESEND] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Vrabel]

On 19/09/16 11:22, Vitaly Kuznetsov wrote:
> David Miller  writes:
> 
>> From: Vitaly Kuznetsov 
>> Date: Fri, 16 Sep 2016 12:59:14 +0200
>>
>>> @@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb, 
>>> struct net_device *dev)
>>> offset = offset_in_page(skb->data);
>>> len = skb_headlen(skb);
>>>  
>>> +   /* The first req should be at least ETH_HLEN size or the packet will be
>>> +* dropped by netback.
>>> +*/
>>> +   if (unlikely(PAGE_SIZE - offset < ETH_HLEN)) {
>>> +   nskb = skb_copy(skb, GFP_ATOMIC);
>>> +   if (!nskb)
>>> +   goto drop;
>>> +   dev_kfree_skb_any(skb);
>>> +   skb = nskb;
>>> +   page = virt_to_page(skb->data);
>>> +   offset = offset_in_page(skb->data);
>>> +   }
>>> +
>>> spin_lock_irqsave(>tx_lock, flags);
>>
>> I think you also have to recalculate 'len' in this case too, as
>> skb_headlen() will definitely be different for nskb.
>>
>> In fact, I can't see how this code can work properly without that fix.
> 
> Thank you for your feedback David,
> 
> in my testing (even when I tried doing skb_copy() for all skbs
> unconditionally) skb_headlen(nskb) always equals 'len' so I was under an
> impression that both 'skb->len' and 'skb->data_len' remain the same when
> we do skb_copy(). However, in case you think there are cases when
> headlen changes, I see no problem with re-calculating 'len' as it won't
> bring any significant performace penalty compared to the already added
> skb_copy().

I think you can move the len = skb_headlen(skb) after the if, no need to
recalculate it.

David

Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[David Vrabel]

On 14/09/16 22:35, Dave Hansen wrote:
> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
> 
> That needs to make it into a comment, please.
> 
> That *is* a Xen bug, right?

This is probably fixed in the latest version of Xen.  Andrew Cooper
would know for sure.

>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int 
>> *err)
>>  #endif
>>  val &= ~X2APIC_ENABLE;
>>  break;
>> +case MSR_PLATFORM_INFO:
>> +val &= ~CPUID_FAULTING_SUPPORT;
>> +break;
>>  }
>>  return val;
>>  }
> 
> Does this mean that Xen guests effectively can't take advantage of this
> feature?

PV guests only.

David

Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[David Vrabel]

On 14/09/16 22:35, Dave Hansen wrote:
> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
> 
> That needs to make it into a comment, please.
> 
> That *is* a Xen bug, right?

This is probably fixed in the latest version of Xen.  Andrew Cooper
would know for sure.

>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int 
>> *err)
>>  #endif
>>  val &= ~X2APIC_ENABLE;
>>  break;
>> +case MSR_PLATFORM_INFO:
>> +val &= ~CPUID_FAULTING_SUPPORT;
>> +break;
>>  }
>>  return val;
>>  }
> 
> Does this mean that Xen guests effectively can't take advantage of this
> feature?

PV guests only.

David

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[David Vrabel]

On 14/09/16 22:01, Kyle Huey wrote:
> Xen advertises the underlying support for CPUID faulting but not does pass
> through writes to the relevant MSR, nor does it virtualize it, so it does
> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.

Could you clarify in the commit message that it is PV guests that are
affected.

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int *err)
>  #endif
>   val &= ~X2APIC_ENABLE;
>   break;
> + case MSR_PLATFORM_INFO:
> + val &= ~CPUID_FAULTING_SUPPORT;
> + break;
>       }
>   return val;
>  }

Acked-by: David Vrabel <david.vra...@citrix.com>

David

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[David Vrabel]

On 14/09/16 22:01, Kyle Huey wrote:
> Xen advertises the underlying support for CPUID faulting but not does pass
> through writes to the relevant MSR, nor does it virtualize it, so it does
> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.

Could you clarify in the commit message that it is PV guests that are
affected.

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int *err)
>  #endif
>   val &= ~X2APIC_ENABLE;
>   break;
> + case MSR_PLATFORM_INFO:
> + val &= ~CPUID_FAULTING_SUPPORT;
> + break;
>       }
>   return val;
>  }

Acked-by: David Vrabel 

David

[GIT PULL] xen: regression fix for 4.8-rc6

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.8b-rc6-tag

xen: regression fix for 4.8-rc6

- - Fix SMP boot in arm guests.

Thanks.

David

 arch/arm/xen/enlighten.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

Vitaly Kuznetsov (1):
  arm/xen: fix SMP guests boot
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX2VWXAAoJEFxbo/MsZsTRNQkIAIxyFCgLWpNHjOc5xfqHIFXD
rQgVixD+7CzgcQ6uC4JliGykLdWwqhy+2lx/69OJtEQ/49SQqainUeMf+GVZSwjg
jBT2v7jfdCPWu2qcTTG2xWYtNDjP4Wb0A+tMpw0pDZj33eYcoQuCl0lxLjjgOUb8
dUIHo47F2ptxMeugg2HetwhkPOqP9+NfGb3DaoruQy5RfYqul1VniRlfDTurLfIY
nVi0jnhLGrHIDFgtxIZaSHDGl+g5piOlPTXT3UEaTKcsxUJNmWdgGfnFJit7T50h
GkZ8riN/pHrSnT3lEcbia4TsiTIL9MF6Bi9u4yL+yCkINatmL63qDwMxMeFHzxs=
=6N4A
-END PGP SIGNATURE-

[GIT PULL] xen: regression fix for 4.8-rc6

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.8b-rc6-tag

xen: regression fix for 4.8-rc6

- - Fix SMP boot in arm guests.

Thanks.

David

 arch/arm/xen/enlighten.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

Vitaly Kuznetsov (1):
  arm/xen: fix SMP guests boot
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX2VWXAAoJEFxbo/MsZsTRNQkIAIxyFCgLWpNHjOc5xfqHIFXD
rQgVixD+7CzgcQ6uC4JliGykLdWwqhy+2lx/69OJtEQ/49SQqainUeMf+GVZSwjg
jBT2v7jfdCPWu2qcTTG2xWYtNDjP4Wb0A+tMpw0pDZj33eYcoQuCl0lxLjjgOUb8
dUIHo47F2ptxMeugg2HetwhkPOqP9+NfGb3DaoruQy5RfYqul1VniRlfDTurLfIY
nVi0jnhLGrHIDFgtxIZaSHDGl+g5piOlPTXT3UEaTKcsxUJNmWdgGfnFJit7T50h
GkZ8riN/pHrSnT3lEcbia4TsiTIL9MF6Bi9u4yL+yCkINatmL63qDwMxMeFHzxs=
=6N4A
-END PGP SIGNATURE-

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

[David Vrabel]

On 09/09/16 07:14, Juergen Gross wrote:
> On 08/09/16 16:10, Boris Ostrovsky wrote:
>> On 09/02/2016 08:30 AM, Juergen Gross wrote:
>>> Support the driver_override scheme introduced with commit 782a985d7af2
>>> ("PCI: Introduce new device binding path using pci_dev.driver_override")
>>>
>>> As pcistub_probe() is called for all devices (it has to check for a
>>> match based on the slot address rather than device type) it has to
>>> check for driver_override set to "pciback" itself.
>>>
>>> Signed-off-by: Juergen Gross 
>>> ---
>>> V2: removed now unused label
>>> ---
>>>  drivers/xen/xen-pciback/pci_stub.c | 16 ++--
>>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
>>> b/drivers/xen/xen-pciback/pci_stub.c
>>> index 258b7c3..85c28f7 100644
>>> --- a/drivers/xen/xen-pciback/pci_stub.c
>>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>>> @@ -25,6 +25,8 @@
>>>  #include "conf_space.h"
>>>  #include "conf_space_quirks.h"
>>>  
>>> +#define PCISTUB_DRIVER_NAME "pciback"
>>> +
>>>  static char *pci_devs_to_hide;
>>>  wait_queue_head_t xen_pcibk_aer_wait_queue;
>>>  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
>>> @@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
>>> struct pci_device_id *id)
>>> "don't have a normal (0) or bridge (1) "
>>> "header type!\n");
>>> err = -ENODEV;
>>> -   goto out;
>>> }
>>>  
>>> +   } else if (!dev->driver_override ||
>>> +  strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
>>> +   /* Didn't find the device */
>>> +   err = -ENODEV;
>>> +
>>> +   if (!err) {
>>> dev_info(>dev, "seizing device\n");
>>> err = pcistub_seize(dev);
>>> -   } else
>>> -   /* Didn't find the device */
>>> -   err = -ENODEV;
>>> +   }
>>
>> Should devices with pciback override be displayed in
>> /sys/bus/pci/drivers/pciback/slots? If they should then they need to be
>> either added to pcistub_device_ids or kept on some other list.
> 
> No, I don't think so. The patch is just needed to _avoid_ having to use
> the slots stuff: without the patch you need something like:
> 
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
> echo :07:10.0 > /sys/bus/pci/drivers_probe
> 
> while with the patch you can use the same mechanism as for similar
> drivers like pci-stub and vfio-pci:
> 
> echo pciback > /sys/bus/pci/devices/\:07\:10.0/driver_override
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers_probe
> 
> So e.g. libvirt doesn't need special handling for pciback. The slot list
> is necessary for assigning devices to pciback on boot, but I think the
> override mechanism is better for runtime assignment.

Can you include something like this in the commit message?

David

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

[David Vrabel]

On 09/09/16 07:14, Juergen Gross wrote:
> On 08/09/16 16:10, Boris Ostrovsky wrote:
>> On 09/02/2016 08:30 AM, Juergen Gross wrote:
>>> Support the driver_override scheme introduced with commit 782a985d7af2
>>> ("PCI: Introduce new device binding path using pci_dev.driver_override")
>>>
>>> As pcistub_probe() is called for all devices (it has to check for a
>>> match based on the slot address rather than device type) it has to
>>> check for driver_override set to "pciback" itself.
>>>
>>> Signed-off-by: Juergen Gross 
>>> ---
>>> V2: removed now unused label
>>> ---
>>>  drivers/xen/xen-pciback/pci_stub.c | 16 ++--
>>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
>>> b/drivers/xen/xen-pciback/pci_stub.c
>>> index 258b7c3..85c28f7 100644
>>> --- a/drivers/xen/xen-pciback/pci_stub.c
>>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>>> @@ -25,6 +25,8 @@
>>>  #include "conf_space.h"
>>>  #include "conf_space_quirks.h"
>>>  
>>> +#define PCISTUB_DRIVER_NAME "pciback"
>>> +
>>>  static char *pci_devs_to_hide;
>>>  wait_queue_head_t xen_pcibk_aer_wait_queue;
>>>  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
>>> @@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
>>> struct pci_device_id *id)
>>> "don't have a normal (0) or bridge (1) "
>>> "header type!\n");
>>> err = -ENODEV;
>>> -   goto out;
>>> }
>>>  
>>> +   } else if (!dev->driver_override ||
>>> +  strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
>>> +   /* Didn't find the device */
>>> +   err = -ENODEV;
>>> +
>>> +   if (!err) {
>>> dev_info(>dev, "seizing device\n");
>>> err = pcistub_seize(dev);
>>> -   } else
>>> -   /* Didn't find the device */
>>> -   err = -ENODEV;
>>> +   }
>>
>> Should devices with pciback override be displayed in
>> /sys/bus/pci/drivers/pciback/slots? If they should then they need to be
>> either added to pcistub_device_ids or kept on some other list.
> 
> No, I don't think so. The patch is just needed to _avoid_ having to use
> the slots stuff: without the patch you need something like:
> 
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers/pciback/new_slot
> echo :07:10.0 > /sys/bus/pci/drivers_probe
> 
> while with the patch you can use the same mechanism as for similar
> drivers like pci-stub and vfio-pci:
> 
> echo pciback > /sys/bus/pci/devices/\:07\:10.0/driver_override
> echo :07:10.0 > /sys/bus/pci/devices/\:07\:10.0/driver/unbind
> echo :07:10.0 > /sys/bus/pci/drivers_probe
> 
> So e.g. libvirt doesn't need special handling for pciback. The slot list
> is necessary for assigning devices to pciback on boot, but I think the
> override mechanism is better for runtime assignment.

Can you include something like this in the commit message?

David

Re: [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Vrabel]

On 22/08/16 16:42, Vitaly Kuznetsov wrote:
> Small packet loss is reported on complex multi host network configurations
> including tunnels, NAT, ... My investigation led me to the following check
> in netback which drops packets:
> 
> if (unlikely(txreq.size < ETH_HLEN)) {
> netdev_err(queue->vif->dev,
>"Bad packet size: %d\n", txreq.size);
> xenvif_tx_err(queue, , extra_count, idx);
> break;
> }
> 
> But this check itself is legitimate. SKBs consist of a linear part (which
> has to have the ethernet header) and (optionally) a number of frags.
> Netfront transmits the head of the linear part up to the page boundary
> as the first request and all the rest becomes frags so when we're
> reconstructing the SKB in netback we can't distinguish between original
> frags and the 'tail' of the linear part. The first SKB needs to be at
> least ETH_HLEN size. So in case we have an SKB with its linear part
> starting too close to the page boundary the packet is lost.
> 
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
>   the original SKB structure. We'll have to add a flag indicating the fact
>   that the particular request is a part of the original linear part and not
>   a frag. We'll need to know the length of the linear part to pre-allocate
>   memory.
> - Avoid transmitting SKBs with linear parts starting too close to the page
>   boundary. That seems preferable short-term and shouldn't bring
>   significant performance degradation as such packets are rare. That's what
>   this patch is trying to achieve with skb_copy().
> 
> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>

We should probably fix the backend to handle this (by grant copying a
minimum amount in the linear area, but since netfront needs to work with
older netback.

Acked-by: David Vrabel <david.vra...@citrix.com>

David

Re: [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Vrabel]

On 22/08/16 16:42, Vitaly Kuznetsov wrote:
> Small packet loss is reported on complex multi host network configurations
> including tunnels, NAT, ... My investigation led me to the following check
> in netback which drops packets:
> 
> if (unlikely(txreq.size < ETH_HLEN)) {
> netdev_err(queue->vif->dev,
>"Bad packet size: %d\n", txreq.size);
> xenvif_tx_err(queue, , extra_count, idx);
> break;
> }
> 
> But this check itself is legitimate. SKBs consist of a linear part (which
> has to have the ethernet header) and (optionally) a number of frags.
> Netfront transmits the head of the linear part up to the page boundary
> as the first request and all the rest becomes frags so when we're
> reconstructing the SKB in netback we can't distinguish between original
> frags and the 'tail' of the linear part. The first SKB needs to be at
> least ETH_HLEN size. So in case we have an SKB with its linear part
> starting too close to the page boundary the packet is lost.
> 
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
>   the original SKB structure. We'll have to add a flag indicating the fact
>   that the particular request is a part of the original linear part and not
>   a frag. We'll need to know the length of the linear part to pre-allocate
>   memory.
> - Avoid transmitting SKBs with linear parts starting too close to the page
>   boundary. That seems preferable short-term and shouldn't bring
>   significant performance degradation as such packets are rare. That's what
>   this patch is trying to achieve with skb_copy().
> 
> Signed-off-by: Vitaly Kuznetsov 

We should probably fix the backend to handle this (by grant copying a
minimum amount in the linear area, but since netfront needs to work with
older netback.

Acked-by: David Vrabel 

David

Re: [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[David Vrabel]

On 07/09/16 10:07, Vitaly Kuznetsov wrote:
> Stefano Stabellini <sstabell...@kernel.org> writes:
> 
>> On Tue, 6 Sep 2016, Vitaly Kuznetsov wrote:
>>> Stefano Stabellini <sstabell...@kernel.org> writes:
>>>
>>>> On Mon, 5 Sep 2016, Vitaly Kuznetsov wrote:
>>>>> Julien Grall <julien.gr...@arm.com> writes:
>>>>>
>>>>>> Hi Vitaly,
>>>>>>
>>>>>> On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>>>>>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>>>>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>>>>>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try 
>>>>>>> booting
>>>>>>> on the vCPU which crashed. This doesn't work very well for PVHVM guests 
>>>>>>> as
>>>>>>> we have a number of hypercalls where we pass vCPU id as a parameter. 
>>>>>>> These
>>>>>>> hypercalls either fail or do something unexpected. To solve the issue
>>>>>>> introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct 
>>>>>>> mapping
>>>>>>> for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
>>>>>>> CPUs it is a bit more trickier. Currently, we initialize IPI vectors
>>>>>>> before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
>>>>>>> instead.
>>>>>>>
>>>>>>> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
>>>>>>> ---
>>>>>>> Changes since v2:
>>>>>>> - Use uint32_t for xen_vcpu_id mapping [Julien Grall]
>>>>>>>
>>>>>>> Changes since v1:
>>>>>>> - Introduce xen_vcpu_nr() helper [David Vrabel]
>>>>>>> - Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
>>>>>>> ---
>>>>>>>  arch/arm/xen/enlighten.c | 10 ++
>>>>>>>  arch/x86/xen/enlighten.c | 23 ++-
>>>>>>>  include/xen/xen-ops.h|  6 ++
>>>>>>>  3 files changed, 38 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>>>>>>> index 75cd734..fe32267 100644
>>>>>>> --- a/arch/arm/xen/enlighten.c
>>>>>>> +++ b/arch/arm/xen/enlighten.c
>>>>>>> @@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
>>>>>>> *)_dummy_shared_info;
>>>>>>>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>>>>>>>  static struct vcpu_info __percpu *xen_vcpu_info;
>>>>>>>
>>>>>>> +/* Linux <-> Xen vCPU id mapping */
>>>>>>> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
>>>>>>> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
>>>>>>> +
>>>>>>>  /* These are unused until we support booting "pre-ballooned" */
>>>>>>>  unsigned long xen_released_pages;
>>>>>>>  struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] 
>>>>>>> __initdata;
>>>>>>> @@ -179,6 +183,9 @@ static void xen_percpu_init(void)
>>>>>>> pr_info("Xen: initializing cpu%d\n", cpu);
>>>>>>> vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>>>>>>>
>>>>>>> +   /* Direct vCPU id mapping for ARM guests. */
>>>>>>> +   per_cpu(xen_vcpu_id, cpu) = cpu;
>>>>>>> +
>>>>>>
>>>>>> We did some internal testing on ARM64 with the latest Linux kernel
>>>>>> (4.8-rc4) and noticed that this patch is breaking SMP support. Sorry
>>>>>> for noticing the issue that late.
>>>>>
>>>>> Sorry for the breakage :-(
>>>>>
>>>>>>
>>>>>> This function is called on the running CPU whilst some code (e.g
>>>>>> init_control_block in drivers/xen/events/events_fifo.c) is executed
>>>>>> whilst preparing the CPU on the boot CPU.
>>>>>>
>>>>>> So xen_vcpu_nr(cpu) will always return 0 in this case and
>>>>>> init_control

Re: [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[David Vrabel]

On 07/09/16 10:07, Vitaly Kuznetsov wrote:
> Stefano Stabellini  writes:
> 
>> On Tue, 6 Sep 2016, Vitaly Kuznetsov wrote:
>>> Stefano Stabellini  writes:
>>>
>>>> On Mon, 5 Sep 2016, Vitaly Kuznetsov wrote:
>>>>> Julien Grall  writes:
>>>>>
>>>>>> Hi Vitaly,
>>>>>>
>>>>>> On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>>>>>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>>>>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>>>>>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try 
>>>>>>> booting
>>>>>>> on the vCPU which crashed. This doesn't work very well for PVHVM guests 
>>>>>>> as
>>>>>>> we have a number of hypercalls where we pass vCPU id as a parameter. 
>>>>>>> These
>>>>>>> hypercalls either fail or do something unexpected. To solve the issue
>>>>>>> introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct 
>>>>>>> mapping
>>>>>>> for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
>>>>>>> CPUs it is a bit more trickier. Currently, we initialize IPI vectors
>>>>>>> before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
>>>>>>> instead.
>>>>>>>
>>>>>>> Signed-off-by: Vitaly Kuznetsov 
>>>>>>> ---
>>>>>>> Changes since v2:
>>>>>>> - Use uint32_t for xen_vcpu_id mapping [Julien Grall]
>>>>>>>
>>>>>>> Changes since v1:
>>>>>>> - Introduce xen_vcpu_nr() helper [David Vrabel]
>>>>>>> - Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
>>>>>>> ---
>>>>>>>  arch/arm/xen/enlighten.c | 10 ++
>>>>>>>  arch/x86/xen/enlighten.c | 23 ++-
>>>>>>>  include/xen/xen-ops.h|  6 ++
>>>>>>>  3 files changed, 38 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>>>>>>> index 75cd734..fe32267 100644
>>>>>>> --- a/arch/arm/xen/enlighten.c
>>>>>>> +++ b/arch/arm/xen/enlighten.c
>>>>>>> @@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
>>>>>>> *)_dummy_shared_info;
>>>>>>>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>>>>>>>  static struct vcpu_info __percpu *xen_vcpu_info;
>>>>>>>
>>>>>>> +/* Linux <-> Xen vCPU id mapping */
>>>>>>> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
>>>>>>> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
>>>>>>> +
>>>>>>>  /* These are unused until we support booting "pre-ballooned" */
>>>>>>>  unsigned long xen_released_pages;
>>>>>>>  struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] 
>>>>>>> __initdata;
>>>>>>> @@ -179,6 +183,9 @@ static void xen_percpu_init(void)
>>>>>>> pr_info("Xen: initializing cpu%d\n", cpu);
>>>>>>> vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>>>>>>>
>>>>>>> +   /* Direct vCPU id mapping for ARM guests. */
>>>>>>> +   per_cpu(xen_vcpu_id, cpu) = cpu;
>>>>>>> +
>>>>>>
>>>>>> We did some internal testing on ARM64 with the latest Linux kernel
>>>>>> (4.8-rc4) and noticed that this patch is breaking SMP support. Sorry
>>>>>> for noticing the issue that late.
>>>>>
>>>>> Sorry for the breakage :-(
>>>>>
>>>>>>
>>>>>> This function is called on the running CPU whilst some code (e.g
>>>>>> init_control_block in drivers/xen/events/events_fifo.c) is executed
>>>>>> whilst preparing the CPU on the boot CPU.
>>>>>>
>>>>>> So xen_vcpu_nr(cpu) will always return 0 in this case and
>>>>>> init_control_block will fail to execute.
>>>>>>
>>>>>
>>>>&g

Re: [Xen-devel] [PATCH] xenbus: Use proc_create_mount_point() to create /proc/xen

[David Vrabel]

On 30/08/16 16:10, Seth Forshee wrote:
> On Tue, Aug 30, 2016 at 04:00:03PM +0100, David Vrabel wrote:
>> On 29/08/16 16:03, Seth Forshee wrote:
>>> Mounting proc in user namespace containers fails if the xenbus
>>> filesystem is mounted on /proc/xen because this directory fails
>>> the "permanently empty" test. proc_create_mount_point() exists
>>> specifically to create such mountpoints in proc but is currently
>>> proc-internal. Export this interface to modules, then use it in
>>> xenbus when creating /proc/xen.
>>
>> Acked-by: David Vrabel <david.vra...@citrix.com>
>>
>> This either needs to be acked by the fs maintainer or go via their tree
>> but you don't appear to have Cc'd the relevant people or lists.
> 
> Huh. I use a script which uses get_maintainer.pl to add the relevant
> maintainers and lists, but appaerntly that failed me this time. Even
> running get_maintainer.pl by hand though it doesn't suggest
> linux-fsdevel though, and it seems it should.

I tend not rely on get_maintainer.pl because it isn't very reliable.
>From MAINTAINERS you want:

FILESYSTEMS (VFS and infrastructure)
M:  Alexander Viro <v...@zeniv.linux.org.uk>
L:  linux-fsde...@vger.kernel.org
S:  Maintained
F:  fs/*

David

Re: [Xen-devel] [PATCH] xenbus: Use proc_create_mount_point() to create /proc/xen

[David Vrabel]

On 30/08/16 16:10, Seth Forshee wrote:
> On Tue, Aug 30, 2016 at 04:00:03PM +0100, David Vrabel wrote:
>> On 29/08/16 16:03, Seth Forshee wrote:
>>> Mounting proc in user namespace containers fails if the xenbus
>>> filesystem is mounted on /proc/xen because this directory fails
>>> the "permanently empty" test. proc_create_mount_point() exists
>>> specifically to create such mountpoints in proc but is currently
>>> proc-internal. Export this interface to modules, then use it in
>>> xenbus when creating /proc/xen.
>>
>> Acked-by: David Vrabel 
>>
>> This either needs to be acked by the fs maintainer or go via their tree
>> but you don't appear to have Cc'd the relevant people or lists.
> 
> Huh. I use a script which uses get_maintainer.pl to add the relevant
> maintainers and lists, but appaerntly that failed me this time. Even
> running get_maintainer.pl by hand though it doesn't suggest
> linux-fsdevel though, and it seems it should.

I tend not rely on get_maintainer.pl because it isn't very reliable.
>From MAINTAINERS you want:

FILESYSTEMS (VFS and infrastructure)
M:  Alexander Viro 
L:  linux-fsde...@vger.kernel.org
S:  Maintained
F:  fs/*

David

Re: [Xen-devel] [PATCH] xenbus: Use proc_create_mount_point() to create /proc/xen

[David Vrabel]

On 29/08/16 16:03, Seth Forshee wrote:
> Mounting proc in user namespace containers fails if the xenbus
> filesystem is mounted on /proc/xen because this directory fails
> the "permanently empty" test. proc_create_mount_point() exists
> specifically to create such mountpoints in proc but is currently
> proc-internal. Export this interface to modules, then use it in
> xenbus when creating /proc/xen.

Acked-by: David Vrabel <david.vra...@citrix.com>

This either needs to be acked by the fs maintainer or go via their tree
but you don't appear to have Cc'd the relevant people or lists.

David

Re: [Xen-devel] [PATCH] xenbus: Use proc_create_mount_point() to create /proc/xen

[David Vrabel]

On 29/08/16 16:03, Seth Forshee wrote:
> Mounting proc in user namespace containers fails if the xenbus
> filesystem is mounted on /proc/xen because this directory fails
> the "permanently empty" test. proc_create_mount_point() exists
> specifically to create such mountpoints in proc but is currently
> proc-internal. Export this interface to modules, then use it in
> xenbus when creating /proc/xen.

Acked-by: David Vrabel 

This either needs to be acked by the fs maintainer or go via their tree
but you don't appear to have Cc'd the relevant people or lists.

David

Re: [Xen-devel] [PATCH] xen/grant-table: Use kmalloc_array() in arch_gnttab_valloc()

[David Vrabel]

On 25/08/16 12:30, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 25 Aug 2016 13:23:06 +0200
> 
> * A multiplication for the size determination of a memory allocation
>   indicated that an array data structure should be processed.
>   Thus reuse the corresponding function "kmalloc_array".
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Replace the specification of a data type by a pointer dereference
>   to make the corresponding size determination a bit safer according to
>   the Linux coding style convention.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH] xen/grant-table: Use kmalloc_array() in arch_gnttab_valloc()

[David Vrabel]

On 25/08/16 12:30, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 25 Aug 2016 13:23:06 +0200
> 
> * A multiplication for the size determination of a memory allocation
>   indicated that an array data structure should be processed.
>   Thus reuse the corresponding function "kmalloc_array".
> 
>   This issue was detected by using the Coccinelle software.
> 
> * Replace the specification of a data type by a pointer dereference
>   to make the corresponding size determination a bit safer according to
>   the Linux coding style convention.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch

[David Vrabel]

On 03/08/16 18:22, Boris Ostrovsky wrote:
> Original version of that patch (commit a89941816726) had to be reverted
> due to Xen allocating irqs in its cpu_up ops.
> 
> The first patch moves allocations into hotplug notifiers and the second
> one restores the original patch (with minor adjustments to new hotplug
> framework)
> 
> This originally went through tip tree but after a couple of failures
> reportedby kbuild robot (due to various combinations of CONFIG_SMP and
> CONFIG_XEN_PVH) I decided to take it through Xen tree (with config problems
> hopefully finally fixed).

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch

[David Vrabel]

On 03/08/16 18:22, Boris Ostrovsky wrote:
> Original version of that patch (commit a89941816726) had to be reverted
> due to Xen allocating irqs in its cpu_up ops.
> 
> The first patch moves allocations into hotplug notifiers and the second
> one restores the original patch (with minor adjustments to new hotplug
> framework)
> 
> This originally went through tip tree but after a couple of failures
> reportedby kbuild robot (due to various combinations of CONFIG_SMP and
> CONFIG_XEN_PVH) I decided to take it through Xen tree (with config problems
> hopefully finally fixed).

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c

[David Vrabel]

On 02/08/16 07:53, Juergen Gross wrote:
> There are two functions with name xen_pmu_init() in the kernel. Rename
> the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in
> arch/x86/xen/pmu.c
> 
> To avoid the same problem in future rename some more functions.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c

[David Vrabel]

On 02/08/16 07:53, Juergen Gross wrote:
> There are two functions with name xen_pmu_init() in the kernel. Rename
> the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in
> arch/x86/xen/pmu.c
> 
> To avoid the same problem in future rename some more functions.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary

[David Vrabel]

On 02/08/16 08:22, Juergen Gross wrote:
> The default for the Xen hypervisor is to not enable VPMU in order to
> avoid security issues. In this case the Linux kernel will issue the
> message "Could not initialize VPMU for cpu 0, error -95" which looks
> more like an error than a normal state.
> 
> Change the message to something less scary in case the hypervisor
> returns EOPNOTSUPP or ENOSYS when trying to activate VPMU.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary

[David Vrabel]

On 02/08/16 08:22, Juergen Gross wrote:
> The default for the Xen hypervisor is to not enable VPMU in order to
> avoid security issues. In this case the Linux kernel will issue the
> message "Could not initialize VPMU for cpu 0, error -95" which looks
> more like an error than a normal state.
> 
> Change the message to something less scary in case the hypervisor
> returns EOPNOTSUPP or ENOSYS when trying to activate VPMU.

Applied to for-linus-4.9, thanks.

David

Re: [Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t

[David Vrabel]

On 29/07/16 10:06, Vitaly Kuznetsov wrote:
> We pass xen_vcpu_id mapping information to hypercalls which require
> uint32_t type so it would be cleaner to have it as uint32_t. The
> initializer to -1 can be dropped as we always do the mapping before using
> it and we never check the 'not set' value anyway.

Applied to for-linus-4.8b, thanks.

David

Re: [Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t

[David Vrabel]

On 29/07/16 10:06, Vitaly Kuznetsov wrote:
> We pass xen_vcpu_id mapping information to hypercalls which require
> uint32_t type so it would be cleaner to have it as uint32_t. The
> initializer to -1 can be dropped as we always do the mapping before using
> it and we never check the 'not set' value anyway.

Applied to for-linus-4.8b, thanks.

David

Re: [Xen-devel] [PATCH] xenbus: don't look up transaction IDs for ordinary writes

[David Vrabel]

On 15/08/16 16:02, Jan Beulich wrote:
> This should really only be done for XS_TRANSACTION_END messages, or
> else at least some of the xenstore-* tools don't work anymore.

Applied to for-linus-4.8b, thanks.

David

Re: [Xen-devel] [PATCH] xenbus: don't look up transaction IDs for ordinary writes

[David Vrabel]

On 15/08/16 16:02, Jan Beulich wrote:
> This should really only be done for XS_TRANSACTION_END messages, or
> else at least some of the xenstore-* tools don't work anymore.

Applied to for-linus-4.8b, thanks.

David

[GIT PULL] xen: regression fix for 4.8-rc3

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.8b-rc3-tag

xen: regression fix for 4.8-rc3

- - Fix a regression in the xenbus device preventing userspace tools
  from working.

Thanks.

David

 arch/arm/xen/enlighten.c | 2 +-
 arch/x86/xen/enlighten.c | 2 +-
 drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
 include/xen/xen-ops.h| 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

Jan Beulich (1):
  xenbus: don't look up transaction IDs for ordinary writes

Vitaly Kuznetsov (1):
  xen: change the type of xen_vcpu_id to uint32_t
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXvdwIAAoJEFxbo/MsZsTR9mAH/1E/8K10KzhYXWy1hS9/Vsfz
Kn2l3ymT8RAANRHq3fL/wFMF+6KPKxbJ7A3CSkismPLZTnPA4WuKp/CiLEVBS3vm
GONWXLBlcWVttAxfsMd9tFAz9VHP2MsYy2iRzaTeBmmouBrjKb/FygUctHgPhGjI
9793Pw10TfVEc2efmSM06c6Jfy26mcclQ8gisOlT6TyjJbBMiRXhc2LjHDpD9jYy
wIKirBwSaL7oN+CM1ua/apu+n7h/bXg+bSsDWqdu7e+vETgVxwrk5kflgcENf+pO
bBn5LR8fMeFd6WrQfWkVpSX7gRFBBAH+XkMdYo7C/s5MYuL143dVdq9ZbAlfVr8=
=L0YJ
-END PGP SIGNATURE-

[GIT PULL] xen: regression fix for 4.8-rc3

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.8b-rc3-tag

xen: regression fix for 4.8-rc3

- - Fix a regression in the xenbus device preventing userspace tools
  from working.

Thanks.

David

 arch/arm/xen/enlighten.c | 2 +-
 arch/x86/xen/enlighten.c | 2 +-
 drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
 include/xen/xen-ops.h| 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

Jan Beulich (1):
  xenbus: don't look up transaction IDs for ordinary writes

Vitaly Kuznetsov (1):
  xen: change the type of xen_vcpu_id to uint32_t
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXvdwIAAoJEFxbo/MsZsTR9mAH/1E/8K10KzhYXWy1hS9/Vsfz
Kn2l3ymT8RAANRHq3fL/wFMF+6KPKxbJ7A3CSkismPLZTnPA4WuKp/CiLEVBS3vm
GONWXLBlcWVttAxfsMd9tFAz9VHP2MsYy2iRzaTeBmmouBrjKb/FygUctHgPhGjI
9793Pw10TfVEc2efmSM06c6Jfy26mcclQ8gisOlT6TyjJbBMiRXhc2LjHDpD9jYy
wIKirBwSaL7oN+CM1ua/apu+n7h/bXg+bSsDWqdu7e+vETgVxwrk5kflgcENf+pO
bBn5LR8fMeFd6WrQfWkVpSX7gRFBBAH+XkMdYo7C/s5MYuL143dVdq9ZbAlfVr8=
=L0YJ
-END PGP SIGNATURE-

Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Vrabel]

On 22/08/16 16:42, Vitaly Kuznetsov wrote:
> 
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
>   the original SKB structure. We'll have to add a flag indicating the fact
>   that the particular request is a part of the original linear part and not
>   a frag. We'll need to know the length of the linear part to pre-allocate
>   memory.

I don't think there needs to be a protocol change.  I think the check in
netback is bogus -- it's the total packet length that must be >
HLEN_ETH.  The upper layers will pull any headers from the frags as
needed (or if necessary, netback could pull a minimum amount).

There's no need to preserve the skb layout (e.g., look how the to-guest
direction we do not do this).

David

Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Vrabel]

On 22/08/16 16:42, Vitaly Kuznetsov wrote:
> 
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
>   the original SKB structure. We'll have to add a flag indicating the fact
>   that the particular request is a part of the original linear part and not
>   a frag. We'll need to know the length of the linear part to pre-allocate
>   memory.

I don't think there needs to be a protocol change.  I think the check in
netback is bogus -- it's the total packet length that must be >
HLEN_ETH.  The upper layers will pull any headers from the frags as
needed (or if necessary, netback could pull a minimum amount).

There's no need to preserve the skb layout (e.g., look how the to-guest
direction we do not do this).

David

Re: [Xen-devel] [PATCH 2/2] xen/events: Convert to hotplug state machine

[David Vrabel]

On 15/08/16 15:46, Boris Ostrovsky wrote:
> From: Sebastian Andrzej Siewior 
> 
> Install the callbacks via the state machine.
[...]
> +static int xen_evtchn_cpu_dead(unsigned int cpu)
> +{
> + __evtchn_fifo_handle_events(cpu, true);
> + return 0;
> +}

I'm not familiar with the new state machine.  When this is called, what
state is the CPU in?

In particular, local interrupts must be disabled and all non-percpu irqs
must have been migrated to other CPUs.


>  int __init xen_evtchn_fifo_init(void)
>  {
> @@ -456,7 +444,9 @@ int __init xen_evtchn_fifo_init(void)
>  
>   evtchn_ops = _ops_fifo;
>  
> - register_cpu_notifier(_fifo_cpu_notifier);
> + cpuhp_setup_state_nocalls(CPUHP_XEN_EVTCHN_PREPARE,
> +   "CPUHP_XEN_EVTCHN_PREPARE",
> +   xen_evtchn_cpu_prepare, xen_evtchn_cpu_dead);
>  out:
>   put_cpu();
>   return ret;
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index d6beeb9..c60a17c 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -22,6 +22,7 @@ enum cpuhp_state {
>   CPUHP_SMPCFD_PREPARE,
>   CPUHP_RCUTREE_PREP,
>   CPUHP_XEN_PREPARE,
> + CPUHP_XEN_EVTCHN_PREPARE,
>   CPUHP_NOTIFY_PREPARE,
>   CPUHP_TIMERS_DEAD,
>   CPUHP_BRINGUP_CPU,
> 

Re: [Xen-devel] [PATCH 2/2] xen/events: Convert to hotplug state machine

[David Vrabel]

On 15/08/16 15:46, Boris Ostrovsky wrote:
> From: Sebastian Andrzej Siewior 
> 
> Install the callbacks via the state machine.
[...]
> +static int xen_evtchn_cpu_dead(unsigned int cpu)
> +{
> + __evtchn_fifo_handle_events(cpu, true);
> + return 0;
> +}

I'm not familiar with the new state machine.  When this is called, what
state is the CPU in?

In particular, local interrupts must be disabled and all non-percpu irqs
must have been migrated to other CPUs.


>  int __init xen_evtchn_fifo_init(void)
>  {
> @@ -456,7 +444,9 @@ int __init xen_evtchn_fifo_init(void)
>  
>   evtchn_ops = _ops_fifo;
>  
> - register_cpu_notifier(_fifo_cpu_notifier);
> + cpuhp_setup_state_nocalls(CPUHP_XEN_EVTCHN_PREPARE,
> +   "CPUHP_XEN_EVTCHN_PREPARE",
> +   xen_evtchn_cpu_prepare, xen_evtchn_cpu_dead);
>  out:
>   put_cpu();
>   return ret;
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index d6beeb9..c60a17c 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -22,6 +22,7 @@ enum cpuhp_state {
>   CPUHP_SMPCFD_PREPARE,
>   CPUHP_RCUTREE_PREP,
>   CPUHP_XEN_PREPARE,
> + CPUHP_XEN_EVTCHN_PREPARE,
>   CPUHP_NOTIFY_PREPARE,
>   CPUHP_TIMERS_DEAD,
>   CPUHP_BRINGUP_CPU,
> 

Re: [Xen-devel] [PATCH linux] xen: change the type of xen_vcpu_id to uint32_t

[David Vrabel]

On 28/07/16 17:24, Vitaly Kuznetsov wrote:
> We pass xen_vcpu_id mapping information to hypercalls which require
> uint32_t type so it would be cleaner to have it as uint32_t. The
> initializer to -1 can be dropped as we always do the mapping before using
> it and we never check the 'not set' value anyway.
[...]
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -9,7 +9,7 @@
>  
>  DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
>  
> -DECLARE_PER_CPU(int, xen_vcpu_id);
> +DECLARE_PER_CPU(uint32_t, xen_vcpu_id);
>  static inline int xen_vcpu_nr(int cpu)

Should the return type of this change to uint32_t as well?

>  {
>   return per_cpu(xen_vcpu_id, cpu);
> 

David

Re: [Xen-devel] [PATCH linux] xen: change the type of xen_vcpu_id to uint32_t

[David Vrabel]

On 28/07/16 17:24, Vitaly Kuznetsov wrote:
> We pass xen_vcpu_id mapping information to hypercalls which require
> uint32_t type so it would be cleaner to have it as uint32_t. The
> initializer to -1 can be dropped as we always do the mapping before using
> it and we never check the 'not set' value anyway.
[...]
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -9,7 +9,7 @@
>  
>  DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
>  
> -DECLARE_PER_CPU(int, xen_vcpu_id);
> +DECLARE_PER_CPU(uint32_t, xen_vcpu_id);
>  static inline int xen_vcpu_nr(int cpu)

Should the return type of this change to uint32_t as well?

>  {
>   return per_cpu(xen_vcpu_id, cpu);
> 

David

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[David Vrabel]

On 27/07/16 04:21, Bob Liu wrote:
> The current VBD layer reserves buffer space for each attached device based on
> three statically configured settings which are read at boot time.
>  * max_indirect_segs: Maximum amount of segments.
>  * max_ring_page_order: Maximum order of pages to be used for the shared ring.
>  * max_queues: Maximum of queues(rings) to be used.

I think you want a single knob for "maximum number of pages in flight".
 This is much easier for an admin to relate to resource usage.

You could apply this limit without having to reconfigure, which would
simplify this patch quite a bit.

David

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[David Vrabel]

On 27/07/16 04:21, Bob Liu wrote:
> The current VBD layer reserves buffer space for each attached device based on
> three statically configured settings which are read at boot time.
>  * max_indirect_segs: Maximum amount of segments.
>  * max_ring_page_order: Maximum order of pages to be used for the shared ring.
>  * max_queues: Maximum of queues(rings) to be used.

I think you want a single knob for "maximum number of pages in flight".
 This is much easier for an admin to relate to resource usage.

You could apply this limit without having to reconfigure, which would
simplify this patch quite a bit.

David

[GIT PULL] xen: features and fixes for 4.8-rc0

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8-rc0-tag

xen: features and fixes for 4.8-rc0

- - ACPI support for guests on ARM platforms.
- - Generic steal time support for arm and x86.
- - Support cases where kernel cpu is not Xen VCPU number (e.g., if
  in-guest kexec is used).
- - Use the system workqueue instead of a custom workqueue in various
  places.

Thanks.

David

 Documentation/devicetree/bindings/arm/xen.txt |  35 +
 arch/arm/include/asm/xen/hypercall.h  |   1 +
 arch/arm/include/asm/xen/xen-ops.h|   6 +
 arch/arm/kernel/setup.c   |   2 +-
 arch/arm/xen/Makefile |   1 +
 arch/arm/xen/efi.c|  40 ++
 arch/arm/xen/enlighten.c  | 157 +++--
 arch/arm/xen/hypercall.S  |   1 +
 arch/arm64/include/asm/xen/xen-ops.h  |   6 +
 arch/arm64/kernel/setup.c |   3 +-
 arch/arm64/xen/Makefile   |   1 +
 arch/arm64/xen/hypercall.S|   1 +
 arch/x86/include/asm/cpu.h|   1 +
 arch/x86/include/asm/smp.h|   2 +
 arch/x86/include/asm/xen/cpuid.h  |   5 +-
 arch/x86/kernel/acpi/boot.c   |  16 ++-
 arch/x86/kernel/apic/apic.c   |   2 +
 arch/x86/kernel/setup_percpu.c|   3 +
 arch/x86/xen/efi.c| 111 +++
 arch/x86/xen/enlighten.c  |  49 +--
 arch/x86/xen/grant-table.c|  57 +---
 arch/x86/xen/irq.c|   3 +-
 arch/x86/xen/pmu.c|   2 +-
 arch/x86/xen/smp.c|  18 ++-
 arch/x86/xen/time.c   |  63 ++---
 arch/x86/xen/xen-ops.h|   1 +
 drivers/acpi/scan.c   |  74 ++
 drivers/block/xen-blkback/xenbus.c|  20 +--
 drivers/block/xen-blkfront.c  |  43 +++---
 drivers/firmware/efi/arm-runtime.c|   5 +
 drivers/firmware/efi/efi.c|  81 ---
 drivers/of/fdt.c  |  13 ++
 drivers/xen/Kconfig   |   2 +-
 drivers/xen/Makefile  |   1 +
 drivers/xen/arm-device.c  | 196 ++
 drivers/xen/efi.c | 173 +--
 drivers/xen/events/events_base.c  |  13 +-
 drivers/xen/events/events_fifo.c  |   2 +-
 drivers/xen/evtchn.c  |  43 +-
 drivers/xen/gntalloc.c|   2 +-
 drivers/xen/gntdev.c  |   2 +-
 drivers/xen/privcmd.c |   2 +-
 drivers/xen/time.c|  50 +--
 drivers/xen/xen-pciback/conf_space.c  |  22 ++-
 drivers/xen/xen-pciback/conf_space_header.c   |  57 +++-
 drivers/xen/xen-pciback/pciback.h |   1 -
 drivers/xen/xen-pciback/pciback_ops.c |   2 +-
 drivers/xen/xen-pciback/xenbus.c  |  10 +-
 drivers/xen/xenbus/xenbus_probe_frontend.c|  15 +-
 drivers/xen/xlate_mmu.c   |  77 ++
 include/linux/kernel_stat.h   |   1 -
 include/linux/of_fdt.h|   2 +
 include/uapi/xen/evtchn.h |  15 ++
 include/xen/interface/hvm/params.h|  40 +-
 include/xen/interface/memory.h|   1 +
 include/xen/interface/vcpu.h  |  24 ++--
 include/xen/interface/xen.h   |  17 ++-
 include/xen/xen-ops.h |  40 --
 kernel/sched/cputime.c|  10 --
 59 files changed, 1150 insertions(+), 493 deletions(-)

Amitoj Kaur Chawla (1):
  x86/xen: Use DIV_ROUND_UP

Bhaktipriya Shridhar (2):
  xen: xen-pciback: Remove create_workqueue
  xen: xenbus: Remove create_workqueue

Boris Ostrovsky (1):
  xen/PMU: Log VPMU initialization error at lower level

David Vrabel (1):
  xen/evtchn: add IOCTL_EVTCHN_RESTRICT

Jan Beulich (11):
  xen-pciback: drop unused function parameter of read_dev_bar()
  xen-pciback: drop rom_init()
  xen-pciback: fold read_dev_bar() into its now single caller
  xen-pciback: simplify determination of 64-bit memory resource
  xen-pciback: use const and unsigned in bar_init()
  xen-pciback: short-circuit read path used for merging write values
  xen-pciback: drop superfluous variables
  xen-blkback: prefer xenbus_scanf() over xenbus_gather()
  xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
  xen-blkback: constify instance of "struct attribute_group"
  xen-blkback: really don't leak mod

[GIT PULL] xen: features and fixes for 4.8-rc0

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8-rc0-tag

xen: features and fixes for 4.8-rc0

- - ACPI support for guests on ARM platforms.
- - Generic steal time support for arm and x86.
- - Support cases where kernel cpu is not Xen VCPU number (e.g., if
  in-guest kexec is used).
- - Use the system workqueue instead of a custom workqueue in various
  places.

Thanks.

David

 Documentation/devicetree/bindings/arm/xen.txt |  35 +
 arch/arm/include/asm/xen/hypercall.h  |   1 +
 arch/arm/include/asm/xen/xen-ops.h|   6 +
 arch/arm/kernel/setup.c   |   2 +-
 arch/arm/xen/Makefile |   1 +
 arch/arm/xen/efi.c|  40 ++
 arch/arm/xen/enlighten.c  | 157 +++--
 arch/arm/xen/hypercall.S  |   1 +
 arch/arm64/include/asm/xen/xen-ops.h  |   6 +
 arch/arm64/kernel/setup.c |   3 +-
 arch/arm64/xen/Makefile   |   1 +
 arch/arm64/xen/hypercall.S|   1 +
 arch/x86/include/asm/cpu.h|   1 +
 arch/x86/include/asm/smp.h|   2 +
 arch/x86/include/asm/xen/cpuid.h  |   5 +-
 arch/x86/kernel/acpi/boot.c   |  16 ++-
 arch/x86/kernel/apic/apic.c   |   2 +
 arch/x86/kernel/setup_percpu.c|   3 +
 arch/x86/xen/efi.c| 111 +++
 arch/x86/xen/enlighten.c  |  49 +--
 arch/x86/xen/grant-table.c|  57 +---
 arch/x86/xen/irq.c|   3 +-
 arch/x86/xen/pmu.c|   2 +-
 arch/x86/xen/smp.c|  18 ++-
 arch/x86/xen/time.c   |  63 ++---
 arch/x86/xen/xen-ops.h|   1 +
 drivers/acpi/scan.c   |  74 ++
 drivers/block/xen-blkback/xenbus.c|  20 +--
 drivers/block/xen-blkfront.c  |  43 +++---
 drivers/firmware/efi/arm-runtime.c|   5 +
 drivers/firmware/efi/efi.c|  81 ---
 drivers/of/fdt.c  |  13 ++
 drivers/xen/Kconfig   |   2 +-
 drivers/xen/Makefile  |   1 +
 drivers/xen/arm-device.c  | 196 ++
 drivers/xen/efi.c | 173 +--
 drivers/xen/events/events_base.c  |  13 +-
 drivers/xen/events/events_fifo.c  |   2 +-
 drivers/xen/evtchn.c  |  43 +-
 drivers/xen/gntalloc.c|   2 +-
 drivers/xen/gntdev.c  |   2 +-
 drivers/xen/privcmd.c |   2 +-
 drivers/xen/time.c|  50 +--
 drivers/xen/xen-pciback/conf_space.c  |  22 ++-
 drivers/xen/xen-pciback/conf_space_header.c   |  57 +++-
 drivers/xen/xen-pciback/pciback.h |   1 -
 drivers/xen/xen-pciback/pciback_ops.c |   2 +-
 drivers/xen/xen-pciback/xenbus.c  |  10 +-
 drivers/xen/xenbus/xenbus_probe_frontend.c|  15 +-
 drivers/xen/xlate_mmu.c   |  77 ++
 include/linux/kernel_stat.h   |   1 -
 include/linux/of_fdt.h|   2 +
 include/uapi/xen/evtchn.h |  15 ++
 include/xen/interface/hvm/params.h|  40 +-
 include/xen/interface/memory.h|   1 +
 include/xen/interface/vcpu.h  |  24 ++--
 include/xen/interface/xen.h   |  17 ++-
 include/xen/xen-ops.h |  40 --
 kernel/sched/cputime.c|  10 --
 59 files changed, 1150 insertions(+), 493 deletions(-)

Amitoj Kaur Chawla (1):
  x86/xen: Use DIV_ROUND_UP

Bhaktipriya Shridhar (2):
  xen: xen-pciback: Remove create_workqueue
  xen: xenbus: Remove create_workqueue

Boris Ostrovsky (1):
  xen/PMU: Log VPMU initialization error at lower level

David Vrabel (1):
  xen/evtchn: add IOCTL_EVTCHN_RESTRICT

Jan Beulich (11):
  xen-pciback: drop unused function parameter of read_dev_bar()
  xen-pciback: drop rom_init()
  xen-pciback: fold read_dev_bar() into its now single caller
  xen-pciback: simplify determination of 64-bit memory resource
  xen-pciback: use const and unsigned in bar_init()
  xen-pciback: short-circuit read path used for merging write values
  xen-pciback: drop superfluous variables
  xen-blkback: prefer xenbus_scanf() over xenbus_gather()
  xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
  xen-blkback: constify instance of "struct attribute_group"
  xen-blkback: really don't leak mod

Re: [Xen-devel] [PATCH] xen: add static initialization of steal_clock op to xen_time_ops

[David Vrabel]

On 26/07/16 13:15, Juergen Gross wrote:
> pv_time_ops might be overwritten with xen_time_ops after the
> steal_clock operation has been initialized already. To prevent calling
> a now uninitialized function pointer add the steal_clock static
> initialization to xen_time_ops.

Applied to for-linus-4.8, thanks.

David

Re: [Xen-devel] [PATCH] xen: add static initialization of steal_clock op to xen_time_ops

[David Vrabel]

On 26/07/16 13:15, Juergen Gross wrote:
> pv_time_ops might be overwritten with xen_time_ops after the
> steal_clock operation has been initialized already. To prevent calling
> a now uninitialized function pointer add the steal_clock static
> initialization to xen_time_ops.

Applied to for-linus-4.8, thanks.

David

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 26/07/16 13:30, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
> we have a number of hypercalls where we pass vCPU id as a parameter. These
> hypercalls either fail or do something unexpected. To solve the issue we
> need to have a mapping between Linux's and Xen's vCPU ids.
> 
> This series solves the issue for x86 PVHVM guests. PV guests don't (and
> probably won't) support kdump so I always assume Xen's vCPU id == Linux's
> vCPU id. ARM guests will probably need to get proper mapping once we start
> supporting kexec/kdump there.
> 
> Changes since v2:
> - Use 'uint32_t' for xen_vcpu_id mapping [Julien Grall]
> - Rebased to linux-4.7

I already applied v2.  If you provide an incremental patch I can queue
it for 4.9.

David

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 26/07/16 13:30, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
> we have a number of hypercalls where we pass vCPU id as a parameter. These
> hypercalls either fail or do something unexpected. To solve the issue we
> need to have a mapping between Linux's and Xen's vCPU ids.
> 
> This series solves the issue for x86 PVHVM guests. PV guests don't (and
> probably won't) support kdump so I always assume Xen's vCPU id == Linux's
> vCPU id. ARM guests will probably need to get proper mapping once we start
> supporting kexec/kdump there.
> 
> Changes since v2:
> - Use 'uint32_t' for xen_vcpu_id mapping [Julien Grall]
> - Rebased to linux-4.7

I already applied v2.  If you provide an incremental patch I can queue
it for 4.9.

David

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 25/07/16 15:01, Julien Grall wrote:
> Hello,
> 
> On 25/07/16 14:39, Vitaly Kuznetsov wrote:
>> Julien Grall <julien.gr...@arm.com> writes:
>>
>>> Hi David,
>>>
>>> On 25/07/16 13:38, David Vrabel wrote:
>>>> On 30/06/16 16:56, Vitaly Kuznetsov wrote:
>>>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>>>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try
>>>>> booting
>>>>> on the vCPU which crashed. This doesn't work very well for PVHVM
>>>>> guests as
>>>>> we have a number of hypercalls where we pass vCPU id as a
>>>>> parameter. These
>>>>> hypercalls either fail or do something unexpected. To solve the
>>>>> issue we
>>>>> need to have a mapping between Linux's and Xen's vCPU ids.
>>>>>
>>>>> This series solves the issue for x86 PVHVM guests. PV guests don't
>>>>> (and
>>>>> probably won't) support kdump so I always assume Xen's vCPU id ==
>>>>> Linux's
>>>>> vCPU id. ARM guests will probably need to get proper mapping once
>>>>> we start
>>>>> supporting kexec/kdump there.
>>>>
>>>> Applied to for-linus-4.8, thanks.
>>>
>>> It would have been nice to send a ping before applying. This patch
>>> series is containing Xen ARM code which has not been acked by Stefano,
>>> nor had feedback from ARM side.
>>>
>>> For instance given that all the hypercalls are representing a "vcpu
>>> id" using "uint32_t" it is a bit weird to use "int" to define
>>> xen_vcpu_id (see patch #3).
>>
>> CPU id is usually 'int' in linux and now we pass it to all
>> hypercalls as it is.
> 
> Well, we need to differentiate between the internal representation of
> the CPU which is based on the boot order and the logical CPU ID. For
> instance on ARM, the logical CPU ID may not be contiguous nor 0 for the
> first CPU.
> 
> From my understanding, the macros in patch #3 will be used at the last
> minute when prepare the hypercall data. IHMO this is very similar to a
> logical ID and defined as uint32_t by the hypercall ABI.
> 
> Although, I agree that currently we use the internal CPU id on ARM which
> is very unfortunate because this value is based on the order of the
> nodes in the device tree.
> 
> One way to abolish it on ARM would be to use the MPIDR (or at least a
> part) for the VCPU ID.
> 
>> It is a bit more convenient in the mapping I
>> introduce as we can set it to a negative value to indicate there is no
>> mapping available. I can definitely change that and use something like
>> U32_MAX-1 to instead but I'm not sure it is worth it...
> 
> I looked at the definition of cpu_acpi_id on x86 which return
> x86_cpu_to_acpiid that has been defined to an uint32_t.
> 
> So you are assuming that it will never be possible to have an ID >
> 0x8000.
> 
> Also, this may not be true on ARM depending how we define the VCPU
> mapping. We could decide to use the MPIDR which is in this case may be
> considered as "negative".

If you want to change how you number vCPUs on ARM in the future, you can
(if necessary) change the type of this per-cpu variable as well.

David

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 25/07/16 15:01, Julien Grall wrote:
> Hello,
> 
> On 25/07/16 14:39, Vitaly Kuznetsov wrote:
>> Julien Grall  writes:
>>
>>> Hi David,
>>>
>>> On 25/07/16 13:38, David Vrabel wrote:
>>>> On 30/06/16 16:56, Vitaly Kuznetsov wrote:
>>>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>>>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try
>>>>> booting
>>>>> on the vCPU which crashed. This doesn't work very well for PVHVM
>>>>> guests as
>>>>> we have a number of hypercalls where we pass vCPU id as a
>>>>> parameter. These
>>>>> hypercalls either fail or do something unexpected. To solve the
>>>>> issue we
>>>>> need to have a mapping between Linux's and Xen's vCPU ids.
>>>>>
>>>>> This series solves the issue for x86 PVHVM guests. PV guests don't
>>>>> (and
>>>>> probably won't) support kdump so I always assume Xen's vCPU id ==
>>>>> Linux's
>>>>> vCPU id. ARM guests will probably need to get proper mapping once
>>>>> we start
>>>>> supporting kexec/kdump there.
>>>>
>>>> Applied to for-linus-4.8, thanks.
>>>
>>> It would have been nice to send a ping before applying. This patch
>>> series is containing Xen ARM code which has not been acked by Stefano,
>>> nor had feedback from ARM side.
>>>
>>> For instance given that all the hypercalls are representing a "vcpu
>>> id" using "uint32_t" it is a bit weird to use "int" to define
>>> xen_vcpu_id (see patch #3).
>>
>> CPU id is usually 'int' in linux and now we pass it to all
>> hypercalls as it is.
> 
> Well, we need to differentiate between the internal representation of
> the CPU which is based on the boot order and the logical CPU ID. For
> instance on ARM, the logical CPU ID may not be contiguous nor 0 for the
> first CPU.
> 
> From my understanding, the macros in patch #3 will be used at the last
> minute when prepare the hypercall data. IHMO this is very similar to a
> logical ID and defined as uint32_t by the hypercall ABI.
> 
> Although, I agree that currently we use the internal CPU id on ARM which
> is very unfortunate because this value is based on the order of the
> nodes in the device tree.
> 
> One way to abolish it on ARM would be to use the MPIDR (or at least a
> part) for the VCPU ID.
> 
>> It is a bit more convenient in the mapping I
>> introduce as we can set it to a negative value to indicate there is no
>> mapping available. I can definitely change that and use something like
>> U32_MAX-1 to instead but I'm not sure it is worth it...
> 
> I looked at the definition of cpu_acpi_id on x86 which return
> x86_cpu_to_acpiid that has been defined to an uint32_t.
> 
> So you are assuming that it will never be possible to have an ID >
> 0x8000.
> 
> Also, this may not be true on ARM depending how we define the VCPU
> mapping. We could decide to use the MPIDR which is in this case may be
> considered as "negative".

If you want to change how you number vCPUs on ARM in the future, you can
(if necessary) change the type of this per-cpu variable as well.

David

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 25/07/16 14:17, Julien Grall wrote:
> Hi David,
> 
> On 25/07/16 13:38, David Vrabel wrote:
>> On 30/06/16 16:56, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try
>>> booting
>>> on the vCPU which crashed. This doesn't work very well for PVHVM
>>> guests as
>>> we have a number of hypercalls where we pass vCPU id as a parameter.
>>> These
>>> hypercalls either fail or do something unexpected. To solve the issue we
>>> need to have a mapping between Linux's and Xen's vCPU ids.
>>>
>>> This series solves the issue for x86 PVHVM guests. PV guests don't (and
>>> probably won't) support kdump so I always assume Xen's vCPU id ==
>>> Linux's
>>> vCPU id. ARM guests will probably need to get proper mapping once we
>>> start
>>> supporting kexec/kdump there.
>>
>> Applied to for-linus-4.8, thanks.
> 
> It would have been nice to send a ping before applying. This patch
> series is containing Xen ARM code which has not been acked by Stefano,
> nor had feedback from ARM side.

The ARM parts are trivial and such a small part of this series, I saw no
need to wait.

David

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 25/07/16 14:17, Julien Grall wrote:
> Hi David,
> 
> On 25/07/16 13:38, David Vrabel wrote:
>> On 30/06/16 16:56, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try
>>> booting
>>> on the vCPU which crashed. This doesn't work very well for PVHVM
>>> guests as
>>> we have a number of hypercalls where we pass vCPU id as a parameter.
>>> These
>>> hypercalls either fail or do something unexpected. To solve the issue we
>>> need to have a mapping between Linux's and Xen's vCPU ids.
>>>
>>> This series solves the issue for x86 PVHVM guests. PV guests don't (and
>>> probably won't) support kdump so I always assume Xen's vCPU id ==
>>> Linux's
>>> vCPU id. ARM guests will probably need to get proper mapping once we
>>> start
>>> supporting kexec/kdump there.
>>
>> Applied to for-linus-4.8, thanks.
> 
> It would have been nice to send a ping before applying. This patch
> series is containing Xen ARM code which has not been acked by Stefano,
> nor had feedback from ARM side.

The ARM parts are trivial and such a small part of this series, I saw no
need to wait.

David

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
> we have a number of hypercalls where we pass vCPU id as a parameter. These
> hypercalls either fail or do something unexpected. To solve the issue we
> need to have a mapping between Linux's and Xen's vCPU ids.
> 
> This series solves the issue for x86 PVHVM guests. PV guests don't (and
> probably won't) support kdump so I always assume Xen's vCPU id == Linux's
> vCPU id. ARM guests will probably need to get proper mapping once we start
> supporting kexec/kdump there.

Applied to for-linus-4.8, thanks.

David

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
> we have a number of hypercalls where we pass vCPU id as a parameter. These
> hypercalls either fail or do something unexpected. To solve the issue we
> need to have a mapping between Linux's and Xen's vCPU ids.
> 
> This series solves the issue for x86 PVHVM guests. PV guests don't (and
> probably won't) support kdump so I always assume Xen's vCPU id == Linux's
> vCPU id. ARM guests will probably need to get proper mapping once we start
> supporting kexec/kdump there.

Applied to for-linus-4.8, thanks.

David

Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

[David Vrabel]

On 14/07/16 15:24, Dave Hansen wrote:
> On 07/14/2016 06:47 AM, Vlastimil Babka wrote:
>> So, this might be just because I know next to nothing about (para)virt,
>> but...
>>
>> in arch/x86/include/asm/paravirt.h, pte_val is implemented via some
>> pvops, which suggests that obtaining a pte value is different than just
>> reading it from memory. But I don't see pte_none() defined to be using
>> this on paravirt, and it shares (before patch 2/4) the "return !pte.pte"
>> implementation, AFAICS?
>>
>> So that itself is suspicious to me. And now that this patches does
>> things like this:
>>
>> -  if (pte_val(*pte)) {
>> +  if (!pte_none(*pte)) {
>>
>> So previously on paravirt these tests would read pte via the pvops, and
>> now they won't. Is that OK?
> 
> I've cc'd a few Xen guys.  I think they're the only ones that would care.
> 
> But, as far as I can tell, the Xen pte_val() will take a _PAGE_PRESENT
> PTE and muck with it.  But its answer will never differ for an all 0 PTE
> from !pte_none() because that PTE does not have _PAGE_PRESENT set.
> 
> It does seem fragile that Xen is doing it this way, but I guess it works.

Xen PV guests never plays games with non-present PTEs so, for the
series, wrt Xen:

Acked-by: David Vrabel <david.vra...@citrix.com>

FWIW, present PTEs have a hardware-specified meaning where-as
non-present PTEs do not, so I'm not sure I'd view Xen PV guests making
this distinct as "fragile".


David

Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

[David Vrabel]

On 14/07/16 15:24, Dave Hansen wrote:
> On 07/14/2016 06:47 AM, Vlastimil Babka wrote:
>> So, this might be just because I know next to nothing about (para)virt,
>> but...
>>
>> in arch/x86/include/asm/paravirt.h, pte_val is implemented via some
>> pvops, which suggests that obtaining a pte value is different than just
>> reading it from memory. But I don't see pte_none() defined to be using
>> this on paravirt, and it shares (before patch 2/4) the "return !pte.pte"
>> implementation, AFAICS?
>>
>> So that itself is suspicious to me. And now that this patches does
>> things like this:
>>
>> -  if (pte_val(*pte)) {
>> +  if (!pte_none(*pte)) {
>>
>> So previously on paravirt these tests would read pte via the pvops, and
>> now they won't. Is that OK?
> 
> I've cc'd a few Xen guys.  I think they're the only ones that would care.
> 
> But, as far as I can tell, the Xen pte_val() will take a _PAGE_PRESENT
> PTE and muck with it.  But its answer will never differ for an all 0 PTE
> from !pte_none() because that PTE does not have _PAGE_PRESENT set.
> 
> It does seem fragile that Xen is doing it this way, but I guess it works.

Xen PV guests never plays games with non-present PTEs so, for the
series, wrt Xen:

Acked-by: David Vrabel 

FWIW, present PTEs have a hardware-specified meaning where-as
non-present PTEs do not, so I'm not sure I'd view Xen PV guests making
this distinct as "fragile".


David

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

[David Vrabel]

On 13/07/16 13:20, Petr Tesarik wrote:
> If a crash kernel is loaded, do not crash the running domain. This is
> needed if the kernel is loaded with crash_kexec_post_notifiers, because
> panic notifiers are run before __crash_kexec() in that case, and this
> Xen hook prevents its being called later.

Prioritising the in-kernel kexec image over the hypervisor one seems
sensible behaviour to me.

Reviewed-by: David Vrabel <david.vra...@citrix.com>

David

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

[David Vrabel]

On 13/07/16 13:20, Petr Tesarik wrote:
> If a crash kernel is loaded, do not crash the running domain. This is
> needed if the kernel is loaded with crash_kexec_post_notifiers, because
> panic notifiers are run before __crash_kexec() in that case, and this
> Xen hook prevents its being called later.

Prioritising the in-kernel kexec image over the hypervisor one seems
sensible behaviour to me.

Reviewed-by: David Vrabel 

David

Re: [Xen-devel] [PATCH] xen_pvscsi: reclaim the ring request when mapping data failed

[David Vrabel]

On 11/07/16 10:33, Juergen Gross wrote:
> On 11/07/16 04:51, Bin Wu wrote:
>> During scsi command queueing, if mapping data fails, we need to
>> reclaim the failed request. Otherwise, the garbage request will
>> be pushed into the ring for the backend to work.
> 
> Well spotted. There is another instance of this problem in
> scsifront_action_handler(). Would you mind correcting this one, too?

Would it make more sense to advance req_prod_pvt only if the request has
been successfully created?

David

>> Signed-off-by: Bin Wu 
>> ---
>>  drivers/scsi/xen-scsifront.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
>> index 9dc8687..655163d 100644
>> --- a/drivers/scsi/xen-scsifront.c
>> +++ b/drivers/scsi/xen-scsifront.c
>> @@ -565,6 +565,7 @@ static int scsifront_queuecommand(struct Scsi_Host
>> *shost,
>>  err = map_data_for_request(info, sc, ring_req, shadow);
>>  if (err < 0) {
>>  pr_debug("%s: err %d\n", __func__, err);
>> +info->ring.req_prod_pvt--;
>>  scsifront_put_rqid(info, rqid);
>>  scsifront_return(info);
>>  spin_unlock_irqrestore(shost->host_lock, flags);
> 
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> https://lists.xen.org/xen-devel
> 

Re: [Xen-devel] [PATCH] xen_pvscsi: reclaim the ring request when mapping data failed

[David Vrabel]

On 11/07/16 10:33, Juergen Gross wrote:
> On 11/07/16 04:51, Bin Wu wrote:
>> During scsi command queueing, if mapping data fails, we need to
>> reclaim the failed request. Otherwise, the garbage request will
>> be pushed into the ring for the backend to work.
> 
> Well spotted. There is another instance of this problem in
> scsifront_action_handler(). Would you mind correcting this one, too?

Would it make more sense to advance req_prod_pvt only if the request has
been successfully created?

David

>> Signed-off-by: Bin Wu 
>> ---
>>  drivers/scsi/xen-scsifront.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
>> index 9dc8687..655163d 100644
>> --- a/drivers/scsi/xen-scsifront.c
>> +++ b/drivers/scsi/xen-scsifront.c
>> @@ -565,6 +565,7 @@ static int scsifront_queuecommand(struct Scsi_Host
>> *shost,
>>  err = map_data_for_request(info, sc, ring_req, shadow);
>>  if (err < 0) {
>>  pr_debug("%s: err %d\n", __func__, err);
>> +info->ring.req_prod_pvt--;
>>  scsifront_put_rqid(info, rqid);
>>  scsifront_return(info);
>>  spin_unlock_irqrestore(shost->host_lock, flags);
> 
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> https://lists.xen.org/xen-devel
> 

Re: [Xen-devel] [PATCHv3 1/2] libfs: allow simple_fill_super() to add symlinks

[David Vrabel]

On 28/06/16 19:06, David Vrabel wrote:
> simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
> The target is provided in the new "link" field.

Can I get an ack for this, please? So it can go into 4.8 via the Xen tree.

David

> 
> Signed-off-by: David Vrabel <david.vra...@citrix.com>
> ---
> v2:
> - simplified.
> ---
>  fs/libfs.c | 15 +--
>  include/linux/fs.h |  2 +-
>  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/libfs.c b/fs/libfs.c
> index cedeacb..bbf2d82 100644
> --- a/fs/libfs.c
> +++ b/fs/libfs.c
> @@ -512,9 +512,20 @@ int simple_fill_super(struct super_block *s, unsigned 
> long magic,
>   dput(dentry);
>   goto out;
>   }
> - inode->i_mode = S_IFREG | files->mode;
> + if (files->mode & S_IFLNK) {
> + inode->i_mode = files->mode;
> + inode->i_op = _symlink_inode_operations;
> + inode->i_link = kstrdup(files->link, GFP_KERNEL);
> + if (!inode->i_link) {
> + iput(inode);
> + dput(dentry);
> + goto out;
> + }
> + } else {
> + inode->i_mode = S_IFREG | files->mode;
> + inode->i_fop = files->ops;
> + }
>   inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
> - inode->i_fop = files->ops;
>   inode->i_ino = i;
>   d_add(dentry, inode);
>   }
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index dd28814..20c54a2 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2953,7 +2953,7 @@ extern const struct file_operations 
> simple_dir_operations;
>  extern const struct inode_operations simple_dir_inode_operations;
>  extern void make_empty_dir_inode(struct inode *inode);
>  extern bool is_empty_dir_inode(struct inode *inode);
> -struct tree_descr { char *name; const struct file_operations *ops; int mode; 
> };
> +struct tree_descr { char *name; const struct file_operations *ops; int mode; 
> char *link; };
>  struct dentry *d_alloc_name(struct dentry *, const char *);
>  extern int simple_fill_super(struct super_block *, unsigned long, struct 
> tree_descr *);
>  extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, 
> int *count);
> 

Re: [Xen-devel] [PATCHv3 1/2] libfs: allow simple_fill_super() to add symlinks

[David Vrabel]

On 28/06/16 19:06, David Vrabel wrote:
> simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
> The target is provided in the new "link" field.

Can I get an ack for this, please? So it can go into 4.8 via the Xen tree.

David

> 
> Signed-off-by: David Vrabel 
> ---
> v2:
> - simplified.
> ---
>  fs/libfs.c | 15 +--
>  include/linux/fs.h |  2 +-
>  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/libfs.c b/fs/libfs.c
> index cedeacb..bbf2d82 100644
> --- a/fs/libfs.c
> +++ b/fs/libfs.c
> @@ -512,9 +512,20 @@ int simple_fill_super(struct super_block *s, unsigned 
> long magic,
>   dput(dentry);
>   goto out;
>   }
> - inode->i_mode = S_IFREG | files->mode;
> + if (files->mode & S_IFLNK) {
> + inode->i_mode = files->mode;
> + inode->i_op = _symlink_inode_operations;
> + inode->i_link = kstrdup(files->link, GFP_KERNEL);
> + if (!inode->i_link) {
> + iput(inode);
> + dput(dentry);
> + goto out;
> + }
> + } else {
> + inode->i_mode = S_IFREG | files->mode;
> + inode->i_fop = files->ops;
> + }
>   inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
> - inode->i_fop = files->ops;
>   inode->i_ino = i;
>   d_add(dentry, inode);
>   }
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index dd28814..20c54a2 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2953,7 +2953,7 @@ extern const struct file_operations 
> simple_dir_operations;
>  extern const struct inode_operations simple_dir_inode_operations;
>  extern void make_empty_dir_inode(struct inode *inode);
>  extern bool is_empty_dir_inode(struct inode *inode);
> -struct tree_descr { char *name; const struct file_operations *ops; int mode; 
> };
> +struct tree_descr { char *name; const struct file_operations *ops; int mode; 
> char *link; };
>  struct dentry *d_alloc_name(struct dentry *, const char *);
>  extern int simple_fill_super(struct super_block *, unsigned long, struct 
> tree_descr *);
>  extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, 
> int *count);
>