| /openbmc/qemu/docs/devel/migration/ |
| H A D | compatibility.rst | 7 When we do migration, we have two QEMU processes: the source and the
18 Let's start with a practical example, we start with:
36 I am going to list the number of combinations that we can have. Let's
50 This are the easiest ones, we will not talk more about them in this
53 Now we start with the more interesting cases. Consider the case where
54 we have the same QEMU version in both sides (qemu-5.2) but we are using
72 because we have the limitation than qemu-5.1 doesn't know pc-5.2. So
78 when we are developing 5.2 we need to take care about not to break
79 migration to qemu-5.1. Notice that we can't make updates to
86 than we are able to receive migrations from qemu-5.1. The problem is
[all …]
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools/build/ |
| H A D | 0001-Riscv-Add-risc-v-Android-config-header.patch | 63 + * Do we have pthread_setname_np()?
66 + * the same name but different parameters, so we can't use that here.)
71 + * Do we have the futex syscall?
85 + * where we can write to /proc/<pid>/oom_adj to modify the out-of-memory
135 + * Define this if we have localtime_r().
140 + * Define this if we have gethostbyname_r().
145 + * Define this if we have ioctl().
150 + * Define this if we want to use WinSock.
160 + * Define this if we have linux style epoll()
167 + * HAVE_ENDIAN_H -- have endian.h header we can include.
[all …]
|
| /openbmc/linux/Documentation/driver-api/thermal/ |
| H A D | cpu-idle-cooling.rst | 25 because of the OPP density, we can only choose an OPP with a power
35 If we can remove the static and the dynamic leakage for a specific
38 injection period, we can mitigate the temperature by modulating the
47 At a specific OPP, we can assume that injecting idle cycle on all CPUs
49 idle state target residency, we lead to dropping the static and the
132 - It is less than or equal to the latency we tolerate when the
134 user experience, reactivity vs performance trade off we want. This
137 - It is greater than the idle state’s target residency we want to go
138 for thermal mitigation, otherwise we end up consuming more energy.
143 When we reach the thermal trip point, we have to sustain a specified
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/pinctrl/ |
| H A D | sprd,pinctrl.txt | 12 to choose one function (like: UART0) for which system, since we
15 There are too much various configuration that we can not list all
16 of them, so we can not make every Spreadtrum-special configuration
18 global configuration in future. Then we add one "sprd,control" to
19 set these various global control configuration, and we need use
22 Moreover we recognise every fields comprising one bit or several
23 bits in one global control register as one pin, thus we should
32 Now we have 4 systems for sleep mode on SC9860 SoC: AP system,
42 In some situation we need set the pin sleep mode and pin sleep related
45 sleep mode. For example, if we set the pin sleep mode as PUBCP_SLEEP
[all …]
|
| /openbmc/linux/Documentation/arch/x86/ |
| H A D | entry_64.rst | 58 so. If we mess that up even slightly, we crash.
60 So when we have a secondary entry, already in kernel mode, we *must
61 not* use SWAPGS blindly - nor must we forget doing a SWAPGS when it's
87 If we are at an interrupt or user-trap/gate-alike boundary then we can
89 whether SWAPGS was already done: if we see that we are a secondary
90 entry interrupting kernel mode execution, then we know that the GS
91 base has already been switched. If it says that we interrupted
92 user-space execution then we must do the SWAPGS.
94 But if we are in an NMI/MCE/DEBUG/whatever super-atomic entry context,
96 stack but before we executed SWAPGS, then the only safe way to check
[all …]
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-multimedia/libid3tag/libid3tag/ |
| H A D | 10_utf16.patch | 25 + * - Try and parse as much as we can and
26 + * - return an error if we're called again when we
27 + * already tried to parse everything we can.
28 + * - tell that we parsed it, which is what we do here.
|
| /openbmc/linux/Documentation/dev-tools/kunit/ |
| H A D | run_wrapper.rst | 10 As long as we can build the kernel, we can run KUnit.
44 kunit_tool. This is useful if we have several different groups of
45 tests we want to run independently, or if we want to use pre-defined
64 If we want to run a specific set of tests (rather than those listed
65 in the KUnit ``defconfig``), we can provide Kconfig options in the
90 set in the kernel ``.config`` before running the tests. It warns if we
96 This means that we can use other tools
104 If we want to make manual changes to the KUnit build process, we
106 When running kunit_tool, from a ``.kunitconfig``, we can generate a
113 To build a KUnit kernel from the current ``.config``, we can use the
[all …]
|
| /openbmc/openbmc/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot/corstone1000/ |
| H A D | 0028-corstone1000-boot-index-from-active.patch | 7 all the boot tries and status, so, every time we get here
8 we know that the we are booting from the active index.
30 + * all the boot tries and status, so, every time we get here
31 + * we know that the we are booting from the active index
|
| /openbmc/u-boot/board/freescale/mpc8569mds/ |
| H A D | README | 39 defined in board/freescale/common/sys_eeprom.c. we must set all 8 MAC
41 we first get the board. The commands are as follows:
44 designer, we can set whatever we want */
46 designer, we can set whatever we want */
61 has been set but we want to update it, we can use the following commands:
69 MPC8569 doesn't have ROM in QE, so we must upload the microcode(ucode) to QE's
|
| /openbmc/linux/Documentation/filesystems/ext4/ |
| H A D | orphan.rst | 9 would leak. Similarly if we truncate or extend the file, we need not be able
10 to perform the operation in a single journalling transaction. In such case we
17 inode (we overload i_dtime inode field for this). However this filesystem
36 When a filesystem with orphan file feature is writeably mounted, we set
38 be valid orphan entries. In case we see this feature when mounting the
39 filesystem, we read the whole orphan file and process all orphan inodes found
40 there as usual. When cleanly unmounting the filesystem we remove the
|
| /openbmc/linux/tools/lib/perf/Documentation/ |
| H A D | libperf-counting.txt | 73 Once the setup is complete we start by defining specific events using the `struct perf_event_attr`.
97 In this case we will monitor current process, so we create threads map with single pid (0):
110 Now we create libperf's event list, which will serve as holder for the events we want:
121 We create libperf's events for the attributes we defined earlier and add them to the list:
156 so we need to enable the whole list explicitly (both events).
158 From this moment events are counting and we can do our workload.
160 When we are done we disable the events list.
171 Now we need to get the counts from events, following code iterates through the
|
| /openbmc/linux/Documentation/hid/ |
| H A D | hid-bpf.rst | 30 With HID-BPF, we can apply this filtering in the kernel directly so userspace
33 Of course, given that this dead zone is specific to an individual device, we
38 HID-BPF allows the userspace program to load the program itself, ensuring we
39 only load the custom API when we have a user.
49 program has been verified by the user, we can embed the source code into the
62 Instead of using hidraw or creating new sysfs entries or ioctls, we can rely
82 screen we likely need to have a haptic click every 15 degrees. But when
89 What if we want to prevent other users to access a specific feature of a
92 With eBPF, we can intercept any HID command emitted to the device and
96 kernel/bpf program because we can intercept any incoming command.
[all …]
|
| /openbmc/linux/Documentation/filesystems/ |
| H A D | xfs-delayed-logging-design.rst | 16 transaction reservations are structured and accounted, and then move into how we
18 reservations bounds. At this point we need to explain how relogging works. With
113 individual modification is atomic, the chain is *not atomic*. If we crash half
140 complete, we can explicitly tag a transaction as synchronous. This will trigger
145 throughput to the IO latency limitations of the underlying storage. Instead, we
161 available to write the modification into the journal before we start making
164 log in the worst case. This means that if we are modifying a btree in the
165 transaction, we have to reserve enough space to record a full leaf-to-root split
166 of the btree. As such, the reservations are quite complex because we have to
173 again. Then we might have to update reverse mappings, which modifies yet
[all …]
|
| H A D | path-lookup.txt | 49 the path given by the name's starting point (which we know in advance -- eg.
55 A parent, of course, must be a directory, and we must have appropriate
79 In order to lookup a dcache (parent, name) tuple, we take a hash on the tuple
81 in that bucket is then walked, and we do a full comparison of each entry
148 However, when inserting object 2 onto a new list, we end up with this:
161 Because we didn't wait for a grace period, there may be a concurrent lookup
182 As explained above, we would like to do path walking without taking locks or
188 than reloading from the dentry later on (otherwise we'd have interesting things
192 no non-atomic stores to shared data), and to recheck the seqcount when we are
194 Avoiding destructive or changing operations means we can easily unwind from
[all …]
|
| H A D | directory-locking.rst | 10 When taking the i_rwsem on multiple non-directory objects, we
16 1) read access. Locking rules: caller locks directory we are accessing.
26 the parent and finds source and target. Then we decide which of the
70 [XXX: will be updated once we are done massaging the lock_rename()]
71 First of all, at any moment we have a linear ordering of the
78 attempts to acquire lock on B, A will remain the parent of B until we
84 renames will be blocked on filesystem lock and we don't start changing
85 the order until we had acquired all locks).
114 would have a contended child and we had assumed that no object is its
119 of its descendents is locked by cross-directory rename (otherwise we
[all …]
|
| /openbmc/linux/Documentation/scheduler/ |
| H A D | schedutil.rst | 8 we know this is flawed, but it is the best workable approximation.
14 With PELT we track some metrics across the various scheduler entities, from
16 we use an Exponentially Weighted Moving Average (EWMA), each period (1024us)
35 Using this we track 2 key metrics: 'running' and 'runnable'. 'Running'
50 a big CPU, we allow architectures to scale the time delta with two ratios, one
53 For simple DVFS architectures (where software is in full control) we trivially
60 For more dynamic systems where the hardware is in control of DVFS we use
62 For Intel specifically, we use::
84 of DVFS and CPU type. IOW. we can transfer and compare them between CPUs.
125 migration, time progression) we call out to schedutil to update the hardware
[all …]
|
| /openbmc/u-boot/test/overlay/ |
| H A D | test-fdt-overlay.dts | 11 /* Test that we can change an int by another */
20 /* Test that we can replace a string by a longer one */
29 /* Test that we add a new property */
38 /* Test that we add a new node (by phandle) */
49 /* Test that we add a new node (by path) */
|
| /openbmc/linux/Documentation/gpu/amdgpu/display/ |
| H A D | dcn-overview.rst | 6 (DCN) works, we need to start with an overview of the hardware pipeline. Below
8 generic diagram, and we have variations per ASIC.
12 Based on this diagram, we can pass through each block and briefly describe
58 setup or ignored accordingly with userspace demands. For example, if we
77 From DCHUB to MPC, we have a representation called dc_plane; from MPC to OPTC,
78 we have dc_stream, and the output (DIO) is handled by dc_link. Keep in mind
100 a one-to-one mapping of the link encoder to PHY, but we can configure the DCN
123 depth format), bit-depth reduction/dithering would kick in. In OPP, we would
125 Eventually, we output data in integer format at DIO.
131 overloaded with multiple meanings, so it is important to define what we mean
[all …]
|
| /openbmc/linux/drivers/scsi/aic7xxx/ |
| H A D | aic79xx.seq | 85 * If we have completions stalled waiting for the qfreeze
109 * ENSELO is cleared by a SELDO, so we must test for SELDO
169 * Since this status did not consume a FIFO, we have to
170 * be a bit more dilligent in how we check for FIFOs pertaining
178 * count in the SCB. In this case, we allow the routine servicing
183 * we detect case 1, we will properly defer the post of the SCB
222 * bad SCSI status (currently only for underruns), we
223 * queue the SCB for normal completion. Otherwise, we
258 * If we have relatively few commands outstanding, don't
303 * one byte of lun information we support.
[all …]
|
| /openbmc/linux/Documentation/powerpc/ |
| H A D | vmemmap_dedup.rst | 14 With 2M PMD level mapping, we require 32 struct pages and a single 64K vmemmap
18 With 1G PUD level mapping, we require 16384 struct pages and a single 64K
19 vmemmap page can contain 1024 struct pages (64K/sizeof(struct page)). Hence we
47 4K vmemmap page contains 64 struct pages(4K/sizeof(struct page)). Hence we
74 With 1G PUD level mapping, we require 262144 struct pages and a single 4K
75 vmemmap page can contain 64 struct pages (4K/sizeof(struct page)). Hence we
|
| /openbmc/qemu/linux-user/s390x/ |
| H A D | vdso.ld | 19 * QEMU handles syscall restart internally, so we don't
40 * when we relocate the binary. We want them to be initially
41 * writable for the relocation; we'll force them read-only after.
48 * But since we manipulated the segment layout,
49 * we have to put these sections somewhere.
|
| /openbmc/qemu/docs/devel/ |
| H A D | s390-dasd-ipl.rst | 34 the real operating system is loaded into memory and we are ready to hand
49 should contain the needed flags for the operating system we have loaded. The
50 psw's instruction address will point to the location in memory where we want
68 In theory we should merely have to do the following to IPL/boot a guest
79 When we start a channel program we pass the channel subsystem parameters via an
95 it from the disk. So we need to be able to handle this case.
100 Since we are forced to live with prefetch we cannot use the very simple IPL
101 procedure we defined in the preceding section. So we compensate by doing the
112 to read the very next record which will be IPL2. But since we are not reading
113 both IPL1 and IPL2 as part of the same channel program we must manually set
[all …]
|
| H A D | tcg-icount.rst | 44 In the case of icount, before the flag is checked we subtract the
46 would cause the instruction budget to go negative we exit the main
49 was due to expire will expire exactly when we exit the main run loop.
54 While we can adjust the instruction budget for known events like timer
55 expiry we cannot do the same for MMIO. Every load/store we execute
56 might potentially trigger an I/O event, at which point we will need an
59 To deal with this case, when an I/O access is made we:
70 MMIO isn't the only type of operation for which we might need a
|
| /openbmc/qemu/docs/system/ |
| H A D | introduction.rst | 82 For a non-x86 system where we emulate a broad range of machine types,
88 command line to launch VMs, we do want to highlight that there are a
152 In the following example we first define a ``virt`` machine which is a
154 virtualisation so we can use KVM inside the emulated guest. As the
155 ``virt`` machine comes with some built in pflash devices we give them
156 names so we can override the defaults later.
177 devices we need to define them. We give them ids so we can link them
188 we forward localhost port 2222 to the ssh port on the guest.
194 We connect the guest visible block device to an LVM partition we have
202 port output (we can switch between the two using :ref:`keys in the
[all …]
|
| /openbmc/u-boot/doc/ |
| H A D | README.hwconfig | 8 via the `hwconfig' environment variable. Later we could write
20 2. Since we don't implement a hwconfig command, i.e. we're working
36 internal API and then we can continue improving the user
38 command with bells and whistles. Or not adding, if we feel
46 enabling HW feature X we may need to disable Y, and turn Z
|