DEV Community: Kernel notes (sunshout)

KVM SR-IOV: intel_iommu=on is not SR-IOV until you create VFs

Kernel notes (sunshout) — Tue, 25 Aug 2026 04:32:36 +0000

A lot of homelab notes stop at GRUB:

pci=assign-busses iommu=pt intel_iommu=on

update-grub or on CentOS:

grub2-mkconfig -o /boot/grub2/grub.cfg

Reboot. dmesg shows Intel-IOMMU: enabled. That means the IOMMU is on. It does not mean you have virtual functions. SR-IOV is a PCIe capability on a physical function (PF). You still have to ask the PF to spawn VFs.

Commands I actually ran, with the dmesg checks, are on the original note:

https://sunshout.tistory.com/1615

Confirm the IOMMU before you blame the NIC

Intel:

dmesg | grep -e DMAR -e IOMMU
# expect Intel-IOMMU: enabled

If that line is missing, the GRUB tokens did not reach the kernel (/proc/cmdline) or the board has IOMMU off in firmware.

Then create VFs

lspci — you want a PF that advertises SR-IOV. On the box I used it was an Intel 82599 10G:

04:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ ...
04:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ ...

Spawn four VFs on the first PF:

echo 4 > /sys/bus/pci/devices/0000:04:00.0/sriov_numvfs
lspci | grep -i virtual

If sriov_numvfs does not exist, the firmware VF count is zero, the kernel driver does not support it, or you echoed into the VF by mistake. Use the PF address.

Make it survive reboot with a udev rule or a oneshot systemd unit. sysfs is not persistent.

vfio-pci bind fails after VFs appear

Usually IOMMU groups, not the echo. A device in a group with a sibling you cannot stub out will refuse assignment. find /sys/kernel/iommu_groups -type l and ACS / firmware settings are the next stop — not a second intel_iommu=on.

Isolation is a separate post

Pinning the datapath CPU so host interrupts do not land on the poll thread is isolcpus + IRQ affinity, not SR-IOV. That write-up:

https://sunshout.tistory.com/1620

If sriov_numvfs is missing on a card the vendor claims is SR-IOV capable, dump lspci -vvv -s 04:00.0 | grep -i sriov before you buy another NIC.

Related lab notes (canonical originals)

TLS vs SSL, three jobs of the tunnel: https://sunshout.tistory.com/2206
isolcpus isolates the scheduler, not IRQs: https://sunshout.tistory.com/1620
QEMU virtio-blk aio=io_uring is a host flag: https://sunshout.tistory.com/2156

isolcpus= takes CPUs off the scheduler. Hardware IRQs still land there.

Kernel notes (sunshout) — Tue, 25 Aug 2026 03:46:13 +0000

The blunt tool is still in a lot of GRUB files:

GRUB_CMDLINE_LINUX_DEFAULT="isolcpus=0,1"

Then update-grub (or grub2-mkconfig) and reboot. Userspace tasks stop landing on CPU0/1. That is all most people verify — they fire a few busy loops and top looks empty on those cores.

IRQs do not care. isolcpus is a scheduler isolation hint. Hardware interrupts can still fire on the "isolated" CPUs. I watched seven tight loops leave 0/1 idle for processes while /proc/interrupts still ticked on those cores.

If you wanted a CPU for DPDK, a user-space NIC, or a cycle-accurate loop, scheduler isolation is necessary and not sufficient.

Lab notes (English original is short; this write-up is the missing IRQ half):

https://sunshout.tistory.com/1620

How to see what you actually isolated

After reboot:

cat /proc/cmdline          # isolcpus=0,1 must be there
grep PREEMPT /boot/config-$(uname -r) || true
taskset -cp 1              # pick a known userspace pid; it should not be 0,1
watch -n1 'grep "^ *[0-9]" /proc/interrupts | head'

If IRQs still increment on CPU0/1, isolation is incomplete. That is expected with classic isolcpus=.

On newer kernels the story split:

