spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
/*
|
|
|
|
* QEMU PowerPC pSeries Logical Partition capabilities handling
|
|
|
|
*
|
|
|
|
* Copyright (c) 2017 David Gibson, Red Hat Inc.
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
#include "qemu/osdep.h"
|
2017-12-11 07:09:37 +03:00
|
|
|
#include "qemu/error-report.h"
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
#include "qapi/error.h"
|
|
|
|
#include "qapi/visitor.h"
|
2017-12-11 05:10:44 +03:00
|
|
|
#include "sysemu/hw_accel.h"
|
|
|
|
#include "target/ppc/cpu.h"
|
|
|
|
#include "cpu-models.h"
|
|
|
|
#include "kvm_ppc.h"
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
|
|
|
|
#include "hw/ppc/spapr.h"
|
|
|
|
|
|
|
|
typedef struct sPAPRCapabilityInfo {
|
|
|
|
const char *name;
|
|
|
|
const char *description;
|
|
|
|
uint64_t flag;
|
|
|
|
|
|
|
|
/* Make sure the virtual hardware can support this capability */
|
|
|
|
void (*allow)(sPAPRMachineState *spapr, Error **errp);
|
|
|
|
|
|
|
|
/* If possible, tell the virtual hardware not to allow the cap to
|
|
|
|
* be used at all */
|
|
|
|
void (*disallow)(sPAPRMachineState *spapr, Error **errp);
|
|
|
|
} sPAPRCapabilityInfo;
|
|
|
|
|
2017-12-11 05:10:44 +03:00
|
|
|
static void cap_htm_allow(sPAPRMachineState *spapr, Error **errp)
|
|
|
|
{
|
|
|
|
if (tcg_enabled()) {
|
|
|
|
error_setg(errp,
|
|
|
|
"No Transactional Memory support in TCG, try cap-htm=off");
|
|
|
|
} else if (kvm_enabled() && !kvmppc_has_cap_htm()) {
|
|
|
|
error_setg(errp,
|
|
|
|
"KVM implementation does not support Transactional Memory, try cap-htm=off"
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-12-07 09:08:47 +03:00
|
|
|
static void cap_vsx_allow(sPAPRMachineState *spapr, Error **errp)
|
|
|
|
{
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
|
|
|
|
/* Allowable CPUs in spapr_cpu_core.c should already have gotten
|
|
|
|
* rid of anything that doesn't do VMX */
|
|
|
|
g_assert(env->insns_flags & PPC_ALTIVEC);
|
|
|
|
if (!(env->insns_flags2 & PPC2_VSX)) {
|
|
|
|
error_setg(errp, "VSX support not available, try cap-vsx=off");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-12-11 09:34:30 +03:00
|
|
|
static void cap_dfp_allow(sPAPRMachineState *spapr, Error **errp)
|
|
|
|
{
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
|
|
|
|
if (!(env->insns_flags2 & PPC2_DFP)) {
|
|
|
|
error_setg(errp, "DFP support not available, try cap-dfp=off");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
static sPAPRCapabilityInfo capability_table[] = {
|
2017-12-11 05:10:44 +03:00
|
|
|
{
|
|
|
|
.name = "htm",
|
|
|
|
.description = "Allow Hardware Transactional Memory (HTM)",
|
|
|
|
.flag = SPAPR_CAP_HTM,
|
|
|
|
.allow = cap_htm_allow,
|
|
|
|
/* TODO: add cap_htm_disallow */
|
|
|
|
},
|
2017-12-07 09:08:47 +03:00
|
|
|
{
|
|
|
|
.name = "vsx",
|
|
|
|
.description = "Allow Vector Scalar Extensions (VSX)",
|
|
|
|
.flag = SPAPR_CAP_VSX,
|
|
|
|
.allow = cap_vsx_allow,
|
|
|
|
/* TODO: add cap_vsx_disallow */
|
|
|
|
},
|
2017-12-11 09:34:30 +03:00
|
|
|
{
|
|
|
|
.name = "dfp",
|
|
|
|
.description = "Allow Decimal Floating Point (DFP)",
|
|
|
|
.flag = SPAPR_CAP_DFP,
|
|
|
|
.allow = cap_dfp_allow,
|
|
|
|
/* TODO: add cap_dfp_disallow */
|
|
|
|
},
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState *spapr,
|
|
|
|
CPUState *cs)
|
|
|
|
{
|
|
|
|
sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
2017-12-11 05:10:44 +03:00
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
sPAPRCapabilities caps;
|
|
|
|
|
|
|
|
caps = smc->default_caps;
|
|
|
|
|
2017-12-11 05:10:44 +03:00
|
|
|
if (!ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_07,
|
|
|
|
0, spapr->max_compat_pvr)) {
|
|
|
|
caps.mask &= ~SPAPR_CAP_HTM;
|
|
|
|
}
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
|
2017-12-07 09:08:47 +03:00
|
|
|
if (!ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_06,
|
|
|
|
0, spapr->max_compat_pvr)) {
|
|
|
|
caps.mask &= ~SPAPR_CAP_VSX;
|
2017-12-11 09:34:30 +03:00
|
|
|
caps.mask &= ~SPAPR_CAP_DFP;
|
2017-12-07 09:08:47 +03:00
|
|
|
}
|
|
|
|
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
return caps;
|
|
|
|
}
|
|
|
|
|
2017-12-11 07:09:37 +03:00
|
|
|
static bool spapr_caps_needed(void *opaque)
|
|
|
|
{
|
|
|
|
sPAPRMachineState *spapr = opaque;
|
|
|
|
|
|
|
|
return (spapr->forced_caps.mask != 0) || (spapr->forbidden_caps.mask != 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This has to be called from the top-level spapr post_load, not the
|
|
|
|
* caps specific one. Otherwise it wouldn't be called when the source
|
|
|
|
* caps are all defaults, which could still conflict with overridden
|
|
|
|
* caps on the destination */
|
|
|
|
int spapr_caps_post_migration(sPAPRMachineState *spapr)
|
|
|
|
{
|
|
|
|
uint64_t allcaps = 0;
|
|
|
|
int i;
|
|
|
|
bool ok = true;
|
|
|
|
sPAPRCapabilities dstcaps = spapr->effective_caps;
|
|
|
|
sPAPRCapabilities srccaps;
|
|
|
|
|
|
|
|
srccaps = default_caps_with_cpu(spapr, first_cpu);
|
|
|
|
srccaps.mask |= spapr->mig_forced_caps.mask;
|
|
|
|
srccaps.mask &= ~spapr->mig_forbidden_caps.mask;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(capability_table); i++) {
|
|
|
|
sPAPRCapabilityInfo *info = &capability_table[i];
|
|
|
|
|
|
|
|
allcaps |= info->flag;
|
|
|
|
|
|
|
|
if ((srccaps.mask & info->flag) && !(dstcaps.mask & info->flag)) {
|
|
|
|
error_report("cap-%s=on in incoming stream, but off in destination",
|
|
|
|
info->name);
|
|
|
|
ok = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(srccaps.mask & info->flag) && (dstcaps.mask & info->flag)) {
|
|
|
|
warn_report("cap-%s=off in incoming stream, but on in destination",
|
|
|
|
info->name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (spapr->mig_forced_caps.mask & ~allcaps) {
|
|
|
|
error_report(
|
|
|
|
"Unknown capabilities 0x%"PRIx64" enabled in incoming stream",
|
|
|
|
spapr->mig_forced_caps.mask & ~allcaps);
|
|
|
|
ok = false;
|
|
|
|
}
|
|
|
|
if (spapr->mig_forbidden_caps.mask & ~allcaps) {
|
|
|
|
warn_report(
|
|
|
|
"Unknown capabilities 0x%"PRIx64" disabled in incoming stream",
|
|
|
|
spapr->mig_forbidden_caps.mask & ~allcaps);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ok ? 0 : -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int spapr_caps_pre_save(void *opaque)
|
|
|
|
{
|
|
|
|
sPAPRMachineState *spapr = opaque;
|
|
|
|
|
|
|
|
spapr->mig_forced_caps = spapr->forced_caps;
|
|
|
|
spapr->mig_forbidden_caps = spapr->forbidden_caps;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int spapr_caps_pre_load(void *opaque)
|
|
|
|
{
|
|
|
|
sPAPRMachineState *spapr = opaque;
|
|
|
|
|
|
|
|
spapr->mig_forced_caps = spapr_caps(0);
|
|
|
|
spapr->mig_forbidden_caps = spapr_caps(0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const VMStateDescription vmstate_spapr_caps = {
|
|
|
|
.name = "spapr/caps",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = spapr_caps_needed,
|
|
|
|
.pre_save = spapr_caps_pre_save,
|
|
|
|
.pre_load = spapr_caps_pre_load,
|
|
|
|
.fields = (VMStateField[]) {
|
|
|
|
VMSTATE_UINT64(mig_forced_caps.mask, sPAPRMachineState),
|
|
|
|
VMSTATE_UINT64(mig_forbidden_caps.mask, sPAPRMachineState),
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
void spapr_caps_reset(sPAPRMachineState *spapr)
|
|
|
|
{
|
|
|
|
Error *local_err = NULL;
|
|
|
|
sPAPRCapabilities caps;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* First compute the actual set of caps we're running with.. */
|
|
|
|
caps = default_caps_with_cpu(spapr, first_cpu);
|
|
|
|
|
2017-12-11 07:09:37 +03:00
|
|
|
/* Remove unnecessary forced/forbidden bits (this will help us
|
|
|
|
* with migration) */
|
|
|
|
spapr->forced_caps.mask &= ~caps.mask;
|
|
|
|
spapr->forbidden_caps.mask &= caps.mask;
|
|
|
|
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
caps.mask |= spapr->forced_caps.mask;
|
|
|
|
caps.mask &= ~spapr->forbidden_caps.mask;
|
|
|
|
|
|
|
|
spapr->effective_caps = caps;
|
|
|
|
|
|
|
|
/* .. then apply those caps to the virtual hardware */
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(capability_table); i++) {
|
|
|
|
sPAPRCapabilityInfo *info = &capability_table[i];
|
|
|
|
|
|
|
|
if (spapr->effective_caps.mask & info->flag) {
|
|
|
|
/* Failure to allow a cap is fatal - if the guest doesn't
|
|
|
|
* have it, we'll be supplying an incorrect environment */
|
|
|
|
if (info->allow) {
|
|
|
|
info->allow(spapr, &error_fatal);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Failure to enforce a cap is only a warning. The guest
|
|
|
|
* shouldn't be using it, since it's not advertised, so it
|
|
|
|
* doesn't get to complain about weird behaviour if it
|
|
|
|
* goes ahead anyway */
|
|
|
|
if (info->disallow) {
|
|
|
|
info->disallow(spapr, &local_err);
|
|
|
|
}
|
|
|
|
if (local_err) {
|
|
|
|
warn_report_err(local_err);
|
|
|
|
local_err = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_cap_get(Object *obj, Visitor *v, const char *name,
|
|
|
|
void *opaque, Error **errp)
|
|
|
|
{
|
|
|
|
sPAPRCapabilityInfo *cap = opaque;
|
|
|
|
sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
|
|
|
|
bool value = spapr_has_cap(spapr, cap->flag);
|
|
|
|
|
|
|
|
/* TODO: Could this get called before effective_caps is finalized
|
|
|
|
* in spapr_caps_reset()? */
|
|
|
|
|
|
|
|
visit_type_bool(v, name, &value, errp);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_cap_set(Object *obj, Visitor *v, const char *name,
|
|
|
|
void *opaque, Error **errp)
|
|
|
|
{
|
|
|
|
sPAPRCapabilityInfo *cap = opaque;
|
|
|
|
sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
|
|
|
|
bool value;
|
|
|
|
Error *local_err = NULL;
|
|
|
|
|
|
|
|
visit_type_bool(v, name, &value, &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_propagate(errp, local_err);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (value) {
|
|
|
|
spapr->forced_caps.mask |= cap->flag;
|
|
|
|
} else {
|
|
|
|
spapr->forbidden_caps.mask |= cap->flag;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void spapr_caps_validate(sPAPRMachineState *spapr, Error **errp)
|
|
|
|
{
|
|
|
|
uint64_t allcaps = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(capability_table); i++) {
|
|
|
|
g_assert((allcaps & capability_table[i].flag) == 0);
|
|
|
|
allcaps |= capability_table[i].flag;
|
|
|
|
}
|
|
|
|
|
|
|
|
g_assert((spapr->forced_caps.mask & ~allcaps) == 0);
|
|
|
|
g_assert((spapr->forbidden_caps.mask & ~allcaps) == 0);
|
|
|
|
|
|
|
|
if (spapr->forced_caps.mask & spapr->forbidden_caps.mask) {
|
|
|
|
error_setg(errp, "Some sPAPR capabilities set both on and off");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void spapr_caps_add_properties(sPAPRMachineClass *smc, Error **errp)
|
|
|
|
{
|
|
|
|
Error *local_err = NULL;
|
|
|
|
ObjectClass *klass = OBJECT_CLASS(smc);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(capability_table); i++) {
|
|
|
|
sPAPRCapabilityInfo *cap = &capability_table[i];
|
|
|
|
const char *name = g_strdup_printf("cap-%s", cap->name);
|
|
|
|
|
|
|
|
object_class_property_add(klass, name, "bool",
|
|
|
|
spapr_cap_get, spapr_cap_set, NULL,
|
|
|
|
cap, &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_propagate(errp, local_err);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
object_class_property_set_description(klass, name, cap->description,
|
|
|
|
&local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_propagate(errp, local_err);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|