Re: heads-up: planned changes in nvmm
Le 03/11/2019 à 07:52, Maxime Villard a écrit : Le 01/11/2019 à 14:46, David Brownlee a écrit : On Mon, 28 Oct 2019 at 14:58, Maxime Villard wrote: Le 22/10/2019 à 22:34, Maxime Villard a écrit : I will soon commit a set of changes in NVMM, which will require a full rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, the libnvmm ATF tests, and the qemu-nvmm package if you're using it. You can cherry-pick each change, but it will be easier to just do a full distribution rebuild and reinstall. Overall it is no different than what I've been doing over the last six months. This time, however, the changes will also be pulled up to 9beta afterwards. I will push my changes in -current and update the qemu-nvmm package in several rounds probably over several days, and then will pull up to 9beta. In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta. So I think I'm done, I'll let the dust settle for a few days, and then will request pullup9. [...] Would you have an idea when the changes might be pulled up to netbsd-9? next Tuesday So, it has been pulled up to 9beta. Now you should be able to upgrade qemu-nvmm and run it with the latest 9beta.
Re: heads-up: planned changes in nvmm
Le 01/11/2019 à 14:46, David Brownlee a écrit : On Mon, 28 Oct 2019 at 14:58, Maxime Villard wrote: Le 22/10/2019 à 22:34, Maxime Villard a écrit : I will soon commit a set of changes in NVMM, which will require a full rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, the libnvmm ATF tests, and the qemu-nvmm package if you're using it. You can cherry-pick each change, but it will be easier to just do a full distribution rebuild and reinstall. Overall it is no different than what I've been doing over the last six months. This time, however, the changes will also be pulled up to 9beta afterwards. I will push my changes in -current and update the qemu-nvmm package in several rounds probably over several days, and then will pull up to 9beta. In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta. So I think I'm done, I'll let the dust settle for a few days, and then will request pullup9. [...] Would you have an idea when the changes might be pulled up to netbsd-9? next Tuesday
Re: heads-up: planned changes in nvmm
On Mon, 28 Oct 2019 at 14:58, Maxime Villard wrote:
>
> Le 22/10/2019 à 22:34, Maxime Villard a écrit :
> > I will soon commit a set of changes in NVMM, which will require a full
> > rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API,
> > the libnvmm ATF tests, and the qemu-nvmm package if you're using it.
> >
> > You can cherry-pick each change, but it will be easier to just do a full
> > distribution rebuild and reinstall.
> >
> > Overall it is no different than what I've been doing over the last six
> > months. This time, however, the changes will also be pulled up to 9beta
> > afterwards.
> >
> > I will push my changes in -current and update the qemu-nvmm package in
> > several rounds probably over several days, and then will pull up to 9beta.
> >
> > In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta.
>
> So I think I'm done, I'll let the dust settle for a few days, and then will
> request pullup9.
>[...]
Would you have an idea when the changes might be pulled up to netbsd-9?
(This is not a "hey get it done", more a "thanks for a cool feature
which has my laptop
already very happily running 64bit Ubuntu and Windows 7 under netbsd-9
and looking forward to doing even more as time goes on" :)
Would there be any general advice in setting up a box to run a few Linux nvmm
guests (I have a non production XEN box I'm tempted to cut across)
For anyone else wanting to {re,}build pkgsrc-wip qemu-nvmm before the pullups
I'd recommend updating to 69cc68ce4bea01c3c1783029442e2ac676430e32,
then copying the qemu-nvmm directory then updating back to HEAD
Thanks again
David
Re: heads-up: planned changes in nvmm
All true; I've already changed nvmmctl permissions, reverted /dev/nvmm to 640 and saw that 'identify' works as a normal user. However the need to change the permission of the tap device remains (and for the disk, but that is obvious). On Tue, 29 Oct 2019 at 08:22, Maxime Villard wrote: > > First of all, you should not change the permissions of /dev/nvmm. It should > remain 640 root:nvmm. > > Then: > > (1) How did you launch qemu-nvmm before I added the "nvmm" group? You > were launching it as root, right? Overall you should not launch a program > like Qemu as root, that's precisely why I added the "nvmm" group. It does > imply, now, that the privileged files you were opening in /dev/ need > special permissions, that you must change manually. (Unless you keep using > qemu-nvmm as root, but as I said, I wouldn't recommend that...) > > (2) Regarding nvmmctl, I forgot to include the 2555 root:nvmm permissions, > my bad, it should be fixed now. You can launch "nvmmctl identify" as a > normal user, but "nvmmctl list" must be launched as root, that intentional. > (Note: I still hesitate a bit about the latter, maybe it should be usable > from unpriv? Being able to see what VM a process uses looks like snooping > a little bit.) > > > > Le 29/10/2019 à 00:20, Chavdar Ivanov a écrit : > > And on top of this if one wants a member of nvmm group to be able to > > run nvmmctl, then /dev/nvmm must be 660 ... > > > > On Mon, 28 Oct 2019 at 23:13, Chavdar Ivanov wrote: > >> > >> And then one has to change the permissions of the tap device and the > >> disk in use, e,g, > >> ... > >> chown root:nvmm /dev/tap3 > >> chmod 660 /dev/tap3 > >> chown root:nvmm /dev/zvol/rdsk/pail/openbsd > >> chmod 660 /dev/zvol/rdsk/pail/openbsd > >> ... > >> > >> On Mon, 28 Oct 2019 at 22:54, Chavdar Ivanov wrote: > >>> > >>> Thanks! Sorted. > >>> > >>> On Mon, 28 Oct 2019 at 21:04, J. Lewis Muir wrote: > > On 10/28, Chavdar Ivanov wrote: > > After the above message I rebuilt the system and got eventually > > nvmmctl, which worked. I couldn't start any VM, though, so I proceeded > > to rebuild wip/qemu-nvmm, although there were no changes since my > > previous build. This time it worked; I also recreated /dev/nvmm (the > > protection changed from 600 to 640). I haven't yet added a nvmm group > > member; is there any specific group ID nvmm should be? ( I think I > > missed the query about the merge of /etc/group during the system > > upgrade. ) > > See Maxime's post to tech-kern: > > https://mail-index.netbsd.org/tech-kern/2019/10/25/msg025623.html > > Lewis --
Re: heads-up: planned changes in nvmm
First of all, you should not change the permissions of /dev/nvmm. It should remain 640 root:nvmm. Then: (1) How did you launch qemu-nvmm before I added the "nvmm" group? You were launching it as root, right? Overall you should not launch a program like Qemu as root, that's precisely why I added the "nvmm" group. It does imply, now, that the privileged files you were opening in /dev/ need special permissions, that you must change manually. (Unless you keep using qemu-nvmm as root, but as I said, I wouldn't recommend that...) (2) Regarding nvmmctl, I forgot to include the 2555 root:nvmm permissions, my bad, it should be fixed now. You can launch "nvmmctl identify" as a normal user, but "nvmmctl list" must be launched as root, that intentional. (Note: I still hesitate a bit about the latter, maybe it should be usable from unpriv? Being able to see what VM a process uses looks like snooping a little bit.) Le 29/10/2019 à 00:20, Chavdar Ivanov a écrit : And on top of this if one wants a member of nvmm group to be able to run nvmmctl, then /dev/nvmm must be 660 ... On Mon, 28 Oct 2019 at 23:13, Chavdar Ivanov wrote: And then one has to change the permissions of the tap device and the disk in use, e,g, ... chown root:nvmm /dev/tap3 chmod 660 /dev/tap3 chown root:nvmm /dev/zvol/rdsk/pail/openbsd chmod 660 /dev/zvol/rdsk/pail/openbsd ... On Mon, 28 Oct 2019 at 22:54, Chavdar Ivanov wrote: Thanks! Sorted. On Mon, 28 Oct 2019 at 21:04, J. Lewis Muir wrote: On 10/28, Chavdar Ivanov wrote: After the above message I rebuilt the system and got eventually nvmmctl, which worked. I couldn't start any VM, though, so I proceeded to rebuild wip/qemu-nvmm, although there were no changes since my previous build. This time it worked; I also recreated /dev/nvmm (the protection changed from 600 to 640). I haven't yet added a nvmm group member; is there any specific group ID nvmm should be? ( I think I missed the query about the merge of /etc/group during the system upgrade. ) See Maxime's post to tech-kern: https://mail-index.netbsd.org/tech-kern/2019/10/25/msg025623.html Lewis
Re: heads-up: planned changes in nvmm
And on top of this if one wants a member of nvmm group to be able to run nvmmctl, then /dev/nvmm must be 660 ... On Mon, 28 Oct 2019 at 23:13, Chavdar Ivanov wrote: > > And then one has to change the permissions of the tap device and the > disk in use, e,g, > ... > chown root:nvmm /dev/tap3 > chmod 660 /dev/tap3 > chown root:nvmm /dev/zvol/rdsk/pail/openbsd > chmod 660 /dev/zvol/rdsk/pail/openbsd > ... > > On Mon, 28 Oct 2019 at 22:54, Chavdar Ivanov wrote: > > > > Thanks! Sorted. > > > > On Mon, 28 Oct 2019 at 21:04, J. Lewis Muir wrote: > > > > > > On 10/28, Chavdar Ivanov wrote: > > > > After the above message I rebuilt the system and got eventually > > > > nvmmctl, which worked. I couldn't start any VM, though, so I proceeded > > > > to rebuild wip/qemu-nvmm, although there were no changes since my > > > > previous build. This time it worked; I also recreated /dev/nvmm (the > > > > protection changed from 600 to 640). I haven't yet added a nvmm group > > > > member; is there any specific group ID nvmm should be? ( I think I > > > > missed the query about the merge of /etc/group during the system > > > > upgrade. ) > > > > > > See Maxime's post to tech-kern: > > > > > > https://mail-index.netbsd.org/tech-kern/2019/10/25/msg025623.html > > > > > > Lewis > > > > > > > > -- > > > > > > -- > --
Re: heads-up: planned changes in nvmm
And then one has to change the permissions of the tap device and the disk in use, e,g, ... chown root:nvmm /dev/tap3 chmod 660 /dev/tap3 chown root:nvmm /dev/zvol/rdsk/pail/openbsd chmod 660 /dev/zvol/rdsk/pail/openbsd ... On Mon, 28 Oct 2019 at 22:54, Chavdar Ivanov wrote: > > Thanks! Sorted. > > On Mon, 28 Oct 2019 at 21:04, J. Lewis Muir wrote: > > > > On 10/28, Chavdar Ivanov wrote: > > > After the above message I rebuilt the system and got eventually > > > nvmmctl, which worked. I couldn't start any VM, though, so I proceeded > > > to rebuild wip/qemu-nvmm, although there were no changes since my > > > previous build. This time it worked; I also recreated /dev/nvmm (the > > > protection changed from 600 to 640). I haven't yet added a nvmm group > > > member; is there any specific group ID nvmm should be? ( I think I > > > missed the query about the merge of /etc/group during the system > > > upgrade. ) > > > > See Maxime's post to tech-kern: > > > > https://mail-index.netbsd.org/tech-kern/2019/10/25/msg025623.html > > > > Lewis > > > > -- > --
Re: heads-up: planned changes in nvmm
Thanks! Sorted. On Mon, 28 Oct 2019 at 21:04, J. Lewis Muir wrote: > > On 10/28, Chavdar Ivanov wrote: > > After the above message I rebuilt the system and got eventually > > nvmmctl, which worked. I couldn't start any VM, though, so I proceeded > > to rebuild wip/qemu-nvmm, although there were no changes since my > > previous build. This time it worked; I also recreated /dev/nvmm (the > > protection changed from 600 to 640). I haven't yet added a nvmm group > > member; is there any specific group ID nvmm should be? ( I think I > > missed the query about the merge of /etc/group during the system > > upgrade. ) > > See Maxime's post to tech-kern: > > https://mail-index.netbsd.org/tech-kern/2019/10/25/msg025623.html > > Lewis --
Re: heads-up: planned changes in nvmm
On 10/28, Chavdar Ivanov wrote: > After the above message I rebuilt the system and got eventually > nvmmctl, which worked. I couldn't start any VM, though, so I proceeded > to rebuild wip/qemu-nvmm, although there were no changes since my > previous build. This time it worked; I also recreated /dev/nvmm (the > protection changed from 600 to 640). I haven't yet added a nvmm group > member; is there any specific group ID nvmm should be? ( I think I > missed the query about the merge of /etc/group during the system > upgrade. ) See Maxime's post to tech-kern: https://mail-index.netbsd.org/tech-kern/2019/10/25/msg025623.html Lewis
Re: heads-up: planned changes in nvmm
After the above message I rebuilt the system and got eventually nvmmctl, which worked. I couldn't start any VM, though, so I proceeded to rebuild wip/qemu-nvmm, although there were no changes since my previous build. This time it worked; I also recreated /dev/nvmm (the protection changed from 600 to 640). I haven't yet added a nvmm group member; is there any specific group ID nvmm should be? ( I think I missed the query about the merge of /etc/group during the system upgrade. ) (BTW, an iteresting factoid; the laptop I am trying this some four years ago used to run Windows 10 professional; since then it has been running only NetBSD-current. A few months ago I installed Windows 10 Professional 32-bit just to try under qemu-nvmm, which worked fine; the interesting bit was that it actually activated Windows 10 on the VM on the basis of the same CPU and MAC address apparently reported and kept in their database. So I have now one properly activated W10 VM ... ). On Mon, 28 Oct 2019 at 14:59, Maxime Villard wrote: > > Le 22/10/2019 à 22:34, Maxime Villard a écrit : > > [I am not subscribed to this list, so if you want to answer, make sure to > > CC me.] > > > > I will soon commit a set of changes in NVMM, which will require a full > > rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, > > the libnvmm ATF tests, and the qemu-nvmm package if you're using it. > > > > You can cherry-pick each change, but it will be easier to just do a full > > distribution rebuild and reinstall. > > > > Overall it is no different than what I've been doing over the last six > > months. This time, however, the changes will also be pulled up to 9beta > > afterwards. > > > > I will push my changes in -current and update the qemu-nvmm package in > > several rounds probably over several days, and then will pull up to 9beta. > > > > In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta. > > So I think I'm done, I'll let the dust settle for a few days, and then will > request pullup9. > > To summarize, most of the changes were internal cleanup and API renaming. > There are three user-visible changes however: > > (1) PCID support for 64bit guests. This increases performance of many such > guests, because since Meltdown, almost every OS uses PCID, including NetBSD. > > (2) New nvmmctl tool, to query the registered VMs in the system. Not > totally useful in its current form, but still good. > > (3) Support for Windows 64bit guests. I tested Win8-64bit and Win10-64bit. > This is supported only on Intel CPUs for now, because I don't have a recent > AMD CPU on which to test. Basically, for Win 64bit to work, you must have > the "TPR VCPU conf" capability, ie: > $ nvmmctl identify > ... > nvmm: Arch VCPU conf 0x3 > ... > For now on AMD CPUs you will see it's not there. If someone has a recent > AMD CPU on which to test, I can add support. > > Also, I've updated the instructions on this page [1], qemu-nvmm must now > be part of the "nvmm" group or launched from a user part of that group. > > [1] https://m00nbsd.net/4e0798b7f2620c965d0dd9d6a7a2f296.html --
Re: heads-up: planned changes in nvmm
Le 22/10/2019 à 22:34, Maxime Villard a écrit : [I am not subscribed to this list, so if you want to answer, make sure to CC me.] I will soon commit a set of changes in NVMM, which will require a full rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, the libnvmm ATF tests, and the qemu-nvmm package if you're using it. You can cherry-pick each change, but it will be easier to just do a full distribution rebuild and reinstall. Overall it is no different than what I've been doing over the last six months. This time, however, the changes will also be pulled up to 9beta afterwards. I will push my changes in -current and update the qemu-nvmm package in several rounds probably over several days, and then will pull up to 9beta. In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta. So I think I'm done, I'll let the dust settle for a few days, and then will request pullup9. To summarize, most of the changes were internal cleanup and API renaming. There are three user-visible changes however: (1) PCID support for 64bit guests. This increases performance of many such guests, because since Meltdown, almost every OS uses PCID, including NetBSD. (2) New nvmmctl tool, to query the registered VMs in the system. Not totally useful in its current form, but still good. (3) Support for Windows 64bit guests. I tested Win8-64bit and Win10-64bit. This is supported only on Intel CPUs for now, because I don't have a recent AMD CPU on which to test. Basically, for Win 64bit to work, you must have the "TPR VCPU conf" capability, ie: $ nvmmctl identify ... nvmm: Arch VCPU conf 0x3 ... For now on AMD CPUs you will see it's not there. If someone has a recent AMD CPU on which to test, I can add support. Also, I've updated the instructions on this page [1], qemu-nvmm must now be part of the "nvmm" group or launched from a user part of that group. [1] https://m00nbsd.net/4e0798b7f2620c965d0dd9d6a7a2f296.html
Re: heads-up: planned changes in nvmm
I've rebuilt my -current system a few hours ago, followed by a build of wip/qemu-nvmm, I see now at 4.1. So far everything seems to be working as expected. BTW I have been getting - on all my qemu-nvmm builds from wip - a PLIST error - share/locale/bg/LC_MESSAGES/qemu.mo share/locale/de_DE/LC_MESSAGES/qemu.mo share/locale/fr_FR/LC_MESSAGES/qemu.mo share/locale/hu/LC_MESSAGES/qemu.mo share/locale/it/LC_MESSAGES/qemu.mo share/locale/tr/LC_MESSAGES/qemu.mo share/locale/zh_CN/LC_MESSAGES/qemu.mo present in the destination folder but missing in PLIST. On Tue, 22 Oct 2019 at 21:34, Maxime Villard wrote: > > [I am not subscribed to this list, so if you want to answer, make sure to > CC me.] > > I will soon commit a set of changes in NVMM, which will require a full > rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, > the libnvmm ATF tests, and the qemu-nvmm package if you're using it. > > You can cherry-pick each change, but it will be easier to just do a full > distribution rebuild and reinstall. > > Overall it is no different than what I've been doing over the last six > months. This time, however, the changes will also be pulled up to 9beta > afterwards. > > I will push my changes in -current and update the qemu-nvmm package in > several rounds probably over several days, and then will pull up to 9beta. > > In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta. --
heads-up: planned changes in nvmm
[I am not subscribed to this list, so if you want to answer, make sure to CC me.] I will soon commit a set of changes in NVMM, which will require a full rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, the libnvmm ATF tests, and the qemu-nvmm package if you're using it. You can cherry-pick each change, but it will be easier to just do a full distribution rebuild and reinstall. Overall it is no different than what I've been doing over the last six months. This time, however, the changes will also be pulled up to 9beta afterwards. I will push my changes in -current and update the qemu-nvmm package in several rounds probably over several days, and then will pull up to 9beta. In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta.
