Re: [PATCH v5 00/19] kvm-unit-tests/arm: initial drop

Christoffer Dall
2014-06-16T07:57:04Z

On Mon, Jun 16, 2014 at 09:46:02AM +0200, Andrew Jones wrote:
> On Sat, Jun 14, 2014 at 04:44:47PM +0200, Christoffer Dall wrote:
> > On Wed, Jun 11, 2014 at 04:01:15PM +0200, Andrew Jones wrote:
> > > This is a v5 of a series that introduces arm to kvm-unit-tests. First,
> > > it does some tidying up of the repo. Then, it adds support for device
> > > trees (libfdt), and for virtio-testdev[1]. Next, it adds the basic
> > > infrastructure for booting a test case (guest), and adds a first
> > > test case, a self-test to confirm setup was completed successfully.
> > > Finally, it further prepares the framework for more complicated tests
> > > by adding vector support, and extends the self-test to test that too.
> > >
> > > This initial drop doesn't require kvmarm. qemu-system-arm is enough,
> > > but it must have mach-virt, and the virtio-testdev patch[1].
> > >
> > > These patches (v5) are also available from a git repo here
> > > https://github.com/rhdrjones/kvm-unit-tests/commits/arm/v5-initial-drop
> > >
> > > The v4 patches are available for reference here
> > > https://github.com/rhdrjones/kvm-unit-tests/commits/arm/v4-initial-drop
> > >
> > > Not too much has changed since v4. There are no new patches nor dropped
> > > patches, and all patches that did get a change have a v5 note. To see
> > > a branch interdiff (created with git-tbdiff[2]) take a look here[3].
> > >
> > > Thanks in advance for reviews!
> > >
> > This now looks pretty good overall. Feels to me like if you address
> > Paolo's comments then this could be merged, and we can start adding more
> > complicated tests to it.
> >
> > When you send out the next (last?) version, I can give it a spin on
> > hardware with KVM as well.
> >
> > -Christoffer
>
> Thanks! It sounds like Paolo would like to see the qemu support merged
> first. Although, IMO, which goes first could go either way (either
> the qemu side waits on kvm-unit-tests, or kvm-unit-tests waits on qemu),
> one must go first.
>
Yeah, but probably makes sense to have the QEMU side go upstream first
as it is the passive agent, and the one that may require a little
discussion etc. to get in place.

-Christoffer