On 27.05.2018 20:04, Warner Losh wrote:
>
>
> On Sun, May 27, 2018 at 11:57 AM, Kamil Rytarowski <n54%gmx.com@localhost
> <mailto: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>
> > <mailto: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/>
> > <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.
>
>
The shortcoming of hqemu is that it's using an old LLVM version and old
qemu as base. I don't feel like backporting NetBSD patches for old
releases of these two projects.. and it might be better to rebase the
code to recent versions or even help the upstream to push the code to qemu.
>
> > 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.
>
I defer my work on netbsd-user and discussion on the details for later.
Thank you for your effort and I'm looking forward to the upstreaming
process!
Temporarily, I try to keep functional what already works and for
usermode-like emulation I use unicorn-engine (qemu's fork).
> Warner
Attachment:
signature.asc
Description: OpenPGP digital signature