Re: nvmm: change the api
On 30.06.2019 11:30, Maxime Villard wrote: > Le 05/06/2019 à 21:26, Kamil Rytarowski a écrit : >> On 05.06.2019 08:08, Maxime Villard wrote: >>> I intend to change the NVMM API in order to reduce the data >>> movements. The >>> patches are available here [1]. >>> >> >> This looks good and it will make the interfaces simpler. >> >> Could we merge the demo example into /usr/share/examples/nvmm ? >> >> https://www.netbsd.org/~maxv/nvmm/nvmm-demo.zip >> >> It will be easier and quicker to navigate it on disk easier whenever >> needed. > > I didn't feel like consuming disk space It's strange as we got some real outdated, incomplete content in src/share/doc and it would be much more valuable to replace it with something that is relevant and useful. BSD was advertised as it's sufficient to install it and browse it without internet access in order to start coding.. signature.asc Description: OpenPGP digital signature
Re: nvmm: change the api
Le 05/06/2019 à 21:26, Kamil Rytarowski a écrit : On 05.06.2019 08:08, Maxime Villard wrote: I intend to change the NVMM API in order to reduce the data movements. The patches are available here [1]. This looks good and it will make the interfaces simpler. Could we merge the demo example into /usr/share/examples/nvmm ? https://www.netbsd.org/~maxv/nvmm/nvmm-demo.zip It will be easier and quicker to navigate it on disk easier whenever needed. I didn't feel like consuming disk space
Re: nvmm: change the api
On 05.06.2019 08:08, Maxime Villard wrote: > I intend to change the NVMM API in order to reduce the data movements. The > patches are available here [1]. > This looks good and it will make the interfaces simpler. Could we merge the demo example into /usr/share/examples/nvmm ? https://www.netbsd.org/~maxv/nvmm/nvmm-demo.zip It will be easier and quicker to navigate it on disk easier whenever needed. signature.asc Description: OpenPGP digital signature
nvmm: change the api
I intend to change the NVMM API in order to reduce the data movements. The
patches are available here [1].
Basically until now the API expected the user to create structures and then
pass them in a libnvmm function. Typically:
/* The structures. */
struct nvmm_machine mach;
struct nvmm_x64_state state;
struct nvmm_event event;
struct nvmm_exit exit;
/* Create the machine and VCPU0. */
nvmm_machine_create();
nvmm_vcpu_create(, 0);
/* Set RAX=123. */
nvmm_vcpu_getstate(, 0, , NVMM_X64_STATE_GPRS);
state.gprs[NVMM_X64_GPR_RAX] = 123;
nvmm_vcpu_setstate(, 0, , NVMM_X64_STATE_GPRS);
/* Inject an #UD exception. */
event.type = NVMM_EXCEPTION;
event.vector = 6;
nvmm_vcpu_inject(, 0, );
/* Run. */
nvmm_vcpu_run(, 0, );
switch (exit.reason) {
...
}
This design has some problems: the structures can occupy a lot of stack
(nvmm_x64_state is > 1000 bytes), and must be copied in and out of the
comm page by libnvmm. We can avoid this by giving the user direct access
to the comm page.
A new nvmm_vcpu structure is introduced, and contains pointers to the comm
page. The new usage is:
/* The structures. */
struct nvmm_machine mach;
struct nvmm_vcpu vcpu;
/* Create the machine and VCPU0. */
nvmm_machine_create();
nvmm_vcpu_create(, 0, );
/* Set RAX=123. getstate populates vcpu.state->gprs[]. */
nvmm_vcpu_getstate(, , NVMM_X64_STATE_GPRS);
vcpu.state->gprs[NVMM_X64_GPR_RAX] = 123;
nvmm_vcpu_setstate(, , NVMM_X64_STATE_GPRS);
/* Inject an #UD exception. */
vcpu.event->type = NVMM_EXCEPTION;
vcpu.event->vector = 6;
nvmm_vcpu_inject(, );
/* Run. */
nvmm_vcpu_run(, );
switch (vcpu.exit->reason) {
...
}
No kernel changes are required. This should be part of NetBSD 9.
[1] https://m00nbsd.net/garbage/nvmm/nvmm-nocopy.zip
