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

[John Baldwin]

On 10/15/18 10:11 AM, Mike Tancsa wrote:
> On 10/15/2018 12:23 PM, John Baldwin wrote:
>>
>> 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.
> 
> I dont understand either. I have a few klds to load. Is it possible
> something is getting initialized out of order at boot up time ?  r339355
> seems to have fixed it for me. But I suspect the real issue might come
> back some other way
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118820.html
> 
> Regardless, I tested with your patch an amd64 and i386 vm and all seems
> to work fine

Ok, thanks!

-- 
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"

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

[Mike Tancsa]

On 10/15/2018 12:23 PM, John Baldwin wrote:
>
> 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.

I dont understand either. I have a few klds to load. Is it possible
something is getting initialized out of order at boot up time ?  r339355
seems to have fixed it for me. But I suspect the real issue might come
back some other way

https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118820.html

Regardless, I tested with your patch an amd64 and i386 vm and all seems
to work fine

    ---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   

___
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"

Re: 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 
> |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
>  
> Features2=0x7ed8320b
>   AMD Features=0x2e500800
>   AMD
> Features2=0x35c233ff
>   Structured Extended
> Features=0x209c01a9
>   XSAVE Features=0xf
>   AMD Extended Feature Extensions ID EBX=0x1007
>   SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>   TSC: P-state invariant, performance statistics
> 
> 
> 
> 
> with the patched version
> 
> ivhd0:  on acpi0
> ivhd0: Flag:b0
> ivhd0: Features(type:0x11) MsiNumPPR = 0 PNBanks= 2 PNCounters= 0
> ivhd0: Extended features[31:0]:22294ada HATS =
> 0x2 GATS = 0x0 GLXSup = 0x1 SmiFSup = 0x1 SmiFRC = 0x2 GAMSup = 0x1
> DualPortLogSup = 0x2 DualEventLogSup = 0x2
> ivhd0: Extended features[62:32]:f77ef Max PASID: 0x2f
> DevTblSegSup = 0x3 MarcSup = 0x1
> ivhd0: supported paging level:7, will use only: 4
> ivhd0: device range: 0x0 - 0x
> ivhd0: PCI cap 0x190b640f@0x40 feature:19

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"

Re: bhyve on reboot loses tap(4) configuration

[Bjoern A. Zeeb]

On 15 Oct 2018, at 16:10, Marcelo Araujo wrote:


Em ter, 16 de out de 2018 às 00:06, Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> escreveu:


Hi,

I tried to use bhyve with the tap(4)/vtnet(4) solution as documented 
in

the handbook (tap needs autoopen).
However, I am using no bridge(4) interface but a “point-to-point”
configuration.

Example:
guest configures vtnet0 to 192.0.2.2/24
host configures tap0 to 192.0.2.1/24

When rebooting the guest inside the bhyve, it seems bhyve loses the
outside tap0 configuration.  I assume that is because the tap0 
interface

is closed and re-opened on the “warm restart”.

Apart from using devd and possibly tracking tap interfaces to come up
and track things there, is there are better solution for not having 
to

reconfigure the host interface on every guest reboot?



Not sure if I understood well your case, but have you tried to set 
this

sysctl: net.link.tap.up_on_open?


That only ensures that effectively “an ifconfig tap up” gets 
issued.


The problem, as I assume is, if you close /dev/tap and re-open /dev/tap 
it seems the configuration (interface addresses) seem to be cleaned up 
on “close”.


/bz
___
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"

Re: bhyve on reboot loses tap(4) configuration

[Marcelo Araujo]

Em ter, 16 de out de 2018 às 00:06, Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> escreveu:

> Hi,
>
> I tried to use bhyve with the tap(4)/vtnet(4) solution as documented in
> the handbook (tap needs autoopen).
> However, I am using no bridge(4) interface but a “point-to-point”
> configuration.
>
> Example:
> guest configures vtnet0 to 192.0.2.2/24
> host configures tap0 to 192.0.2.1/24
>
> When rebooting the guest inside the bhyve, it seems bhyve loses the
> outside tap0 configuration.  I assume that is because the tap0 interface
> is closed and re-opened on the “warm restart”.
>
> Apart from using devd and possibly tracking tap interfaces to come up
> and track things there, is there are better solution for not having to
> reconfigure the host interface on every guest reboot?
>

Not sure if I understood well your case, but have you tried to set this
sysctl: net.link.tap.up_on_open?

Best,

-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
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"

bhyve on reboot loses tap(4) configuration

[Bjoern A. Zeeb]

Hi,

I tried to use bhyve with the tap(4)/vtnet(4) solution as documented in 
the handbook (tap needs autoopen).
However, I am using no bridge(4) interface but a “point-to-point” 
configuration.


Example:
guest configures vtnet0 to 192.0.2.2/24
host configures tap0 to 192.0.2.1/24

When rebooting the guest inside the bhyve, it seems bhyve loses the 
outside tap0 configuration.  I assume that is because the tap0 interface 
is closed and re-opened on the “warm restart”.


Apart from using devd and possibly tracking tap interfaces to come up 
and track things there, is there are better solution for not having to 
reconfigure the host interface on every guest reboot?



/bz
___
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"