[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCHv2] tests: re-enable vhost-user-test
From: |
Marc-André Lureau |
Subject: |
Re: [Qemu-devel] [PATCHv2] tests: re-enable vhost-user-test |
Date: |
Tue, 27 Oct 2015 10:33:26 -0400 (EDT) |
Hi
----- Original Message -----
> On 26 October 2015 at 14:32, <address@hidden> wrote:
> > From: Marc-André Lureau <address@hidden>
> >
> > Commit 7fe34ca9c2e actually disabled vhost-user-test altogether,
> > since CONFIG_VHOST_NET is a per-target config variable.
> >
> > tests/vhost-user-test is already x86/x64 softmmu specific test, in order
> > to enable it correctly, kvm & vhost-net are also conditions. To check
> > that, set CONFIG_VHOST_NET_TEST_$target when kvm is also enabled.
> >
> > Since "check-qtest-x86_64-y = $(check-qtest-i386-y)", avoid duplication
> > when both x86 & x64 are enabled.
> >
> > Other targets than x86 aren't enabled yet, and is intentionally left as
> > a future improvement, since I can't easily test those.
> >
> > Signed-off-by: Marc-André Lureau <address@hidden>
>
> I ran this through my build-tests, which pass, but:
>
> (a) there's still the clang warning about the negative shifts
> in target-i386/. This is an ancient bug and we can fix it later.
I sent a patch to fix this.
> (b) there are new warning messages:
> Warning: path not on HugeTLBFS: /tmp/vhost-test-xaGJRK
> Warning: path not on HugeTLBFS: /tmp/vhost-test-xaGJRK
> Warning: path not on HugeTLBFS: /tmp/vhost-test-xaGJRK
These are part of qemu file_ram_alloc()
> I would like (b) fixed -- tests should either:
> (1) complete without printing "warning" about anything
We would need to change the qemu warning.
> (2) fail the test if the warning is actually important
> (3) skip the test if the test requires something that the host
> machine doesn't have (like a hugetlbfs)
It is not important for the test to succeed.
I imagine a few options to get rid of the warning:
1. only run the test on hugetlbfs
2. remove the warning from qemu
3. silence qemu errors in the test
4. add an option to memory-backend-file to require hugetlbfs: something like
...,require-hugetlbfs=true,false,warn
I guess 4. is the most interesting, although I would need some advice on how to
express this best.
(tbh, I think this could be addressed later)