cachepc-qemu

Fork of AMDESE/qemu with changes for cachepc side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-qemu
Log | Files | Refs | Submodules | LICENSE | sfeed.txt

cluster.h (3026B)

      1/*
      2 * QEMU CPU cluster
      3 *
      4 * Copyright (c) 2018 GreenSocs SAS
      5 *
      6 * This program is free software; you can redistribute it and/or
      7 * modify it under the terms of the GNU General Public License
      8 * as published by the Free Software Foundation; either version 2
      9 * of the License, or (at your option) any later version.
     10 *
     11 * This program is distributed in the hope that it will be useful,
     12 * but WITHOUT ANY WARRANTY; without even the implied warranty of
     13 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     14 * GNU General Public License for more details.
     15 *
     16 * You should have received a copy of the GNU General Public License
     17 * along with this program; if not, see
     18 * <http://www.gnu.org/licenses/gpl-2.0.html>
     19 */
     20#ifndef HW_CPU_CLUSTER_H
     21#define HW_CPU_CLUSTER_H
     22
     23#include "hw/qdev-core.h"
     24#include "qom/object.h"
     25
     26/*
     27 * CPU Cluster type
     28 *
     29 * A cluster is a group of CPUs which are all identical and have the same view
     30 * of the rest of the system. It is mainly an internal QEMU representation and
     31 * does not necessarily match with the notion of clusters on the real hardware.
     32 *
     33 * If CPUs are not identical (for example, Cortex-A53 and Cortex-A57 CPUs in an
     34 * Arm big.LITTLE system) they should be in different clusters. If the CPUs do
     35 * not have the same view of memory (for example the main CPU and a management
     36 * controller processor) they should be in different clusters.
     37 *
     38 * A cluster is created by creating an object of TYPE_CPU_CLUSTER, and then
     39 * adding the CPUs to it as QOM child objects (e.g. using the
     40 * object_initialize_child() or object_property_add_child() functions).
     41 * The CPUs may be either direct children of the cluster object, or indirect
     42 * children (e.g. children of children of the cluster object).
     43 *
     44 * All CPUs must be added as children before the cluster is realized.
     45 * (Regrettably QOM provides no way to prevent adding children to a realized
     46 * object and no way for the parent to be notified when a new child is added
     47 * to it, so this restriction is not checked for, but the system will not
     48 * behave correctly if it is not adhered to. The cluster will assert that
     49 * it contains at least one CPU, which should catch most inadvertent
     50 * violations of this constraint.)
     51 *
     52 * A CPU which is not put into any cluster will be considered implicitly
     53 * to be in a cluster with all the other "loose" CPUs, so all CPUs that are
     54 * not assigned to clusters must be identical.
     55 */
     56
     57#define TYPE_CPU_CLUSTER "cpu-cluster"
     58OBJECT_DECLARE_SIMPLE_TYPE(CPUClusterState, CPU_CLUSTER)
     59
     60/*
     61 * This limit is imposed by TCG, which puts the cluster ID into an
     62 * 8 bit field (and uses all-1s for the default "not in any cluster").
     63 */
     64#define MAX_CLUSTERS 255
     65
     66/**
     67 * CPUClusterState:
     68 * @cluster_id: The cluster ID. This value is for internal use only and should
     69 *   not be exposed directly to the user or to the guest.
     70 *
     71 * State of a CPU cluster.
     72 */
     73struct CPUClusterState {
     74    /*< private >*/
     75    DeviceState parent_obj;
     76
     77    /*< public >*/
     78    uint32_t cluster_id;
     79};
     80
     81#endif