Re: QEMU/NetBSD status wiki page

[Warner Losh]

On Sun, May 27, 2018 at 11:57 AM, Kamil Rytarowski  wrote:

> On 27.05.2018 16:53, Warner Losh wrote:
> >
> >
> > On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski  > > wrote:
> >
> > As requested, I've prepared a QEMU/NetBSD status page:
> >
> > 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

Re: QEMU/NetBSD status wiki page

[Warner Losh]

On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski  wrote:

> As requested, I've prepared a QEMU/NetBSD status page:
>
> 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.

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.

Warner

Re: QEMU/NetBSD status wiki page

[Kamil Rytarowski]

On 27.05.2018 20:04, Warner Losh wrote:
> 
> 
> On Sun, May 27, 2018 at 11:57 AM, Kamil Rytarowski  > wrote:
> 
> On 27.05.2018 16:53, Warner Losh wrote:
> > 
> > 
> > On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski  
> > >> wrote:
> > 
> >     As requested, I've prepared a QEMU/NetBSD status page:
> > 
> >     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).

> 

Re: QEMU/NetBSD status wiki page

[Kamil Rytarowski]

On 27.05.2018 16:53, Warner Losh wrote:
> 
> 
> On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski  > wrote:
> 
> As requested, I've prepared a QEMU/NetBSD status page:
> 
> 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
> 




signature.asc
Description: OpenPGP digital signature

QEMU/NetBSD status wiki page

[Kamil Rytarowski]

As requested, I've prepared a QEMU/NetBSD status page:

http://wiki.netbsd.org/users/kamil/qemu/

I've attempted to be rather conservative with claims that something
works, without detailed verification.



signature.asc
Description: OpenPGP digital signature