From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Jiri Slaby <jirislaby@kernel.org>,
Alexander Bulekov <alxndr@bu.edu>,
Chris Friedt <chrisfriedt@gmail.com>,
cfriedt@meta.com, qemu-devel@nongnu.org
Subject: Re: [v2] hw: misc: edu: fix 2 off-by-one errors
Date: Tue, 18 Oct 2022 13:11:20 +0100 [thread overview]
Message-ID: <87a65tcoqs.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9ONenFfxz=78pMf8vXkHB+JwEORoMwhwEmbUTv_9Q7XA@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On Tue, 18 Oct 2022 at 10:21, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Jiri Slaby <jirislaby@kernel.org> writes:
>>
>> > On 17. 10. 22, 16:13, Peter Maydell wrote:
>> >> * for situations where the guest has misprogrammed the device,
>> >> log that with qemu_log_mask(LOG_GUEST_ERROR, ...)
>> >> and continue with whatever the real hardware would do, or
>> >> some reasonable choice if the h/w spec is vague
>> >
>> > As I wrote in the previous mail, can we stop the machine after the
>> > print somehow, for example? So that the students have to "cont" in the
>> > qemu console as an acknowledgment when this happens.
>>
>> You can bring the system to a halt with vm_stop(RUN_STATE_PAUSED) or
>> possible RUN_STATE_DEBUG?
>
> No, please don't do anything like that. This should not be special.
> Just log a message if the guest does something bad. There are
> an absolute ton of things that the guest can do wrong, and
> in general QEMU does not attempt to be an "identify all the
> ways the guest does something wrong in a friendly way" system.
We should clean-up the other uses of vm_stop in hw/ then:
./hw/ppc/prep_systemio.c:78: vm_stop(RUN_STATE_PAUSED);
./hw/ppc/vof.c:921: vm_stop(RUN_STATE_PAUSED);
./hw/vfio/pci.c:2725: vm_stop(RUN_STATE_INTERNAL_ERROR);
>
> thanks
> -- PMM
--
Alex Bennée
next prev parent reply other threads:[~2022-10-18 12:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-15 21:10 [v2] hw: misc: edu: fix 2 off-by-one errors Chris Friedt
2022-10-17 6:22 ` Jiri Slaby
2022-10-17 16:36 ` Christopher Friedt
2022-11-01 18:59 ` Christopher Friedt
2022-10-17 13:44 ` Alexander Bulekov
2022-10-17 14:13 ` Peter Maydell
2022-10-17 17:21 ` Alex Bennée
2022-10-17 22:05 ` Chris Friedt
2022-10-18 6:11 ` Alex Bennée
2022-10-18 6:30 ` Jiri Slaby
2022-10-18 9:18 ` Alex Bennée
2022-10-18 9:30 ` Peter Maydell
2022-10-18 12:11 ` Alex Bennée [this message]
2022-10-18 6:27 ` Jiri Slaby
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=87a65tcoqs.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=alxndr@bu.edu \
--cc=cfriedt@meta.com \
--cc=chrisfriedt@gmail.com \
--cc=jirislaby@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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.