From: Laszlo Ersek <lersek@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
qemu-arm <qemu-arm@nongnu.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash
Date: Wed, 9 Mar 2016 15:21:06 +0100 [thread overview]
Message-ID: <56E03152.9060003@redhat.com> (raw)
In-Reply-To: <56E02E1C.2090207@redhat.com>
On 03/09/16 15:07, Paolo Bonzini wrote:
>
>
> On 09/03/2016 15:06, Laszlo Ersek wrote:
>> However: despite reusing the core SMM code identically in the guest,
>> there is at least one stark behavioral difference: in QEMU the SMI is
>> raised only on the processor that triggers it. This exercises paths in
>> the core SMM code where processors have to count down timeouts and bring
>> each other in, and these busy loops are very visible to an interactive
>> user in certain circumstances.
>
> Right, and that's unfortunately something that's hard to change because
> SeaBIOS relies on it. :((
I recall (and am still thankful for) the relevant patch receiving the
due attention and investigation on the list, so I'm not bitter about it
or anything.
Just a bit worried about users asking about the animation :)
Laszlo
WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
qemu-arm <qemu-arm@nongnu.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash
Date: Wed, 9 Mar 2016 15:21:06 +0100 [thread overview]
Message-ID: <56E03152.9060003@redhat.com> (raw)
In-Reply-To: <56E02E1C.2090207@redhat.com>
On 03/09/16 15:07, Paolo Bonzini wrote:
>
>
> On 09/03/2016 15:06, Laszlo Ersek wrote:
>> However: despite reusing the core SMM code identically in the guest,
>> there is at least one stark behavioral difference: in QEMU the SMI is
>> raised only on the processor that triggers it. This exercises paths in
>> the core SMM code where processors have to count down timeouts and bring
>> each other in, and these busy loops are very visible to an interactive
>> user in certain circumstances.
>
> Right, and that's unfortunately something that's hard to change because
> SeaBIOS relies on it. :((
I recall (and am still thankful for) the relevant patch receiving the
due attention and investigation on the list, so I'm not bitter about it
or anything.
Just a bit worried about users asking about the animation :)
Laszlo
next prev parent reply other threads:[~2016-03-09 14:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 14:45 [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash Peter Maydell
2016-02-12 14:45 ` [Qemu-devel] [PATCH 1/4] hw/arm/virt: Provide a secure-only RAM if booting in Secure mode Peter Maydell
2016-02-12 14:45 ` [Qemu-arm] [PATCH 2/4] loader: Add load_image_mr() to load ROM image to a MemoryRegion Peter Maydell
2016-02-12 14:45 ` [Qemu-devel] " Peter Maydell
2016-03-03 16:46 ` [Qemu-arm] " Paolo Bonzini
2016-03-03 16:46 ` [Qemu-devel] " Paolo Bonzini
2016-03-04 7:42 ` [Qemu-arm] " Michael S. Tsirkin
2016-03-04 7:42 ` [Qemu-devel] " Michael S. Tsirkin
2016-02-12 14:46 ` [Qemu-devel] [PATCH 3/4] hw/arm/virt: Load bios image to MemoryRegion, not physaddr Peter Maydell
2016-02-12 14:46 ` [Qemu-arm] [PATCH 4/4] hw/arm/virt: Make first flash device Secure-only if booting secure Peter Maydell
2016-02-12 14:46 ` [Qemu-devel] " Peter Maydell
2016-02-12 22:54 ` [Qemu-devel] [PATCH 0/4] virt: provide secure-only RAM and first flash Mark Cave-Ayland
2016-02-25 16:47 ` [Qemu-arm] " Peter Maydell
2016-02-25 16:47 ` Peter Maydell
2016-03-07 15:20 ` [Qemu-arm] " Paolo Bonzini
2016-03-07 15:20 ` [Qemu-devel] " Paolo Bonzini
2016-03-07 23:34 ` Peter Maydell
2016-03-08 12:02 ` [Qemu-arm] " Paolo Bonzini
2016-03-08 12:02 ` [Qemu-devel] " Paolo Bonzini
2016-03-08 12:10 ` [Qemu-arm] " Ard Biesheuvel
2016-03-08 12:10 ` [Qemu-devel] " Ard Biesheuvel
2016-03-08 12:13 ` Ard Biesheuvel
2016-03-08 12:14 ` [Qemu-arm] " Paolo Bonzini
2016-03-08 12:14 ` [Qemu-devel] " Paolo Bonzini
2016-03-08 12:16 ` [Qemu-arm] " Ard Biesheuvel
2016-03-08 12:16 ` [Qemu-devel] " Ard Biesheuvel
2016-03-08 12:41 ` [Qemu-arm] " Paolo Bonzini
2016-03-08 12:41 ` [Qemu-devel] " Paolo Bonzini
2016-03-08 12:50 ` Ard Biesheuvel
2016-03-08 13:06 ` [Qemu-arm] " Paolo Bonzini
2016-03-08 13:06 ` [Qemu-devel] " Paolo Bonzini
2016-03-08 13:46 ` [Qemu-arm] " Peter Maydell
2016-03-08 13:46 ` [Qemu-devel] " Peter Maydell
2016-03-09 14:06 ` [Qemu-arm] " Laszlo Ersek
2016-03-09 14:06 ` Laszlo Ersek
2016-03-09 14:07 ` [Qemu-arm] " Paolo Bonzini
2016-03-09 14:07 ` Paolo Bonzini
2016-03-09 14:21 ` Laszlo Ersek [this message]
2016-03-09 14:21 ` Laszlo Ersek
2016-03-08 13:49 ` [Qemu-arm] " Peter Maydell
2016-03-08 13:49 ` [Qemu-devel] " Peter Maydell
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=56E03152.9060003@redhat.com \
--to=lersek@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=armbru@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.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.