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.
|
|
|
|
|
*/
|
2019-05-23 17:35:05 +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
|
|
|
#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"
|
2018-04-18 07:21:45 +03:00
|
|
|
#include "exec/ram_addr.h"
|
2017-12-11 05:10:44 +03:00
|
|
|
#include "target/ppc/cpu.h"
|
2018-03-16 11:19:13 +03:00
|
|
|
#include "target/ppc/mmu-hash64.h"
|
2017-12-11 05:10:44 +03:00
|
|
|
#include "cpu-models.h"
|
|
|
|
|
#include "kvm_ppc.h"
|
2019-08-12 08:23:45 +03:00
|
|
|
#include "migration/vmstate.h"
|
2019-05-23 17:35:05 +03:00
|
|
|
#include "sysemu/tcg.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"
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
typedef struct SpaprCapPossible {
|
2018-03-01 09:37:59 +03:00
|
|
|
int num; /* size of vals array below */
|
|
|
|
|
const char *help; /* help text for vals */
|
|
|
|
|
/*
|
|
|
|
|
* Note:
|
|
|
|
|
* - because of the way compatibility is determined vals MUST be ordered
|
|
|
|
|
* such that later options are a superset of all preceding options.
|
|
|
|
|
* - the order of vals must be preserved, that is their index is important,
|
|
|
|
|
* however vals may be added to the end of the list so long as the above
|
|
|
|
|
* point is observed
|
|
|
|
|
*/
|
|
|
|
|
const char *vals[];
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
} SpaprCapPossible;
|
2018-03-01 09:37:59 +03:00
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
typedef struct SpaprCapabilityInfo {
|
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
|
|
|
const char *name;
|
|
|
|
|
const char *description;
|
2018-01-12 08:33:43 +03:00
|
|
|
int index;
|
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
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
/* Getter and Setter Function Pointers */
|
|
|
|
|
ObjectPropertyAccessor *get;
|
|
|
|
|
ObjectPropertyAccessor *set;
|
|
|
|
|
const char *type;
|
2018-03-01 09:37:59 +03:00
|
|
|
/* Possible values if this is a custom string type */
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapPossible *possible;
|
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
|
|
|
/* Make sure the virtual hardware can support this capability */
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
void (*apply)(SpaprMachineState *spapr, uint8_t val, Error **errp);
|
|
|
|
|
void (*cpu_apply)(SpaprMachineState *spapr, PowerPCCPU *cpu,
|
2018-03-28 06:45:44 +03:00
|
|
|
uint8_t val, Error **errp);
|
2019-05-22 16:43:46 +03:00
|
|
|
bool (*migrate_needed)(void *opaque);
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
} SpaprCapabilityInfo;
|
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
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
static void spapr_cap_get_bool(Object *obj, Visitor *v, const char *name,
|
|
|
|
|
void *opaque, Error **errp)
|
|
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *cap = opaque;
|
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2018-01-12 08:33:43 +03:00
|
|
|
bool value = spapr_get_cap(spapr, cap->index) == SPAPR_CAP_ON;
|
|
|
|
|
|
|
|
|
|
visit_type_bool(v, name, &value, errp);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void spapr_cap_set_bool(Object *obj, Visitor *v, const char *name,
|
|
|
|
|
void *opaque, Error **errp)
|
2017-12-11 05:10:44 +03:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *cap = opaque;
|
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2018-01-12 08:33:43 +03:00
|
|
|
bool value;
|
|
|
|
|
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 19:06:02 +03:00
|
|
|
if (!visit_type_bool(v, name, &value, errp)) {
|
2018-01-12 08:33:43 +03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
spapr->cmd_line_caps[cap->index] = true;
|
|
|
|
|
spapr->eff.caps[cap->index] = value ? SPAPR_CAP_ON : SPAPR_CAP_OFF;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-19 08:00:01 +03:00
|
|
|
|
2022-03-02 08:51:39 +03:00
|
|
|
static void spapr_cap_get_string(Object *obj, Visitor *v, const char *name,
|
|
|
|
|
void *opaque, Error **errp)
|
2018-03-01 09:37:59 +03:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *cap = opaque;
|
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2022-03-02 08:51:39 +03:00
|
|
|
g_autofree char *val = NULL;
|
2018-03-01 09:37:59 +03:00
|
|
|
uint8_t value = spapr_get_cap(spapr, cap->index);
|
|
|
|
|
|
|
|
|
|
if (value >= cap->possible->num) {
|
|
|
|
|
error_setg(errp, "Invalid value (%d) for cap-%s", value, cap->name);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
val = g_strdup(cap->possible->vals[value]);
|
|
|
|
|
|
|
|
|
|
visit_type_str(v, name, &val, errp);
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-01 09:38:00 +03:00
|
|
|
static void spapr_cap_set_string(Object *obj, Visitor *v, const char *name,
|
|
|
|
|
void *opaque, Error **errp)
|
2018-03-01 09:37:59 +03:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *cap = opaque;
|
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2018-03-01 09:37:59 +03:00
|
|
|
uint8_t i;
|
2022-03-02 08:51:39 +03:00
|
|
|
g_autofree char *val = NULL;
|
2018-03-01 09:37:59 +03:00
|
|
|
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 19:06:02 +03:00
|
|
|
if (!visit_type_str(v, name, &val, errp)) {
|
2018-03-01 09:37:59 +03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!strcmp(val, "?")) {
|
|
|
|
|
error_setg(errp, "%s", cap->possible->help);
|
2022-03-02 08:51:39 +03:00
|
|
|
return;
|
2018-03-01 09:37:59 +03:00
|
|
|
}
|
|
|
|
|
for (i = 0; i < cap->possible->num; i++) {
|
|
|
|
|
if (!strcasecmp(val, cap->possible->vals[i])) {
|
|
|
|
|
spapr->cmd_line_caps[cap->index] = true;
|
|
|
|
|
spapr->eff.caps[cap->index] = i;
|
2022-03-02 08:51:39 +03:00
|
|
|
return;
|
2018-03-01 09:37:59 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
error_setg(errp, "Invalid capability mode \"%s\" for cap-%s", val,
|
|
|
|
|
cap->name);
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-16 11:19:13 +03:00
|
|
|
static void spapr_cap_get_pagesize(Object *obj, Visitor *v, const char *name,
|
|
|
|
|
void *opaque, Error **errp)
|
|
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *cap = opaque;
|
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2018-03-16 11:19:13 +03:00
|
|
|
uint8_t val = spapr_get_cap(spapr, cap->index);
|
|
|
|
|
uint64_t pagesize = (1ULL << val);
|
|
|
|
|
|
|
|
|
|
visit_type_size(v, name, &pagesize, errp);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void spapr_cap_set_pagesize(Object *obj, Visitor *v, const char *name,
|
|
|
|
|
void *opaque, Error **errp)
|
|
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *cap = opaque;
|
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2018-03-16 11:19:13 +03:00
|
|
|
uint64_t pagesize;
|
|
|
|
|
uint8_t val;
|
|
|
|
|
|
error: Eliminate error_propagate() with Coccinelle, part 1
When all we do with an Error we receive into a local variable is
propagating to somewhere else, we can just as well receive it there
right away. Convert
if (!foo(..., &err)) {
...
error_propagate(errp, err);
...
return ...
}
to
if (!foo(..., errp)) {
...
...
return ...
}
where nothing else needs @err. Coccinelle script:
@rule1 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
binary operator op;
constant c1, c2;
symbol false;
@@
if (
(
- fun(args, &err, args2)
+ fun(args, errp, args2)
|
- !fun(args, &err, args2)
+ !fun(args, errp, args2)
|
- fun(args, &err, args2) op c1
+ fun(args, errp, args2) op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
)
}
@rule2 forall@
identifier fun, err, errp, lbl;
expression list args, args2;
expression var;
binary operator op;
constant c1, c2;
symbol false;
@@
- var = fun(args, &err, args2);
+ var = fun(args, errp, args2);
... when != err
if (
(
var
|
!var
|
var op c1
)
)
{
... when != err
when != lbl:
when strict
- error_propagate(errp, err);
... when != err
(
return;
|
return c2;
|
return false;
|
return var;
)
}
@depends on rule1 || rule2@
identifier err;
@@
- Error *err = NULL;
... when != err
Not exactly elegant, I'm afraid.
The "when != lbl:" is necessary to avoid transforming
if (fun(args, &err)) {
goto out
}
...
out:
error_propagate(errp, err);
even though other paths to label out still need the error_propagate().
For an actual example, see sclp_realize().
Without the "when strict", Coccinelle transforms vfio_msix_setup(),
incorrectly. I don't know what exactly "when strict" does, only that
it helps here.
The match of return is narrower than what I want, but I can't figure
out how to express "return where the operand doesn't use @err". For
an example where it's too narrow, see vfio_intx_enable().
Silently fails to convert hw/arm/armsse.c, because Coccinelle gets
confused by ARMSSE being used both as typedef and function-like macro
there. Converted manually.
Line breaks tidied up manually. One nested declaration of @local_err
deleted manually. Preexisting unwanted blank line dropped in
hw/riscv/sifive_e.c.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-07 19:06:02 +03:00
|
|
|
if (!visit_type_size(v, name, &pagesize, errp)) {
|
2018-03-16 11:19:13 +03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!is_power_of_2(pagesize)) {
|
|
|
|
|
error_setg(errp, "cap-%s must be a power of 2", cap->name);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
val = ctz64(pagesize);
|
|
|
|
|
spapr->cmd_line_caps[cap->index] = true;
|
|
|
|
|
spapr->eff.caps[cap->index] = val;
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_htm_apply(SpaprMachineState *spapr, uint8_t val, Error **errp)
|
2018-01-12 08:33:43 +03:00
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2018-01-12 08:33:43 +03:00
|
|
|
if (!val) {
|
|
|
|
|
/* TODO: We don't support disabling htm yet */
|
|
|
|
|
return;
|
|
|
|
|
}
|
2017-12-11 05:10:44 +03:00
|
|
|
if (tcg_enabled()) {
|
2020-07-28 16:29:34 +03:00
|
|
|
error_setg(errp, "No Transactional Memory support in TCG");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-htm=off\n");
|
2017-12-11 05:10:44 +03:00
|
|
|
} else if (kvm_enabled() && !kvmppc_has_cap_htm()) {
|
|
|
|
|
error_setg(errp,
|
2020-07-28 16:29:34 +03:00
|
|
|
"KVM implementation does not support Transactional Memory");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-htm=off\n");
|
2017-12-11 05:10:44 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_vsx_apply(SpaprMachineState *spapr, uint8_t val, Error **errp)
|
2017-12-07 09:08:47 +03:00
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2017-12-07 09:08:47 +03:00
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
|
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
if (!val) {
|
|
|
|
|
/* TODO: We don't support disabling vsx yet */
|
|
|
|
|
return;
|
|
|
|
|
}
|
2017-12-07 09:08:47 +03:00
|
|
|
/* 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)) {
|
2020-07-28 16:29:34 +03:00
|
|
|
error_setg(errp, "VSX support not available");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-vsx=off\n");
|
2017-12-07 09:08:47 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_dfp_apply(SpaprMachineState *spapr, uint8_t val, Error **errp)
|
2017-12-11 09:34:30 +03:00
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2017-12-11 09:34:30 +03:00
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
|
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
if (!val) {
|
|
|
|
|
/* TODO: We don't support disabling dfp yet */
|
|
|
|
|
return;
|
|
|
|
|
}
|
2017-12-11 09:34:30 +03:00
|
|
|
if (!(env->insns_flags2 & PPC2_DFP)) {
|
2020-07-28 16:29:34 +03:00
|
|
|
error_setg(errp, "DFP support not available");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-dfp=off\n");
|
2017-12-11 09:34:30 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapPossible cap_cfpc_possible = {
|
2018-03-01 09:38:00 +03:00
|
|
|
.num = 3,
|
|
|
|
|
.vals = {"broken", "workaround", "fixed"},
|
|
|
|
|
.help = "broken - no protection, workaround - workaround available,"
|
|
|
|
|
" fixed - fixed in hardware",
|
|
|
|
|
};
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_safe_cache_apply(SpaprMachineState *spapr, uint8_t val,
|
2018-01-19 08:00:02 +03:00
|
|
|
Error **errp)
|
|
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2018-03-01 09:38:00 +03:00
|
|
|
uint8_t kvm_val = kvmppc_get_cap_safe_cache();
|
|
|
|
|
|
2018-01-19 08:00:02 +03:00
|
|
|
if (tcg_enabled() && val) {
|
2019-03-01 07:46:08 +03:00
|
|
|
/* TCG only supports broken, allow other values and print a warning */
|
2020-06-11 16:40:11 +03:00
|
|
|
warn_report("TCG doesn't support requested feature, cap-cfpc=%s",
|
|
|
|
|
cap_cfpc_possible.vals[val]);
|
2018-03-01 09:38:00 +03:00
|
|
|
} else if (kvm_enabled() && (val > kvm_val)) {
|
|
|
|
|
error_setg(errp,
|
2020-07-28 16:29:34 +03:00
|
|
|
"Requested safe cache capability level not supported by KVM");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-cfpc=%s\n",
|
|
|
|
|
cap_cfpc_possible.vals[kvm_val]);
|
2018-01-19 08:00:02 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapPossible cap_sbbc_possible = {
|
2018-03-01 09:38:01 +03:00
|
|
|
.num = 3,
|
|
|
|
|
.vals = {"broken", "workaround", "fixed"},
|
|
|
|
|
.help = "broken - no protection, workaround - workaround available,"
|
|
|
|
|
" fixed - fixed in hardware",
|
|
|
|
|
};
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_safe_bounds_check_apply(SpaprMachineState *spapr, uint8_t val,
|
2018-01-19 08:00:03 +03:00
|
|
|
Error **errp)
|
|
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2018-03-01 09:38:01 +03:00
|
|
|
uint8_t kvm_val = kvmppc_get_cap_safe_bounds_check();
|
|
|
|
|
|
2018-01-19 08:00:03 +03:00
|
|
|
if (tcg_enabled() && val) {
|
2019-03-01 07:46:08 +03:00
|
|
|
/* TCG only supports broken, allow other values and print a warning */
|
2020-06-11 16:40:11 +03:00
|
|
|
warn_report("TCG doesn't support requested feature, cap-sbbc=%s",
|
|
|
|
|
cap_sbbc_possible.vals[val]);
|
2018-03-01 09:38:01 +03:00
|
|
|
} else if (kvm_enabled() && (val > kvm_val)) {
|
|
|
|
|
error_setg(errp,
|
2020-07-28 16:29:34 +03:00
|
|
|
"Requested safe bounds check capability level not supported by KVM");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-sbbc=%s\n",
|
|
|
|
|
cap_sbbc_possible.vals[kvm_val]);
|
2018-01-19 08:00:03 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapPossible cap_ibs_possible = {
|
2019-03-01 06:19:11 +03:00
|
|
|
.num = 5,
|
2018-03-01 09:38:02 +03:00
|
|
|
/* Note workaround only maintained for compatibility */
|
2019-03-01 06:19:11 +03:00
|
|
|
.vals = {"broken", "workaround", "fixed-ibs", "fixed-ccd", "fixed-na"},
|
|
|
|
|
.help = "broken - no protection, workaround - count cache flush"
|
|
|
|
|
", fixed-ibs - indirect branch serialisation,"
|
|
|
|
|
" fixed-ccd - cache count disabled,"
|
|
|
|
|
" fixed-na - fixed in hardware (no longer applicable)",
|
2018-03-01 09:38:02 +03:00
|
|
|
};
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_safe_indirect_branch_apply(SpaprMachineState *spapr,
|
2018-01-19 08:00:04 +03:00
|
|
|
uint8_t val, Error **errp)
|
|
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2018-03-01 09:38:02 +03:00
|
|
|
uint8_t kvm_val = kvmppc_get_cap_safe_indirect_branch();
|
|
|
|
|
|
2019-03-01 06:19:11 +03:00
|
|
|
if (tcg_enabled() && val) {
|
2019-03-01 07:46:08 +03:00
|
|
|
/* TCG only supports broken, allow other values and print a warning */
|
2020-06-11 16:40:11 +03:00
|
|
|
warn_report("TCG doesn't support requested feature, cap-ibs=%s",
|
|
|
|
|
cap_ibs_possible.vals[val]);
|
2019-03-01 06:19:11 +03:00
|
|
|
} else if (kvm_enabled() && (val > kvm_val)) {
|
2018-03-01 09:38:02 +03:00
|
|
|
error_setg(errp,
|
2020-07-28 16:29:34 +03:00
|
|
|
"Requested safe indirect branch capability level not supported by KVM");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-ibs=%s\n",
|
|
|
|
|
cap_ibs_possible.vals[kvm_val]);
|
2018-01-19 08:00:04 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-19 08:00:02 +03:00
|
|
|
#define VALUE_DESC_TRISTATE " (broken, workaround, fixed)"
|
2018-01-12 08:33:43 +03:00
|
|
|
|
2020-09-14 15:35:03 +03:00
|
|
|
bool spapr_check_pagesize(SpaprMachineState *spapr, hwaddr pagesize,
|
2018-04-18 07:21:45 +03:00
|
|
|
Error **errp)
|
|
|
|
|
{
|
|
|
|
|
hwaddr maxpagesize = (1ULL << spapr->eff.caps[SPAPR_CAP_HPT_MAXPAGESIZE]);
|
|
|
|
|
|
|
|
|
|
if (!kvmppc_hpt_needs_host_contiguous_pages()) {
|
2020-09-14 15:35:03 +03:00
|
|
|
return true;
|
2018-04-18 07:21:45 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (maxpagesize > pagesize) {
|
|
|
|
|
error_setg(errp,
|
|
|
|
|
"Can't support %"HWADDR_PRIu" kiB guest pages with %"
|
|
|
|
|
HWADDR_PRIu" kiB host pages with this KVM implementation",
|
|
|
|
|
maxpagesize >> 10, pagesize >> 10);
|
2020-09-14 15:35:03 +03:00
|
|
|
return false;
|
2018-04-18 07:21:45 +03:00
|
|
|
}
|
2020-09-14 15:35:03 +03:00
|
|
|
|
|
|
|
|
return true;
|
2018-04-18 07:21:45 +03:00
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_hpt_maxpagesize_apply(SpaprMachineState *spapr,
|
2018-03-16 11:19:13 +03:00
|
|
|
uint8_t val, Error **errp)
|
|
|
|
|
{
|
|
|
|
|
if (val < 12) {
|
|
|
|
|
error_setg(errp, "Require at least 4kiB hpt-max-page-size");
|
2018-04-18 07:21:45 +03:00
|
|
|
return;
|
2018-03-16 11:19:13 +03:00
|
|
|
} else if (val < 16) {
|
|
|
|
|
warn_report("Many guests require at least 64kiB hpt-max-page-size");
|
|
|
|
|
}
|
2018-04-18 07:21:45 +03:00
|
|
|
|
2019-04-17 14:31:43 +03:00
|
|
|
spapr_check_pagesize(spapr, qemu_minrampagesize(), errp);
|
2018-03-16 11:19:13 +03:00
|
|
|
}
|
|
|
|
|
|
2019-05-22 16:43:46 +03:00
|
|
|
static bool cap_hpt_maxpagesize_migrate_needed(void *opaque)
|
|
|
|
|
{
|
|
|
|
|
return !SPAPR_MACHINE_GET_CLASS(opaque)->pre_4_1_migration;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-16 09:47:19 +03:00
|
|
|
static bool spapr_pagesize_cb(void *opaque, uint32_t seg_pshift,
|
|
|
|
|
uint32_t pshift)
|
|
|
|
|
{
|
|
|
|
|
unsigned maxshift = *((unsigned *)opaque);
|
|
|
|
|
|
|
|
|
|
assert(pshift >= seg_pshift);
|
|
|
|
|
|
|
|
|
|
/* Don't allow the guest to use pages bigger than the configured
|
|
|
|
|
* maximum size */
|
|
|
|
|
if (pshift > maxshift) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* For whatever reason, KVM doesn't allow multiple pagesizes
|
|
|
|
|
* within a segment, *except* for the case of 16M pages in a 4k or
|
|
|
|
|
* 64k segment. Always exclude other cases, so that TCG and KVM
|
|
|
|
|
* guests see a consistent environment */
|
|
|
|
|
if ((pshift != seg_pshift) && (pshift != 24)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-06 19:39:39 +03:00
|
|
|
static void ppc_hash64_filter_pagesizes(PowerPCCPU *cpu,
|
|
|
|
|
bool (*cb)(void *, uint32_t, uint32_t),
|
|
|
|
|
void *opaque)
|
|
|
|
|
{
|
|
|
|
|
PPCHash64Options *opts = cpu->hash64_opts;
|
|
|
|
|
int i;
|
|
|
|
|
int n = 0;
|
|
|
|
|
bool ci_largepage = false;
|
|
|
|
|
|
|
|
|
|
assert(opts);
|
|
|
|
|
|
|
|
|
|
n = 0;
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(opts->sps); i++) {
|
|
|
|
|
PPCHash64SegmentPageSizes *sps = &opts->sps[i];
|
|
|
|
|
int j;
|
|
|
|
|
int m = 0;
|
|
|
|
|
|
|
|
|
|
assert(n <= i);
|
|
|
|
|
|
|
|
|
|
if (!sps->page_shift) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (j = 0; j < ARRAY_SIZE(sps->enc); j++) {
|
|
|
|
|
PPCHash64PageSize *ps = &sps->enc[j];
|
|
|
|
|
|
|
|
|
|
assert(m <= j);
|
|
|
|
|
if (!ps->page_shift) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (cb(opaque, sps->page_shift, ps->page_shift)) {
|
|
|
|
|
if (ps->page_shift >= 16) {
|
|
|
|
|
ci_largepage = true;
|
|
|
|
|
}
|
|
|
|
|
sps->enc[m++] = *ps;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Clear rest of the row */
|
|
|
|
|
for (j = m; j < ARRAY_SIZE(sps->enc); j++) {
|
|
|
|
|
memset(&sps->enc[j], 0, sizeof(sps->enc[j]));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (m) {
|
|
|
|
|
n++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Clear the rest of the table */
|
|
|
|
|
for (i = n; i < ARRAY_SIZE(opts->sps); i++) {
|
|
|
|
|
memset(&opts->sps[i], 0, sizeof(opts->sps[i]));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!ci_largepage) {
|
|
|
|
|
opts->flags &= ~PPC_HASH64_CI_LARGEPAGE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_hpt_maxpagesize_cpu_apply(SpaprMachineState *spapr,
|
2018-04-16 09:47:19 +03:00
|
|
|
PowerPCCPU *cpu,
|
|
|
|
|
uint8_t val, Error **errp)
|
|
|
|
|
{
|
|
|
|
|
unsigned maxshift = val;
|
|
|
|
|
|
|
|
|
|
ppc_hash64_filter_pagesizes(cpu, spapr_pagesize_cb, &maxshift);
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_nested_kvm_hv_apply(SpaprMachineState *spapr,
|
2018-10-08 06:25:39 +03:00
|
|
|
uint8_t val, Error **errp)
|
|
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2020-07-16 20:11:21 +03:00
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
|
2022-02-18 10:34:14 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2020-07-16 20:11:21 +03:00
|
|
|
|
2018-10-08 06:25:39 +03:00
|
|
|
if (!val) {
|
|
|
|
|
/* capability disabled by default */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-18 10:34:14 +03:00
|
|
|
if (!(env->insns_flags2 & PPC2_ISA300)) {
|
|
|
|
|
error_setg(errp, "Nested-HV only supported on POWER9 and later");
|
2020-07-28 16:29:34 +03:00
|
|
|
error_append_hint(errp, "Try appending -machine cap-nested-hv=off\n");
|
2022-02-18 10:34:14 +03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (kvm_enabled()) {
|
2020-07-16 20:11:21 +03:00
|
|
|
if (!ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_3_00, 0,
|
|
|
|
|
spapr->max_compat_pvr)) {
|
2022-02-18 10:34:14 +03:00
|
|
|
error_setg(errp, "Nested-HV only supported on POWER9 and later");
|
2020-07-16 20:11:21 +03:00
|
|
|
error_append_hint(errp,
|
|
|
|
|
"Try appending -machine max-cpu-compat=power9\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-08 06:25:39 +03:00
|
|
|
if (!kvmppc_has_cap_nested_kvm_hv()) {
|
|
|
|
|
error_setg(errp,
|
2022-02-18 10:34:14 +03:00
|
|
|
"KVM implementation does not support Nested-HV");
|
2020-07-28 16:29:34 +03:00
|
|
|
error_append_hint(errp,
|
|
|
|
|
"Try appending -machine cap-nested-hv=off\n");
|
2018-10-08 06:25:39 +03:00
|
|
|
} else if (kvmppc_set_cap_nested_kvm_hv(val) < 0) {
|
2020-07-28 16:29:34 +03:00
|
|
|
error_setg(errp, "Error enabling cap-nested-hv with KVM");
|
|
|
|
|
error_append_hint(errp,
|
|
|
|
|
"Try appending -machine cap-nested-hv=off\n");
|
2018-10-08 06:25:39 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_large_decr_apply(SpaprMachineState *spapr,
|
2019-03-01 05:43:14 +03:00
|
|
|
uint8_t val, Error **errp)
|
|
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2019-03-01 05:43:15 +03:00
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
|
2019-03-01 05:43:16 +03:00
|
|
|
PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
|
2019-03-01 05:43:15 +03:00
|
|
|
|
|
|
|
|
if (!val) {
|
|
|
|
|
return; /* Disabled by default */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (tcg_enabled()) {
|
|
|
|
|
if (!ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_3_00, 0,
|
|
|
|
|
spapr->max_compat_pvr)) {
|
2020-07-28 16:29:34 +03:00
|
|
|
error_setg(errp, "Large decrementer only supported on POWER9");
|
|
|
|
|
error_append_hint(errp, "Try -cpu POWER9\n");
|
2019-03-01 05:43:15 +03:00
|
|
|
return;
|
|
|
|
|
}
|
2019-03-01 05:43:16 +03:00
|
|
|
} else if (kvm_enabled()) {
|
|
|
|
|
int kvm_nr_bits = kvmppc_get_cap_large_decr();
|
|
|
|
|
|
|
|
|
|
if (!kvm_nr_bits) {
|
2020-07-28 16:29:34 +03:00
|
|
|
error_setg(errp, "No large decrementer support");
|
|
|
|
|
error_append_hint(errp,
|
|
|
|
|
"Try appending -machine cap-large-decr=off\n");
|
2019-03-01 05:43:16 +03:00
|
|
|
} else if (pcc->lrg_decr_bits != kvm_nr_bits) {
|
|
|
|
|
error_setg(errp,
|
2020-07-28 16:29:34 +03:00
|
|
|
"KVM large decrementer size (%d) differs to model (%d)",
|
|
|
|
|
kvm_nr_bits, pcc->lrg_decr_bits);
|
|
|
|
|
error_append_hint(errp,
|
|
|
|
|
"Try appending -machine cap-large-decr=off\n");
|
2019-03-01 05:43:16 +03:00
|
|
|
}
|
2019-03-01 05:43:15 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_large_decr_cpu_apply(SpaprMachineState *spapr,
|
2019-03-01 05:43:15 +03:00
|
|
|
PowerPCCPU *cpu,
|
|
|
|
|
uint8_t val, Error **errp)
|
|
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2019-03-01 05:43:15 +03:00
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
|
target_ulong lpcr = env->spr[SPR_LPCR];
|
|
|
|
|
|
2019-03-01 05:43:16 +03:00
|
|
|
if (kvm_enabled()) {
|
|
|
|
|
if (kvmppc_enable_cap_large_decr(cpu, val)) {
|
2020-07-28 16:29:34 +03:00
|
|
|
error_setg(errp, "No large decrementer support");
|
|
|
|
|
error_append_hint(errp,
|
|
|
|
|
"Try appending -machine cap-large-decr=off\n");
|
2019-03-01 05:43:16 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 05:43:15 +03:00
|
|
|
if (val) {
|
|
|
|
|
lpcr |= LPCR_LD;
|
|
|
|
|
} else {
|
|
|
|
|
lpcr &= ~LPCR_LD;
|
|
|
|
|
}
|
|
|
|
|
ppc_store_lpcr(cpu, lpcr);
|
2019-03-01 05:43:14 +03:00
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static void cap_ccf_assist_apply(SpaprMachineState *spapr, uint8_t val,
|
2019-03-01 06:19:12 +03:00
|
|
|
Error **errp)
|
|
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2019-03-01 06:19:12 +03:00
|
|
|
uint8_t kvm_val = kvmppc_get_cap_count_cache_flush_assist();
|
|
|
|
|
|
|
|
|
|
if (tcg_enabled() && val) {
|
spapr: Enable DD2.3 accelerated count cache flush in pseries-5.0 machine
For POWER9 DD2.2 cpus, the best current Spectre v2 indirect branch
mitigation is "count cache disabled", which is configured with:
-machine cap-ibs=fixed-ccd
However, this option isn't available on DD2.3 CPUs with KVM, because they
don't have the count cache disabled.
For POWER9 DD2.3 cpus, it is "count cache flush with assist", configured
with:
-machine cap-ibs=workaround,cap-ccf-assist=on
However this option isn't available on DD2.2 CPUs with KVM, because they
don't have the special CCF assist instruction this relies on.
On current machine types, we default to "count cache flush w/o assist",
that is:
-machine cap-ibs=workaround,cap-ccf-assist=off
This runs, with mitigation on both DD2.2 and DD2.3 host cpus, but has a
fairly significant performance impact.
It turns out we can do better. The special instruction that CCF assist
uses to trigger a count cache flush is a no-op on earlier CPUs, rather than
trapping or causing other badness. It doesn't, of itself, implement the
mitigation, but *if* we have count-cache-disabled, then the count cache
flush is unnecessary, and so using the count cache flush mitigation is
harmless.
Therefore for the new pseries-5.0 machine type, enable cap-ccf-assist by
default. Along with that, suppress throwing an error if cap-ccf-assist
is selected but KVM doesn't support it, as long as KVM *is* giving us
count-cache-disabled. To allow TCG to work out of the box, even though it
doesn't implement the ccf flush assist, downgrade the error in that case to
a warning. This matches several Spectre mitigations where we allow TCG
to operate for debugging, since we don't really make guarantees about TCG
security properties anyway.
While we're there, make the TCG warning for this case match that for other
mitigations.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
2020-01-30 02:28:56 +03:00
|
|
|
/* TCG doesn't implement anything here, but allow with a warning */
|
|
|
|
|
warn_report("TCG doesn't support requested feature, cap-ccf-assist=on");
|
2019-03-01 06:19:12 +03:00
|
|
|
} else if (kvm_enabled() && (val > kvm_val)) {
|
spapr: Enable DD2.3 accelerated count cache flush in pseries-5.0 machine
For POWER9 DD2.2 cpus, the best current Spectre v2 indirect branch
mitigation is "count cache disabled", which is configured with:
-machine cap-ibs=fixed-ccd
However, this option isn't available on DD2.3 CPUs with KVM, because they
don't have the count cache disabled.
For POWER9 DD2.3 cpus, it is "count cache flush with assist", configured
with:
-machine cap-ibs=workaround,cap-ccf-assist=on
However this option isn't available on DD2.2 CPUs with KVM, because they
don't have the special CCF assist instruction this relies on.
On current machine types, we default to "count cache flush w/o assist",
that is:
-machine cap-ibs=workaround,cap-ccf-assist=off
This runs, with mitigation on both DD2.2 and DD2.3 host cpus, but has a
fairly significant performance impact.
It turns out we can do better. The special instruction that CCF assist
uses to trigger a count cache flush is a no-op on earlier CPUs, rather than
trapping or causing other badness. It doesn't, of itself, implement the
mitigation, but *if* we have count-cache-disabled, then the count cache
flush is unnecessary, and so using the count cache flush mitigation is
harmless.
Therefore for the new pseries-5.0 machine type, enable cap-ccf-assist by
default. Along with that, suppress throwing an error if cap-ccf-assist
is selected but KVM doesn't support it, as long as KVM *is* giving us
count-cache-disabled. To allow TCG to work out of the box, even though it
doesn't implement the ccf flush assist, downgrade the error in that case to
a warning. This matches several Spectre mitigations where we allow TCG
to operate for debugging, since we don't really make guarantees about TCG
security properties anyway.
While we're there, make the TCG warning for this case match that for other
mitigations.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
2020-01-30 02:28:56 +03:00
|
|
|
uint8_t kvm_ibs = kvmppc_get_cap_safe_indirect_branch();
|
|
|
|
|
|
|
|
|
|
if (kvm_ibs == SPAPR_CAP_FIXED_CCD) {
|
|
|
|
|
/*
|
|
|
|
|
* If we don't have CCF assist on the host, the assist
|
|
|
|
|
* instruction is a harmless no-op. It won't correctly
|
|
|
|
|
* implement the cache count flush *but* if we have
|
|
|
|
|
* count-cache-disabled in the host, that flush is
|
2022-06-14 13:40:44 +03:00
|
|
|
* unnecessary. So, specifically allow this case. This
|
spapr: Enable DD2.3 accelerated count cache flush in pseries-5.0 machine
For POWER9 DD2.2 cpus, the best current Spectre v2 indirect branch
mitigation is "count cache disabled", which is configured with:
-machine cap-ibs=fixed-ccd
However, this option isn't available on DD2.3 CPUs with KVM, because they
don't have the count cache disabled.
For POWER9 DD2.3 cpus, it is "count cache flush with assist", configured
with:
-machine cap-ibs=workaround,cap-ccf-assist=on
However this option isn't available on DD2.2 CPUs with KVM, because they
don't have the special CCF assist instruction this relies on.
On current machine types, we default to "count cache flush w/o assist",
that is:
-machine cap-ibs=workaround,cap-ccf-assist=off
This runs, with mitigation on both DD2.2 and DD2.3 host cpus, but has a
fairly significant performance impact.
It turns out we can do better. The special instruction that CCF assist
uses to trigger a count cache flush is a no-op on earlier CPUs, rather than
trapping or causing other badness. It doesn't, of itself, implement the
mitigation, but *if* we have count-cache-disabled, then the count cache
flush is unnecessary, and so using the count cache flush mitigation is
harmless.
Therefore for the new pseries-5.0 machine type, enable cap-ccf-assist by
default. Along with that, suppress throwing an error if cap-ccf-assist
is selected but KVM doesn't support it, as long as KVM *is* giving us
count-cache-disabled. To allow TCG to work out of the box, even though it
doesn't implement the ccf flush assist, downgrade the error in that case to
a warning. This matches several Spectre mitigations where we allow TCG
to operate for debugging, since we don't really make guarantees about TCG
security properties anyway.
While we're there, make the TCG warning for this case match that for other
mitigations.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
2020-01-30 02:28:56 +03:00
|
|
|
* allows us to have better performance on POWER9 DD2.3,
|
|
|
|
|
* while still working on POWER9 DD2.2 and POWER8 host
|
|
|
|
|
* cpus.
|
|
|
|
|
*/
|
|
|
|
|
return;
|
|
|
|
|
}
|
2019-03-01 06:19:12 +03:00
|
|
|
error_setg(errp,
|
2020-07-28 16:29:34 +03:00
|
|
|
"Requested count cache flush assist capability level not supported by KVM");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-ccf-assist=off\n");
|
2019-03-01 06:19:12 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-16 17:26:07 +03:00
|
|
|
static void cap_fwnmi_apply(SpaprMachineState *spapr, uint8_t val,
|
2020-01-30 21:44:18 +03:00
|
|
|
Error **errp)
|
|
|
|
|
{
|
2020-07-28 16:29:34 +03:00
|
|
|
ERRP_GUARD();
|
2020-01-30 21:44:18 +03:00
|
|
|
if (!val) {
|
|
|
|
|
return; /* Disabled by default */
|
|
|
|
|
}
|
ppc: spapr: Handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS calls
This patch adds support in QEMU to handle "ibm,nmi-register"
and "ibm,nmi-interlock" RTAS calls.
The machine check notification address is saved when the
OS issues "ibm,nmi-register" RTAS call.
This patch also handles the case when multiple processors
experience machine check at or about the same time by
handling "ibm,nmi-interlock" call. In such cases, as per
PAPR, subsequent processors serialize waiting for the first
processor to issue the "ibm,nmi-interlock" call. The second
processor that also received a machine check error waits
till the first processor is done reading the error log.
The first processor issues "ibm,nmi-interlock" call
when the error log is consumed.
Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com>
[Register fwnmi RTAS calls in core_rtas_register_types()
where other RTAS calls are registered]
Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
Message-Id: <20200130184423.20519-6-ganeshgr@linux.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-30 21:44:21 +03:00
|
|
|
|
2020-03-16 17:26:10 +03:00
|
|
|
if (kvm_enabled()) {
|
2020-03-25 17:29:03 +03:00
|
|
|
if (!kvmppc_get_fwnmi()) {
|
|
|
|
|
error_setg(errp,
|
|
|
|
|
"Firmware Assisted Non-Maskable Interrupts(FWNMI) not supported by KVM.");
|
|
|
|
|
error_append_hint(errp, "Try appending -machine cap-fwnmi=off\n");
|
ppc: spapr: Handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS calls
This patch adds support in QEMU to handle "ibm,nmi-register"
and "ibm,nmi-interlock" RTAS calls.
The machine check notification address is saved when the
OS issues "ibm,nmi-register" RTAS call.
This patch also handles the case when multiple processors
experience machine check at or about the same time by
handling "ibm,nmi-interlock" call. In such cases, as per
PAPR, subsequent processors serialize waiting for the first
processor to issue the "ibm,nmi-interlock" call. The second
processor that also received a machine check error waits
till the first processor is done reading the error log.
The first processor issues "ibm,nmi-interlock" call
when the error log is consumed.
Signed-off-by: Aravinda Prasad <arawinda.p@gmail.com>
[Register fwnmi RTAS calls in core_rtas_register_types()
where other RTAS calls are registered]
Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
Message-Id: <20200130184423.20519-6-ganeshgr@linux.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-01-30 21:44:21 +03:00
|
|
|
}
|
|
|
|
|
}
|
2020-01-30 21:44:18 +03:00
|
|
|
}
|
|
|
|
|
|
2021-07-06 14:24:40 +03:00
|
|
|
static void cap_rpt_invalidate_apply(SpaprMachineState *spapr,
|
|
|
|
|
uint8_t val, Error **errp)
|
|
|
|
|
{
|
|
|
|
|
ERRP_GUARD();
|
|
|
|
|
|
|
|
|
|
if (!val) {
|
|
|
|
|
/* capability disabled by default */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (tcg_enabled()) {
|
|
|
|
|
error_setg(errp, "No H_RPT_INVALIDATE support in TCG");
|
|
|
|
|
error_append_hint(errp,
|
|
|
|
|
"Try appending -machine cap-rpt-invalidate=off\n");
|
|
|
|
|
} else if (kvm_enabled()) {
|
|
|
|
|
if (!kvmppc_has_cap_mmu_radix()) {
|
|
|
|
|
error_setg(errp, "H_RPT_INVALIDATE only supported on Radix");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!kvmppc_has_cap_rpt_invalidate()) {
|
|
|
|
|
error_setg(errp,
|
|
|
|
|
"KVM implementation does not support H_RPT_INVALIDATE");
|
|
|
|
|
error_append_hint(errp,
|
|
|
|
|
"Try appending -machine cap-rpt-invalidate=off\n");
|
|
|
|
|
} else {
|
|
|
|
|
kvmppc_enable_h_rpt_invalidate();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
|
2018-01-12 08:33:43 +03:00
|
|
|
[SPAPR_CAP_HTM] = {
|
2017-12-11 05:10:44 +03:00
|
|
|
.name = "htm",
|
|
|
|
|
.description = "Allow Hardware Transactional Memory (HTM)",
|
2018-01-12 08:33:43 +03:00
|
|
|
.index = SPAPR_CAP_HTM,
|
|
|
|
|
.get = spapr_cap_get_bool,
|
|
|
|
|
.set = spapr_cap_set_bool,
|
|
|
|
|
.type = "bool",
|
|
|
|
|
.apply = cap_htm_apply,
|
2017-12-11 05:10:44 +03:00
|
|
|
},
|
2018-01-12 08:33:43 +03:00
|
|
|
[SPAPR_CAP_VSX] = {
|
2017-12-07 09:08:47 +03:00
|
|
|
.name = "vsx",
|
|
|
|
|
.description = "Allow Vector Scalar Extensions (VSX)",
|
2018-01-12 08:33:43 +03:00
|
|
|
.index = SPAPR_CAP_VSX,
|
|
|
|
|
.get = spapr_cap_get_bool,
|
|
|
|
|
.set = spapr_cap_set_bool,
|
|
|
|
|
.type = "bool",
|
|
|
|
|
.apply = cap_vsx_apply,
|
2017-12-07 09:08:47 +03:00
|
|
|
},
|
2018-01-12 08:33:43 +03:00
|
|
|
[SPAPR_CAP_DFP] = {
|
2017-12-11 09:34:30 +03:00
|
|
|
.name = "dfp",
|
|
|
|
|
.description = "Allow Decimal Floating Point (DFP)",
|
2018-01-12 08:33:43 +03:00
|
|
|
.index = SPAPR_CAP_DFP,
|
|
|
|
|
.get = spapr_cap_get_bool,
|
|
|
|
|
.set = spapr_cap_set_bool,
|
|
|
|
|
.type = "bool",
|
|
|
|
|
.apply = cap_dfp_apply,
|
2017-12-11 09:34:30 +03:00
|
|
|
},
|
2018-01-19 08:00:02 +03:00
|
|
|
[SPAPR_CAP_CFPC] = {
|
|
|
|
|
.name = "cfpc",
|
|
|
|
|
.description = "Cache Flush on Privilege Change" VALUE_DESC_TRISTATE,
|
|
|
|
|
.index = SPAPR_CAP_CFPC,
|
2018-03-01 09:38:00 +03:00
|
|
|
.get = spapr_cap_get_string,
|
|
|
|
|
.set = spapr_cap_set_string,
|
2018-01-19 08:00:02 +03:00
|
|
|
.type = "string",
|
2018-03-01 09:38:00 +03:00
|
|
|
.possible = &cap_cfpc_possible,
|
2018-01-19 08:00:02 +03:00
|
|
|
.apply = cap_safe_cache_apply,
|
|
|
|
|
},
|
2018-01-19 08:00:03 +03:00
|
|
|
[SPAPR_CAP_SBBC] = {
|
|
|
|
|
.name = "sbbc",
|
|
|
|
|
.description = "Speculation Barrier Bounds Checking" VALUE_DESC_TRISTATE,
|
|
|
|
|
.index = SPAPR_CAP_SBBC,
|
2018-03-01 09:38:01 +03:00
|
|
|
.get = spapr_cap_get_string,
|
|
|
|
|
.set = spapr_cap_set_string,
|
2018-01-19 08:00:03 +03:00
|
|
|
.type = "string",
|
2018-03-01 09:38:01 +03:00
|
|
|
.possible = &cap_sbbc_possible,
|
2018-01-19 08:00:03 +03:00
|
|
|
.apply = cap_safe_bounds_check_apply,
|
|
|
|
|
},
|
2018-01-19 08:00:04 +03:00
|
|
|
[SPAPR_CAP_IBS] = {
|
|
|
|
|
.name = "ibs",
|
2018-03-01 09:38:02 +03:00
|
|
|
.description =
|
2019-03-01 06:19:11 +03:00
|
|
|
"Indirect Branch Speculation (broken, workaround, fixed-ibs,"
|
|
|
|
|
"fixed-ccd, fixed-na)",
|
2018-01-19 08:00:04 +03:00
|
|
|
.index = SPAPR_CAP_IBS,
|
2018-03-01 09:38:02 +03:00
|
|
|
.get = spapr_cap_get_string,
|
|
|
|
|
.set = spapr_cap_set_string,
|
2018-01-19 08:00:04 +03:00
|
|
|
.type = "string",
|
2018-03-01 09:38:02 +03:00
|
|
|
.possible = &cap_ibs_possible,
|
2018-01-19 08:00:04 +03:00
|
|
|
.apply = cap_safe_indirect_branch_apply,
|
|
|
|
|
},
|
2018-03-16 11:19:13 +03:00
|
|
|
[SPAPR_CAP_HPT_MAXPAGESIZE] = {
|
|
|
|
|
.name = "hpt-max-page-size",
|
|
|
|
|
.description = "Maximum page size for Hash Page Table guests",
|
|
|
|
|
.index = SPAPR_CAP_HPT_MAXPAGESIZE,
|
|
|
|
|
.get = spapr_cap_get_pagesize,
|
|
|
|
|
.set = spapr_cap_set_pagesize,
|
|
|
|
|
.type = "int",
|
|
|
|
|
.apply = cap_hpt_maxpagesize_apply,
|
2018-04-16 09:47:19 +03:00
|
|
|
.cpu_apply = cap_hpt_maxpagesize_cpu_apply,
|
2019-05-22 16:43:46 +03:00
|
|
|
.migrate_needed = cap_hpt_maxpagesize_migrate_needed,
|
2018-03-16 11:19:13 +03:00
|
|
|
},
|
2018-10-08 06:25:39 +03:00
|
|
|
[SPAPR_CAP_NESTED_KVM_HV] = {
|
|
|
|
|
.name = "nested-hv",
|
|
|
|
|
.description = "Allow Nested KVM-HV",
|
|
|
|
|
.index = SPAPR_CAP_NESTED_KVM_HV,
|
|
|
|
|
.get = spapr_cap_get_bool,
|
|
|
|
|
.set = spapr_cap_set_bool,
|
|
|
|
|
.type = "bool",
|
|
|
|
|
.apply = cap_nested_kvm_hv_apply,
|
|
|
|
|
},
|
2019-03-01 05:43:14 +03:00
|
|
|
[SPAPR_CAP_LARGE_DECREMENTER] = {
|
|
|
|
|
.name = "large-decr",
|
|
|
|
|
.description = "Allow Large Decrementer",
|
|
|
|
|
.index = SPAPR_CAP_LARGE_DECREMENTER,
|
|
|
|
|
.get = spapr_cap_get_bool,
|
|
|
|
|
.set = spapr_cap_set_bool,
|
|
|
|
|
.type = "bool",
|
|
|
|
|
.apply = cap_large_decr_apply,
|
2019-03-01 05:43:15 +03:00
|
|
|
.cpu_apply = cap_large_decr_cpu_apply,
|
2019-03-01 05:43:14 +03:00
|
|
|
},
|
2019-03-01 06:19:12 +03:00
|
|
|
[SPAPR_CAP_CCF_ASSIST] = {
|
|
|
|
|
.name = "ccf-assist",
|
|
|
|
|
.description = "Count Cache Flush Assist via HW Instruction",
|
|
|
|
|
.index = SPAPR_CAP_CCF_ASSIST,
|
|
|
|
|
.get = spapr_cap_get_bool,
|
|
|
|
|
.set = spapr_cap_set_bool,
|
|
|
|
|
.type = "bool",
|
|
|
|
|
.apply = cap_ccf_assist_apply,
|
|
|
|
|
},
|
2020-03-16 17:26:07 +03:00
|
|
|
[SPAPR_CAP_FWNMI] = {
|
|
|
|
|
.name = "fwnmi",
|
|
|
|
|
.description = "Implements PAPR FWNMI option",
|
|
|
|
|
.index = SPAPR_CAP_FWNMI,
|
2020-01-30 21:44:18 +03:00
|
|
|
.get = spapr_cap_get_bool,
|
|
|
|
|
.set = spapr_cap_set_bool,
|
|
|
|
|
.type = "bool",
|
2020-03-16 17:26:07 +03:00
|
|
|
.apply = cap_fwnmi_apply,
|
2020-01-30 21:44:18 +03:00
|
|
|
},
|
2021-07-06 14:24:40 +03:00
|
|
|
[SPAPR_CAP_RPT_INVALIDATE] = {
|
|
|
|
|
.name = "rpt-invalidate",
|
|
|
|
|
.description = "Allow H_RPT_INVALIDATE",
|
|
|
|
|
.index = SPAPR_CAP_RPT_INVALIDATE,
|
|
|
|
|
.get = spapr_cap_get_bool,
|
|
|
|
|
.set = spapr_cap_set_bool,
|
|
|
|
|
.type = "bool",
|
|
|
|
|
.apply = cap_rpt_invalidate_apply,
|
|
|
|
|
},
|
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
|
|
|
};
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
static SpaprCapabilities default_caps_with_cpu(SpaprMachineState *spapr,
|
2018-06-14 09:33:58 +03:00
|
|
|
const char *cputype)
|
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
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
|
|
|
|
SpaprCapabilities caps;
|
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 = smc->default_caps;
|
|
|
|
|
|
2019-03-01 05:43:17 +03:00
|
|
|
if (!ppc_type_check_compat(cputype, CPU_POWERPC_LOGICAL_3_00,
|
|
|
|
|
0, spapr->max_compat_pvr)) {
|
|
|
|
|
caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_OFF;
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-14 09:33:58 +03:00
|
|
|
if (!ppc_type_check_compat(cputype, CPU_POWERPC_LOGICAL_2_07,
|
|
|
|
|
0, spapr->max_compat_pvr)) {
|
2018-01-12 08:33:43 +03:00
|
|
|
caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
|
2018-06-12 08:16:30 +03:00
|
|
|
caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_BROKEN;
|
2017-12-11 05:10:44 +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
|
|
|
|
2018-06-14 09:33:58 +03:00
|
|
|
if (!ppc_type_check_compat(cputype, CPU_POWERPC_LOGICAL_2_06_PLUS,
|
|
|
|
|
0, spapr->max_compat_pvr)) {
|
2018-03-01 09:38:04 +03:00
|
|
|
caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_BROKEN;
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-14 09:33:58 +03:00
|
|
|
if (!ppc_type_check_compat(cputype, CPU_POWERPC_LOGICAL_2_06,
|
|
|
|
|
0, spapr->max_compat_pvr)) {
|
2018-01-12 08:33:43 +03:00
|
|
|
caps.caps[SPAPR_CAP_VSX] = SPAPR_CAP_OFF;
|
|
|
|
|
caps.caps[SPAPR_CAP_DFP] = SPAPR_CAP_OFF;
|
2018-03-01 09:38:04 +03:00
|
|
|
caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
|
2017-12-07 09:08:47 +03:00
|
|
|
}
|
|
|
|
|
|
2018-07-02 11:54:56 +03:00
|
|
|
/* This is for pseries-2.12 and older */
|
|
|
|
|
if (smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] == 0) {
|
|
|
|
|
uint8_t mps;
|
|
|
|
|
|
|
|
|
|
if (kvmppc_hpt_needs_host_contiguous_pages()) {
|
2019-04-17 14:31:43 +03:00
|
|
|
mps = ctz64(qemu_minrampagesize());
|
2018-07-02 11:54:56 +03:00
|
|
|
} else {
|
|
|
|
|
mps = 34; /* allow everything up to 16GiB, i.e. everything */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = mps;
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
int spapr_caps_pre_load(void *opaque)
|
2017-12-11 07:09:37 +03:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2017-12-11 07:09:37 +03:00
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
/* Set to default so we can tell if this came in with the migration */
|
|
|
|
|
spapr->mig = spapr->def;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int spapr_caps_pre_save(void *opaque)
|
|
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2018-01-12 08:33:43 +03:00
|
|
|
|
|
|
|
|
spapr->mig = spapr->eff;
|
|
|
|
|
return 0;
|
2017-12-11 07:09:37 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* 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 */
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
int spapr_caps_post_migration(SpaprMachineState *spapr)
|
2017-12-11 07:09:37 +03:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
bool ok = true;
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilities dstcaps = spapr->eff;
|
|
|
|
|
SpaprCapabilities srccaps;
|
2017-12-11 07:09:37 +03:00
|
|
|
|
2018-06-14 09:33:58 +03:00
|
|
|
srccaps = default_caps_with_cpu(spapr, MACHINE(spapr)->cpu_type);
|
2018-01-12 08:33:43 +03:00
|
|
|
for (i = 0; i < SPAPR_CAP_NUM; i++) {
|
|
|
|
|
/* If not default value then assume came in with the migration */
|
|
|
|
|
if (spapr->mig.caps[i] != spapr->def.caps[i]) {
|
|
|
|
|
srccaps.caps[i] = spapr->mig.caps[i];
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-12-11 07:09:37 +03:00
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
for (i = 0; i < SPAPR_CAP_NUM; i++) {
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *info = &capability_table[i];
|
2017-12-11 07:09:37 +03:00
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
if (srccaps.caps[i] > dstcaps.caps[i]) {
|
|
|
|
|
error_report("cap-%s higher level (%d) in incoming stream than on destination (%d)",
|
|
|
|
|
info->name, srccaps.caps[i], dstcaps.caps[i]);
|
2017-12-11 07:09:37 +03:00
|
|
|
ok = false;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
if (srccaps.caps[i] < dstcaps.caps[i]) {
|
|
|
|
|
warn_report("cap-%s lower level (%d) in incoming stream than on destination (%d)",
|
|
|
|
|
info->name, srccaps.caps[i], dstcaps.caps[i]);
|
2017-12-11 07:09:37 +03:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ok ? 0 : -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-19 08:00:00 +03:00
|
|
|
/* Used to generate the migration field and needed function for a spapr cap */
|
2018-02-15 03:44:41 +03:00
|
|
|
#define SPAPR_CAP_MIG_STATE(sname, cap) \
|
|
|
|
|
static bool spapr_cap_##sname##_needed(void *opaque) \
|
2018-01-19 08:00:00 +03:00
|
|
|
{ \
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque; \
|
2019-05-22 16:43:46 +03:00
|
|
|
bool (*needed)(void *opaque) = \
|
|
|
|
|
capability_table[cap].migrate_needed; \
|
2018-01-19 08:00:00 +03:00
|
|
|
\
|
2019-05-22 16:43:46 +03:00
|
|
|
return needed ? needed(opaque) : true && \
|
|
|
|
|
spapr->cmd_line_caps[cap] && \
|
2018-02-15 03:44:41 +03:00
|
|
|
(spapr->eff.caps[cap] != \
|
|
|
|
|
spapr->def.caps[cap]); \
|
2018-01-19 08:00:00 +03:00
|
|
|
} \
|
|
|
|
|
\
|
2018-02-15 03:44:41 +03:00
|
|
|
const VMStateDescription vmstate_spapr_cap_##sname = { \
|
|
|
|
|
.name = "spapr/cap/" #sname, \
|
2018-01-19 08:00:00 +03:00
|
|
|
.version_id = 1, \
|
|
|
|
|
.minimum_version_id = 1, \
|
2018-02-15 03:44:41 +03:00
|
|
|
.needed = spapr_cap_##sname##_needed, \
|
2018-01-19 08:00:00 +03:00
|
|
|
.fields = (VMStateField[]) { \
|
2018-02-15 03:44:41 +03:00
|
|
|
VMSTATE_UINT8(mig.caps[cap], \
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprMachineState), \
|
2018-01-19 08:00:00 +03:00
|
|
|
VMSTATE_END_OF_LIST() \
|
|
|
|
|
}, \
|
2017-12-11 07:09:37 +03:00
|
|
|
}
|
|
|
|
|
|
2018-02-15 03:44:41 +03:00
|
|
|
SPAPR_CAP_MIG_STATE(htm, SPAPR_CAP_HTM);
|
|
|
|
|
SPAPR_CAP_MIG_STATE(vsx, SPAPR_CAP_VSX);
|
|
|
|
|
SPAPR_CAP_MIG_STATE(dfp, SPAPR_CAP_DFP);
|
|
|
|
|
SPAPR_CAP_MIG_STATE(cfpc, SPAPR_CAP_CFPC);
|
|
|
|
|
SPAPR_CAP_MIG_STATE(sbbc, SPAPR_CAP_SBBC);
|
|
|
|
|
SPAPR_CAP_MIG_STATE(ibs, SPAPR_CAP_IBS);
|
2019-05-17 07:10:44 +03:00
|
|
|
SPAPR_CAP_MIG_STATE(hpt_maxpagesize, SPAPR_CAP_HPT_MAXPAGESIZE);
|
2018-10-08 06:25:39 +03:00
|
|
|
SPAPR_CAP_MIG_STATE(nested_kvm_hv, SPAPR_CAP_NESTED_KVM_HV);
|
2019-03-01 05:43:14 +03:00
|
|
|
SPAPR_CAP_MIG_STATE(large_decr, SPAPR_CAP_LARGE_DECREMENTER);
|
2019-03-01 06:19:12 +03:00
|
|
|
SPAPR_CAP_MIG_STATE(ccf_assist, SPAPR_CAP_CCF_ASSIST);
|
2020-03-16 17:26:07 +03:00
|
|
|
SPAPR_CAP_MIG_STATE(fwnmi, SPAPR_CAP_FWNMI);
|
2021-07-06 14:24:40 +03:00
|
|
|
SPAPR_CAP_MIG_STATE(rpt_invalidate, SPAPR_CAP_RPT_INVALIDATE);
|
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
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
void spapr_caps_init(SpaprMachineState *spapr)
|
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
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilities default_caps;
|
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
|
|
|
int i;
|
|
|
|
|
|
2018-06-14 09:37:28 +03:00
|
|
|
/* Compute the actual set of caps we should run with */
|
2018-06-14 09:33:58 +03:00
|
|
|
default_caps = default_caps_with_cpu(spapr, MACHINE(spapr)->cpu_type);
|
2018-01-12 08:33:43 +03:00
|
|
|
|
|
|
|
|
for (i = 0; i < SPAPR_CAP_NUM; i++) {
|
|
|
|
|
/* Store the defaults */
|
|
|
|
|
spapr->def.caps[i] = default_caps.caps[i];
|
|
|
|
|
/* If not set on the command line then apply the default value */
|
|
|
|
|
if (!spapr->cmd_line_caps[i]) {
|
|
|
|
|
spapr->eff.caps[i] = default_caps.caps[i];
|
|
|
|
|
}
|
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
|
|
|
}
|
2018-06-14 09:37:28 +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
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
void spapr_caps_apply(SpaprMachineState *spapr)
|
2018-06-14 09:37:28 +03:00
|
|
|
{
|
|
|
|
|
int i;
|
2018-01-12 08:33:43 +03:00
|
|
|
|
|
|
|
|
for (i = 0; i < SPAPR_CAP_NUM; i++) {
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *info = &capability_table[i];
|
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
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
/*
|
|
|
|
|
* If the apply function can't set the desired level and thinks it's
|
|
|
|
|
* fatal, it should cause that.
|
|
|
|
|
*/
|
|
|
|
|
info->apply(spapr, spapr->eff.caps[i], &error_fatal);
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
void spapr_caps_cpu_apply(SpaprMachineState *spapr, PowerPCCPU *cpu)
|
2018-03-28 06:45:44 +03:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < SPAPR_CAP_NUM; i++) {
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *info = &capability_table[i];
|
2018-03-28 06:45:44 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the apply function can't set the desired level and thinks it's
|
|
|
|
|
* fatal, it should cause that.
|
|
|
|
|
*/
|
|
|
|
|
if (info->cpu_apply) {
|
|
|
|
|
info->cpu_apply(spapr, cpu, spapr->eff.caps[i], &error_fatal);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-05-05 18:29:23 +03:00
|
|
|
void spapr_caps_add_properties(SpaprMachineClass *smc)
|
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
|
|
|
{
|
|
|
|
|
ObjectClass *klass = OBJECT_CLASS(smc);
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(capability_table); i++) {
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 07:35:37 +03:00
|
|
|
SpaprCapabilityInfo *cap = &capability_table[i];
|
2022-03-02 08:51:39 +03:00
|
|
|
g_autofree char *name = g_strdup_printf("cap-%s", cap->name);
|
|
|
|
|
g_autofree char *desc = g_strdup_printf("%s", cap->description);
|
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
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
object_class_property_add(klass, name, cap->type,
|
|
|
|
|
cap->get, cap->set,
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
NULL, cap);
|
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
|
|
|
|
2020-05-05 18:29:15 +03:00
|
|
|
object_class_property_set_description(klass, name, desc);
|
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
|
|
|
}
|
|
|
|
|
}
|