isolcpus=domain / cpusets / cgroup cpuset — userspace
isolcpus=managed_irq or manual irqaffinity / /proc/irq/*/smp_affinity — interrupts
nohz_full= — tick reduction, another knob, not a substitute

isolcpus is also marked deprecated in some trees in favor of cpusets. The IRQ caveat did not go away when the docs changed the preferred interface.

Moving IRQs by hand

Find the noisy ones (eth0, NVMe, GPU):

grep -E 'eth|nvme|enp' /proc/interrupts
# smp_affinity is a hex CPU mask. CPU2 only → 4
echo 4 > /proc/irq/IRQNUM/smp_affinity

Or set the default affinity so new IRQs skip 0/1:

irqaffinity=2-7

in the same GRUB line (adjust to your CPU count). Some devices ignore this (managed IRQs, VFIO). Then you isolate at the driver: bind the NIC to vfio-pci and poll from a pinned thread.

When this shows up next to SR-IOV

Passing a VF into KVM does not pin host IRQs for you. IOMMU on (intel_iommu=on iommu=pt) is a different checklist. I wrote the VF creation half here:

https://sunshout.tistory.com/1615

Typical datapath box:

IOMMU on, VFs created, vfio-pci bound.
isolcpus and IRQ affinity so the poll thread is not preempted by the host NIC's own interrupt.
Confirm with /proc/interrupts, not with top.

If your kernel is 6.x, say so in the comments — the flags moved, the IRQ rule did not.

Related lab notes (canonical originals)

TLS vs SSL, three jobs of the tunnel: https://sunshout.tistory.com/2206
KVM SR-IOV: intel_iommu=on is not VFs until you create them: https://sunshout.tistory.com/1615
QEMU virtio-blk aio=io_uring is a host flag: https://sunshout.tistory.com/2156

Stop saying SSL: TLS only does three jobs, and your 'SSL cert' is usually not the outage

Kernel notes (sunshout) — Tue, 25 Aug 2026 03:34:23 +0000

Runbooks still say "renew the SSL certificate" when the browser warning is obsolete protocol. The certificate can be brand new. The tunnel is still TLS 1.0.

This is a shortened English note. The tables, handshake diagram, and OpenSSL CLI checks live on the original post:

https://sunshout.tistory.com/2206

SSL vs TLS (the only distinction that matters)

SSL is a Netscape protocol from the 1990s. SSL 3.0 is withdrawn (POODLE and friends). What every browser speaks now is TLS, currently 1.2 or 1.3.

People still say "SSL cert" because vendors sold that phrase. The file is an X.509 certificate. The handshake that uses it is TLS.

	SSL	TLS
Who	Netscape	IETF
Versions you might still see	2.0 / 3.0 (disable)	1.0 / 1.1 (disable), 1.2 / 1.3 (use)
Status	Forbidden	Required

If a ticket says "SSL is broken", translate it to: which TLS version did the handshake negotiate, and which cipher?

The tunnel only has three jobs

Confidentiality — encryption so a tap does not yield plaintext.
Integrity — a MAC (today: AEAD) so a MITM cannot flip bits unnoticed.
Authentication — the certificate binds this hostname to a key a CA will vouch for.

https is that tunnel. It is not "the lock icon means the page is safe to click." It means the bits on the wire are for that name, encrypted, and unmodified. XSS and a malicious origin are a different layer.

The outage that is not the certificate

Symptom: new Let's Encrypt leaf, browsers still scream obsolete TLS or refuse the handshake on phones.

Cause: nginx/Apache/openssl still allow TLS 1.0/1.1, or the server has no 1.2+. Renewing the cert does nothing.

Check, do not guess:

# must fail
openssl s_client -connect example.com:443 -tls1
# must work
openssl s_client -connect example.com:443 -tls1_2

nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

Keep TLS 1.2 next to 1.3 if you still have old Android or old Java. New services can prefer 1.3.

What to put in the cipher line

Key exchange: ECDHE (forward secrecy). Static RSA key exchange is how yesterday's traffic gets decrypted after a key leak.
Bulk: AES-GCM or ChaCha20-Poly1305. CBC + HMAC is how Lucky Thirteen-class bugs keep showing up.
Drop: 3DES, RC4, MD5, SHA-1 as a PRF.

OpenSSL 1.0.2 / 1.1.1 are past EOL. Heartbleed was a reminder that "it still links" is not a security policy. Run 3.x LTS and patch when the project says High/Critical.

Let's Encrypt vs OpenSSL

Let's Encrypt issues the certificate. OpenSSL (or BoringSSL, or the language runtime) runs the handshake with that certificate. Buying a cert does not harden ssl_protocols.

Private key files: chmod 400 or 600, owned by the daemon user, not world-readable. Compression off (SSL_OP_NO_COMPRESSION) — CRIME/BREACH.

I keep the longer Korean original, including the four-step handshake and a cipher table, here:

https://sunshout.tistory.com/2206

If your site opens but a scanner still flags TLS 1.0, paste the openssl s_client -tls1 output before you renew anything else.

Related lab notes (canonical originals)

These are the Korean posts with the tables and command output. English is a short version.

isolcpus isolates the scheduler, not IRQs: https://sunshout.tistory.com/1620
KVM SR-IOV: intel_iommu=on is not VFs: https://sunshout.tistory.com/1615
QEMU virtio-blk aio=io_uring is a host flag: https://sunshout.tistory.com/2156