Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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<CPUID,TPR>
>         ...
> 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]


Home | Main Index | Thread Index | Old Index