[Qemu-devel] NetBSD maintenance

[Qemu-devel] NetBSD maintenance

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

Hello,

I noted a call for NetBSD maintainers in the 2.9.0 release notes.

I'm willing to attach a NetBSD machine to CI cluster and volunteer basic
maintenance. I'm mostly interested in NetBSD as host & as guest as this
is my daily and work driver on my desktop and development machines.

If I understand correctly there is currently no infrastructure for CI:
http://wiki.qemu.org/Testing/ContinuousIntegration


I'm familiar with Python buildbot, I run a machine for the LLVM
toolchain with Clang and LLDB. This setup works very well and it's easy
to setup with minimal dependencies:
http://llvm.org/docs/HowToAddABuilder.html

My LLVM machine:
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7

Although, I plan to upgrade it pretty soon and rename, so look for
lldb-amd64-ninja-netbsd8.


As of today NetBSD patches for qemu are maintained in pkgsrc. There are
also at least DragonFly and SunOS (SmartOS) diffs available.
https://github.com/NetBSD/pkgsrc/tree/trunk/emulators/qemu/patches


Qemu is one of the core tools in NetBSD development and it's used in our
release engineering infrastructure:

http://releng.netbsd.org/test-results.html


I will start with upstreaming local diffs and move on to running tests.
I'm aware that there are lately issues with ACPI, APIC, SMP and certain
device drivers... but not everything at once.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] NetBSD maintenance

[Peter Maydell]

On 23 April 2017 at 00:27, Kamil Rytarowski <n54@gmx.com> wrote:
> I noted a call for NetBSD maintainers in the 2.9.0 release notes.
>
> I'm willing to attach a NetBSD machine to CI cluster and volunteer basic
> maintenance. I'm mostly interested in NetBSD as host & as guest as this
> is my daily and work driver on my desktop and development machines.

Thanks for the offer of assistance. At the moment I have a
NetBSD VM set up so I can run the usual make/make check
tests that I run on other hosts. So the most immediate
requirement is for somebody to investigate and send patches
for the bugs which mean it doesn't build at all.
My initial investigation suggests that at least one bug is that
ivshmem-server uses shm_open but doesn't link -lrt, so
some fixes to the build machinery are needed.

> As of today NetBSD patches for qemu are maintained in pkgsrc. There are
> also at least DragonFly and SunOS (SmartOS) diffs available.
> https://github.com/NetBSD/pkgsrc/tree/trunk/emulators/qemu/patches

Accumulating patches downstream like this is I think
a big part of the problem -- if QEMU has bugs on NetBSD
then we need NetBSD users to report the problems and
provide us with fixes. Otherwise you get what's happened:
we try to build NetBSD with upstream QEMU, find it doesn't
even compile, and conclude that obviously nobody's using
QEMU on NetBSD because nobody's complained that it doesn't
work, so we might as well drop it.

(I recall hitting that "ssp/unistd.h defines macros for read, etc"
bug a few years back when I last tried NetBSD as a host;
it looks like it's fixed in the headers on newer NetBSD, though,
so maybe those patches could just be dropped if we're lucky.)

> Qemu is one of the core tools in NetBSD development and it's used in our
> release engineering infrastructure:
>
> http://releng.netbsd.org/test-results.html

Do you use/test the bsd-user code, or just system emulation?
I know the FreeBSD folks have extensive patches to the usermode
code, but does it work OK on NetBSD hosts, or is it just unused?

> I will start with upstreaming local diffs and move on to running tests.

Thanks, I think that is the right place to start.

-- PMM

Re: [Qemu-devel] NetBSD maintenance

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]

On 23.04.2017 12:19, Peter Maydell wrote:
> On 23 April 2017 at 00:27, Kamil Rytarowski <n54@gmx.com> wrote:
>> I noted a call for NetBSD maintainers in the 2.9.0 release notes.
>>
>> I'm willing to attach a NetBSD machine to CI cluster and volunteer basic
>> maintenance. I'm mostly interested in NetBSD as host & as guest as this
>> is my daily and work driver on my desktop and development machines.
> 
> Thanks for the offer of assistance. At the moment I have a
> NetBSD VM set up so I can run the usual make/make check
> tests that I run on other hosts. So the most immediate
> requirement is for somebody to investigate and send patches
> for the bugs which mean it doesn't build at all.
> My initial investigation suggests that at least one bug is that
> ivshmem-server uses shm_open but doesn't link -lrt, so
> some fixes to the build machinery are needed.
> 

I will have a look and try to build qemu from git (master branch).

I also find it surprising that there was a call for CI machines and
there is no infrastructure for it.

