- User Since
- Dec 19 2016, 4:11 AM (108 w, 2 d)
Mon, Jan 14
Correct spelling of VM_MAXCPU
Fri, Jan 11
Thu, Jan 10
Change from exposing struct vm to using an accessor function, this just adds the accessor.
Tue, Jan 8
I'm not sure the impact of the changes you are intend to do related with the ACPI MADT table, I have this ticket under my hands and as you are working on these changes now, maybe you should take a double look on this ticket. This ticket also has couple links to some discussions regarding the bump of VM_MAXCPU.
I have taken that bug, I was aware of those issues and plan a seperate review for fixing the MADT table issue, which does not even reference VM_MAXCPU when it should. I may quickly add a CTASSERT(VM_MAXCPU>20) which iirc is where that table starts to run into issues, though that would stop pmooney who is using efi only and hence does not have the issue this table creates. Fixing the MADT is a rather easy thing once all the other bits are in place.
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!
Mon, Jan 7
Sat, Jan 5
Fri, Jan 4
Dec 16 2018
Age should not be a criteria for removal. BSD is old, very old, shall we remove it simply cause it is old? IMHO you all are getting way ahead of the process, having reviews to remove code before the cost/benefit and open discussions happens is backwards.
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)!
Dec 15 2018
I do not like changing defaults without very good reasons, what reasons are there for making this change?
Nov 15 2018
Nov 13 2018
I like imp@'s revisions. I am accepting either version though.
Nov 12 2018
Nov 11 2018
There should be an UPDATING entry to tell people to go get the port.. This has a 0 length deprecation notice if we just go rip it out now. I would support first adding a gonein(13) and merging that to release 12 or 12.1. That should be done first, before this. Have the ports builders made a pkg avaliable for ^/head yet, I see that you can build it, but can pkg get one yet? I would not want to remove it until a binary can be fetched via pkg.
Nov 8 2018
Nov 7 2018
A M lib/libvmmapi/amd64/vmmapi_amd64.h (143 lines)
A M lib/libvmmapi/amd64/vmmapi_amd64.c (1035 lines)
These 2 files are showing up as "added" when clearly they are copied/moved from some place else. This may be an artifact of either git or phabricator and hopefully the svn commit shows the proper logic.
Nov 5 2018
Oct 26 2018
Proposal: Rename the current bhyvectl code to bhyvedbg, and create a new bhyvectl that has --create, --destory and --list. This could also be the tool to do the bhyvectl --addcpu, --addmemory, --adddisk, etc, etc. This is just a random braincell firing of an idea, anyone and everyone can ignore as they see fit.
I shall re assert my earlier concern that we want to keep bhyvectl purely as a debugging tool, and not start to clutter it with stuff that is not part of that. Yes, there is the use of --destroy by others, but that is and should be the exception rather than the norm.
Sorry for the extra noise here, I did not mean to accept it as bhvye, only me personally, so did delete/add bhyve umbrella to clear that bit.
I am good with this too, other than it is not emulating it, it is just ignoring it by returning a 0, which may or may not have future implications.
Oct 25 2018
Oct 23 2018
One of the reasons for me asking to "macrotise" this is that we can commit it today with a poor URL in it, and very easily correct that URL some time soon(ish),
Brooks if you or Imp write the macro I'll do the leg work of converting the current diff to use that macro and remove all my objections from the current state of affairs.
Does it make any sense at all to #define a macro gone_by_fcp101?
Oct 22 2018
The bhyve group hat was requested by Peter Grehan for "Maintainer" approval and awareness of bhyve bits, as far as I can see this review does not touch any bits that need bhyve maintainer approval, so you can commit with out an accept from them.
Oct 12 2018
Oct 10 2018
Though this may fix running 12.0 on 12.0 we well need EN's back to 11 and perhaps even 10 as the issue exists there as well.
How badly do we need that CLFLUSH instruction in 12?
Oct 5 2018
Please break out the man page changes that are not related to the boot time tuneable into a seperate commit/differential.
Sep 10 2018
Is there anyway to NOT have the 141,000 line xml version of the file stored in SVN?
Also we need to make absolutely sure that any services used by ports are not effected by anything this changes.
Sep 7 2018
It just hit me and I have to ask, why isnt libcasper avaliable in a static configuration? I certainly see a /usr/lib/libcasper.a on my systems.
Sep 6 2018
Aug 29 2018
Aug 27 2018
Allan, would you update the diff please
Aug 26 2018
To add information, I have email from Paul Vixie and in fact he is wanting to break the reboot loop with -x so that it can be handled externally.
I do not believe this is a desirable change, at least it does not do what it claims it does.
Aug 25 2018
Looks good, my minor nits can be ignored, up to you.
Oh, I see you changed the return code of the module load, I take it that is to lower its preference???
Aug 24 2018
I am sorry for not getting to this today, I was side lined.
Aug 23 2018
I respectfully request that a straight revert of the commits be done rather than this, for one this does not allow us to do the proper deprecation commits, nor to merge those commits back to stable/11. This is still a major violation of deprecation policy. Warner, would you new policy allow this type of thing to be accepted? I would hope not.
Looks ok, though I wonder about a shell script that writes a Makefile, it should be possible to do that in a Makefile by itself, there is the .for/.endfor operator to make which can duplicate what the shell script does.
Aug 22 2018
Can I please have atleast 24 hours to review the text of this.
Aug 21 2018
Im no perl fan so I wont comment on that aspect.
Aug 20 2018
Aug 18 2018
Can you please break the change to share/mk/bsd.confs.mk out into a separate review, though it is required by the moving of the profile files, it is actually not a part of that change directly. I would also like to ask that you tag bdrewery in on the review of the .mk change. I do not see how file owner/group/mode are set in the new Makefile.
Though I disagree with the relocation of this to libc as it is going to be installed with the absolute minimal system anyway so this delta just creates src tree churn, and user finger memory churn. You site your reason for moving it is to put it close to the sources, well, traditionally BSD sources are layed out to match the installed DESTDIR tree. I understand things like csh and sh conf files moving, that makes since in a world where csh or sh may or may not be installed by a pkgbase, however that makes no since in a world where libc and hence master.passwd shall always be installed.
Aug 17 2018
A question has come up, isnt libc part of base, ie even in a pkgbase system libc must be installed? If that is the case then master.passwd must be installed, and I do not see a good compelling reason to move it from its current orthagonal to DESTDIR locatoin in the src tree.
Aug 16 2018
This looks okay to me for just the moving of master.passwd, though I am not found of its landing location, but can I ask for 24 hours to put together the net effect patch of what was commited, and partially reverted in combination with this patch to look for any of the pointy sticks that came up. Thanks, Rod
Aug 15 2018
Aug 14 2018
Would there be an objection to using SUBDIR names of loader.4th, loader.lua and loader.simp so that they sort next to each other vs the current names that scattter them about the directory? This also means that loader.foo/Makefile simply includes ../loader/Makefile all nice and orderly :-)
Aug 1 2018
Well, I am still on the fence with this one, seems someone has already done it to the route get -n command.
Jul 12 2018
Jul 11 2018
Jul 9 2018
This is also going to require a man page update, as now there are more than the 4 exit codes listed in the man page.
Jul 7 2018
Does this not also make it so that these drivers require IFLIB, so they need to be marked as such in GENERIC/NOTES/etc and man pages?
Jul 6 2018
Looks good over all, just some nits on errx vs err when it appears that there is a proper errno avaliable.
Jun 29 2018
I think it might be better to have 3 conv types, IDIRECT, ODIRECT, and DIRECT==IDIRECT|ODIRECT. You may or may not want vm effects on specific files.