From: Laszlo Ersek <lersek@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Cc: qemu-stable@nongnu.org
Subject: Re: [PATCH v2 3/3] x86: Clear MTRRs on vCPU reset
Date: Thu, 14 Aug 2014 23:23:49 +0200 [thread overview]
Message-ID: <53ED28E5.9040305@redhat.com> (raw)
In-Reply-To: <20140814192415.13303.34846.stgit@gimli.home>
On 08/14/14 21:24, Alex Williamson wrote:
> The SDM specifies (June 2014 Vol3 11.11.5):
>
> On a hardware reset, the P6 and more recent processors clear the
> valid flags in variable-range MTRRs and clear the E flag in the
> IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in the
> MTRRs are undefined.
>
> We currently do none of that, so whatever MTRR settings you had prior
> to reset is what you have after reset. Usually this doesn't matter
> because KVM often ignores the guest mappings and uses write-back
> anyway. However, if you have an assigned device and an IOMMU that
> allows NoSnoop for that device, KVM defers to the guest memory
> mappings which are now stale after reset. The result is that OVMF
> rebooting on such a configuration takes a full minute to LZMA
> decompress the firmware volume, a process that is nearly instant on
> the initial boot.
>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: qemu-stable@nongnu.org
> ---
>
> target-i386/cpu.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index 6d008ab..9768be1 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -2588,6 +2588,16 @@ static void x86_cpu_reset(CPUState *s)
>
> env->xcr0 = 1;
>
> + /*
> + * SDM 11.11.5 requires:
> + * - IA32_MTRR_DEF_TYPE MSR.E = 0
> + * - IA32_MTRR_PHYSMASKn.V = 0
> + * All other bits are undefined. For simplification, zero it all.
> + */
> + env->mtrr_deftype = 0;
> + memset(env->mtrr_var, 0, sizeof(env->mtrr_var));
> + memset(env->mtrr_fixed, 0, sizeof(env->mtrr_fixed));
> +
> #if !defined(CONFIG_USER_ONLY)
> /* We hard-wire the BSP to the first CPU. */
> if (s->cpu_index == 0) {
>
I like this heavy-handed approach.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Ersek <lersek@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Cc: qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 3/3] x86: Clear MTRRs on vCPU reset
Date: Thu, 14 Aug 2014 23:23:49 +0200 [thread overview]
Message-ID: <53ED28E5.9040305@redhat.com> (raw)
In-Reply-To: <20140814192415.13303.34846.stgit@gimli.home>
On 08/14/14 21:24, Alex Williamson wrote:
> The SDM specifies (June 2014 Vol3 11.11.5):
>
> On a hardware reset, the P6 and more recent processors clear the
> valid flags in variable-range MTRRs and clear the E flag in the
> IA32_MTRR_DEF_TYPE MSR to disable all MTRRs. All other bits in the
> MTRRs are undefined.
>
> We currently do none of that, so whatever MTRR settings you had prior
> to reset is what you have after reset. Usually this doesn't matter
> because KVM often ignores the guest mappings and uses write-back
> anyway. However, if you have an assigned device and an IOMMU that
> allows NoSnoop for that device, KVM defers to the guest memory
> mappings which are now stale after reset. The result is that OVMF
> rebooting on such a configuration takes a full minute to LZMA
> decompress the firmware volume, a process that is nearly instant on
> the initial boot.
>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: qemu-stable@nongnu.org
> ---
>
> target-i386/cpu.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index 6d008ab..9768be1 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -2588,6 +2588,16 @@ static void x86_cpu_reset(CPUState *s)
>
> env->xcr0 = 1;
>
> + /*
> + * SDM 11.11.5 requires:
> + * - IA32_MTRR_DEF_TYPE MSR.E = 0
> + * - IA32_MTRR_PHYSMASKn.V = 0
> + * All other bits are undefined. For simplification, zero it all.
> + */
> + env->mtrr_deftype = 0;
> + memset(env->mtrr_var, 0, sizeof(env->mtrr_var));
> + memset(env->mtrr_fixed, 0, sizeof(env->mtrr_fixed));
> +
> #if !defined(CONFIG_USER_ONLY)
> /* We hard-wire the BSP to the first CPU. */
> if (s->cpu_index == 0) {
>
I like this heavy-handed approach.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
next prev parent reply other threads:[~2014-08-14 21:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-14 19:23 [PATCH v2 0/3] Sync MTRRs with KVM and disable on reset Alex Williamson
2014-08-14 19:23 ` [Qemu-devel] " Alex Williamson
2014-08-14 19:24 ` [PATCH v2 1/3] x86: Use common variable range MTRR counts Alex Williamson
2014-08-14 19:24 ` [Qemu-devel] " Alex Williamson
2014-08-14 20:47 ` Laszlo Ersek
2014-08-14 20:47 ` [Qemu-devel] " Laszlo Ersek
2014-08-14 19:24 ` [PATCH v2 2/3] x86: kvm: Add MTRR support for kvm_get|put_msrs() Alex Williamson
2014-08-14 19:24 ` [Qemu-devel] " Alex Williamson
2014-08-14 21:20 ` Laszlo Ersek
2014-08-14 21:20 ` [Qemu-devel] " Laszlo Ersek
2014-08-14 21:32 ` Alex Williamson
2014-08-14 21:32 ` [Qemu-devel] " Alex Williamson
2014-08-14 21:27 ` Laszlo Ersek
2014-08-14 21:27 ` [Qemu-devel] " Laszlo Ersek
2014-08-14 19:24 ` [PATCH v2 3/3] x86: Clear MTRRs on vCPU reset Alex Williamson
2014-08-14 19:24 ` [Qemu-devel] " Alex Williamson
2014-08-14 21:23 ` Laszlo Ersek [this message]
2014-08-14 21:23 ` Laszlo Ersek
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=53ED28E5.9040305@redhat.com \
--to=lersek@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@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.