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.william...@redhat.com> > Cc: Laszlo Ersek <ler...@redhat.com> > Cc: qemu-sta...@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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
