All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm@nongnu.org,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Zhichao Huang <zhichao.huang@linaro.org>,
	kvm-devel <kvm@vger.kernel.org>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	"kvmarm\@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests
Date: Tue, 08 Dec 2015 12:02:11 +0000	[thread overview]
Message-ID: <87poyhp2rg.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9q1MpiM4vM+RH-YQ2RpB=eV-Xgyw1-yw6qHG0hbem6_Q@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On 12 November 2015 at 16:20, Alex Bennée <alex.bennee@linaro.org> wrote:
>> From: Alex Bennée <alex@bennee.com>
>>
>> The aim of these tests is to combine with an appropriate kernel
>> image (with symbol-file vmlinux) and check it behaves as it should.
>> Given a kernel it checks:
>>
>>   - single step
>>   - software breakpoint
>>   - hardware breakpoint
>>   - access, read and write watchpoints
>>
>> On success it returns 0 to the calling process.
>>
>> I've not plumbed this into the "make check" logic though as we need a
>> solution for providing non-host binaries to the tests. However the test
>> is structured to work with pretty much any Linux kernel image as it
>> uses the basic kernel_init code which is common across architectures.
>
> Do these tests pass if you run them on the TCG QEMU, just out
> of interest?

You'll be glad to know they do.

> I'm not a great fan of tests that aren't in 'make check'
> because IME they just bitrot, but as you say we have no
> sensible approach for handling tests that need to run real
> guest code :-(

I was pondering if a git sub-project with large file support would work.
We could add pre-built binaries to the tree with appropriate meta-data
(src tree, version, config) to rebuild if required.

There would be some degree of trust implied in the original builder
though. Maybe a signed commit?

>
> thanks
> -- PMM


--
Alex Bennée

WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: kvm-devel <kvm@vger.kernel.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm@nongnu.org,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Zhichao Huang <zhichao.huang@linaro.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>
Subject: Re: [Qemu-devel] [PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests
Date: Tue, 08 Dec 2015 12:02:11 +0000	[thread overview]
Message-ID: <87poyhp2rg.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9q1MpiM4vM+RH-YQ2RpB=eV-Xgyw1-yw6qHG0hbem6_Q@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On 12 November 2015 at 16:20, Alex Bennée <alex.bennee@linaro.org> wrote:
>> From: Alex Bennée <alex@bennee.com>
>>
>> The aim of these tests is to combine with an appropriate kernel
>> image (with symbol-file vmlinux) and check it behaves as it should.
>> Given a kernel it checks:
>>
>>   - single step
>>   - software breakpoint
>>   - hardware breakpoint
>>   - access, read and write watchpoints
>>
>> On success it returns 0 to the calling process.
>>
>> I've not plumbed this into the "make check" logic though as we need a
>> solution for providing non-host binaries to the tests. However the test
>> is structured to work with pretty much any Linux kernel image as it
>> uses the basic kernel_init code which is common across architectures.
>
> Do these tests pass if you run them on the TCG QEMU, just out
> of interest?

You'll be glad to know they do.

> I'm not a great fan of tests that aren't in 'make check'
> because IME they just bitrot, but as you say we have no
> sensible approach for handling tests that need to run real
> guest code :-(

I was pondering if a git sub-project with large file support would work.
We could add pre-built binaries to the tree with appropriate meta-data
(src tree, version, config) to rebuild if required.

There would be some degree of trust implied in the original builder
though. Maybe a signed commit?

>
> thanks
> -- PMM


--
Alex Bennée

WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm@nongnu.org,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Zhichao Huang <zhichao.huang@linaro.org>,
	kvm-devel <kvm@vger.kernel.org>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests
Date: Tue, 08 Dec 2015 12:02:11 +0000	[thread overview]
Message-ID: <87poyhp2rg.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9q1MpiM4vM+RH-YQ2RpB=eV-Xgyw1-yw6qHG0hbem6_Q@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On 12 November 2015 at 16:20, Alex Bennée <alex.bennee@linaro.org> wrote:
>> From: Alex Bennée <alex@bennee.com>
>>
>> The aim of these tests is to combine with an appropriate kernel
>> image (with symbol-file vmlinux) and check it behaves as it should.
>> Given a kernel it checks:
>>
>>   - single step
>>   - software breakpoint
>>   - hardware breakpoint
>>   - access, read and write watchpoints
>>
>> On success it returns 0 to the calling process.
>>
>> I've not plumbed this into the "make check" logic though as we need a
>> solution for providing non-host binaries to the tests. However the test
>> is structured to work with pretty much any Linux kernel image as it
>> uses the basic kernel_init code which is common across architectures.
>
> Do these tests pass if you run them on the TCG QEMU, just out
> of interest?

You'll be glad to know they do.

> I'm not a great fan of tests that aren't in 'make check'
> because IME they just bitrot, but as you say we have no
> sensible approach for handling tests that need to run real
> guest code :-(

I was pondering if a git sub-project with large file support would work.
We could add pre-built binaries to the tree with appropriate meta-data
(src tree, version, config) to rebuild if required.

There would be some degree of trust implied in the original builder
though. Maybe a signed commit?

>
> thanks
> -- PMM


--
Alex Bennée

WARNING: multiple messages have this Message-ID (diff)
From: alex.bennee@linaro.org (Alex Bennée)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests
Date: Tue, 08 Dec 2015 12:02:11 +0000	[thread overview]
Message-ID: <87poyhp2rg.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9q1MpiM4vM+RH-YQ2RpB=eV-Xgyw1-yw6qHG0hbem6_Q@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On 12 November 2015 at 16:20, Alex Benn?e <alex.bennee@linaro.org> wrote:
>> From: Alex Benn?e <alex@bennee.com>
>>
>> The aim of these tests is to combine with an appropriate kernel
>> image (with symbol-file vmlinux) and check it behaves as it should.
>> Given a kernel it checks:
>>
>>   - single step
>>   - software breakpoint
>>   - hardware breakpoint
>>   - access, read and write watchpoints
>>
>> On success it returns 0 to the calling process.
>>
>> I've not plumbed this into the "make check" logic though as we need a
>> solution for providing non-host binaries to the tests. However the test
>> is structured to work with pretty much any Linux kernel image as it
>> uses the basic kernel_init code which is common across architectures.
>
> Do these tests pass if you run them on the TCG QEMU, just out
> of interest?

You'll be glad to know they do.

> I'm not a great fan of tests that aren't in 'make check'
> because IME they just bitrot, but as you say we have no
> sensible approach for handling tests that need to run real
> guest code :-(

I was pondering if a git sub-project with large file support would work.
We could add pre-built binaries to the tree with appropriate meta-data
(src tree, version, config) to rebuild if required.

There would be some degree of trust implied in the original builder
though. Maybe a signed commit?

>
> thanks
> -- PMM


--
Alex Benn?e

  reply	other threads:[~2015-12-08 12:02 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 16:20 [PATCH v9 0/6] QEMU support for KVM Guest Debug on arm64 Alex Bennée
2015-11-12 16:20 ` Alex Bennée
2015-11-12 16:20 ` [Qemu-devel] " Alex Bennée
2015-11-12 16:20 ` [PATCH v9 1/6] target-arm: kvm64 - introduce kvm_arm_init_debug() Alex Bennée
2015-11-12 16:20   ` Alex Bennée
2015-11-12 16:20   ` [Qemu-devel] " Alex Bennée
2015-11-20 15:05   ` Peter Maydell
2015-11-20 15:05     ` Peter Maydell
2015-11-20 15:05     ` [Qemu-devel] " Peter Maydell
2015-11-20 15:11     ` Peter Maydell
2015-11-20 15:11       ` Peter Maydell
2015-11-20 15:11       ` [Qemu-devel] " Peter Maydell
2015-11-20 15:23       ` Alex Bennée
2015-11-20 15:23         ` Alex Bennée
2015-11-20 15:23         ` Alex Bennée
2015-11-20 15:23         ` [Qemu-devel] " Alex Bennée
2015-11-12 16:20 ` [PATCH v9 2/6] target-arm: kvm - implement software breakpoints Alex Bennée
2015-11-12 16:20   ` Alex Bennée
2015-11-12 16:20   ` [Qemu-devel] " Alex Bennée
2015-11-20 15:27   ` Peter Maydell
2015-11-20 15:27     ` Peter Maydell
2015-11-20 15:27     ` [Qemu-devel] " Peter Maydell
2015-11-12 16:20 ` [PATCH v9 3/6] target-arm: kvm - support for single step Alex Bennée
2015-11-12 16:20   ` Alex Bennée
2015-11-12 16:20   ` [Qemu-devel] " Alex Bennée
2015-11-20 15:30   ` Peter Maydell
2015-11-20 15:30     ` Peter Maydell
2015-11-20 15:30     ` [Qemu-devel] " Peter Maydell
2015-12-08 11:49     ` Alex Bennée
2015-12-08 11:49       ` Alex Bennée
2015-12-08 11:49       ` [Qemu-devel] " Alex Bennée
2015-11-12 16:20 ` [PATCH v9 4/6] target-arm: kvm - add support for HW assisted debug Alex Bennée
2015-11-12 16:20   ` Alex Bennée
2015-11-12 16:20   ` [Qemu-devel] " Alex Bennée
2015-11-20 15:48   ` Peter Maydell
2015-11-20 15:48     ` Peter Maydell
2015-11-20 15:48     ` [Qemu-devel] " Peter Maydell
2015-11-12 16:20 ` [PATCH v9 5/6] target-arm: kvm - re-inject guest debug exceptions Alex Bennée
2015-11-12 16:20   ` Alex Bennée
2015-11-12 16:20   ` [Qemu-devel] " Alex Bennée
2015-11-20 16:14   ` Peter Maydell
2015-11-20 16:14     ` Peter Maydell
2015-11-20 16:14     ` [Qemu-devel] " Peter Maydell
2015-11-12 16:20 ` [PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests Alex Bennée
2015-11-12 16:20   ` Alex Bennée
2015-11-12 16:20   ` [Qemu-devel] " Alex Bennée
2015-11-20 16:17   ` Peter Maydell
2015-11-20 16:17     ` Peter Maydell
2015-11-20 16:17     ` [Qemu-devel] " Peter Maydell
2015-12-08 12:02     ` Alex Bennée [this message]
2015-12-08 12:02       ` Alex Bennée
2015-12-08 12:02       ` Alex Bennée
2015-12-08 12:02       ` [Qemu-devel] " Alex Bennée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87poyhp2rg.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=zhichao.huang@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.