Re: QEMU/NetBSD status wiki page

On Sun, May 27, 2018 at 11:57 AM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:

On 27.05.2018 16:53, Warner Losh wrote:
>
>
> On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski <n54%gmx.com@localhost
> <mailto:n54%gmx.com@localhost>> wrote:
>
> As requested, I've prepared a QEMU/NetBSD status page:
>
> http://wiki.netbsd.org/users/kamil/qemu/
> <http://wiki.netbsd.org/users/kamil/qemu/>
>
> I've attempted to be rather conservative with claims that something
> works, without detailed verification.
>
>
> FreeBSD has a complete QEMU user-mode implementation in a branch right
> now. It's sufficiently advanced we build all our arm, arm64 and mips
> packages using it. What's in upstream QEMU is totally, totally broken.
> The work breaks things down so the common BSD could be shared. Starting
> from that base would be a huge leg up to getting things working.
>

Thank you for the feedback.

I would like to stress that In my point of view - whether bluetooth or
vde is 100% functional - doesn't really matter in the context of:

- user mode emulation
- hardware assisted virtualization
- virtio
- vhost
- device passthrough

Once that will work well, getting this or that library for compression
of images of GUI is a matter packaging in tools.

We can consider whether to collect the native kernel implementation of
nbd from Bitrig, as it was required for at least a single ARM evaluation
board in a bootstrap/booting process.

The HQEMU project can be very useful for releng, as we can boost
emulation of e.g. ARM by a factor of 3-20x on a amd64 host (exact boost
times depend on the type of executed code), run the tests more quickly
and save precious time and CPU cycles.

Haven't investigated that.

> I'm in the process of getting it upstream. FreeBSD's branch is a royal
> mess that has all the usual problem with a git branch that has lots of
> merges applied: it had become almost impossible to rebase. I've sorted
> most of that out, and am now sorting out collapsing down all the bug
> fixes and/or qemu API changes that happened over the years so each
> change in my branch is buildable. That should land this summer, maybe in
> time for 3.0, but maybe not.
>

How close is this code to linux-user? I think that maintaining a concept
of bsd-user in 2018 is obsolete, new code in one BSD can be closer to
Linux or Solaris than other BSDs.

I'm not sure I follow this logic at all. The BSDs share a base that's quite similar, even if new bits aren't similar. Have you looked at the code I'm upstreaming? See the bsd-user branch in https://github.com/seanbruno/qemu-bsd-user for details. It actually works today, so it's not obsolete. It might be better not shared, but since that doesn't exist today, I can't judge those efforts.

Ideally we should go for [unix-]user shared between Linux and BSDs, add
OS specific differences in dedicated {linux,freebsd,netbsd}-user,
splitting NetBSD and FreeBSD.

I used to think that but no longer. There's a lot of code to deal with threading and vm differences that insinuates itself into a lot of code. I'm not so sure that sharing between Linux and anything else is really all that sane, though there's some commonality. Without substantial changes in upstream behavior, it will also result in lots of breakage as the code velocity there is fast and often times the changes made are no good for BSD.

For now please ignore NetBSD code in this upstreaming process.

I'm upstreaming exactly what we have, which moves the current netbsd/opensd to their own subdirectory of bsd-user. The code in upstream is currently totally broken, and this won't break it any more. My efforts are to push up the code we have today that works really really well and nothing further. Any cross-bsd or pan-unix efforts will post-date my upstreaming since those do not exist today.

Warner