From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDaq6-0000sw-QR for qemu-devel@nongnu.org; Thu, 16 Jun 2016 13:12:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDapz-0006Ih-L6 for qemu-devel@nongnu.org; Thu, 16 Jun 2016 13:12:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDapz-0006IW-Eg for qemu-devel@nongnu.org; Thu, 16 Jun 2016 13:12:15 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 14BD03FC03 for ; Thu, 16 Jun 2016 17:12:15 +0000 (UTC) From: "Dr. David Alan Gilbert (git)" Date: Thu, 16 Jun 2016 18:12:08 +0100 Message-Id: <1466097133-5489-1-git-send-email-dgilbert@redhat.com> Subject: [Qemu-devel] [PATCH 0/5] x86: Physical address limit patches List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, pbonzini@redhat.com, aarcange@redhat.com, ehabkost@redhat.com From: "Dr. David Alan Gilbert" QEMU sets the guests physical address bits to 40; this is wrong on most hardware, and can theoretically be detected by the guest. It also stops you using really huge multi-TB VMs. Red Hat has had a patch, that Andrea wrote, downstream for a couple of years that reads the hosts value and uses that in the guest. That's correct as far as the guest sees it, and lets you create huge VMs. The downside, is that if you've got a mix of hosts, say an i7 and a Xeon, life gets complicated in migration; prior to 2.6 it all apparently worked (although a guest that looked might spot the change). In 2.6 Paolo started checking MSR writes and they failed when the incoming MTRR mask didn't fit. This series: a) Fixes up mtrr masks so that if you're migrating between hosts of different physical address size it tries to do something sensible. b) Lets you specify the guest physical address size via a CPU property, i.e. -cpu SandyBridge,phys-bits=36 The default is to use the existing 40 bits value. c) Lets you tell qemu to use the same setting as the host, i.e. -cpu SandyBridge,phys-bits=0 Note that mixed size hosts are still not necessarily safe; a guest started on a host with a large physical address size might start using those bits and get upset when it's moved to a small host. However that was already potentially broken in existing qemu that used a magic value of 40. There's potential to add some extra guards against people doing silly stuff; e.g. stop people running VMs using 1TB of address space on a tiny host. Dave Dr. David Alan Gilbert (5): BIT_RANGE convenience macro x86: Mask mtrr mask based on CPU physical address limits x86: fill high bits of mtrr mask x86: Allow physical address bits to be set x86: Set physical address bits based on host include/hw/i386/pc.h | 5 +++++ include/qemu/bitops.h | 3 +++ target-i386/cpu.c | 36 +++++++++++++++++++++++++++++++++--- target-i386/cpu.h | 7 +++++++ target-i386/kvm.c | 38 +++++++++++++++++++++++++++++++++++--- 5 files changed, 83 insertions(+), 6 deletions(-) -- 2.7.4