* [PATCH v10 0/2] x86/viridian improvements
@ 2014-09-09 14:21 Paul Durrant
2014-09-09 14:21 ` [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask Paul Durrant
2014-09-09 14:21 ` [PATCH v10 2/2] x86/viridian: Add partition time reference counter MSR support Paul Durrant
0 siblings, 2 replies; 6+ messages in thread
From: Paul Durrant @ 2014-09-09 14:21 UTC (permalink / raw)
To: xen-devel
This patch series incorporates several improvements to the code
supporting viridian (i.e. hyper-v compatible) enlightenments for
Windows guests:
Patch #1 series lays the foundations for adding new viridian
enlightenments such that they can be optionally enabled, and not
immediately exposed to a guest across a save/restore boundary.
Patch #2 adds support for the 'Partition Time Reference Counter'
enlightenment.
v2:
- Addressed comments from Jan Beulich
- Added patch #2
v3:
- Addressed comments from Andrew Cooper and Jan Beulich
- Re-worked patch #2
- Simplified patch #3 to use guest TSC
v4:
- Added missing domain info to printks in patch #2
v5:
- Clarified comment of patch #1 as suggested by David Vrabel
- More logging tweaks in patch #2 as suggested by Andrew Cooper
v6:
- Dropped previous patch to reduce logging verbosity as it has been
applied
- Toolstack changes only:
- New libxl_integer_list and libxl_viridian_enlightenment types to
avoid passing of strings between xl and libxl, as requested by
Ian Jackson.
- Retained and deprecated viridian defbool rather than replacing it
to avoid API breakage pointed out by Ian Campbell. Enlightenment list
is now in a new hvm-only viridian_enlightenments field of the build
info.
v7:
- Changes to patch #2 only:
- Reference time calculation now makes use of struct time_scale and
set_time_scale and scale_delta functions to avoid overflow issues
pointed out by Christoph Egger.
v8:
- Changes to patch #2 only:
- Fixed 32- to 64-bit type promotion issue as pointed out by
Jan Beulich
v9:
- Changes to ocaml stubs in patch #1 only
- There was a missing calloc in the libxl_integer_list ocaml stubs
v10:
- Toolstack changes only:
- Re-worked toolstack code after discussion with Ian C and Ian J.
See http://lists.xen.org/archives/html/xen-devel/2014-09/msg00416.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask
2014-09-09 14:21 [PATCH v10 0/2] x86/viridian improvements Paul Durrant
@ 2014-09-09 14:21 ` Paul Durrant
2014-09-15 16:10 ` Ian Jackson
2014-09-09 14:21 ` [PATCH v10 2/2] x86/viridian: Add partition time reference counter MSR support Paul Durrant
1 sibling, 1 reply; 6+ messages in thread
From: Paul Durrant @ 2014-09-09 14:21 UTC (permalink / raw)
To: xen-devel
Cc: Keir Fraser, David Scott, Stefano Stabellini, Ian Jackson,
Paul Durrant, Ian Campbell
The following commits introduced the time reference counter MSR and
TSC/APIC frequency MSRs into the viridian feature set respectively:
e36cd2cdc9674a7a4855d21fb7b3e6e17c4bb33b
84657efd9116f40924aa13c9d5a349e007da716f
The time reference counter MSR feature was then reverted by commit
1cd4fab14ce25859efa4a2af13475e6650a5506c
because a flaw in the implementation meant the counter was reset on
migration.
All of these changes were made without any addtional options being
added to the VM configuration, or any compatibility checks being made
in the domain save/restore code. Hence setting the single boolean
'viridian' option in the VM configuration yields a different set of
features depending on which version of Xen the VM is started on, and the
feature set can change across migration (so new MSRs can magically appear).
This patch grandfathers in the current viridian features set and calls them
the 'base' and 'freq' feature sets. HVM_PARAM_VIRIDIAN is re-purposed as
a feature mask. The hypervisor has only ever allowed it ot be set to 0
or 1, so the presence of the base and freq sets are indicated by setting
bit 0. The freq set can then be turned off by setting bit 1, thus
restoring the pre-Xen-4.4 base set. Newly implemented viridian features
can be optionally enabled in future by setting further bits.
The viridian option in xl.cfg(5) has also been changed to a list so
that the sets can be individually enabled or disabled. For compatibility,
if the option is specified as a boolean, then a true (1) value will enable
the base and freq sets and a false (0) value will not enable any
enlightenments.
This patch also alters the allowed write accesses to HVM_PARAM_VIRIDIAN.
Currently there is nothing to stop the guest writing this value (which,
while harmless to anything else, should not happen) and nothing to
stop a toolstack from setting the value back to zero whilst the guest is
running, causing CPUID leaves to disappear and MSR accesses to start
causing GPFs in the guest. Both of these possibilities are now disallowed:
Once the parameter is set to a non-zero value it may not be modified (only
re-written with the same value), and guests no longer have any write
access.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: David Scott <dave.scott@eu.citrix.com>
---
docs/man/xl.cfg.pod.5 | 65 +++++++++++++++++++++++++++++++--------
tools/libxc/xc_domain_restore.c | 4 +--
tools/libxl/gentypes.py | 6 ++++
tools/libxl/idl.py | 6 ++++
tools/libxl/libxl.h | 5 +++
tools/libxl/libxl_dom.c | 62 +++++++++++++++++++++++++++++++++++--
tools/libxl/libxl_types.idl | 8 +++++
tools/libxl/xl_cmdimpl.c | 57 ++++++++++++++++++++++++++++++++--
xen/arch/x86/hvm/hvm.c | 18 ++++++++++-
xen/arch/x86/hvm/viridian.c | 21 +++++++++++--
xen/include/asm-x86/hvm/hvm.h | 7 +++--
xen/include/public/hvm/params.h | 33 +++++++++++++++++++-
12 files changed, 266 insertions(+), 26 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 1e04eed..4090464 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1106,18 +1106,59 @@ Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
Setting B<xen_platform_pci=0> with the default device_model "qemu-xen"
requires at least QEMU 1.6.
-=item B<viridian=BOOLEAN>
-
-Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
-compatible enlightenments to the guest. These can improve performance
-of Microsoft Windows guests from Windows Vista and Windows 2008
-onwards and setting this option for such guests is strongly
-recommended. This option should be harmless for other versions of
-Windows (although it will not give any benefit) and the majority of
-other non-Windows OSes. However it is known to be incompatible with
-some other Operating Systems and in some circumstance can prevent
-Xen's own paravirtualisation interfaces for HVM guests from being
-used.
+=item B<viridian=[ "SET", "SET", ...]>
+
+The sets of Microsoft Hyper-V (AKA viridian) compatible enlightenments
+exposed to the guest. The following sets of enlightenments may be
+specified:
+
+=over 4
+
+=item B<base>
+
+This set incorporates the Hypercall MSRs, Virtual processor index MSR,
+and APIC access MSRs. These enlightenments can improve performance of
+Windows Vista and Windows Server 2008 onwards and setting this option
+for such guests is strongly recommended.
+This set is also a pre-requisite for all other sets. If it is
+disabled then all enlightenments will be disabled.
+
+=item B<freq>
+
+This set incorporates the TSC and APIC frequency MSRs.
+
+These enlightenments can improve performance of Windows 7 and Windows
+Server 2008 R2 onwards.
+
+=item B<all>
+
+This is a special value that enables all of the above sets
+
+=back
+
+Sets can be disabled by prefixing the name with '!'. So, for example,
+to enable all sets except B<freq>, specify:
+
+=over 4
+
+B<viridian=['all', '!freq']>
+
+=back
+
+For details of the enlightenments see the latest version of Microsoft's
+Hypervisor Top-Level Functional Specification.
+
+The enlightenments should be harmless for other versions of Windows
+(although they will not give any benefit) and the majority of other
+non-Windows OSes.
+However it is known that they are incompatible with some other Operating
+Systems and in some circumstance can prevent Xen's own paravirtualisation
+interfaces for HVM guests from being used.
+
+Specifying the viridian option as a boolean is deprecated. However, for
+backwards compatibility, if it is specified as a boolean a value of
+true (1) will cause both the B<base> and B<freq> sets to be exposed to
+the guest, and a value of false (0) will disable all enlightenments.
=back
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index b9a56d5..d362e3a 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -922,7 +922,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
{
- PERROR("error read the viridian flag");
+ PERROR("error reading the viridian enlightenments");
return -1;
}
return pagebuf_get_one(xch, ctx, buf, fd, dom);
@@ -1733,7 +1733,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
}
if (pagebuf.viridian != 0)
- xc_hvm_param_set(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+ xc_hvm_param_set(xch, dom, HVM_PARAM_VIRIDIAN, pagebuf.viridian);
/*
* If we are migrating in from a host that does not support
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 3e73821..e101de4 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -564,6 +564,8 @@ if __name__ == '__main__':
f.write("%sconst char *%s_to_string(%s);\n" % (ty.hidden(), ty.typename, ty.make_arg("p")))
f.write("%sint %s_from_string(const char *s, %s);\n" % (ty.hidden(), ty.typename, ty.make_arg("e", passby=idl.PASS_BY_REFERENCE)))
f.write("%sextern libxl_enum_string_table %s_string_table[];\n" % (ty.hidden(), ty.typename))
+ f.write("%sextern %s %s_min_val;\n" % (ty.hidden(), ty.typename, ty.typename))
+ f.write("%sextern %s %s_max_val;\n" % (ty.hidden(), ty.typename, ty.typename))
f.write("\n")
f.write("""#endif /* %s */\n""" % (header_define))
@@ -678,6 +680,10 @@ if __name__ == '__main__':
f.write("}\n")
f.write("\n")
+ f.write("%s %s_min_val = %d;\n" % (ty.typename, ty.typename, ty.min))
+ f.write("%s %s_max_val = %d;\n" % (ty.typename, ty.typename, ty.max))
+ f.write("\n")
+
for ty in [t for t in types if t.json_gen_fn is not None]:
f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
f.write("{\n")
diff --git a/tools/libxl/idl.py b/tools/libxl/idl.py
index 437049e..983253d 100644
--- a/tools/libxl/idl.py
+++ b/tools/libxl/idl.py
@@ -174,9 +174,15 @@ class Enumeration(Type):
self.namespace)
self.values = []
+ self.min = sys.maxint
+ self.max = -sys.maxint - 1
for v in values:
# (value, name)
(num,name) = v
+ if num < self.min:
+ self.min = num
+ if num > self.max:
+ self.max = num
self.values.append(EnumerationValue(self, num, name,
typename=self.rawname))
def lookup(self, name):
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index bfeb3bc..6f628cf 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -128,6 +128,11 @@
#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_ENABLE 1
/*
+ * libxl_domain_build_info has u.hvm.viridian_enable and _disable fields.
+ */
+#define LIBXL_HAVE_BUILDINFO_HVM_VIRIDIAN_ENABLE_DISABLE 1
+
+/*
* libxl ABI compatibility
*
* The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c944804..d8dfbad 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -209,14 +209,66 @@ static unsigned long timer_mode(const libxl_domain_build_info *info)
return ((unsigned long)mode);
}
+#if defined(__i386__) || defined(__x86_64__)
+static void hvm_set_viridian_features(libxl__gc *gc, uint32_t domid,
+ libxl_domain_build_info *const info)
+{
+ libxl_bitmap enlightenments;
+ libxl_viridian_enlightenment v;
+ uint64_t mask = 0;
+
+ if (!libxl_defbool_val(info->u.hvm.viridian))
+ return;
+
+ libxl_bitmap_init(&enlightenments);
+ libxl_bitmap_alloc(CTX, &enlightenments, libxl_viridian_enlightenment_max_val);
+
+ if (libxl_bitmap_is_empty(&info->u.hvm.viridian_enable) &&
+ libxl_bitmap_is_empty(&info->u.hvm.viridian_disable)) {
+ /* Use historical defaults */
+ libxl_bitmap_set(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_BASE);
+ libxl_bitmap_set(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_FREQ);
+ } else {
+ libxl_for_each_set_bit(v, info->u.hvm.viridian_enable)
+ if (v <= libxl_viridian_enlightenment_max_val &&
+ !libxl_bitmap_test(&info->u.hvm.viridian_disable, v))
+ libxl_bitmap_set(&enlightenments, v);
+
+ /* The base set is a pre-requisite for all others */
+ if (!libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_BASE)) {
+ LOG(DETAIL, "base set not enabled");
+ libxl_bitmap_set_none(&enlightenments);
+ }
+ }
+
+ libxl_for_each_set_bit(v, enlightenments)
+ LOG(DETAIL, "%s set enabled", libxl_viridian_enlightenment_to_string(v));
+
+ if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_BASE)) {
+ mask |= HVMPV_base_freq;
+
+ if (!libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_FREQ))
+ mask |= HVMPV_no_freq;
+ }
+
+ if (xc_hvm_param_set(CTX->xch,
+ domid,
+ HVM_PARAM_VIRIDIAN,
+ mask) != 0)
+ LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_WARNING,
+ "Couldn't set viridian feature mask (0x%"PRIx64")",
+ mask);
+
+ libxl_bitmap_dispose(&enlightenments);
+}
+#endif
+
static void hvm_set_conf_params(xc_interface *handle, uint32_t domid,
libxl_domain_build_info *const info)
{
xc_hvm_param_set(handle, domid, HVM_PARAM_PAE_ENABLED,
libxl_defbool_val(info->u.hvm.pae));
#if defined(__i386__) || defined(__x86_64__)
- xc_hvm_param_set(handle, domid, HVM_PARAM_VIRIDIAN,
- libxl_defbool_val(info->u.hvm.viridian));
xc_hvm_param_set(handle, domid, HVM_PARAM_HPET_ENABLED,
libxl_defbool_val(info->u.hvm.hpet));
#endif
@@ -350,8 +402,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
- if (info->type == LIBXL_DOMAIN_TYPE_HVM)
+ if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
hvm_set_conf_params(ctx->xch, domid, info);
+#if defined(__i386__) || defined(__x86_64__)
+ hvm_set_viridian_features(gc, domid, info);
+#endif
+ }
rc = libxl__arch_domain_create(gc, d_config, domid);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 0b3496f..f383ce0 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -175,6 +175,12 @@ libxl_vendor_device = Enumeration("vendor_device", [
(0, "NONE"),
(1, "XENSERVER"),
])
+
+libxl_viridian_enlightenment = Enumeration("viridian_enlightenment", [
+ (0, "base"),
+ (1, "freq"),
+ ])
+
#
# Complex libxl types
#
@@ -365,6 +371,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
("acpi_s4", libxl_defbool),
("nx", libxl_defbool),
("viridian", libxl_defbool),
+ ("viridian_enable", libxl_bitmap),
+ ("viridian_disable", libxl_bitmap),
("timeoffset", string),
("hpet", libxl_defbool),
("vpt_align", libxl_defbool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f1c136a..9ca88ce 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -775,8 +775,8 @@ static void parse_config_data(const char *config_source,
long l;
XLU_Config *config;
XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
- XLU_ConfigList *ioports, *irqs, *iomem;
- int num_ioports, num_irqs, num_iomem, num_cpus;
+ XLU_ConfigList *ioports, *irqs, *iomem, *viridian;
+ int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian;
int pci_power_mgmt = 0;
int pci_msitranslate = 0;
int pci_permissive = 0;
@@ -993,10 +993,61 @@ static void parse_config_data(const char *config_source,
xlu_cfg_get_defbool(config, "acpi_s3", &b_info->u.hvm.acpi_s3, 0);
xlu_cfg_get_defbool(config, "acpi_s4", &b_info->u.hvm.acpi_s4, 0);
xlu_cfg_get_defbool(config, "nx", &b_info->u.hvm.nx, 0);
- xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
+ switch (xlu_cfg_get_list(config, "viridian",
+ &viridian, &num_viridian, 1))
+ {
+ case 0: /* Success */
+ if (num_viridian) {
+ libxl_defbool_set(&b_info->u.hvm.viridian, true);
+
+ libxl_bitmap_alloc(ctx, &b_info->u.hvm.viridian_enable,
+ libxl_viridian_enlightenment_max_val + 1);
+ libxl_bitmap_alloc(ctx, &b_info->u.hvm.viridian_disable,
+ libxl_viridian_enlightenment_max_val + 1);
+ }
+ for (i = 0; i < num_viridian; i++) {
+ libxl_viridian_enlightenment v;
+
+ buf = xlu_cfg_get_listitem(viridian, i);
+ if (strcmp(buf, "all") == 0)
+ libxl_bitmap_set_any(&b_info->u.hvm.viridian_enable);
+ else {
+ libxl_bitmap *m = &b_info->u.hvm.viridian_enable;
+
+ if (*buf == '!') {
+ m = &b_info->u.hvm.viridian_disable;
+ buf++;
+ }
+
+ e = libxl_viridian_enlightenment_from_string(buf, &v);
+ if (e) {
+ fprintf(stderr,
+ "xl: unknown viridian enlightenment '%s'\n",
+ buf);
+ exit(-ERROR_FAIL);
+ }
+
+ libxl_bitmap_set(m, v);
+ }
+ }
+ break;
+ case ESRCH: break; /* Option not present */
+ case EINVAL:
+ xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 1);
+ if (libxl_defbool_val(b_info->u.hvm.viridian)) {
+ fprintf(stderr, "WARNING: Specifying \"viridian\""
+ " as a boolean is deprecated. "
+ "Please use a list of features.\n");
+ }
+ break;
+ default:
+ fprintf(stderr,"xl: Unable to parse viridian enlightenments.\n");
+ exit(-ERROR_FAIL);
+ }
+
if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
const char *s = libxl_timer_mode_to_string(l);
fprintf(stderr, "WARNING: specifying \"timer_mode\" as an integer is deprecated. "
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 94b18ba..8aeb8a6 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5554,8 +5554,24 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
rc = -EINVAL;
break;
case HVM_PARAM_VIRIDIAN:
- if ( a.value > 1 )
+ /* This should only ever be set once by the tools and read by the guest. */
+ rc = -EPERM;
+ if ( curr_d == d )
+ break;
+
+ if ( a.value != d->arch.hvm_domain.params[a.index] )
+ {
+ rc = -EEXIST;
+ if ( d->arch.hvm_domain.params[a.index] != 0 )
+ break;
+
rc = -EINVAL;
+ if ( (a.value & ~HVMPV_feature_mask) ||
+ !(a.value & HVMPV_base_freq) )
+ break;
+ }
+
+ rc = 0;
break;
case HVM_PARAM_IDENT_PT:
/* Not reflexive, as we must domain_pause(). */
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index b646a8a..28c4479 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -90,8 +90,9 @@ int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
/* Which hypervisor MSRs are available to the guest */
*eax = (CPUID3A_MSR_APIC_ACCESS |
CPUID3A_MSR_HYPERCALL |
- CPUID3A_MSR_VP_INDEX |
- CPUID3A_MSR_FREQ);
+ CPUID3A_MSR_VP_INDEX);
+ if ( !(viridian_feature_mask(d) & HVMPV_no_freq) )
+ *eax |= CPUID3A_MSR_FREQ;
break;
case 4:
/* Recommended hypercall usage. */
@@ -312,11 +313,17 @@ int rdmsr_viridian_regs(uint32_t idx, uint64_t *val)
break;
case VIRIDIAN_MSR_TSC_FREQUENCY:
+ if ( viridian_feature_mask(d) & HVMPV_no_freq )
+ return 0;
+
perfc_incr(mshv_rdmsr_tsc_frequency);
*val = (uint64_t)d->arch.tsc_khz * 1000ull;
break;
case VIRIDIAN_MSR_APIC_FREQUENCY:
+ if ( viridian_feature_mask(d) & HVMPV_no_freq )
+ return 0;
+
perfc_incr(mshv_rdmsr_apic_frequency);
*val = 1000000000ull / APIC_BUS_CYCLE_NS;
break;
@@ -489,3 +496,13 @@ static int viridian_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_VCPU, viridian_save_vcpu_ctxt,
viridian_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 0ebd478..24e513b 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -344,8 +344,11 @@ static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
return hvm_funcs.get_shadow_gs_base(v);
}
-#define is_viridian_domain(_d) \
- (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))
+#define viridian_feature_mask(d) \
+ ((d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN])
+
+#define is_viridian_domain(d) \
+ (is_hvm_domain(d) && (viridian_feature_mask(d) & HVMPV_base_freq))
void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
uint32_t *eax, uint32_t *ebx,
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 614ff5f..68d26fd 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -56,9 +56,40 @@
#if defined(__i386__) || defined(__x86_64__)
-/* Expose Viridian interfaces to this HVM guest? */
+/*
+ * Viridian enlightenments
+ *
+ * (See http://download.microsoft.com/download/A/B/4/AB43A34E-BDD0-4FA6-BDEF-79EEF16E880B/Hypervisor%20Top%20Level%20Functional%20Specification%20v4.0.docx)
+ *
+ * To expose viridian enlightenments to the guest set this parameter
+ * to the desired feature mask. The base feature set must be present
+ * in any valid feature mask.
+ */
#define HVM_PARAM_VIRIDIAN 9
+/* Base+Freq viridian feature sets:
+ *
+ * - Hypercall MSRs (HV_X64_MSR_GUEST_OS_ID and HV_X64_MSR_HYPERCALL)
+ * - APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR)
+ * - Virtual Processor index MSR (HV_X64_MSR_VP_INDEX)
+ * - Timer frequency MSRs (HV_X64_MSR_TSC_FREQUENCY and
+ * HV_X64_MSR_APIC_FREQUENCY)
+ */
+#define _HVMPV_base_freq 0
+#define HVMPV_base_freq (1 << _HVMPV_base_freq)
+
+/* Feature set modifications */
+
+/* Disable timer frequency MSRs (HV_X64_MSR_TSC_FREQUENCY and
+ * HV_X64_MSR_APIC_FREQUENCY).
+ * This modification restores the viridian feature set to the
+ * original 'base' set exposed in releases prior to Xen 4.4.
+ */
+#define _HVMPV_no_freq 1
+#define HVMPV_no_freq (1 << _HVMPV_no_freq)
+
+#define HVMPV_feature_mask (HVMPV_base_freq|HVMPV_no_freq)
+
#endif
/*
--
1.7.10.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v10 2/2] x86/viridian: Add partition time reference counter MSR support
2014-09-09 14:21 [PATCH v10 0/2] x86/viridian improvements Paul Durrant
2014-09-09 14:21 ` [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask Paul Durrant
@ 2014-09-09 14:21 ` Paul Durrant
1 sibling, 0 replies; 6+ messages in thread
From: Paul Durrant @ 2014-09-09 14:21 UTC (permalink / raw)
To: xen-devel
Cc: Keir Fraser, Ian Campbell, Stefano Stabellini, Christoph Egger,
Ian Jackson, Paul Durrant
This patch optionally re-instates support for the partition time reference
counter that was previously introduced by commit
e36cd2cdc9674a7a4855d21fb7b3e6e17c4bb33b and reverted by commit
1cd4fab14ce25859efa4a2af13475e6650a5506c. The previous implementation was
non-optional and flawed.
This implementation uses the tsc of vcpu0, which is preserved across
save/restore as part of the architectural state, and then converts that
to a 100ns tick using the domain's tsc_khz.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Christoph Egger <chegger@amazon.de>
---
docs/man/xl.cfg.pod.5 | 7 +++++++
tools/libxl/libxl_dom.c | 3 +++
tools/libxl/libxl_types.idl | 1 +
xen/arch/x86/hvm/viridian.c | 29 ++++++++++++++++++++++++-----
xen/arch/x86/time.c | 4 ++--
xen/include/asm-x86/perfc_defn.h | 1 +
xen/include/asm-x86/time.h | 4 ++++
xen/include/public/hvm/params.h | 9 ++++++++-
8 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 4090464..43ab083 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1130,6 +1130,13 @@ This set incorporates the TSC and APIC frequency MSRs.
These enlightenments can improve performance of Windows 7 and Windows
Server 2008 R2 onwards.
+=item B<time_ref_count>
+
+This set incorporates Partition Time Reference Counter MSR.
+
+This enlightenment can improve performance of Windows 8 and Windows
+Server 2012 onwards.
+
=item B<all>
This is a special value that enables all of the above sets
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d8dfbad..1b5ff74 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -251,6 +251,9 @@ static void hvm_set_viridian_features(libxl__gc *gc, uint32_t domid,
mask |= HVMPV_no_freq;
}
+ if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_TIME_REF_COUNT))
+ mask |= HVMPV_time_ref_count;
+
if (xc_hvm_param_set(CTX->xch,
domid,
HVM_PARAM_VIRIDIAN,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f383ce0..0298a4c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -179,6 +179,7 @@ libxl_vendor_device = Enumeration("vendor_device", [
libxl_viridian_enlightenment = Enumeration("viridian_enlightenment", [
(0, "base"),
(1, "freq"),
+ (2, "time_ref_count"),
])
#
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 28c4479..53138fd 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -36,11 +36,11 @@
#define HvNotifyLongSpinWait 8
/* Viridian CPUID 4000003, Viridian MSR availability. */
-#define CPUID3A_MSR_REF_COUNT (1 << 1)
-#define CPUID3A_MSR_APIC_ACCESS (1 << 4)
-#define CPUID3A_MSR_HYPERCALL (1 << 5)
-#define CPUID3A_MSR_VP_INDEX (1 << 6)
-#define CPUID3A_MSR_FREQ (1 << 11)
+#define CPUID3A_MSR_TIME_REF_COUNT (1 << 1)
+#define CPUID3A_MSR_APIC_ACCESS (1 << 4)
+#define CPUID3A_MSR_HYPERCALL (1 << 5)
+#define CPUID3A_MSR_VP_INDEX (1 << 6)
+#define CPUID3A_MSR_FREQ (1 << 11)
/* Viridian CPUID 4000004, Implementation Recommendations. */
#define CPUID4A_MSR_BASED_APIC (1 << 3)
@@ -93,6 +93,8 @@ int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
CPUID3A_MSR_VP_INDEX);
if ( !(viridian_feature_mask(d) & HVMPV_no_freq) )
*eax |= CPUID3A_MSR_FREQ;
+ if ( viridian_feature_mask(d) & HVMPV_time_ref_count )
+ *eax |= CPUID3A_MSR_TIME_REF_COUNT;
break;
case 4:
/* Recommended hypercall usage. */
@@ -344,6 +346,23 @@ int rdmsr_viridian_regs(uint32_t idx, uint64_t *val)
*val = v->arch.hvm_vcpu.viridian.apic_assist.raw;
break;
+ case VIRIDIAN_MSR_TIME_REF_COUNT:
+ {
+ uint64_t tsc;
+ struct time_scale tsc_to_ns;
+
+ if ( !(viridian_feature_mask(d) & HVMPV_time_ref_count) )
+ return 0;
+
+ perfc_incr(mshv_rdmsr_time_ref_count);
+ tsc = hvm_get_guest_tsc(pt_global_vcpu_target(d));
+
+ /* convert tsc to count of 100ns periods */
+ set_time_scale(&tsc_to_ns, (uint64_t)d->arch.tsc_khz * 1000ul);
+ *val = scale_delta(tsc, &tsc_to_ns) / 100ul;
+ break;
+ }
+
default:
return 0;
}
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index bd89219..74c01e3 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -121,7 +121,7 @@ static inline u32 mul_frac(u32 multiplicand, u32 multiplier)
* Scale a 64-bit delta by scaling and multiplying by a 32-bit fraction,
* yielding a 64-bit result.
*/
-static inline u64 scale_delta(u64 delta, struct time_scale *scale)
+u64 scale_delta(u64 delta, struct time_scale *scale)
{
u64 product;
@@ -272,7 +272,7 @@ static u64 init_pit_and_calibrate_tsc(void)
return ((end - start) * (u64)CALIBRATE_FRAC);
}
-static void set_time_scale(struct time_scale *ts, u64 ticks_per_sec)
+void set_time_scale(struct time_scale *ts, u64 ticks_per_sec)
{
u64 tps64 = ticks_per_sec;
u32 tps32;
diff --git a/xen/include/asm-x86/perfc_defn.h b/xen/include/asm-x86/perfc_defn.h
index 7d802cc..170da00 100644
--- a/xen/include/asm-x86/perfc_defn.h
+++ b/xen/include/asm-x86/perfc_defn.h
@@ -120,6 +120,7 @@ PERFCOUNTER(mshv_rdmsr_hc_page, "MS Hv rdmsr hypercall page")
PERFCOUNTER(mshv_rdmsr_vp_index, "MS Hv rdmsr vp index")
PERFCOUNTER(mshv_rdmsr_tsc_frequency, "MS Hv rdmsr TSC frequency")
PERFCOUNTER(mshv_rdmsr_apic_frequency, "MS Hv rdmsr APIC frequency")
+PERFCOUNTER(mshv_rdmsr_time_ref_count, "MS Hv rdmsr time ref count")
PERFCOUNTER(mshv_rdmsr_icr, "MS Hv rdmsr icr")
PERFCOUNTER(mshv_rdmsr_tpr, "MS Hv rdmsr tpr")
PERFCOUNTER(mshv_rdmsr_apic_assist, "MS Hv rdmsr APIC assist")
diff --git a/xen/include/asm-x86/time.h b/xen/include/asm-x86/time.h
index 420620e..c4d82f6 100644
--- a/xen/include/asm-x86/time.h
+++ b/xen/include/asm-x86/time.h
@@ -76,4 +76,8 @@ void cpuid_time_leaf(uint32_t sub_idx, uint32_t *eax, uint32_t *ebx,
u64 stime2tsc(s_time_t stime);
+struct time_scale;
+void set_time_scale(struct time_scale *ts, u64 ticks_per_sec);
+u64 scale_delta(u64 delta, struct time_scale *scale);
+
#endif /* __X86_TIME_H__ */
diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
index 68d26fd..3c51072 100644
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -88,7 +88,14 @@
#define _HVMPV_no_freq 1
#define HVMPV_no_freq (1 << _HVMPV_no_freq)
-#define HVMPV_feature_mask (HVMPV_base_freq|HVMPV_no_freq)
+/* Enable Partition Time Reference Counter (HV_X64_MSR_TIME_REF_COUNT) */
+#define _HVMPV_time_ref_count 2
+#define HVMPV_time_ref_count (1 << _HVMPV_time_ref_count)
+
+#define HVMPV_feature_mask \
+ (HVMPV_base_freq | \
+ HVMPV_no_freq | \
+ HVMPV_time_ref_count)
#endif
--
1.7.10.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask
2014-09-09 14:21 ` [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask Paul Durrant
@ 2014-09-15 16:10 ` Ian Jackson
2014-09-15 16:56 ` Paul Durrant
2014-09-16 8:35 ` Paul Durrant
0 siblings, 2 replies; 6+ messages in thread
From: Ian Jackson @ 2014-09-15 16:10 UTC (permalink / raw)
To: Paul Durrant
Cc: David Scott, Stefano Stabellini, Keir Fraser, Ian Campbell, xen-devel
Paul Durrant writes ("[PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask"):
> The viridian option in xl.cfg(5) has also been changed to a list so
> that the sets can be individually enabled or disabled. For compatibility,
> if the option is specified as a boolean, then a true (1) value will enable
> the base and freq sets and a false (0) value will not enable any
> enlightenments.
Thanks.
I like what you have done with the enum and libxl_bitmap.
I disagree with the semantics of the interface you propose at the
libxl level. The new API syntax would permit the specification not
only of `none', `defaults', `exactly this set' but also of `like the
defaults but with these additions or omissions'. But your
interpretation of that syntax does not.
I would suggest the following semantics for these fields:
(from my mail of Wed, 3 Sep 2014 17:26:29 +0100)
] For libxl I think this means:
]
] - Keep the existing flag
]
] - Introduce two new bitmaps called something like
] viridian_features_{enable,disable}
]
] - Features actually enabled are
] !defbool_value(viridian) ? 0 :
] ((viridian_features_enable | default) & ~viridian_features_disable)
Your implementation has
- Features actually enabled are
!defbool_value(viridian) ? 0 :
(!viridian_features_enable && !viridian_features_disable) ? default :
(viridian_features_enable &~ viridian_features_disable)
which I think is a bit daft - especially since it renders
viridian_features_disable rather pointless. (default seems to be
BASE|FREQ, and I have no quibble with that.)
(I'm using bitmask-in-integer notation here for clarity even though
these are actually libxl bitmaps.)
At the xl level the semantics are OK, but it would be quite easy to
allow the user to modify, rather than simply replace, the default set.
To do that I would suggest:
- have "all" do enable = ~0, disable = 0;
- have "!all" do enable = 0, disable = ~0;
- have each other keyword do enable |= bit, disable &= ~bit;
- have each other !keyword do disable |= bit, enable &= ~bit;
So you can say
viridian=["!all","base"]
to turn on exactly base, or
viridian=["!freq"]
to turn on the defaults but disable freq.
What do you think ?
I have some minor comments about the xl interface and its docs:
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 1e04eed..4090464 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
...
> +=item B<viridian=[ "SET", "SET", ...]>
> +
> +The sets of Microsoft Hyper-V (AKA viridian) compatible enlightenments
> +exposed to the guest. The following sets of enlightenments may be
> +specified:
This whole thing might be less confusing if you used the word `group'
rather than `set'. Then the bitmaps etc. specify a `set of groups'
rather than a `set of sets'.
> +=over 4
> +
> +=item B<base>
> +
> +This set incorporates the Hypercall MSRs, Virtual processor index MSR,
> +and APIC access MSRs. These enlightenments can improve performance of
> +Windows Vista and Windows Server 2008 onwards and setting this option
> +for such guests is strongly recommended.
> +This set is also a pre-requisite for all other sets. If it is
> +disabled then all enlightenments will be disabled.
Wouldn't it be better to reject, rather than silently ignore, an
erroneous configuration ?
> +=item B<all>
> +
> +This is a special value that enables all of the above sets
That's not technically true. It enables all of the available
enlightenments, not specifically all of `base' and `freq'. The
difference is that future versions of xl will interpret `all' more
widely.
> +Specifying the viridian option as a boolean is deprecated. However, for
> +backwards compatibility, if it is specified as a boolean a value of
> +true (1) will cause both the B<base> and B<freq> sets to be exposed to
> +the guest, and a value of false (0) will disable all enlightenments.
Why do we now need to deprecate this ?
It would be IMO better to formally document that specifying it as a
boolean gets you the `default' set of groups, which is currently
`base' and `freq'.
Thanks,
Ian.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask
2014-09-15 16:10 ` Ian Jackson
@ 2014-09-15 16:56 ` Paul Durrant
2014-09-16 8:35 ` Paul Durrant
1 sibling, 0 replies; 6+ messages in thread
From: Paul Durrant @ 2014-09-15 16:56 UTC (permalink / raw)
To: Ian Jackson
Cc: Stefano Stabellini, Dave Scott, Keir (Xen.org), Ian Campbell, xen-devel
> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 15 September 2014 17:11
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; Keir (Xen.org); Ian Campbell; Stefano Stabellini;
> Dave Scott
> Subject: Re: [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to
> be a feature mask
>
> Paul Durrant writes ("[PATCH v10 1/2] x86/viridian: Re-purpose the HVM
> parameter to be a feature mask"):
> > The viridian option in xl.cfg(5) has also been changed to a list so
> > that the sets can be individually enabled or disabled. For compatibility,
> > if the option is specified as a boolean, then a true (1) value will enable
> > the base and freq sets and a false (0) value will not enable any
> > enlightenments.
>
> Thanks.
>
>
> I like what you have done with the enum and libxl_bitmap.
>
>
> I disagree with the semantics of the interface you propose at the
> libxl level. The new API syntax would permit the specification not
> only of `none', `defaults', `exactly this set' but also of `like the
> defaults but with these additions or omissions'. But your
> interpretation of that syntax does not.
>
> I would suggest the following semantics for these fields:
>
> (from my mail of Wed, 3 Sep 2014 17:26:29 +0100)
> ] For libxl I think this means:
> ]
> ] - Keep the existing flag
> ]
> ] - Introduce two new bitmaps called something like
> ] viridian_features_{enable,disable}
> ]
> ] - Features actually enabled are
> ] !defbool_value(viridian) ? 0 :
> ] ((viridian_features_enable | default) & ~viridian_features_disable)
>
> Your implementation has
>
> - Features actually enabled are
> !defbool_value(viridian) ? 0 :
> (!viridian_features_enable && !viridian_features_disable) ? default :
> (viridian_features_enable &~ viridian_features_disable)
>
> which I think is a bit daft - especially since it renders
> viridian_features_disable rather pointless. (default seems to be
> BASE|FREQ, and I have no quibble with that.)
>
The problem was that, using your suggestion, you could do something like set viridian_features_enable to FREQ and that (because BASE is also in defaults) would be apparently fine... but essentially it's not, because BASE is a pre-requisite for everything else. This is why I opted for:
viridian = 0 -> nothing
viridian = 1 and no enable/disable masks -> defaults (for compatibility)
viridian = 1 and masks specified -> whatever the masks say
I agree that the logic looks weird but because of BASE being a pre-requisite it seemed more sensible to me to just have a 'defaults' purely for compatibility.
> (I'm using bitmask-in-integer notation here for clarity even though
> these are actually libxl bitmaps.)
>
>
> At the xl level the semantics are OK, but it would be quite easy to
> allow the user to modify, rather than simply replace, the default set.
>
> To do that I would suggest:
>
> - have "all" do enable = ~0, disable = 0;
> - have "!all" do enable = 0, disable = ~0;
> - have each other keyword do enable |= bit, disable &= ~bit;
> - have each other !keyword do disable |= bit, enable &= ~bit;
>
> So you can say
> viridian=["!all","base"]
> to turn on exactly base, or
> viridian=["!freq"]
> to turn on the defaults but disable freq.
>
> What do you think ?
>
I'd say it seems a bit weird, from a user perspective, that you'd have to say ["!all", "base"] rather than just ["base"] if that's the only set you wanted. I still favour a list that includes specific sets, or contains "all" and then excludes specific sets.
>
> I have some minor comments about the xl interface and its docs:
>
> > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> > index 1e04eed..4090464 100644
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> ...
> > +=item B<viridian=[ "SET", "SET", ...]>
> > +
> > +The sets of Microsoft Hyper-V (AKA viridian) compatible enlightenments
> > +exposed to the guest. The following sets of enlightenments may be
> > +specified:
>
> This whole thing might be less confusing if you used the word `group'
> rather than `set'. Then the bitmaps etc. specify a `set of groups'
> rather than a `set of sets'.
>
Ok.
> > +=over 4
> > +
> > +=item B<base>
> > +
> > +This set incorporates the Hypercall MSRs, Virtual processor index MSR,
> > +and APIC access MSRs. These enlightenments can improve performance
> of
> > +Windows Vista and Windows Server 2008 onwards and setting this option
> > +for such guests is strongly recommended.
> > +This set is also a pre-requisite for all other sets. If it is
> > +disabled then all enlightenments will be disabled.
>
> Wouldn't it be better to reject, rather than silently ignore, an
> erroneous configuration ?
>
Ok.
> > +=item B<all>
> > +
> > +This is a special value that enables all of the above sets
>
> That's not technically true. It enables all of the available
> enlightenments, not specifically all of `base' and `freq'. The
> difference is that future versions of xl will interpret `all' more
> widely.
>
>
> > +Specifying the viridian option as a boolean is deprecated. However, for
> > +backwards compatibility, if it is specified as a boolean a value of
> > +true (1) will cause both the B<base> and B<freq> sets to be exposed to
> > +the guest, and a value of false (0) will disable all enlightenments.
>
> Why do we now need to deprecate this ?
>
I thought that it would be better to deprecate use of the boolean and use a list of groups going forward. Use of a boolean may, I guess, mean that users may believe they are somehow getting a magically optimal set of enlightenments for their OS. I would prefer that users either opted for 'all' or said what they wanted. Maybe not the boolean and have it mean 'all'? That does mean more enlightenments may get turned on at reboot if a VM is moved from one host to a newer host though.
Paul
> It would be IMO better to formally document that specifying it as a
> boolean gets you the `default' set of groups, which is currently
> `base' and `freq'.
>
>
> Thanks,
> Ian.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask
2014-09-15 16:10 ` Ian Jackson
2014-09-15 16:56 ` Paul Durrant
@ 2014-09-16 8:35 ` Paul Durrant
1 sibling, 0 replies; 6+ messages in thread
From: Paul Durrant @ 2014-09-16 8:35 UTC (permalink / raw)
To: Ian Jackson
Cc: Stefano Stabellini, Dave Scott, Keir (Xen.org), Ian Campbell, xen-devel
> -----Original Message-----
> From: Paul Durrant
> Sent: 15 September 2014 17:56
> To: 'Ian Jackson'
> Cc: xen-devel@lists.xen.org; Keir (Xen.org); Ian Campbell; Stefano Stabellini;
> Dave Scott
> Subject: RE: [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to
> be a feature mask
>
> > -----Original Message-----
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > Sent: 15 September 2014 17:11
> > To: Paul Durrant
> > Cc: xen-devel@lists.xen.org; Keir (Xen.org); Ian Campbell; Stefano
> Stabellini;
> > Dave Scott
> > Subject: Re: [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter
> to
> > be a feature mask
> >
> > Paul Durrant writes ("[PATCH v10 1/2] x86/viridian: Re-purpose the HVM
> > parameter to be a feature mask"):
> > > The viridian option in xl.cfg(5) has also been changed to a list so
> > > that the sets can be individually enabled or disabled. For compatibility,
> > > if the option is specified as a boolean, then a true (1) value will enable
> > > the base and freq sets and a false (0) value will not enable any
> > > enlightenments.
> >
> > Thanks.
> >
> >
> > I like what you have done with the enum and libxl_bitmap.
> >
> >
> > I disagree with the semantics of the interface you propose at the
> > libxl level. The new API syntax would permit the specification not
> > only of `none', `defaults', `exactly this set' but also of `like the
> > defaults but with these additions or omissions'. But your
> > interpretation of that syntax does not.
> >
> > I would suggest the following semantics for these fields:
> >
> > (from my mail of Wed, 3 Sep 2014 17:26:29 +0100)
> > ] For libxl I think this means:
> > ]
> > ] - Keep the existing flag
> > ]
> > ] - Introduce two new bitmaps called something like
> > ] viridian_features_{enable,disable}
> > ]
> > ] - Features actually enabled are
> > ] !defbool_value(viridian) ? 0 :
> > ] ((viridian_features_enable | default) & ~viridian_features_disable)
> >
> > Your implementation has
> >
> > - Features actually enabled are
> > !defbool_value(viridian) ? 0 :
> > (!viridian_features_enable && !viridian_features_disable) ? default :
> > (viridian_features_enable &~ viridian_features_disable)
> >
> > which I think is a bit daft - especially since it renders
> > viridian_features_disable rather pointless. (default seems to be
> > BASE|FREQ, and I have no quibble with that.)
> >
>
> The problem was that, using your suggestion, you could do something like
> set viridian_features_enable to FREQ and that (because BASE is also in
> defaults) would be apparently fine... but essentially it's not, because BASE is
> a pre-requisite for everything else. This is why I opted for:
>
> viridian = 0 -> nothing
> viridian = 1 and no enable/disable masks -> defaults (for compatibility)
> viridian = 1 and masks specified -> whatever the masks say
>
Thinking about this more overnight, would you be ok with this?
features = (!defbool_val(viridian) ? 0 : default) | (viridian_enable & ~viridian_disable)
That way compatibility is maintained, but an application not wishing to use the default set can then avoid enabling it rather than having to set viridian_disable to ~0, which I think is ugly.
> I agree that the logic looks weird but because of BASE being a pre-requisite it
> seemed more sensible to me to just have a 'defaults' purely for compatibility.
>
> > (I'm using bitmask-in-integer notation here for clarity even though
> > these are actually libxl bitmaps.)
> >
> >
> > At the xl level the semantics are OK, but it would be quite easy to
> > allow the user to modify, rather than simply replace, the default set.
> >
> > To do that I would suggest:
> >
> > - have "all" do enable = ~0, disable = 0;
> > - have "!all" do enable = 0, disable = ~0;
> > - have each other keyword do enable |= bit, disable &= ~bit;
> > - have each other !keyword do disable |= bit, enable &= ~bit;
> >
> > So you can say
> > viridian=["!all","base"]
> > to turn on exactly base, or
> > viridian=["!freq"]
> > to turn on the defaults but disable freq.
> >
> > What do you think ?
> >
>
> I'd say it seems a bit weird, from a user perspective, that you'd have to say
> ["!all", "base"] rather than just ["base"] if that's the only set you wanted. I
> still favour a list that includes specific sets, or contains "all" and then excludes
> specific sets.
>
If you are amenable to the above then we now have xl only use 'viridian' if the param is specified as boolean. If the param is specified as a list it just uses the enable/disable masks, so we can avoid "!all" . An empty list -> no enlightenments, so the user can either explicitly enable groups or use "all" and then explicitly disable groups.
That seems better to me and should reduce the size of the patch too.
Paul
> >
> > I have some minor comments about the xl interface and its docs:
> >
> > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> > > index 1e04eed..4090464 100644
> > > --- a/docs/man/xl.cfg.pod.5
> > > +++ b/docs/man/xl.cfg.pod.5
> > ...
> > > +=item B<viridian=[ "SET", "SET", ...]>
> > > +
> > > +The sets of Microsoft Hyper-V (AKA viridian) compatible enlightenments
> > > +exposed to the guest. The following sets of enlightenments may be
> > > +specified:
> >
> > This whole thing might be less confusing if you used the word `group'
> > rather than `set'. Then the bitmaps etc. specify a `set of groups'
> > rather than a `set of sets'.
> >
>
> Ok.
>
> > > +=over 4
> > > +
> > > +=item B<base>
> > > +
> > > +This set incorporates the Hypercall MSRs, Virtual processor index MSR,
> > > +and APIC access MSRs. These enlightenments can improve performance
> > of
> > > +Windows Vista and Windows Server 2008 onwards and setting this
> option
> > > +for such guests is strongly recommended.
> > > +This set is also a pre-requisite for all other sets. If it is
> > > +disabled then all enlightenments will be disabled.
> >
> > Wouldn't it be better to reject, rather than silently ignore, an
> > erroneous configuration ?
> >
>
> Ok.
>
> > > +=item B<all>
> > > +
> > > +This is a special value that enables all of the above sets
> >
> > That's not technically true. It enables all of the available
> > enlightenments, not specifically all of `base' and `freq'. The
> > difference is that future versions of xl will interpret `all' more
> > widely.
> >
> >
> > > +Specifying the viridian option as a boolean is deprecated. However, for
> > > +backwards compatibility, if it is specified as a boolean a value of
> > > +true (1) will cause both the B<base> and B<freq> sets to be exposed to
> > > +the guest, and a value of false (0) will disable all enlightenments.
> >
> > Why do we now need to deprecate this ?
> >
>
> I thought that it would be better to deprecate use of the boolean and use a
> list of groups going forward. Use of a boolean may, I guess, mean that users
> may believe they are somehow getting a magically optimal set of
> enlightenments for their OS. I would prefer that users either opted for 'all' or
> said what they wanted. Maybe not the boolean and have it mean 'all'? That
> does mean more enlightenments may get turned on at reboot if a VM is
> moved from one host to a newer host though.
>
> Paul
>
> > It would be IMO better to formally document that specifying it as a
> > boolean gets you the `default' set of groups, which is currently
> > `base' and `freq'.
> >
> >
> > Thanks,
> > Ian.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-09-16 8:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-09 14:21 [PATCH v10 0/2] x86/viridian improvements Paul Durrant
2014-09-09 14:21 ` [PATCH v10 1/2] x86/viridian: Re-purpose the HVM parameter to be a feature mask Paul Durrant
2014-09-15 16:10 ` Ian Jackson
2014-09-15 16:56 ` Paul Durrant
2014-09-16 8:35 ` Paul Durrant
2014-09-09 14:21 ` [PATCH v10 2/2] x86/viridian: Add partition time reference counter MSR support Paul Durrant
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.