Friday, March 1, 2019

All my computers are "busy" again, and that's a good sign. I'm slowly recovering from the ongoing tiredness caused by Christine's ailments (being woken up several time every night breaks you down quickly). Coincidentally, I had my first full night that I can recall since at least FOSDEM.

QEMU build failure

I thought I had done a git bisect run make, but instead I had just run make manually. So instead of running the bisect all night, it stopped after the first build. Re-started it.

Documentation

Documentation work. The current RHEL8 virtual devices section has:

The following types of passthrough devices are supported:

• VFIO device assignment
• USB, PCI, and SCSI passthrough
• SR-IOV
• NPIV
• GPUs and vGPUs

I find this wording quite dry, and tried to explain in one short sentence what each of these were. Problem

System upgrades

Systems upgrading to Fedora 29. I would also like to spend the time to install RHEL8 on two of my machines, including my primary test machines. Not sure I will have the time, but Karen wanted me to run some SMT tests, and that big machine is the best candidate for that testing.

Muse no longer has graphics. Old GeForce 580. Filed Red Hat Bugzilla 1684548.

Learned today that SMT is disabled by default in the guest unless you specify a topology. That makes sense from a scheduling point of view, but I'm concerned about mitigation code like the following:

static void __init
spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd)
{
	enum spectre_v2_user_mitigation mode = SPECTRE_V2_USER_NONE;
	bool smt_possible = IS_ENABLED(CONFIG_SMP);
	enum spectre_v2_user_cmd cmd;

	if (!boot_cpu_has(X86_FEATURE_IBPB) && !boot_cpu_has(X86_FEATURE_STIBP))
		return;

	if (cpu_smt_control == CPU_SMT_FORCE_DISABLED ||
	    cpu_smt_control == CPU_SMT_NOT_SUPPORTED)
		smt_possible = false;

RHEL8 Documentation

Still working on the wording for the types of devices

Network disk access issue

Can't access the "Systems" directory on Turbo for some reason. Grrr.

A clean install of F29 with {tt "virt-install"} goes straight to the emergency shell:

virt-install --vcpus 4 --name f29-turbo --memory 2048 --disk size=20 --network type=direct,source=enp5s0,model=virtio   --location Fedora-Workstation-Live-x86_64-29-1.2.iso

I suspect the problem is with --location vs. --cdrom.

virt-install --vcpus 4 --name f29-turbo --memory 2048 --disk size=20 --network type=direct,source=enp5s0,model=virtio   --cdrom Fedora-Workstation-Live-x86_64-29-1.2.iso

Tried my first French installation, filed my first localization bug, Red Hat Bugzilla 1684639.