- CR4_VMXE: VMX operations, used for hardware virtualization.
- CR4_SMXE: SMX operations, used for safer Mode Extensions (ground for
Intel's TXT - Trusted Execution Technology - platform).
- CR4_FSGSBASE: enable *FSBASE and *GSBASE instructions, for R/W access
to FS/GS segment base addresses.
- CR4_PCIDE: enable Process Context IDentifiers (other architectures may call
these "address space identifiers").
- CR4_OSXSAVE: enable xsave and xrestore instructions
- CR4_SMEP: Supervisor Mode Execution Prevention. Allows enforcing --x rights
from cpl 0.
From Intel® 64 and IA-32 Architectures Software Developer’s Manual,
March 2012.
Align declarations.
CPUID_* bits for these features follow.
all we decided to adopt the Linux API, therefore there is rationale
to stick to it.
No standard tells us what to do, and our extended attribute API has not
been used in a release, therefore we do not break anything, and we get
more easily compatible with programs using the Linux extended attribute
API.
Note that FreeBSD and MacOS X return ENOATTR. FreeBSD has its own API
and MacOS X has a Linux-like API. How did the world get so complicated?
- Remove copy-pasting in error paths, use execve_free_{vmspace,data}().
- Move some code (both in the init and exit paths) out of the locks.
- Slightly simplify do_posix_spawn() callers.
- Add few asserts and comments.
translate FSYNC_LAZY into PGO_LAZY for VOP_PUTPAGES() so that
genfs_do_io() can set the appropriate io priority for the I/O.
this is the first part of addressing PR 46325.
To make code in 'external' (etc) still compile, MALLOC_DECLARE() still
has to generate something of type 'struct malloc_type *', with
normal optimisation gcc generates a compile-time 0.
MALLOC_DEFINE() and friends have no effect.
Fix one or two places where the code would no longer compile.
The M_xxx arg is left on the calls to malloc() and free(),
maybe they could be converted to an enumeration and just saved in
the malloc header (for deep diag use).
Remove the malloc_type from mbuf extension.
Fixes rump build as well.
Welcome to 6.99.6
Based on isaki@'s patch and debugged by both isaki@ and tsutsui@.
PSX16550 specific hardware infomation is taken from Human68k's PSXIO driver:
http://retropc.net/x68000/software/hardware/psx16550/
XXX1: TL16C550C seems to have some timing critical issue around THRE interrupt
XXX2: auto hardware flow control of TL16C550 is not implemented in MI com(4)
