qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: ehabkost@redhat.com, sakisp@xilinx.com,
	mark.burton@greensocs.com, qemu-devel@nongnu.org,
	armbru@redhat.com, edgari@xilinx.com, crosa@redhat.com,
	pbonzini@redhat.com, "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	luc.michel@greensocs.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [RFC PATCH 0/5] FAULT INJECTION FRAMEWORK
Date: Tue, 9 Jul 2019 15:42:56 +0200	[thread overview]
Message-ID: <20190709134256.GA3836@stefanha-x1.localdomain> (raw)
In-Reply-To: <601ba4fe-136d-05fb-1823-6b0f13156fe6@greensocs.com>

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]

On Wed, Jul 03, 2019 at 05:47:47PM +0200, Damien Hedde wrote:
> On 7/3/19 11:29 AM, Stefan Hajnoczi wrote:
> > On Mon, Jul 01, 2019 at 12:16:44PM +0200, Philippe Mathieu-Daudé wrote:
> >> On 7/1/19 10:37 AM, Stefan Hajnoczi wrote:
> >>> On Fri, Jun 28, 2019 at 02:45:29PM +0200, Damien Hedde wrote:
> >>>> This series adds a python framework aiming to provide some ways to do fault
> >>>> injection in a running vm. In its current state, it allows to easily interact
> >>>> with memory, change gpios and qom properties.
> >>>>
> >>>> The framework consists in a python script based on the qmp existing module
> >>>> which allows to interact with the vm.
> >>>
> >>> How does this compare to qtest?  There seems to be a lot of overlap
> >>> between them.
> >>>
> >>> Why is it called "fault injection"?  The commands seem to be
> >>> general-purpose device testing functions (like qtest and libqos), not
> >>> functions for testing error code paths as would be expected from a fault
> >>> injection framework.
> >>
> >> I understand qtest is to test QEMU, while this framework/command is to
> >> test how the guest react to an hardware faults.
> > 
> > The commands seems to be equivalent to qtest commands, just implemented
> > as QMP commands.
> > 
> > Damien: Can you explain the use case more and show some example test
> > cases?
> 
> The goal is to test and validate the software running on the vp. We want
> to generate some fault to test if the software behave correctly. We
> target corner cases that do not happen otherwise on the vp. Basically we
> would like, using some scripts, to run some specific scenarios and check
> that the expected behavior happens.
> 
> Regarding qtest, I was not aware that it provided such commands. I'm
> sorry I've missed that. Just checked after reading your feedback,
> commands seem indeed equivalent. I don't know if running the vp with
> qtest enabled has some hidden drawbacks. But if that's not the case, we
> can work to extend the existing qtest commands (or switch some of them
> to QMP like Philippe proposed, I don't know what's best).

I'm not 100% sure that qtest is the right tool for the job.  Maybe you
really need to add QMP commands as you have done.

Could you share some test cases so reviewers have an idea of how these
new commands are used for fault injection?

qtest is special in that no guest code executes.  QEMU allocates guest
RAM and initializes devices as usual but TCG/KVM do not execute guest
CPU instructions.  Does your use case require guest execution?

Here is a presentation on qtest if you want to get an overview:
https://www.youtube.com/watch?v=4TSaMmrnHy8

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2019-07-09 17:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28 12:45 [Qemu-devel] [RFC PATCH 0/5] FAULT INJECTION FRAMEWORK Damien Hedde
2019-06-28 12:45 ` [Qemu-devel] [RFC PATCH 1/5] introduce [p]mem(read|write) qmp commands Damien Hedde
2019-06-28 12:45 ` [Qemu-devel] [RFC PATCH 2/5] introduce a qmp command to set gpios Damien Hedde
2019-06-28 12:45 ` [Qemu-devel] [RFC PATCH 3/5] add qmp time-notify event triggering system Damien Hedde
2019-06-28 12:45 ` [Qemu-devel] [RFC PATCH 4/5] fault_injection: introduce Python scripting framework Damien Hedde
2019-06-28 12:45 ` [Qemu-devel] [RFC PATCH 5/5] docs: add fault injection framework documentation Damien Hedde
2019-07-01  8:37 ` [Qemu-devel] [RFC PATCH 0/5] FAULT INJECTION FRAMEWORK Stefan Hajnoczi
2019-07-01 10:16   ` Philippe Mathieu-Daudé
2019-07-03  9:29     ` Stefan Hajnoczi
2019-07-03 15:47       ` Damien Hedde
2019-07-09 13:42         ` Stefan Hajnoczi [this message]

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=20190709134256.GA3836@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=damien.hedde@greensocs.com \
    --cc=edgari@xilinx.com \
    --cc=ehabkost@redhat.com \
    --cc=luc.michel@greensocs.com \
    --cc=mark.burton@greensocs.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sakisp@xilinx.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).