>> As of today NetBSD patches for qemu are maintained in pkgsrc. There are
>> also at least DragonFly and SunOS (SmartOS) diffs available.
>> https://github.com/NetBSD/pkgsrc/tree/trunk/emulators/qemu/patches
> 
> Accumulating patches downstream like this is I think
> a big part of the problem -- if QEMU has bugs on NetBSD
> then we need NetBSD users to report the problems and
> provide us with fixes. Otherwise you get what's happened:
> we try to build NetBSD with upstream QEMU, find it doesn't
> even compile, and conclude that obviously nobody's using
> QEMU on NetBSD because nobody's complained that it doesn't
> work, so we might as well drop it.
> 

We should maintain buildable and functional version for major BSDs (Net,
Free, Open, DragonFly), Linux, Darwin and SunOS in pkgsrc. Not
necessarily every release is verified on each Operating System, but our
users at some point managed to get it functional on all of them.

> (I recall hitting that "ssp/unistd.h defines macros for read, etc"
> bug a few years back when I last tried NetBSD as a host;
> it looks like it's fixed in the headers on newer NetBSD, though,
> so maybe those patches could just be dropped if we're lucky.)
> 

I will have a look.

>> Qemu is one of the core tools in NetBSD development and it's used in our
>> release engineering infrastructure:
>>
>> http://releng.netbsd.org/test-results.html
> 
> Do you use/test the bsd-user code, or just system emulation?
> I know the FreeBSD folks have extensive patches to the usermode
> code, but does it work OK on NetBSD hosts, or is it just unused?
> 

I'm afraid that there is no support in qemu usermode on NetBSD right now.

I just used unicorn-engine (qemu fork) for this purpose.

>> I will start with upstreaming local diffs and move on to running tests.
> 
> Thanks, I think that is the right place to start.
> 

Thanks for reply!

> -- PMM
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] NetBSD maintenance

[Fam Zheng]

On Mon, 04/24 00:45, Kamil Rytarowski wrote:
> I will have a look and try to build qemu from git (master branch).
> 
> I also find it surprising that there was a call for CI machines and
> there is no infrastructure for it.

There are. We use travis and patchew. I don't know a lot about NetBSD testing
with travis, but patchew has x86_64 and s390x machines that test patches, and
welcomes more OSes/architectures:

http://patchew.org/QEMU/20170423223216.17856-1-aurelien@aurel32.net/

If qemu master can be build on NetBDS, I can create a VM for this on my x86_64
machine, or you can generously contribute one, which is even better. :)

Fam

Re: [Qemu-devel] NetBSD maintenance

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On 24.04.2017 09:26, Fam Zheng wrote:
> On Mon, 04/24 00:45, Kamil Rytarowski wrote:
>> I will have a look and try to build qemu from git (master branch).
>>
>> I also find it surprising that there was a call for CI machines and
>> there is no infrastructure for it.
> 
> There are. We use travis and patchew. I don't know a lot about NetBSD testing
> with travis, but patchew has x86_64 and s390x machines that test patches, and
> welcomes more OSes/architectures:
> 
> http://patchew.org/QEMU/20170423223216.17856-1-aurelien@aurel32.net/
> 
> If qemu master can be build on NetBDS, I can create a VM for this on my x86_64
> machine, or you can generously contribute one, which is even better. :)
> 
> Fam
> 

That's great - we will be back to you when the build issues will be
sorted out.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] NetBSD maintenance

[Peter Maydell]

On 23 April 2017 at 23:45, Kamil Rytarowski <n54@gmx.com> wrote:
> On 23.04.2017 12:19, Peter Maydell wrote:
>> On 23 April 2017 at 00:27, Kamil Rytarowski <n54@gmx.com> wrote:
>>> I noted a call for NetBSD maintainers in the 2.9.0 release notes.
>>>
>>> I'm willing to attach a NetBSD machine to CI cluster and volunteer basic
>>> maintenance. I'm mostly interested in NetBSD as host & as guest as this
>>> is my daily and work driver on my desktop and development machines.
>>
>> Thanks for the offer of assistance. At the moment I have a
>> NetBSD VM set up so I can run the usual make/make check
>> tests that I run on other hosts. So the most immediate
>> requirement is for somebody to investigate and send patches
>> for the bugs which mean it doesn't build at all.
>> My initial investigation suggests that at least one bug is that
>> ivshmem-server uses shm_open but doesn't link -lrt, so
>> some fixes to the build machinery are needed.
>>
>
> I will have a look and try to build qemu from git (master branch).
>
> I also find it surprising that there was a call for CI machines and
> there is no infrastructure for it.

