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 <j...@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>
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
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
