On Sat, 27 Jan 2024 at 11:28, Emile 'iMil' Heitor wrote:
>
>
> I've synced up our NVMM code (kmod, lib and tool) with its current
> state in DragonFlyBSD; if you're using NVMM on NetBSD as your
> hypervisor you might want to give it a try
> https
I've synced up our NVMM code (kmod, lib and tool) with its current
state in DragonFlyBSD; if you're using NVMM on NetBSD as your
hypervisor you might want to give it a try
https://github.com/NetBSD/src/compare/trunk...NetBSDfr:NetBSD-src:nvmm
I've also added a vmware compatibl
levant
> parts of the architecture manual.
>
I committed our simplified approach yesterday:
https://freshbsd.org/openbsd/src/commit/PB5K056kGxKiZfxJ
>> We plan on enabling it prior to the release of OpenBSD 7.3 and this will
>> have ramifications for OpenBSD guests under nvmm potential
; hypervisor.
That sounds reasonable. If you would like to share the diff I'd be
happy to take a look. Need to familiarize myself with the relevant
parts of the architecture manual.
> We plan on enabling it prior to the release of OpenBSD 7.3 and this will
> have ramifications for Open
Hi NetBSD devs,
I didn't know whom to approach as it's not clear if there's an active
maintainer of nvmm or not. I felt this list is probably a good starting
point given the topic at hand.
I'm an OpenBSD developer (dv@) that works primarily on our hypervisor
(vmm/vmd) and
Hi Mario,
On Tue, Jan 11, 2022 at 11:05:54PM +0100, Mario Marietto wrote:
> I'm trying to create a small group of developers to work on adding the VT-D
> support for NVMM. I would like to create a mixed group : a bhyve
> developer,a DFLY developer and a NetBSD developer,since th
experience for me. I've learned
a lot from them. I've enjoyed the experience so much that I want to
repeat it.
I'm trying to create a small group of developers to work on adding the VT-D
support for NVMM. I would like to create a mixed group : a bhyve
developer,a DFLY developer and
Dear folks,
On Thu, Oct 29, 2020 at 09:54:02PM +0100, Reinoud Zandijk wrote:
> i stumbled on an instruction that NVMM couldn't code and thus couldn't
> emulate either. It was as stated the REPE CMPS (0xF3A7) instruction as stated
> in https://c9x.me/x86/html/file_module_
On Sun, Nov 15, 2020 at 12:23:00PM +0100, Reinoud Zandijk wrote:
> [...]
>
> IIRC, XEN uses Qemu too (regretfully) :-/
It depends. it uses qemu for or (PV)HVM guests only. PV or PVH guests don't
need it.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On Wed, Nov 11, 2020 at 10:58:25AM -0600, Robert Nestor wrote:
> > I have never tried to boot MacOS-X with qemu+nvmm. I think lots of other
> > things will need to be prepared for qemu to even start.
> >
> > Do you know of other possible (more recent) OSs I could try to
e the
> emulation before committing it.
>
>> 2) Is there some code that one can insert locally into NVMM and/or LIBNVMM
>> to help catch other possible problems similar to this?
>
> There are some unhandled cases on Intel support code that can bomb out libnvmm
> and thus q
ith this opcode, is there another correct fix coming?
Working on a patch in libnvmm for it and it ought to work fine now, but i'm
stuggling with writing ATF case codes; they are needed to validate the
emulation before committing it.
> 2) Is there some code that one can insert locally i
> Date: Sun, 1 Nov 2020 10:16:17 +0100
> From: Maxime Villard
>
> Note that the main NVMM tree is not NetBSD anymore.
Is there now an upstream tree that we should be following? If yes,
where?
. It
ought now give a proper REPE memory assist implementation. It could use some
minor enhancements still though.
With regards,
Reinoud
Note that the main NVMM tree is not NetBSD anymore. Also I am no longer a NetBSD
developer, please stop spamming me.
Dear folks,
I've reworked the patch using the feedback I got from Maxime and had to
refactor some minor parts in the other code. I'm in the process of writing the
test-cases now but would like feedback for this solution in the meantime. It
ought now give a proper REPE memory assist implementation.
can insert locally into NVMM and/or LIBNVMM to
help catch other possible problems similar to this?
While NVMM is very robust and runs a lot of other systems, there are some that
it still stumbles over. I’m sure the vast majority of users don’t care about
running something like OS X under NVMM
Dear Maxime,
On Sat, Oct 31, 2020 at 08:24:05AM +0100, Maxime Villard wrote:
> Le 29/10/2020 à 21:54, Reinoud Zandijk a écrit :
> > i stumbled on an instruction that NVMM couldn't code and thus couldn't
> > emulate either. It was as stated the REPE CMPS (0xF3A7) instruct
Le 29/10/2020 à 21:54, Reinoud Zandijk a écrit :
Dear folks,
i stumbled on an instruction that NVMM couldn't code and thus couldn't
emulate either. It was as stated the REPE CMPS (0xF3A7) instruction as stated
in https://c9x.me/x86/html/file_module_x86_id_279.html and confirmed by
d
Dear folks,
i stumbled on an instruction that NVMM couldn't code and thus couldn't
emulate either. It was as stated the REPE CMPS (0xF3A7) instruction as stated
in https://c9x.me/x86/html/file_module_x86_id_279.html and confirmed by
disassembly by ndisasm (from nasm).
Appen
On 25.10.2019 12:49, Maxime Villard wrote:
> Currently /dev/nvmm has these permissions
>
> c rw- --- --- root wheel
>
> Which means the user has to tune the permissions manually. I would like to
> introduce an "nvmm" group, and change the perms to
>
&g
Currently /dev/nvmm has these permissions
c rw- --- --- root wheel
Which means the user has to tune the permissions manually. I would like to
introduce an "nvmm" group, and change the perms to
c rw- r-- --- root nvmm
This means that emulators will have to be setgi
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].
&
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
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
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
Le 13/10/2018 à 08:18, Maxime Villard a écrit :
It seems that we have to provide our own small decoder for that, to get
source/destination/size from an instruction.
I know we also need a gva->gpa translator, independently from Qemu, so we'll
have to add it too.
I've put a new archive. Libnvmm
have to provide our own small decoder for that, to get
source/destination/size from an instruction.
I know we also need a gva->gpa translator, independently from Qemu, so we'll
have to add it too.
Meanwhile, I've made some adjustments and fixes in NVMM, to ease the Qemu
code.
On Mon 08 Oct 2018 at 12:02:14 +0200, Maxime Villard wrote:
> Here is support for hardware-accelerated virtualization on x86 [1]. A generic
Since I'm currently working at an ISP which also provides an OpenStack
cloud: when can I use this with Qemu? :-)
I should really go and see what the state of
mit it soon, in:
>
> module/src/nvmm.c -> sys/dev/nvmm/nvmm.c
> module/src/nvmm.h -> sys/dev/nvmm/nvmm.h
> module/src/nvmm_internal.h -> sys/dev/nvmm/nvmm_internal.h
> module/src/nvmm_ioctl.h-> sys/dev/nvmm/nvm
Here is support for hardware-accelerated virtualization on x86 [1]. A generic
MI driver, to which MD backends can be plugged. Most of it has already been
discussed in private.
I intend to commit it soon, in:
module/src/nvmm.c -> sys/dev/nvmm/nvmm.c
module/
30 matches
Mail list logo
