On 04/16/2012 03:14 PM, Paolo Bonzini wrote:
The bits I'm more interested about is edge case testing (things that
could pose a security concern). Since WHQL interfaces at the expected
paths for the driver, it's unlikely that it can test any of this.
It does include fuzz tests.
But VMXNET3 isn't really special here. From this point forward, I
would expect all new devices to come with a qtest-based test case.
I find this to be hard to justify.
With a grand total of 1 device tested, and with a coverage of almost
zero even for that device, I think it's only sane to consider qtest
a proof of concept.
How else are we going to get there other than asking people to use it?
I agree. But I'm saying it's too early even for that.
For a 10 line test that enumerates the PCI device given the command line
argument?
Here's the thing, I just looked through the code and spotted what I think is a
buffer overflow. It's hard to tell purely from code inspection. With just a
basic qtest harness, it makes it possible to attempt to test whether or not you
can overflow.
Look, it's pretty darn simple to add a basic test for vmxnet3 to qtest
that initializes the device. I don't see what the big deal is asking for
that.
For that, qemu-test is enough. Just boot into a Linux system that has
the driver.
I'm basically looking for