Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
and /dev/xen/xenbus via pvops is used instead. This is an effort to
eventually drop this interface after a reasonable amount of time.
Signed-off-by: Doug Goldstein <[email protected]>
---
drivers/xen/Kconfig | 12 ++++++++++++
drivers/xen/xenfs/super.c | 10 ++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..7003984 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -123,6 +123,18 @@ config XEN_COMPAT_XENFS
a xen platform.
If in doubt, say yes.
+config XEN_COMPAT_XENFS_XENBUS
+ bool "xenbus accessible from xenfs"
+ depends on XENFS
+ default y
+ help
+ Since Xen 4.6.0, xenstore will prefer to use the /dev/xen/xenbus
+ device over the "xenbus" interface on the xenfs filesystem.
+ Selecting this causes the kernel to include the "xenbus"
+ interface on the xenfs filesystem and you can safely say no for
+ Xen 4.6.0 and newer.
+ If in doubt, say yes.
+
config XEN_SYS_HYPERVISOR
bool "Create xen entries under /sys/hypervisor"
depends on SYSFS
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..86ff5b3 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -45,14 +45,20 @@ 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", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
+ [2] =
+#ifdef CONFIG_XEN_COMPAT_XENFS_XENBUS
+ { "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
+#endif
{ "capabilities", &capabilities_file_ops, S_IRUGO },
{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
{""},
};
static struct tree_descr xenfs_init_files[] = {
- [2] = { "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
+ [2] =
+#ifdef CONFIG_XEN_COMPAT_XENFS_XENBUS
+ { "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
+#endif
{ "capabilities", &capabilities_file_ops, S_IRUGO },
{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
{ "xsd_kva", &xsd_kva_file_ops, S_IRUSR|S_IWUSR},
--
2.4.10
Since Xen 4.7.0, using privcmd via xenfs (/proc/xen/privcmd) is deprecated
and /dev/xen/privcmd via pvops is used instead. This is an effort to
eventually drop this interface after a reasonable amount of time.
Signed-off-by: Doug Goldstein <[email protected]>
---
drivers/xen/Kconfig | 12 ++++++++++++
drivers/xen/xenfs/super.c | 4 ++++
2 files changed, 16 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 7003984..c610902 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -135,6 +135,18 @@ config XEN_COMPAT_XENFS_XENBUS
Xen 4.6.0 and newer.
If in doubt, say yes.
+config XEN_COMPAT_XENFS_PRIVCMD
+ bool "privcmd accessible from xenfs"
+ depends on XENFS
+ default y
+ help
+ Since Xen 4.7.0, Xen userland will prefer to use the
+ /dev/xen/privcmd device over the "privcmd" interface on the
+ xenfs filesystem. Selecting this causes the kernel to include
+ the "privcmd" interface on the xenfs filesystem and you can
+ safely say no for Xen 4.7.0 and newer.
+ If in doubt, say yes.
+
config XEN_SYS_HYPERVISOR
bool "Create xen entries under /sys/hypervisor"
depends on SYSFS
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 86ff5b3..bb40970b 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -50,7 +50,9 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
#endif
{ "capabilities", &capabilities_file_ops, S_IRUGO },
+#ifdef CONFIG_XEN_COMPAT_XENFS_PRIVCMD
{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
+#endif
{""},
};
@@ -60,7 +62,9 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
#endif
{ "capabilities", &capabilities_file_ops, S_IRUGO },
+#ifdef CONFIG_XEN_COMPAT_XENFS_PRIVCMD
{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
+#endif
{ "xsd_kva", &xsd_kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", &xsd_port_file_ops, S_IRUSR|S_IWUSR},
#ifdef CONFIG_XEN_SYMS
--
2.4.10
On 30/11/15 21:35, Doug Goldstein wrote:
> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
> and /dev/xen/xenbus via pvops is used instead. This is an effort to
> eventually drop this interface after a reasonable amount of time.
I would prefer the /proc/xen/xenbus and /proc/xen/evtchn files to be
replaced with symlinks to the corresponding /dev/xen/ devices. Then I
see no need to ever remove them, thus avoiding the need for yet another
config option.
I did briefly look at this and it seemed possible but didn't get as far
as actually trying to change it.
David
On 01/12/15 10:42, David Vrabel wrote:
> On 30/11/15 21:35, Doug Goldstein wrote:
>> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
>> and /dev/xen/xenbus via pvops is used instead. This is an effort to
>> eventually drop this interface after a reasonable amount of time.
>
> I would prefer the ... /proc/xen/evtchn files to be
I meant /proc/xen/privcmd here.
David
On 12/1/15 4:44 AM, David Vrabel wrote:
> On 01/12/15 10:42, David Vrabel wrote:
>> On 30/11/15 21:35, Doug Goldstein wrote:
>>> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
>>> and /dev/xen/xenbus via pvops is used instead. This is an effort to
>>> eventually drop this interface after a reasonable amount of time.
>>
>> I would prefer the ... /proc/xen/evtchn files to be
>
> I meant /proc/xen/privcmd here.
>
> David
>
I can look into that. I do have a few questions, some of which are out
of scope from the original patch.
Would it be preferable to just remove "xenbus" from the xenfs
filesystem? Ever since Linux 3.14 even if you are running a version of
Xen earlier than 4.6 you will not be able to have a disaggregated
xenstore (which is the xenbus consumer) due to the addition of F_ATOMIC_POS.
Is it safe for a kernel virtual filesystem to provide a symlink outside
of itself where the destination can't be verified? Its possible this
already exists and I just don't know off any cases off the top of my head.
Since the /proc/xen mount point has been marked as COMPAT for nearly 6
years would the eventual goal be to move xenfs to somewhere like
/sys/hypervisor given that most of the virtual filesystems are mounted
under /sys now days?
--
Doug Goldstein
On 01/12/15 13:45, Doug Goldstein wrote:
> On 12/1/15 4:44 AM, David Vrabel wrote:
>> On 01/12/15 10:42, David Vrabel wrote:
>>> On 30/11/15 21:35, Doug Goldstein wrote:
>>>> Since Xen 4.6.0, using xenbus via xenfs (/proc/xen/xenbus) is deprecated
>>>> and /dev/xen/xenbus via pvops is used instead. This is an effort to
>>>> eventually drop this interface after a reasonable amount of time.
>>>
>>> I would prefer the ... /proc/xen/evtchn files to be
>>
>> I meant /proc/xen/privcmd here.
>>
>> David
>>
>
> I can look into that. I do have a few questions, some of which are out
> of scope from the original patch.
>
> Would it be preferable to just remove "xenbus" from the xenfs
> filesystem? Ever since Linux 3.14 even if you are running a version of
> Xen earlier than 4.6 you will not be able to have a disaggregated
> xenstore (which is the xenbus consumer) due to the addition of F_ATOMIC_POS.
If /proc/xen/xenbus is made a symlink then older Xen toolstacks will
work again.
> Is it safe for a kernel virtual filesystem to provide a symlink outside
> of itself where the destination can't be verified?
Yes. The symlink target is just a string containing a path.
> Since the /proc/xen mount point has been marked as COMPAT for nearly 6
> years would the eventual goal be to move xenfs to somewhere like
> /sys/hypervisor given that most of the virtual filesystems are mounted
> under /sys now days?
No. The information might move to /sys/hypervisor (or elsewhere) but
xenfs will always be mounted in /proc/xen (or not mounted at all).
David