vm.js, vmadm: migrate-listen startup mode for bhyve live migration
Adds a first-class way to boot a bhyve VM in its live-migration
destination mode, replacing the /tmp/migrate.listen sentinel file
sidechannel with a properly scoped zonecfg attribute.
Interface:
vmadm start <uuid> migrate-listen=true
This flows through VM.start(uuid, extra, {migrate_listen: true}, cb)
→ startVM → startZone, which (for the duration of this single
zoneadm boot call only) adds a transient `migrate_listen=true`
attribute to the zone's config via zonecfg. The brand boot program
(usr/src/lib/brand/bhyve/zone/boot.c, illumos-joyent companion
change) reads the attribute and appends `-o migrate.listen=true` to
the bhyve argv, causing bhyve to skip bootrom + vcpu_reset and block
on its in-zone control socket waiting for import-state from the GZ
migration agent.
[16 lines not shown]
vm.js, vmadm: migrate-listen startup mode for bhyve live migration
Adds a first-class way to boot a bhyve VM in its live-migration
destination mode, replacing the /tmp/migrate.listen sentinel file
sidechannel with a properly scoped zonecfg attribute.
Interface:
vmadm start <uuid> migrate-listen=true
This flows through VM.start(uuid, extra, {migrate_listen: true}, cb)
→ startVM → startZone, which (for the duration of this single
zoneadm boot call only) adds a transient `migrate_listen=true`
attribute to the zone's config via zonecfg. The brand boot program
(usr/src/lib/brand/bhyve/zone/boot.c, illumos-joyent companion
change) reads the attribute and appends `-o migrate.listen=true` to
the bhyve argv, causing bhyve to skip bootrom + vcpu_reset and block
on its in-zone control socket waiting for import-state from the GZ
migration agent.
[16 lines not shown]
[WebAssembly] Improve FP16 load and store generation. (#191274)
Previously, these LL instructions were expanded to software emulation
calls, causing performance overhead in benchmarks. By making these
operations legal and providing patterns, we can generate efficient code
using the new instructions.
[lldb] Add synthetic variable support to Get*VariableList.
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_synthetic_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include synthetic variables or not and leave comments explaining the decision.
As a consequence of producing synthetic variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no synthetic variables".
stack-info: PR: https://github.com/llvm/llvm-project/pull/181501, branch: users/bzcheeseman/stack/9
ifconfig: Do not build geneve with WITHOUT_NETLINK_SUPPORT
geneve(4) is netlink-only, therefore, don't build it with
WITHOUT_NETLINK_SUPPORT=1 set.
Reported by: kp
Fixes: 688e289ee904 ("ifconfig: Add support for geneve (netlink)")
Differential Revision: https://reviews.freebsd.org/D55184
devel/codex: update to 0.121.0; recovery code mode; claim maintainership
patches which cut off code mode from codex grows, and I think soon it
will make that tool useless.
Here an opposite approach: build v8 which is requried for code mode.
For now it is limited only for amd64 and arm64.
[lldb] Scaffolding for synthetic variable support. (#181500)
This patch handles most of the scaffolding for synthetic variable support that isn't directly tied to functional changes. This patch will be used by one following patch that actually modifies the lldb_private::StackFrame API to allow us to fetch synthetic variables.
There were a couple important/interesting decisions made in this patch that should be noted:
- Any value type may be synthetic, which is why it's a mask applied over the top of another value type.
- When printing frame variables with `fr v`, default to showing synthetic variables.
This new value type mask makes some of the ValueType handling more interesting, but since nothing generates objects with this mask until the next patch, we can land the concept in this patch in some amount of isolation.
powerpc/intr setup: Don't check intr name for IPI
Since whether or not the irq is an IPI is passed into
powerpc_setup_intr_int(), use this as the check for IPI instead of
checking the name string.
powerpc/pmap: Add support for page sizes found on E6500
E6500 cores (MMUv2) support all powers-of-2 page sizes from 4k to 1TB,
not just powers of 4. By using the other page sizes (8k, 32k, etc) we
can save on TLB1 space, saving up to ~1/3 of used TLB1 entries.
[lldb] Add synthetic variable support to Get*VariableList.
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_synthetic_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include synthetic variables or not and leave comments explaining the decision.
As a consequence of producing synthetic variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no synthetic variables".
stack-info: PR: https://github.com/llvm/llvm-project/pull/181501, branch: users/bzcheeseman/stack/9
[lldb] Scaffolding for synthetic variable support.
This patch handles most of the scaffolding for synthetic variable support that isn't directly tied to functional changes. This patch will be used by one following patch that actually modifies the lldb_private::StackFrame API to allow us to fetch synthetic variables.
There were a couple important/interesting decisions made in this patch that should be noted:
- Any value type may be synthetic, which is why it's a mask applied over the top of another value type.
- When printing frame variables with `fr v`, default to showing synthetic variables.
This new value type mask makes some of the ValueType handling more interesting, but since nothing generates objects with this mask until the next patch, we can land the concept in this patch in some amount of isolation.
stack-info: PR: https://github.com/llvm/llvm-project/pull/181500, branch: users/bzcheeseman/stack/8
[LoopBoundSplit] Fix edge connections during transformation (#192106)
Fixed #190672.
The issue is caused by invalid intermediate IR when `getSCEV()` is
called during transformation: the exiting block of `pre-loop` did not
re-connect to preheader of the `post-loop`, causing `LI.verify()`
unable to correctly recompute another LoopInfo for verification.
To fix, reconnect the edge earlier before calling `getSCEV()`.
Also moved the DT updates to more appropriate places right after IR
control flow has changed. and added a few LI and DT verifications to
improve robustness of the pass.
[lldb] Add synthetic variable support to Get*VariableList.
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_synthetic_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include synthetic variables or not and leave comments explaining the decision.
As a consequence of producing synthetic variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no synthetic variables".
stack-info: PR: https://github.com/llvm/llvm-project/pull/181501, branch: users/bzcheeseman/stack/9
[lldb] Scaffolding for synthetic variable support.
This patch handles most of the scaffolding for synthetic variable support that isn't directly tied to functional changes. This patch will be used by one following patch that actually modifies the lldb_private::StackFrame API to allow us to fetch synthetic variables.
There were a couple important/interesting decisions made in this patch that should be noted:
- Any value type may be synthetic, which is why it's a mask applied over the top of another value type.
- When printing frame variables with `fr v`, default to showing synthetic variables.
This new value type mask makes some of the ValueType handling more interesting, but since nothing generates objects with this mask until the next patch, we can land the concept in this patch in some amount of isolation.
stack-info: PR: https://github.com/llvm/llvm-project/pull/181500, branch: users/bzcheeseman/stack/8
[AMDGPU] Add `.amdgpu.info` section for per-function metadata
AMDGPU object linking requires the linker to propagate resource usage
(registers, stack, LDS) across translation units. To support this, the compiler
must emit per-function metadata and call graph edges in the relocatable object
so the linker can compute whole-program resource requirements.
This PR introduces a `.amdgpu.info` ELF section using a tagged, length-prefixed
binary format: each entry is encoded as:
```
[kind: u8] [len: u8] [payload: <len> bytes]
```
A function scope is opened by an `INFO_FUNC` entry (containing a symbol
reference), followed by per-function attributes (register counts, flags, private
segment size) and relational edges (direct calls, LDS uses, indirect call
signatures). String data such as function type signatures is stored in a
companion `.amdgpu.strtab` section.
[4 lines not shown]
[flang][cuda] Avoid false positive on multi device symbol with components (#192513)
Semantic was wrongly flagging derived-type components as two device
resident object. Update how we collect symbols and count the number of
device resident object.