The infrastructure here is "if I have a machine I can ssh
into I have some local scripts which do a build-and-test".
In the case of NetBSD I did manage to get a VM set up after
we applied the patches to print the deprecation warnings,
so that allows me to skip getting somebody else to run a
machine and provide an account on it.

Right now we're in the "get at least something working to
let us test all our platforms" stage; we can try for more
fancy official CI setups later.

>>> As of today NetBSD patches for qemu are maintained in pkgsrc. There are
>>> also at least DragonFly and SunOS (SmartOS) diffs available.
>>> https://github.com/NetBSD/pkgsrc/tree/trunk/emulators/qemu/patches
>>
>> Accumulating patches downstream like this is I think
>> a big part of the problem -- if QEMU has bugs on NetBSD
>> then we need NetBSD users to report the problems and
>> provide us with fixes. Otherwise you get what's happened:
>> we try to build NetBSD with upstream QEMU, find it doesn't
>> even compile, and conclude that obviously nobody's using
>> QEMU on NetBSD because nobody's complained that it doesn't
>> work, so we might as well drop it.
>
> We should maintain buildable and functional version for major BSDs (Net,
> Free, Open, DragonFly), Linux, Darwin and SunOS in pkgsrc. Not
> necessarily every release is verified on each Operating System, but our
> users at some point managed to get it functional on all of them.

Upstream we're definitely going to drop SunOS/Solaris support unless
somebody provides us with a machine we can do build/test on.
DragonFly BSD is in my "let's see if anybody complains" list.
OpenBSD is also in this "let's see" list but it seems more plausible
that somebody will complain (and I have a VM setup for it; it
doesn't pass 'make check' at the moment so the first step there
will be for somebody to investigate and send fixes.)

The motivation here is that we would rather like to get rid of
things like #ifdef __NetBSD__ in our sources (in favour of doing
checks in configure for presence/absence of particular functions
and acting accordingly), and also avoid using "uname" to figure
out our compile target. That's very likely to break platforms
we can't test on, so the idea is to identify which platforms
people do care about, and make sure we are testing them, and
then not worry about breaking anything that we aren't testing.

Also I think it doesn't do our users any favours to claim to
support platform Foo if in fact it doesn't even compile.

>>> Qemu is one of the core tools in NetBSD development and it's used in our
>>> release engineering infrastructure:
>>>
>>> http://releng.netbsd.org/test-results.html
>>
>> Do you use/test the bsd-user code, or just system emulation?
>> I know the FreeBSD folks have extensive patches to the usermode
>> code, but does it work OK on NetBSD hosts, or is it just unused?
>>
>
> I'm afraid that there is no support in qemu usermode on NetBSD right now.

It presumably worked once, since there's a bsd-user/netbsd/ directory.
However if it's broken now then we don't need to try to keep it
working while we land the FreeBSD usermode fixes, so we could
perhaps delete it and reinstate later.

thanks
-- PMM

Re: [Qemu-devel] NetBSD maintenance

[Kamil Rytarowski]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

On 24.04.2017 12:12, Peter Maydell wrote:
> Upstream we're definitely going to drop SunOS/Solaris support unless
> somebody provides us with a machine we can do build/test on.
> DragonFly BSD is in my "let's see if anybody complains" list.
> OpenBSD is also in this "let's see" list but it seems more plausible
> that somebody will complain (and I have a VM setup for it; it
> doesn't pass 'make check' at the moment so the first step there
> will be for somebody to investigate and send fixes.)
> 
> The motivation here is that we would rather like to get rid of
> things like #ifdef __NetBSD__ in our sources (in favour of doing
> checks in configure for presence/absence of particular functions
> and acting accordingly), and also avoid using "uname" to figure
> out our compile target. That's very likely to break platforms
> we can't test on, so the idea is to identify which platforms
> people do care about, and make sure we are testing them, and
> then not worry about breaking anything that we aren't testing.
> 
> Also I think it doesn't do our users any favours to claim to
> support platform Foo if in fact it doesn't even compile.
> 

I can only speak for pkgsrc, qemu/Illumos (SmartOS) is actively maintained.

I have got an access to an Illumos machine for pkgsrc developers. Once I
will sort out NetBSD issues I will test qemu over there. I cannot speak
for Oracle Solaris and other proprietary Operating Systems.

I should get shell account for myself for DragonFly and Minix within 2
months.

I cannot maintain non-NetBSD targets beyond occasional and trivial
patches thought.

I will keep upstreaming small chunks of patches for NetBSD and let's see
how it will go. Thanks for help!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]