Re: [Xen-devel] [PATCH 15/22] vixen: pass through version hypercalls to parent Xen
>>> On 07.01.18 at 16:40, wrote: > On Sun, Jan 7, 2018 at 12:31 AM, Roger Pau Monné wrote: >> On Sat, Jan 06, 2018 at 02:54:30PM -0800, Anthony Liguori wrote: >>> From: Anthony Liguori >>> >>> This is necessary to trigger event channel upcalls but it is also >> >> I'm lost here, what does version have to do with upcalls? > > In Linux, xen_force_evtchn_callback() does HYPERVISOR_xen_version(0, > NULL). This is done when IRQs are re-enabled after being disabled to > trigger checking pending. > > I'm not 100% confident that it's necessary to pass this all the way > through to the parent Xen but it seemed like the right thing to do > since we need the parent to update pending events in order for the > events in Vixen to get updated. > >>> useful to passthrough the full version information such that the >>> guest believes it is running on the parent Xen. >> >> In any case, I think this is wrong. The interface the guest sees is >> the interface from vixen, not the interface of the L0. Hence reporting >> the L0 version is not appropriate. > > I think it depends on what you want. We were aiming for maximum > compatibility and many users trigger behavior from Xen version for > better or worse. At the example of the plain version number, I think what is being reported back to the guest may need to be the lower of shim and actual hypervisor versions. XENVER_get_features may want ANDing both values (perhaps with some customization in case there are bits exclusively affected by either party). I didn't think through other sub-ops yet. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 15/22] vixen: pass through version hypercalls to parent Xen
On 07/01/2018 15:40, Anthony Liguori wrote: > On Sun, Jan 7, 2018 at 12:31 AM, Roger Pau Monné wrote: >> On Sat, Jan 06, 2018 at 02:54:30PM -0800, Anthony Liguori wrote: >>> From: Anthony Liguori >>> >>> This is necessary to trigger event channel upcalls but it is also >> I'm lost here, what does version have to do with upcalls? > In Linux, xen_force_evtchn_callback() does HYPERVISOR_xen_version(0, > NULL). This is done when IRQs are re-enabled after being disabled to > trigger checking pending. > > I'm not 100% confident that it's necessary to pass this all the way > through to the parent Xen but it seemed like the right thing to do > since we need the parent to update pending events in order for the > events in Vixen to get updated. > >>> useful to passthrough the full version information such that the >>> guest believes it is running on the parent Xen. >> In any case, I think this is wrong. The interface the guest sees is >> the interface from vixen, not the interface of the L0. Hence reporting >> the L0 version is not appropriate. > I think it depends on what you want. We were aiming for maximum > compatibility and many users trigger behavior from Xen version for > better or worse. > > Happy to make this optional if this isn't universally desired. It will be subtle either way. My gut feeling is that it will be worse to pretend that Xen 4.10 isn't 4.10, than having PV guests suddenly find themselves on a newer hypervisor. The PV ABI hasn't changed much at all. I don't have any evident to back up this feeling though. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 15/22] vixen: pass through version hypercalls to parent Xen
On Sun, Jan 7, 2018 at 12:31 AM, Roger Pau Monné wrote: > On Sat, Jan 06, 2018 at 02:54:30PM -0800, Anthony Liguori wrote: >> From: Anthony Liguori >> >> This is necessary to trigger event channel upcalls but it is also > > I'm lost here, what does version have to do with upcalls? In Linux, xen_force_evtchn_callback() does HYPERVISOR_xen_version(0, NULL). This is done when IRQs are re-enabled after being disabled to trigger checking pending. I'm not 100% confident that it's necessary to pass this all the way through to the parent Xen but it seemed like the right thing to do since we need the parent to update pending events in order for the events in Vixen to get updated. >> useful to passthrough the full version information such that the >> guest believes it is running on the parent Xen. > > In any case, I think this is wrong. The interface the guest sees is > the interface from vixen, not the interface of the L0. Hence reporting > the L0 version is not appropriate. I think it depends on what you want. We were aiming for maximum compatibility and many users trigger behavior from Xen version for better or worse. Happy to make this optional if this isn't universally desired. Regards, Anthony Liguori > Thanks, Roger. > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 15/22] vixen: pass through version hypercalls to parent Xen
On Sat, Jan 06, 2018 at 02:54:30PM -0800, Anthony Liguori wrote: > From: Anthony Liguori > > This is necessary to trigger event channel upcalls but it is also I'm lost here, what does version have to do with upcalls? > useful to passthrough the full version information such that the > guest believes it is running on the parent Xen. In any case, I think this is wrong. The interface the guest sees is the interface from vixen, not the interface of the L0. Hence reporting the L0 version is not appropriate. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 15/22] vixen: pass through version hypercalls to parent Xen
From: Anthony Liguori
This is necessary to trigger event channel upcalls but it is also
useful to passthrough the full version information such that the
guest believes it is running on the parent Xen.
Signed-off-by: Matt Wilson
Signed-off-by: Anthony Liguori
---
xen/common/kernel.c | 82 +
1 file changed, 70 insertions(+), 12 deletions(-)
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8d137c5..b9885c8 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#ifndef COMPAT
@@ -311,14 +312,32 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
switch ( cmd )
{
case XENVER_version:
-return (xen_major_version() << 16) | xen_minor_version();
+if ( is_vixen() )
+return HYPERVISOR_xen_version(XENVER_version, NULL);
+else
+return (xen_major_version() << 16) | xen_minor_version();
case XENVER_extraversion:
{
xen_extraversion_t extraversion;
+int rc;
memset(extraversion, 0, sizeof(extraversion));
-safe_strcpy(extraversion, deny ? xen_deny() : xen_extra_version());
+if ( is_vixen() )
+{
+if ( deny )
+safe_strcpy(extraversion, xen_deny());
+else
+{
+rc = HYPERVISOR_xen_version(XENVER_extraversion,
&extraversion);
+if ( rc )
+return rc;
+}
+}
+else
+{
+safe_strcpy(extraversion, deny ? xen_deny() : xen_extra_version());
+}
if ( copy_to_guest(arg, extraversion, ARRAY_SIZE(extraversion)) )
return -EFAULT;
return 0;
@@ -327,12 +346,22 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
case XENVER_compile_info:
{
xen_compile_info_t info;
+int rc;
memset(&info, 0, sizeof(info));
-safe_strcpy(info.compiler, deny ? xen_deny() : xen_compiler());
-safe_strcpy(info.compile_by, deny ? xen_deny() : xen_compile_by());
-safe_strcpy(info.compile_domain, deny ? xen_deny() :
xen_compile_domain());
-safe_strcpy(info.compile_date, deny ? xen_deny() :
xen_compile_date());
+if ( is_vixen() )
+{
+rc = HYPERVISOR_xen_version(XENVER_compile_info, &info);
+if ( rc )
+return rc;
+}
+else
+{
+safe_strcpy(info.compiler, deny ? xen_deny() :
xen_compiler());
+safe_strcpy(info.compile_by, deny ? xen_deny() :
xen_compile_by());
+safe_strcpy(info.compile_domain, deny ? xen_deny() :
xen_compile_domain());
+safe_strcpy(info.compile_date, deny ? xen_deny() :
xen_compile_date());
+}
if ( copy_to_guest(arg, &info, 1) )
return -EFAULT;
return 0;
@@ -366,9 +395,24 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
case XENVER_changeset:
{
xen_changeset_info_t chgset;
+int rc;
memset(chgset, 0, sizeof(chgset));
-safe_strcpy(chgset, deny ? xen_deny() : xen_changeset());
+if ( is_vixen() )
+{
+if ( deny )
+safe_strcpy(chgset, xen_deny());
+else
+{
+rc = HYPERVISOR_xen_version(XENVER_changeset, &chgset);
+if ( rc )
+return rc;
+}
+}
+else
+{
+safe_strcpy(chgset, deny ? xen_deny() : xen_changeset());
+}
if ( copy_to_guest(arg, chgset, ARRAY_SIZE(chgset)) )
return -EFAULT;
return 0;
@@ -430,15 +474,29 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
case XENVER_guest_handle:
{
xen_domain_handle_t hdl;
+int rc;
-if ( deny )
-memset(&hdl, 0, ARRAY_SIZE(hdl));
+memset(&hdl, 0, ARRAY_SIZE(hdl));
BUILD_BUG_ON(ARRAY_SIZE(current->domain->handle) != ARRAY_SIZE(hdl));
-if ( copy_to_guest(arg, deny ? hdl : current->domain->handle,
- ARRAY_SIZE(hdl) ) )
-return -EFAULT;
+if ( is_vixen () )
+{
+if ( !deny )
+{
+rc = HYPERVISOR_xen_version(XENVER_guest_handle, &hdl);
+if ( rc )
+return rc;
+}
+if ( copy_to_guest(arg, hdl, ARRAY_SIZE(hdl) ) )
+return -EFAULT;
+}
+else
+{
+if ( copy_to_guest(arg, deny ? hdl : current->domain->handle,
+ ARRAY_SIZE(hdl) ) )
+return -EFAULT;
+}
return 0;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.or
