CFT: Reload LDTR after #VMEXIT on AMD-v in bhyve

[John Baldwin]

On 10/11/18 1:04 PM, Mike Tancsa wrote:
> 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
> 
> 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.

That panic doesn't really make sense. :(  The patch only changes behavior
when you are actually running a guest, it doesn't affect anything in the
vmm.ko initialization.
> 
> 
> 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 at 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 at 0x40 feature:19<IOTLB,EFR,CapExt>

Are these messages (ivhd0) new with the patched version and not present with
the old one?  These shouldn't change due to the patch as these are about the
AMD I/O MMU only used by bhyve when doing PCI pass through.

-- 
John Baldwin