Am 03.01.2012 14:42, schrieb Anthony Liguori:
> On 12/30/2011 09:43 AM, Andreas Färber wrote:
>> Am 29.12.2011 23:30, schrieb Anthony Liguori:
>>> 1) build binutils for desired target
>>>
>>> 2) build GCC using (1) as a cross compiler. This is a limited form of
>>> GCC (no thread support) targeted
On 12/29/2011 07:20 PM, Lucas Meneghel Rodrigues wrote:
On 12/29/2011 10:33 PM, Anthony Liguori wrote:
So I decided to do some snooping. Here are some stats:
anthony@titi:~/git/autotest/client/tests/kvm/tests$ wc -l *.py
150 balloon_check.py
68 boot_savevm.py
190 cdrom.py
1875 cgroup.py
111 cpu
On 12/30/2011 09:43 AM, Andreas Färber wrote:
Am 29.12.2011 23:30, schrieb Anthony Liguori:
On 12/29/2011 04:10 PM, Peter Maydell wrote:
How does your framework deal with non-x86 targets?
http://git.qemu.org/qemu-jeos.git
I've already got ppc32 support working. Adding a new arch is just a
m
On 01/03/2012 09:19 AM, Stefan Hajnoczi wrote:
I haven't started yet but I am planning to write qtest virtio PCI tests
and will definitely be taking a look at virtio-scsi.
We don't necessarily need mock devices, just really simply temporary raw
files or similar. On the other hand mock devices c
On Mon, Jan 02, 2012 at 03:07:08PM +0100, Paolo Bonzini wrote:
> On 12/29/2011 07:33 PM, Anthony Liguori wrote:
> >
> >FWIW, I expect virtio-scsi to be the first guinea pig here... I believe
> >Stefan has already started looking at writing some qtest based tests for
> >virtio-scsi.
>
> I'm curiou
On 12/29/2011 07:33 PM, Anthony Liguori wrote:
FWIW, I expect virtio-scsi to be the first guinea pig here... I believe
Stefan has already started looking at writing some qtest based tests for
virtio-scsi.
I'm curious, because a SCSI HBA makes it as hard as it can be to write
unit tests. Pre
On 12/29/2011 11:10 PM, Peter Maydell wrote:
>
> > Even if that turns out to be the case, it's fine. Better to
> > have a few good devices than dozens of bad ones.
>
> This is easier to say on the x86 side of the fence, since
> most of the devices you need are already in the codebase and
> nobody
Am 29.12.2011 23:30, schrieb Anthony Liguori:
> On 12/29/2011 04:10 PM, Peter Maydell wrote:
>> How does your framework deal with non-x86 targets?
>
> http://git.qemu.org/qemu-jeos.git
>
> I've already got ppc32 support working. Adding a new arch is just a
> matter of adding a kernel config and
Am 29.12.2011 19:33, schrieb Anthony Liguori:
> I don't think we should focus much on qtest for non-x86 targets. I
> mean, if you are interested in it for ARM, fantastic, but I don't think
> we would mandate it.
I'm actually very interested in having a qtest framework for non-x86 for
a) unit tes
On 12/29/2011 10:20 PM, Lucas Meneghel Rodrigues wrote:
On 12/29/2011 10:33 PM, Anthony Liguori wrote:
So I decided to do some snooping. Here are some stats:
anthony@titi:~/git/autotest/client/tests/kvm/tests$ wc -l *.py
150 balloon_check.py
68 boot_savevm.py
190 cdrom.py
1875 cgroup.py
111 cpu
On 12/29/2011 10:33 PM, Anthony Liguori wrote:
So I decided to do some snooping. Here are some stats:
anthony@titi:~/git/autotest/client/tests/kvm/tests$ wc -l *.py
150 balloon_check.py
68 boot_savevm.py
190 cdrom.py
1875 cgroup.py
111 cpu_hotplug.py
170 enospc.py
71 floppy.py
72 getfd.py
89 hdp
On 12/29/2011 05:17 PM, Lucas Meneghel Rodrigues wrote:
On 12/29/2011 03:02 PM, Anthony Liguori wrote:
On 12/29/2011 10:53 AM, Avi Kivity wrote:
On 12/29/2011 06:39 PM, Anthony Liguori wrote:
It might have made sense to split the kvm-testing functionality of
autotest, and have autotest drive t
On 12/29/2011 03:02 PM, Anthony Liguori wrote:
On 12/29/2011 10:53 AM, Avi Kivity wrote:
On 12/29/2011 06:39 PM, Anthony Liguori wrote:
It might have made sense to split the kvm-testing functionality of
autotest, and have autotest drive that. We could even have called it
qemu-test.
I specific
On 12/29/2011 12:38 PM, Dor Laor wrote:
From the recent threads it looks to me that the 2 advantages of
qemu-test over kvm-autotest are:
1. python is not used within the guest
^ Just a (relatively small) subset of KVM autotest tests do require
python in the guest (the ones that execute the a
On 12/29/2011 04:10 PM, Peter Maydell wrote:
On 29 December 2011 21:46, Anthony Liguori wrote:
But 0% test coverage is absolutely not enough. So the first step is to get
an infrastructure together that we can all live with and start writing
tests.
Agreed.
How does your framework deal with n
On 12/29/2011 05:04 PM, Peter Maydell wrote:
On 29 December 2011 18:35, Anthony Liguori wrote:
On 12/29/2011 11:49 AM, Peter Maydell wrote:
The next obvious question is: are we going to make a serious attempt?
(For instance, in a hypothetical tests-required world, would we
tell those nice folk
On 29 December 2011 21:46, Anthony Liguori wrote:
> But 0% test coverage is absolutely not enough. So the first step is to get
> an infrastructure together that we can all live with and start writing
> tests.
Agreed.
How does your framework deal with non-x86 targets? Finding and
installing a wo
On 12/29/2011 01:04 PM, Peter Maydell wrote:
On 29 December 2011 18:35, Anthony Liguori wrote:
On 12/29/2011 11:49 AM, Peter Maydell wrote:
The next obvious question is: are we going to make a serious attempt?
(For instance, in a hypothetical tests-required world, would we
tell those nice folk
On 29 December 2011 17:56, Avi Kivity wrote:
> On 12/29/2011 07:49 PM, Peter Maydell wrote:
>> I suspect that if we set the bar for new board and device models
>> that high then the result will largely be that we don't in fact
>> get new board or device models.)
>
> If just doubles the effort, I d
On Thu, Dec 29, 2011 at 19:04, Peter Maydell wrote:
> On 29 December 2011 18:35, Anthony Liguori wrote:
>> On 12/29/2011 11:49 AM, Peter Maydell wrote:
>>> The next obvious question is: are we going to make a serious attempt?
>>> (For instance, in a hypothetical tests-required world, would we
>>>
On 29 December 2011 18:35, Anthony Liguori wrote:
> On 12/29/2011 11:49 AM, Peter Maydell wrote:
>> The next obvious question is: are we going to make a serious attempt?
>> (For instance, in a hypothetical tests-required world, would we
>> tell those nice folks from Samsung "no you can't land your
On 12/29/2011 11:49 AM, Peter Maydell wrote:
On 29 December 2011 17:26, Avi Kivity wrote:
On 12/29/2011 07:22 PM, Peter Maydell wrote:
My guess is that a serious attempt at tests covering all the
functionality of a device is probably approximately doubling
the effort required for a device mode
On 12/29/2011 11:22 AM, Peter Maydell wrote:
On 29 December 2011 16:36, Avi Kivity wrote:
Yes; but using Linux limits you to what it exposes (of course Linux
exposes quite a lot, so that's mostly a non issue; but we'll have
counterexamples).
Actually IME Linux is pretty conservative about how
On 12/29/2011 11:22 AM, Avi Kivity wrote:
On 12/29/2011 07:14 PM, Anthony Liguori wrote:
On 12/29/2011 11:08 AM, Avi Kivity wrote:
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
I firmly
On 12/29/2011 07:49 PM, Peter Maydell wrote:
> On 29 December 2011 17:26, Avi Kivity wrote:
> > On 12/29/2011 07:22 PM, Peter Maydell wrote:
> >> My guess is that a serious attempt at tests covering all the
> >> functionality of a device is probably approximately doubling
> >> the effort required
On 29 December 2011 17:26, Avi Kivity wrote:
> On 12/29/2011 07:22 PM, Peter Maydell wrote:
>> My guess is that a serious attempt at tests covering all the
>> functionality of a device is probably approximately doubling
>> the effort required for a device model, incidentally. A
>> half-hearted att
On 12/29/2011 07:36 PM, Peter Maydell wrote:
> On 29 December 2011 17:26, Avi Kivity wrote:
> > On 12/29/2011 07:22 PM, Peter Maydell wrote:
> >> I think for devices what would be particularly useful would be
> >> if you can write a (simple) test for something at the register
> >> level, which gen
On 29 December 2011 17:26, Avi Kivity wrote:
> On 12/29/2011 07:22 PM, Peter Maydell wrote:
>> I think for devices what would be particularly useful would be
>> if you can write a (simple) test for something at the register
>> level, which generates an image which you can run on the real
>> hardwa
On 12/29/2011 07:22 PM, Peter Maydell wrote:
> On 29 December 2011 16:36, Avi Kivity wrote:
> > Yes; but using Linux limits you to what it exposes (of course Linux
> > exposes quite a lot, so that's mostly a non issue; but we'll have
> > counterexamples).
>
> Actually IME Linux is pretty conservat
On 12/29/2011 07:16 PM, Anthony Liguori wrote:
>> Would there be device-level tests in qemu-test?
>
>
> qemu-jeos has a kernel build environment for the target so it is also
> possible to build userspace C programs and/or kernel modules so you
> could also write guest tests in C.
>
> So it may actu
On 12/29/2011 07:14 PM, Anthony Liguori wrote:
> On 12/29/2011 11:08 AM, Avi Kivity wrote:
>> On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
>>>
>>>
>>> I firmly believe that with qtes
On 29 December 2011 16:36, Avi Kivity wrote:
> Yes; but using Linux limits you to what it exposes (of course Linux
> exposes quite a lot, so that's mostly a non issue; but we'll have
> counterexamples).
Actually IME Linux is pretty conservative about how it uses devices.
A lot of the ARM device m
On 12/29/2011 07:10 PM, Anthony Liguori wrote:
> On 12/29/2011 11:03 AM, Avi Kivity wrote:
>> On 12/29/2011 06:49 PM, Anthony Liguori wrote:
However, I don't think it's even necessary. From a quick read of the
manual, SMBIOS is just a set of static tables in memory which are
picked
On 12/29/2011 11:08 AM, Avi Kivity wrote:
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
I firmly believe that with qtest we'll end up eventually building a
libOS to make it easier to writ
On 12/29/2011 11:08 AM, Avi Kivity wrote:
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
I firmly believe that with qtest we'll end up eventually building a
libOS to make it easier to writ
On 12/29/2011 11:06 AM, Avi Kivity wrote:
On 12/29/2011 07:02 PM, Anthony Liguori wrote:
Those are rare occurrences and have always been a bit awkward. OTOH,
we're talking about the critical path of essentially every single
feature that gets merged into QEMU.
Won't that be qtest?
The diff
On 12/29/2011 11:03 AM, Avi Kivity wrote:
On 12/29/2011 06:49 PM, Anthony Liguori wrote:
However, I don't think it's even necessary. From a quick read of the
manual, SMBIOS is just a set of static tables in memory which are picked
up using a signature. So all we need to do is boot an empty gue
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
>> In what way is your specifically configured kernel's TCP stack better
>> than the random distro's kernel's?
>
>
> I firmly believe that with qtest we'll end up eventually building a
> libOS to make it easier to write qtest tests.
>
> Overtime, that
On 12/29/2011 07:02 PM, Anthony Liguori wrote:
>
> Those are rare occurrences and have always been a bit awkward. OTOH,
> we're talking about the critical path of essentially every single
> feature that gets merged into QEMU.
>
Won't that be qtest?
Major features are rare. Small changes are com
On 12/29/2011 06:49 PM, Anthony Liguori wrote:
> On 12/29/2011 10:36 AM, Avi Kivity wrote:
>> On 12/29/2011 06:12 PM, Anthony Liguori wrote:
> That's why I've also proposed qtest. But having written quite a few
> qtest unit tests by now, you hit the limits of this type of testing
> pre
On 12/29/2011 10:53 AM, Avi Kivity wrote:
On 12/29/2011 06:39 PM, Anthony Liguori wrote:
qemu-test builds a custom guest, entirely from source. This makes it
possible to efficiently test non-native architectures. The tests are
written for this minimal environment (which is not straight forwar
On 12/29/2011 10:46 AM, Avi Kivity wrote:
On 12/29/2011 06:26 PM, Anthony Liguori wrote:
I don't want to write a TCP/IP stack. We aren't just grabbing a
random distro kernel. We're building one from scratch configured in a
specific way.
How does that help?
Not sure I understand the questio
On 12/29/2011 06:39 PM, Anthony Liguori wrote:
>
> qemu-test builds a custom guest, entirely from source. This makes it
> possible to efficiently test non-native architectures. The tests are
> written for this minimal environment (which is not straight forward to
> do). This tests will never run
On 12/29/2011 10:36 AM, Avi Kivity wrote:
On 12/29/2011 06:12 PM, Anthony Liguori wrote:
That's why I've also proposed qtest. But having written quite a few
qtest unit tests by now, you hit the limits of this type of testing
pretty quickly.
Can you describe those limits?
I started writing
On 12/29/2011 06:26 PM, Anthony Liguori wrote:
> On 12/28/2011 11:21 AM, Avi Kivity wrote:
>> On 12/28/2011 06:42 PM, Anthony Liguori wrote:
In fact using linux as a guest negates that. First of all, which
linux
version? if it's fixed, you'll eventually miss functionality and
n
On 12/29/2011 08:38 AM, Dor Laor wrote:
On 12/28/2011 07:21 PM, Avi Kivity wrote:
Would you add live migration testing to qemu-test? If yes, you're
duplicating some more. If not, you're not doing functional or coverage
tests for that functionality.
From the recent threads it looks to me that
On 12/29/2011 06:12 PM, Anthony Liguori wrote:
>>> That's why I've also proposed qtest. But having written quite a few
>>> qtest unit tests by now, you hit the limits of this type of testing
>>> pretty quickly.
>>
>> Can you describe those limits?
>
>
> I started writing a finger print test. Whil
On 12/28/2011 11:21 AM, Avi Kivity wrote:
On 12/28/2011 06:42 PM, Anthony Liguori wrote:
In fact using linux as a guest negates that. First of all, which linux
version? if it's fixed, you'll eventually miss functionality and need to
migrate. If it keeps changing, so does your test, and it will
On 12/28/2011 11:26 AM, Avi Kivity wrote:
On 12/28/2011 06:44 PM, Anthony Liguori wrote:
On 12/28/2011 09:28 AM, Avi Kivity wrote:
On 12/28/2011 05:01 PM, Avi Kivity wrote:
I'd say that running a ping test is a weak version of kvm-autotest's
system tests. Running a synthetic test that pokes v
On 12/28/2011 07:21 PM, Avi Kivity wrote:
I think you're advocating for qtest. This is another important part
> of my testing strategy. I haven't received a lot of input on that RFC...
>
> http://mid.gmane.org/1322765012-3164-1-git-send-email-aligu...@us.ibm.com
>
> But there's certain thing
On 12/28/2011 06:44 PM, Anthony Liguori wrote:
> On 12/28/2011 09:28 AM, Avi Kivity wrote:
>> On 12/28/2011 05:01 PM, Avi Kivity wrote:
>>> I'd say that running a ping test is a weak version of kvm-autotest's
>>> system tests. Running a synthetic test that pokes values into memory
>>> and mmio and
On 12/28/2011 06:42 PM, Anthony Liguori wrote:
>> In fact using linux as a guest negates that. First of all, which linux
>> version? if it's fixed, you'll eventually miss functionality and need to
>> migrate. If it keeps changing, so does your test, and it will keep
>> breaking.
>
>
> The kernel
On 12/28/2011 09:28 AM, Avi Kivity wrote:
On 12/28/2011 05:01 PM, Avi Kivity wrote:
I'd say that running a ping test is a weak version of kvm-autotest's
system tests. Running a synthetic test that pokes values into memory
and mmio and sees a packet coming out is a unit test (the latter can in
f
On 12/28/2011 09:01 AM, Avi Kivity wrote:
On 12/28/2011 04:27 PM, Anthony Liguori wrote:
Maybe I've used the wrong wording. I got the feeling that, besides
testing qemu
the way you need it, keeping qemu-test simple was really important.
Simple is always important. In the case of qemu-test, t
On 12/28/2011 08:49 AM, Christoph Hellwig wrote:
On Mon, Dec 19, 2011 at 11:13:24AM -0600, Anthony Liguori wrote:
Hi,
I've published a set of tests I wrote over the weekend on qemu.org. My
motivations were 1) to prevent regressions like the libguestfs one and 2)
to have an easier way to do dev
On 12/28/2011 05:01 PM, Avi Kivity wrote:
> I'd say that running a ping test is a weak version of kvm-autotest's
> system tests. Running a synthetic test that pokes values into memory
> and mmio and sees a packet coming out is a unit test (the latter can in
> fact be executed without a guest at al
On 12/28/2011 04:27 PM, Anthony Liguori wrote:
>> Maybe I've used the wrong wording. I got the feeling that, besides
>> testing qemu
>> the way you need it, keeping qemu-test simple was really important.
>
>
> Simple is always important. In the case of qemu-test, there are some
> important trade o
On Mon, Dec 19, 2011 at 11:13:24AM -0600, Anthony Liguori wrote:
> Hi,
>
> I've published a set of tests I wrote over the weekend on qemu.org. My
> motivations were 1) to prevent regressions like the libguestfs one and 2)
> to have an easier way to do development testing as I work on QEMU Object
On 12/27/2011 11:01 PM, Cleber Rosa wrote:
On 12/27/2011 11:37 PM, Anthony Liguori wrote:
I think the main goal of qemu-tests (may be implicit) is to be quick and simple.
qemu-test doesn't have a main goal. My goal is to improve QEMU's quality.
qemu-test is just a tool to help achieve that goa
On 12/27/2011 11:37 PM, Anthony Liguori wrote:
On 12/27/2011 04:35 PM, Cleber Rosa wrote:
On 12/26/2011 08:00 PM, Dor Laor wrote:
On 12/26/2011 05:12 PM, Anthony Liguori wrote:
Hi Dor,
Merry Christmas Anthony,
On 12/25/2011 09:19 AM, Dor Laor wrote:
On 12/19/2011 07:13 PM, Anthony Liguor
On 12/27/2011 11:37 PM, Anthony Liguori wrote:
On 12/27/2011 04:35 PM, Cleber Rosa wrote:
On 12/26/2011 08:00 PM, Dor Laor wrote:
On 12/26/2011 05:12 PM, Anthony Liguori wrote:
Hi Dor,
Merry Christmas Anthony,
On 12/25/2011 09:19 AM, Dor Laor wrote:
On 12/19/2011 07:13 PM, Anthony Liguor
On 12/27/2011 04:35 PM, Cleber Rosa wrote:
On 12/26/2011 08:00 PM, Dor Laor wrote:
On 12/26/2011 05:12 PM, Anthony Liguori wrote:
Hi Dor,
Merry Christmas Anthony,
On 12/25/2011 09:19 AM, Dor Laor wrote:
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
Well, I'm still not convinced that a n
On 12/26/2011 08:00 PM, Dor Laor wrote:
On 12/26/2011 05:12 PM, Anthony Liguori wrote:
Hi Dor,
Merry Christmas Anthony,
On 12/25/2011 09:19 AM, Dor Laor wrote:
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
Well, I'm still not convinced that a new standalone package should
handle these
ca
On 12/27/2011 02:40 PM, Anthony Liguori wrote:
On 12/27/2011 09:58 AM, Avi Kivity wrote:
On 12/27/2011 05:22 PM, Anthony Liguori wrote:
The infrastructure assumes that you have a full OS available in the
guest. The tests are written in Python and make a variety of
assumptions. To my knowledge,
On 12/27/2011 09:58 AM, Avi Kivity wrote:
On 12/27/2011 05:22 PM, Anthony Liguori wrote:
The infrastructure assumes that you have a full OS available in the
guest. The tests are written in Python and make a variety of
assumptions. To my knowledge, it's not very practical to build a
busybox en
On 12/27/2011 05:22 PM, Anthony Liguori wrote:
>
> The infrastructure assumes that you have a full OS available in the
> guest. The tests are written in Python and make a variety of
> assumptions. To my knowledge, it's not very practical to build a
> busybox environment with Python embedded in it
On 12/26/2011 05:00 PM, Dor Laor wrote:
On 12/26/2011 05:12 PM, Anthony Liguori wrote:
Hi Dor,
Merry Christmas Anthony,
Happy Hanukkah!
I think it's not a bad thing to have multiple test suites when there
isn't considerable overlap.
I agree but in this case, it loos to me that qemu-test
On 12/26/2011 05:12 PM, Anthony Liguori wrote:
Hi Dor,
Merry Christmas Anthony,
On 12/25/2011 09:19 AM, Dor Laor wrote:
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
Well, I'm still not convinced that a new standalone package should
handle these
cases instead of kvm autotest. I'll be happ
Hi Dor,
On 12/25/2011 09:19 AM, Dor Laor wrote:
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
Well, I'm still not convinced that a new standalone package should handle these
cases instead of kvm autotest. I'll be happy to integrate the tests to kvm
autotest anyway and the more the merrier but
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
Hi,
I've published a set of tests I wrote over the weekend on qemu.org. My
motivations were 1) to prevent regressions like the libguestfs one and
2) to have an easier way to do development testing as I work on QEMU
Object Model.
Now before sending
On 12/19/2011 03:55 PM, Anthony Liguori wrote:
On 12/19/2011 11:39 AM, Avi Kivity wrote:
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
Hi,
I've published a set of tests I wrote over the weekend on qemu.org.
My motivations were 1) to prevent regressions like the libguestfs one
and 2) to have a
On 12/19/2011 11:39 AM, Avi Kivity wrote:
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
Hi,
I've published a set of tests I wrote over the weekend on qemu.org.
My motivations were 1) to prevent regressions like the libguestfs one
and 2) to have an easier way to do development testing as I work
On 12/19/2011 07:13 PM, Anthony Liguori wrote:
> Hi,
>
> I've published a set of tests I wrote over the weekend on qemu.org.
> My motivations were 1) to prevent regressions like the libguestfs one
> and 2) to have an easier way to do development testing as I work on
> QEMU Object Model.
>
> Now be
73 matches
Mail list logo
