Date: Thu, 11 Oct 2018 16:40:15 -0400 From: Mike Tancsa <mike@sentex.net> To: John Baldwin <jhb@FreeBSD.org>, freebsd-virtualization@freebsd.org Subject: Re: CFT: Reload LDTR after #VMEXIT on AMD-v in bhyve Message-ID: <cdb40424-82a3-5fb7-a15d-09812750f8da@sentex.net> In-Reply-To: <b74d13e5-1f76-1e28-3034-7ef32b983d32@FreeBSD.org> References: <b74d13e5-1f76-1e28-3034-7ef32b983d32@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/11/2018 3:02 PM, John Baldwin wrote: > Can someone using bhyve on an AMD host test this patch? Just booting a > guest to multiuser is probably sufficient testing: > > https://github.com/bsdjhb/freebsd/commit/97323364e196900548f5293ac97bfb22b8a2ba72.patch > > Thanks. > well, if I let the box boot fully and then load the vmm.ko, all is good. But if I load it from /boot/loader.conf, I get a panic at boot up (img attached) But other than that, it works fine. 0{ryzenbsd12}# fetch -o p https://github.com/bsdjhb/freebsd/commit/97323364e196900548f5293ac97bfb22b8a2ba72.patch fetch: https://github.com/bsdjhb/freebsd/commit/97323364e196900548f5293ac97bfb22b8a2ba72.patch: size of remote file is not known p 1618 B 15 MBps 00s 0{ryzenbsd12}# patch < p Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |From 97323364e196900548f5293ac97bfb22b8a2ba72 Mon Sep 17 00:00:00 2001 |From: John Baldwin <jhb@FreeBSD.org> |Date: Tue, 9 Oct 2018 14:49:37 -0700 |Subject: [PATCH] Reload the LDT selector after an AMD-v #VMEXIT. | |cpu_switch() always reloads the LDT, so this can only affect the |hypervisor process itself. Fix this by explicitly reloading the host |LDT selector after each #VMEXIT. The stock bhyve process on FreeBSD |never uses a custom LDT, so this change is cosmetic. |--- | sys/amd64/vmm/amd/svm.c | 13 +++++++++++++ | 1 file changed, 13 insertions(+) | |diff --git a/sys/amd64/vmm/amd/svm.c b/sys/amd64/vmm/amd/svm.c |index 2597bf9775706..c420db550bc7e 100644 |--- a/sys/amd64/vmm/amd/svm.c |+++ b/sys/amd64/vmm/amd/svm.c -------------------------- Patching file sys/amd64/vmm/amd/svm.c using Plan A... Hunk #1 succeeded at 1940. Hunk #2 succeeded at 2025. Hunk #3 succeeded at 2064. done 0{ryzenbsd12}# I confirmed prior to the patch I could run stock 11.2R i386 and amd64 guest images on 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 r339287 as the hypervisor CPU: AMD Ryzen 5 1600X Six-Core Processor (3593.34-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x7ed8320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM> AMD Features2=0x35c233ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,SKINIT,WDT,TCE,Topology,PCXC,PNXC,DBE,PL2I,MWAITX> Structured Extended Features=0x209c01a9<FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> AMD Extended Feature Extensions ID EBX=0x1007<CLZERO,IRPerf,XSaveErPtr> SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics with the patched version ivhd0: <AMD-Vi/IOMMU ivhd with EFR> on acpi0 ivhd0: Flag:b0<IotlbSup,Coherent> ivhd0: Features(type:0x11) MsiNumPPR = 0 PNBanks= 2 PNCounters= 0 ivhd0: Extended features[31:0]:22294ada<PPRSup,NXSup,GTSup,IASup> HATS = 0x2 GATS = 0x0 GLXSup = 0x1 SmiFSup = 0x1 SmiFRC = 0x2 GAMSup = 0x1 DualPortLogSup = 0x2 DualEventLogSup = 0x2 ivhd0: Extended features[62:32]:f77ef<USSup> Max PASID: 0x2f DevTblSegSup = 0x3 MarcSup = 0x1 ivhd0: supported paging level:7, will use only: 4 ivhd0: device range: 0x0 - 0xffff ivhd0: PCI cap 0x190b640f@0x40 feature:19<IOTLB,EFR,CapExt> Tested with ./vmrun.sh -c 4 -m 4096M -t tap0 -d FreeBSD-11.2-RELEASE-amd64.raw amd64 and ./vmrun.sh -c 4 -m 4096M -t tap1 -d FreeBSD-11.2-RELEASE-i386.raw i386 I sent a jpg of the crash in a separate image as it was rejected from the mailing list. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cdb40424-82a3-5fb7-a15d-09812750f8da>