qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 2/3] x86: kvm: Add MTRR support for kvm_get|put_msrs()
Date: Thu, 14 Aug 2014 23:27:11 +0200	[thread overview]
Message-ID: <53ED29AF.60705@redhat.com> (raw)
In-Reply-To: <20140814192409.13303.58779.stgit@gimli.home>

On 08/14/14 21:24, Alex Williamson wrote:
> The MTRR state in KVM currently runs completely independent of the
> QEMU state in CPUX86State.mtrr_*.  This means that on migration, the
> target loses MTRR state from the source.  Generally that's ok though
> because KVM ignores it and maps everything as write-back anyway.  The
> exception to this rule is when we have an assigned device and an IOMMU
> that doesn't promote NoSnoop transactions from that device to be cache
> coherent.  In that case KVM trusts the guest mapping of memory as
> configured in the MTRR.
> 
> This patch updates kvm_get|put_msrs() so that we retrieve the actual
> vCPU MTRR settings and therefore keep CPUX86State synchronized for
> migration.  kvm_put_msrs() is also used on vCPU reset and therefore
> allows future modificaitons of MTRR state at reset to be realized.
> 
> Note that the entries array used by both functions was already
> slightly undersized for holding every possible MSR, so this patch
> increases it beyond the 28 new entries necessary for MTRR state.
> 
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: qemu-stable@nongnu.org
> ---
> 
>  target-i386/cpu.h |    2 +
>  target-i386/kvm.c |  101 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 101 insertions(+), 2 deletions(-)

Another (positive) remark I wanted to add: if we migrate from an
MTRR-capable KVM host that lacks these patches, to an MTRR-capable KVM
host that has these patches, then the migration stream will simply
contain zeros (because the patch-less source never fetched those from
the source-side KVM), so when we send those zeros to the target KVM, we
won't regress (because those zeroes should match the "initial KVM MTRR
state" that the target comes up in anyway).

If we migrate from patchful to patchless (ie. reverse direction), then
we lose MTRR state, which is the current status quo; not bad.

Thanks
Laszlo

  parent reply	other threads:[~2014-08-14 21:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-14 19:23 [Qemu-devel] [PATCH v2 0/3] Sync MTRRs with KVM and disable on reset Alex Williamson
2014-08-14 19:24 ` [Qemu-devel] [PATCH v2 1/3] x86: Use common variable range MTRR counts Alex Williamson
2014-08-14 20:47   ` Laszlo Ersek
2014-08-14 19:24 ` [Qemu-devel] [PATCH v2 2/3] x86: kvm: Add MTRR support for kvm_get|put_msrs() Alex Williamson
2014-08-14 21:20   ` Laszlo Ersek
2014-08-14 21:32     ` Alex Williamson
2014-08-14 21:27   ` Laszlo Ersek [this message]
2014-08-14 19:24 ` [Qemu-devel] [PATCH v2 3/3] x86: Clear MTRRs on vCPU reset Alex Williamson
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=53ED29AF.60705@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 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).