Revert strnlen to strlen on pci_virtio_net as snprintf does the job already.

The Makefile disappear :D

Missing MOVED entry!

I will commit it in a few!
Thanks again and sorry my delay!

It seems to be redundant py-python, I don't believe it is necessary to do it.

LGTM!

Thanks for the patch, it looks right for me, although I don't have any AMD machine right now to make more tests.
I have only two requests and I would like to check with you if you could follow them:

1. Give some more time for @jhb to also have a chance to take a look on this patch.
2. When you commit it, please don't use the word "unfuck", just to avoid open room for people to have something to create noise.

In D18744#402454, @jhb wrote:

Thanks! Hopefully this means 'grep -c ENOSYS' in bhyve is now zero. :)

It doesn't looks quite right! I need more time to articulate better arguments, but this patch as it is, must not be committed in.

It doesn't looks quite right! I need more time to articulate better arguments, but this patch as it is, must not be committed in.

In D18831#402110, @richard_meric.id.au wrote:

In D18831#402109, @araujo wrote:

Hi Richard,

Do you mind share the tests you made??

Best,

I've currently got these changes running in a FreeNAS-11.2-RELEASE-U1 instance (FreeBSD 11.2 kernel) running a couple of Windows 2016 VMs plus one Centos 7 - all using virtio-blk disk devices without issue. I also have pfSense (FreeBSD 11.2) and OpenSuSE (Leap 42.3) VMs which I haven't tested yet - but can do if required.

Hi Richard,

Thanks for the patch, I will take a look on within the next two weeks.

In D18755#400855, @rgrimes wrote:

Add bhyve group, I thought I had that in the list when I created the review. I am soliciting feedback on if I should abandon this diff and re-write the code using an accessor function (called vmm_vm_maxcpus()) to vmm.c that does the vmx->vm->maxcpus dereference and call that. The most common use of this is in vmm.c itself, and would probably end up inlined by the compiler anyway, though there are at least 4 other files that have the need for this, and iirc there is userland code that uses the VM_MAXCPU constant that needs to NOT do that!

LGTM

Version needs to be update to 1.1.0, John have spotted that already!!!!

Don't forget to add the tag related with the review! When you add it, the review will be closed automatically.

It was committed already, but for some reason the svn log tags were missed, so I'm closing it.

It was committed already, but for some reason the svn log tags were missed, so I'm closing it.

Following @jhb suggestion, I will break down these updates in chunks.

Just remove the portrevision before you commit it.

Lgtm!!

In D18744#399866, @emaste wrote:

Smoke test built without CAPSICUM and CASPER. Ex.: "-DWITHOUT_CAPSICUM"

But all of the WITHOUT_CAPSICUM #ifdefs have been removed?

LGTM! Could you please set a MFC?

LGTM! Do you mind set a MFC?

I have asked @miwi to keep that huge patch on the review because of the lack of coordination and discussion between different groups and also because there is not a clear plan how to bring OpenRC into FreeBSD. So in that way people could try the patch easily without chasing different open reviews, and to be honest, without further discussion regarding to how the transition would happens between rcd and OpenRC, there is nothing much to review here.

In D12419#391704, @araujo wrote:

In D12419#391688, @kalle.carlbark_freebsd_kcbark.net wrote:

Hi @araujo, are there plans to move forward with this now that https://reviews.freebsd.org/rS340373 (libcasper: introduce cap_fileargs service) was commited?

Yes, definitely! I'm working on it, I got some issues with cap_fileargs and I have asked Mariuz support to help me debug the issue. But yeah, I'm on it right now!

Email to developers and more discussion are necessary prior to move forward with this patch!

As we have spoke in private 2 or 3 times already, I think you need to send an email as a RFC for developers@ list and/or freebsd-hackers! Add OpenRC on FreeBSD needs a broad discussion with developers and community.
Also we will need some documentation that are missing in this patch.

In D18574#396028, @rgrimes wrote:

In D18574#395995, @araujo wrote:

Hi guys,

...

One possible solution would be to give the options for users to choose between tap and vmnet style to be used and also document it (we can add some info on our bhyve wiki page)!

There already is a documented -t option that allows one to change this setting on the command line, it is in the usage() message. vmrun.sh is an example script and needs to die sooner, rather than later, with less effort spent on it and more effort on a new config file syntax that gets us out of using this "temporary" script.

Hi guys,

In D17874#394517, @araujo wrote:

In D17874#394330, @alexandru.elisei_gmail.com wrote:

Tested using the following guests:

1. FreeBSD without UEFI - installation and then booting from disk file.
2. Fedora 29 Workstation with grub2-bhyve - installation and then booting from disk file.
3. FreeBSD with UEFI - installation and then booting from disk file.
4. Fedora 29 Workstation with UEFI - installation and then booting from disk file.

Commands used for testing can be found at github.

Not tested:

1. Windows guest - I don't have an iso image for Windows.
2. PCI passthrough - not possible on my laptop.

Hi,

For the Windows guest, you can download a trial ISO that works for 90 days.
Usually I test Windows using these ISOs and it works great.

In D17874#394330, @alexandru.elisei_gmail.com wrote:

Tested using the following guests:

1. FreeBSD without UEFI - installation and then booting from disk file.
2. Fedora 29 Workstation with grub2-bhyve - installation and then booting from disk file.
3. FreeBSD with UEFI - installation and then booting from disk file.
4. Fedora 29 Workstation with UEFI - installation and then booting from disk file.

Commands used for testing can be found at github.

Not tested:

1. Windows guest - I don't have an iso image for Windows.
2. PCI passthrough - not possible on my laptop.

LGTM! Thanks for the patch!

Lgtm!