| /qemu/include/hw/ppc/ |
| H A D | spapr_ovec.h | 4 * Each architecture option is organized/documented by the following
11 * where each vector entry can be one or more bytes.
14 * structure, where each entry is stored in little-endian so that the
15 * byte ordering reflects that of the documentation, but where each bit
17 * a byte value where the MSB is the left-most bit. Thus, each
|
| /qemu/docs/specs/ |
| H A D | ppc-spapr-hotplug.rst | 26 the name/index/power-domain/type of each DRC allocated to a guest at
35 The array properties are described below. Each entry/element in an array
44 Each entry: a NULL-terminated ``<name>`` string encoded as a byte array.
52 defined as being "location codes", which are the "location labels" of each
68 Each 4-byte entry: BE-encoded ``<index>`` integer that is unique across all
95 Each 4-byte entry: 32-bit, BE-encoded ``<index>`` integer that specifies the
107 Each entry: a NULL-terminated ``<type>`` string encoded as a byte array.
125 Each DRC is given a globally unique DRC index, and resources associated with a
455 This 64-bit integer defines the size of each dynamically reconfigurable LMB.
461 information for each LMB can be found. It is a property encoded array
[all …]
|
| H A D | ppc-xive.rst | 19 The XIVE IC is composed of three sub-engines, each taking care of a
33 Controller (PC). It maintains the interrupt context state of each
76 Each of the sub-engines uses a set of tables to redirect interrupts
107 for each source that allows events to be triggered. They are stored in
112 configured for the source. Each Event Notification Descriptor defines
119 each thread in a NVT table.
132 Each exception has a state independent from the others called a Thread
147 (TIMA), four aligned pages, each exposing a different view of the
196 four sets of registers, one for each exception that can be delivered
|
| H A D | rapl-msr.rst | 42 Each core belonging to the same Package reading the MSR_PKG_ENERGY_STATUS (i.e
64 time spent scheduled for each QEMU thread *and* the energy spent by the
73 of vcpu threads so that each vcpu thread will get an equal part of the
78 9. Calculate the energy for each virtual package.
80 10. The virtual MSRs are updated for each virtual package. Each vCPU that
|
| H A D | pci-testdev.rst | 8 Each of BAR 0+1 can be memory or IO. Guests must detect
11 BAR 0+1 size is up to 4K bytes each.
32 The device is expected to always implement tests 0 to N on each BAR, and to add new
|
| H A D | ppc-spapr-numa.rst | 41 Each allocable resource has an ibm,associativity property. The LOPAPR
55 is also deprecated. With the current format, each integer of the
62 to the same first boundary will have the shortest distance from each
71 The first NUMA level (0x3) is interpreted as the third element of each
74 belonging to the first NUMA level have distance equal to 10 from each
75 other, and each NUMA level doubles the distance from the previous. This
143 way to calculate it. We have the ibm,associativity for each resource, which
148 The result is that each OS is free to implement and to interpret the distance
149 as it sees fit. For the pseries Linux guest, each level of NUMA duplicates
275 each distance:
|
| H A D | ivshmem-spec.rst | 41 - If you additionally need the capability for peers to interrupt each
139 For each new client that connects to the server, the server
161 communicate with each other normally, but won't receive disconnect
180 Each message consists of a single 8 byte little-endian signed number,
201 repeated N times. Each repetition is accompanied by one file
208 Each repetition is accompanied by one file descriptor. These are
|
| /qemu/target/hexagon/ |
| H A D | README | 27 encode*.def Encoding patterns for each instruction
29 legal VLIW slots for each instruction
158 Notice that we also generate a variable named <operand>_off for each operand of
183 We also generate an analyze_<tag> function for each instruction. Currently,
185 During gen_start_packet, we invoke the analyze_<tag> function for each instruction in
187 semantics can be short-circuited. If not, we initialize the result register for each
208 runtime information for each thread and contains stuff like the GPR and
233 These files create a function for each instruction. It is mostly composed of
252 packet is committed. We record the results of each instruction in a side data
301 The helper function for each instruction is named helper_<TAG>, so here's
|
| /qemu/qapi/ |
| H A D | stats.json | 29 # for each power of two.
119 # @target: the kind of objects to query. Note that each possible
123 # optionally which named values to return within each provider
189 # Returns: a list of StatsResult, one for each provider and object
190 # (e.g., for each vCPU).
204 # @name: name of the statistic; each element of the schema is uniquely
223 # width of each bucket of the histogram.
|
| /qemu/target/xtensa/core-dsp3400/ |
| H A D | core-matmap.h | 54 /* Cache Attribute encodings -- lists of access modes for each cache attribute: */
134 * way = each TLB (ITLB and DTLB) consists of a number of "ways"
139 * each way can be independently configured in terms of number of
182 /* Way set to which each way belongs: */
212 /* Constant VPN values for each entry of ITLB way set 0 (because VPN_CONSTMASK is non-zero): */
221 /* Reset PPN values for each entry of ITLB way set 0 (because SET0_PPN_RESET is non-zero): */
230 /* Reset CA values for each entry of ITLB way set 0 (because SET0_CA_RESET is non-zero): */
248 /* Way set to which each way belongs: */
278 /* Constant VPN values for each entry of DTLB way set 0 (because VPN_CONSTMASK is non-zero): */
287 /* Reset PPN values for each entry of DTLB way set 0 (because SET0_PPN_RESET is non-zero): */
[all …]
|
| /qemu/docs/devel/testing/ |
| H A D | fuzzing.rst | 57 libFuzzer stores each "interesting" input in this corpus directory. The next
76 * ``-use_value_profile=1`` : For each comparison operation, libFuzzer computes
79 the fuzzer's input and Arg2 is a magic constant, then each time the Hamming
155 MemoryRegion names and MemoryRegion owner names, to decide whether each
186 ``tests/qtest/fuzz/generic_fuzz_configs.h``. Each config must specify:
275 ``LLVMFuzzerTestOneInput``: called for each fuzzing run. Processes the input and
276 resets the state at the end of each run.
295 be reset at the end of each run. For example, this can be done by rebooting the
296 VM, after each run.
302 for QOS-based targets), this initialization needs to be done after each
|
| /qemu/include/hw/arm/ |
| H A D | armsse.h | 29 * space are secure and non-secure aliases of each other
36 * a control interface for an icache for each CPU
51 * address of each SRAM bank (and thus the total amount of internal SRAM)
76 * Controlling each of the 4 expansion AHB PPCs which a system using the IoTKit
83 * Controlling each of the 16 expansion MPCs which a system using the IoTKit
86 * Controlling each of the 16 expansion MSCs which a system using the IoTKit
131 /* We have an IRQ splitter and an OR gate input for each external PPC
|
| /qemu/scripts/ |
| H A D | cpu-x86-uarch-abi.py | 6 # compatibility levels for each CPU model.
19 # Mandatory CPUID features for each microarch ABI level
112 # Whether each x86-64 ABI level is satisfied
126 # Calculate whether the CPU models satisfy each ABI level
138 # Cache list of CPU models satisfying each ABI level
|
| /qemu/hw/pci/ |
| H A D | slotid_cap.c | 18 error_setg(errp, "Bridge chassis not specified. Each bridge is required" in slotid_cap_init()
32 /* We make each chassis unique, this way each bridge is First in Chassis */ in slotid_cap_init()
|
| /qemu/include/hw/misc/ |
| H A D | iotkit-secctl.h | 29 * Controlling each of the 4 expansion APB PPCs which a system using the IoTKit
36 * Controlling each of the 4 expansion AHB PPCs which a system using the IoTKit
45 * Controlling each of the 16 expansion MPCs which a system using the IoTKit
48 * Controlling each of the 16 expansion MSCs which a system using the IoTKit
|
| H A D | npcm7xx_pwm.h | 23 /* Each PWM module holds 4 PWM channels. */
33 * The maximum duty values. Each duty unit represents 1/NPCM7XX_PWM_MAX_DUTY
80 * @duty_gpio_out: The duty cycle of each PWM channels as a output GPIO.
|
| /qemu/include/qemu/ |
| H A D | qht.h | 28 * @chain: frequency distribution representing the number of buckets in each
34 * Each bucket can host several entries.
178 * @func: function to be called for each entry in QHT
181 * Each time it is called, user-provided @func is passed a pointer-hash pair,
192 * @func: function to be called for each entry in QHT
195 * Each time it is called, user-provided @func is passed a pointer-hash pair,
|
| /qemu/migration/ |
| H A D | dirtyrate.h | 54 * Store dirtypage info for each ramblock.
57 char idstr[RAMBLOCK_INFO_MAX_LEN]; /* idstr for each ramblock */
73 * Store calculation statistics for each measure.
|
| /qemu/ui/ |
| H A D | vnc-enc-tight.h | 36 *-- The first byte of each Tight-encoded rectangle is a "compression control
76 * Here each character denotes one bit, xxxxxxx are the least significant 7
98 * which converts each color component to a difference between a "predicted"
114 * is 2, then each pixel is encoded in 1 bit, otherwise 8 bits is used to
116 * significant bits correspond to the leftmost pixels, and each raw of pixels
155 * and each one should be encoded separately.
|
| /qemu/docs/devel/migration/ |
| H A D | main.rst | 9 that, saves the state for each device that the guest is running.
11 state of each device.
174 different for each registration. Use the second one if you already
175 have an id that is different for each instance of the device:
208 Each device has to register two functions, one to save the state and
394 Each version is associated with a series of fields saved. The ``save_state`` always saves
508 the point that stream bandwidth limits tell it to stop. Each call
554 Each section contains a device, or one iteration of a device save.
558 - ID string (First section of each device)
559 - instance id (First section of each device)
[all …]
|
| /qemu/docs/devel/ |
| H A D | build-system.rst | 253 once for each target being built. Target-dependent files are included
256 Each emulator also includes sources for files in the ``hw/`` and ``target/``
257 subdirectories. The subdirectory used for each emulator comes
261 Each subdirectory in ``hw/`` adds one sourceset to the ``hw_arch`` dictionary,
271 Each subdirectory in ``target/`` instead should add one sourceset to each
314 into each emulator:
318 that are built into each QEMU system emulation targets. They merely contain
332 file for each emulator\ [#cfgtarget]_. However, the ``TARGET_ARCH``
334 ``target/`` subdirectories that are compiled into each target.
573 features for each target. enabled. They are generated from
[all …]
|
| /qemu/tests/qtest/fuzz/ |
| H A D | i440fx_fuzz.c | 44 * loop over the Data, breaking it up into actions. each action has an in ioport_fuzz_qtest()
162 "rebooting after each run", in register_pci_fuzz_targets()
169 * reboot after each run, we would also have to redo the qos-related in register_pci_fuzz_targets()
175 "rebooting after each run", in register_pci_fuzz_targets()
|
| /qemu/docs/ |
| H A D | pcie.txt | 81 A PCI Express Root bus supports up to 32 devices. Since each
128 - (slot, chassis) pair is mandatory and must be unique for each
143 (each supporting also 32 slots) will support hundreds of legacy devices.
174 Firmware/Guest OS as PCI-PCI Bridges. As required by the PCI spec, each
176 (multifunction) device can be plugged into each Port. This results in
180 by not allocating IO space for each PCI Express Root / PCI Express
198 Each PCI domain can have up to only 256 buses and the QEMU PCI Express
202 Each element of the PCI Express hierarchy (Root Complexes,
246 For each such PCI-PCI Bridge the Guest Firmware is expected to reserve
260 to, each one of those uses an extra PCI bus (for its Upstream Port)
|
| /qemu/tests/uefi-test-tools/UefiTestToolsPkg/Include/Guid/ |
| H A D | BiosTablesTest.h | 48 // value that the hypervisor should look for at each MB boundary, looping
59 // ACPI 2.0 or later specification RSD PTR table. Each of these fields may be
71 // in the same representation. Each of these fields may be zero
|
| /qemu/docs/system/arm/ |
| H A D | fby35.rst | 18 In this generation, the BMC is an AST2600 and each BIC is an AST1030. The BMC
32 Since this machine has multiple SoC's, each with their own serial console, the
33 recommended way to run it is to allocate a pseudoterminal for each serial
|