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.
> 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.
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.
For now please ignore NetBSD code in this upstreaming process.
> Warner
>
Attachment:
signature.asc
Description: OpenPGP digital signature