Re: [PATCH] Add Documentation/kvm/msr.txt
On 05/26/2010 09:04 PM, Glauber Costa wrote:
This patch adds a file that documents the usage of KVM-specific
MSRs.
Looks good. A few comments:
+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK: 0x11
+
+ data: physical address of a memory area.
Which must be in guest RAM (i.e., don't point it somewhere random and
expect the hypervisor to allocate it for you).
Must be aligned to 4 bytes (we don't enforce it though).
+
+MSR_KVM_SYSTEM_TIME: 0x12
+
+ data: physical address of a memory area. This memory is expected to
+ hold a copy of the following structure:
In guest RAM. What are the alignment restrictions? I don't think we
can restrict to less than 4 bytes without breaking guests retroactively.
+
+ struct pvclock_vcpu_time_info {
+ u32 version;
+ u32 pad0;
+ u64 tsc_timestamp;
+ u64 system_time;
+ u32 tsc_to_system_mul;
+ s8tsc_shift;
+ u8flags;
+ u8pad[2];
+ } __attribute__((__packed__)); /* 32 bytes */
+
+ whose data will be filled in by the hypervisor periodically. Only one
+ write, or registration, is needed for each VCPU. The interval between
+ updates of this structure is arbitrary, and implementation-dependent.
+
+ version: guest has to check version before and after grabbing
+ time information, and check that they are both equal and even.
+ An odd version indicates an in-progress update.
+
+ tsc_timestamp: the tsc value at the current VCPU, at the time
+ of the update of this structure. Guests can subtract this value
+ from current tsc to derive a notion of elapsed time since the
+ structure update.
+
+ system_time: the current system time at the time this structure
+ was last updated. Unit is nanoseconds.
What is the baseline for system_time? Guest boot?
+
+ tsc_to_system_mul: a function of the tsc frequency. One has
+ to multiply any tsc-related quantity by this value to get
+ a value in nanoseconds, besides dividing by 2^tsc_shift
+
+ tsc_shift: cycle to nanosecond divider, as a power of two, to
+ allow for shift rights. One has to shift right any tsc-related
+ quantity by this value to get a value in nanoseconds, besides
+ multiplying by tsc_to_system_mul.
Would be good to write down the formula for calculating time here.
+
+ flags: bits in this field indicate extended capabilities
+ coordinated between the guest and the hypervisor. Availability
+ of specific flags has to be checked in 0x4001 cpuid leaf.
+ Refer to cpuid.txt for details.
Need to document bit 0 here for completeness. cpuid.txt documents how
to discover it, here we document how to use it.
+
+ Availability of this MSR must be checked via bit 0 in 0x401 cpuid
+ leaf prior to usage.
+
+ This MSR falls outside the reserved KVM range, and may be removed in the
+ future. Its usage is deprecated.
+
+MSR_KVM_WALL_CLOCK_NEW: 0x4b564d00
+
+ data and functioning: same as MSR_KVM_WALL_CLOCK. Use this instead.
+
+ Availability of this MSR must be checked via bit 3 in 0x401 cpuid
+ leaf prior to usage.
+
+MSR_KVM_SYSTEM_TIME_NEW: 0x4b564d01
+
+ data and functioning: same as MSR_KVM_SYSTEM_TIME. Use this instead.
+
+ Availability of this MSR must be checked via bit 3 in 0x401 cpuid
+ leaf prior to usage.
+
Please detail the suggested algorithm for using the msrs (new then old).
--
error compiling committee.c: too many arguments to function
--
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
[PATCH] kvm mmu: don't check PT_WRITABLE_MASK directly
Since we have is_writable_pte(), make use of it.
Signed-off-by: Gui Jianfeng
---
arch/x86/kvm/mmu.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ce4bbd3..441a5d8 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2923,7 +2923,7 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
int slot)
pt = sp->spt;
for (i = 0; i < PT64_ENT_PER_PAGE; ++i)
/* avoid RMW */
- if (pt[i] & PT_WRITABLE_MASK)
+ if (is_writable_pte(pt[i]))
pt[i] &= ~PT_WRITABLE_MASK;
}
kvm_flush_remote_tlbs(kvm);
@@ -3358,7 +3358,7 @@ void inspect_spte_has_rmap(struct kvm *kvm, u64 *sptep)
struct kvm_mmu_page *rev_sp;
gfn_t gfn;
- if (*sptep & PT_WRITABLE_MASK) {
+ if (is_writable_pte(*sptep)) {
rev_sp = page_header(__pa(sptep));
gfn = rev_sp->gfns[sptep - rev_sp->spt];
@@ -3408,7 +3408,7 @@ static void check_writable_mappings_rmap(struct kvm_vcpu
*vcpu)
if (!(ent & PT_PRESENT_MASK))
continue;
- if (!(ent & PT_WRITABLE_MASK))
+ if (!is_writable_pte(ent))
continue;
inspect_spte_has_rmap(vcpu->kvm, &pt[i]);
}
@@ -3442,7 +3442,7 @@ static void audit_write_protection(struct kvm_vcpu *vcpu)
spte = rmap_next(vcpu->kvm, rmapp, NULL);
while (spte) {
- if (*spte & PT_WRITABLE_MASK)
+ if (is_writable_pte(*spte))
printk(KERN_ERR "%s: (%s) shadow page has "
"writable mappings: gfn %lx role %x\n",
__func__, audit_msg, sp->gfn,
--
1.6.5.2
--
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
Re: [PATCH] KVM test: Add perfmon into the guest tests
On 05/25/10 05:05, Chen Cao wrote: > perfmon2 API provides access to the hardware performance counters of > modern processors. > > Dependency, > To compile the source code of the test, the following packages should > be installed, > glibc-static-2.11.1-6.x86_64 > glibc-headers-2.11.1-6.x86_64 > glibc-common-2.11.1-6.x86_64 > glibc-devel-2.11.1-6.x86_64 > glibc-2.11.1-6.x86_64 > > Note, > 1. libpfm uses the Performance Monitor Unit (PMU) on the processors, > but this unit is not provided by kvm currently, i.e. the test should > fail in kvm guests. > 2. According to the README file of perfmon-tests-0.3, 2.6.24 or higer > Linux kernel (with perfmon v2.8 or higher) is needed to run the tests. I thought perfmon2 was deprecated in favor of perf_event.c ? The only reference left for perfmon2 in the kernel is in the ia64 tree, and KVM/ia64 seems to be pretty dead these days. Cheers, Jes -- 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
[PATCH] kvm mmu: optimizations when tdp is in use
In case of using tdp, checking write protected page isn't needed and
quadrant also no need to be calculated.
Signed-off-by: Gui Jianfeng
---
arch/x86/kvm/mmu.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 0bb9f17..ce4bbd3 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -495,10 +495,13 @@ static int mapping_level(struct kvm_vcpu *vcpu, gfn_t
large_gfn)
max_level = kvm_x86_ops->get_lpage_level() < host_level ?
kvm_x86_ops->get_lpage_level() : host_level;
+ if (tdp_enabled)
+ goto done;
+
for (level = PT_DIRECTORY_LEVEL; level <= max_level; ++level)
if (has_wrprotected_page(vcpu->kvm, large_gfn, level))
break;
-
+done:
return level - 1;
}
@@ -1346,7 +1349,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
if (role.direct)
role.cr4_pae = 0;
role.access = access;
- if (vcpu->arch.mmu.root_level <= PT32_ROOT_LEVEL) {
+ if (!tdp_enabled && vcpu->arch.mmu.root_level <= PT32_ROOT_LEVEL) {
quadrant = gaddr >> (PAGE_SHIFT + (PT64_PT_BITS * level));
quadrant &= (1 << ((PT32_PT_BITS - PT64_PT_BITS) * level)) - 1;
role.quadrant = quadrant;
--
1.6.5.2
--
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
Re: [PATCH] device-assignment: don't truncate MSIX capabilities table size
On 05/26/10 14:48, Avi Kivity wrote: > On 05/26/2010 03:27 AM, Juan Quintela wrote: >> BTW, I also noticed the lack of pci_set_long() and friend functions, but >> arrived to the same conclusion that you: all the device assignment >> assumes that the world is x86_64 :) >> > > IIRC it used to work on ia64 as well. > Same endianess, unless you run HPUX on the CPU. Jes -- 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
RE: [PATCH 1/4] Fix tboot enabled macro
Wang, Shane wrote: > > Why is VTX assumed to be disabled? > tboot_enabled == 0 but (msr & > FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX) == 1 if you have VT > enabled. If you have VT enabled, VMX outside SMX is 1 always. > > Shane BTW: In hardware, VT is enabled, TXT is enabled, then outside = 1, inside = 1; VT is enabled, TXT is disabled, then outside = 1, inside = 0; VT is disabled, then outside = 0;-- 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
About upgrade KVM
Hi folks, KVM -virtualizer host - Debian 5.0 This virtual machine has been running for sometimes. IIRC the KVM was download from KVM website. Its version is quite old. $ sudo kvm | head -1 QEMU PC emulator version 0.9.1 (kvm-72), Copyright (c) 2003-2008 Fabrice Bellard $ apt-cache policy qemu-kvm qemu-kvm: Installed: (none) Candidate: 0.12.4+dfsg-1~bpo50+1 Version table: 0.12.4+dfsg-1~bpo50+1 0 1 http://www.backports.org lenny-backports/main Packages I tried to upgrade it on System -> Administration -> Synaptic Package Manager; - qemu-kvm - qemu-kvm-dbg On marking them to install following warning popup:- Mark additional required changes? To be removed kvm To be added libasyncns0 libcap1 libpulse0 - end - My questions are; 1) On deleting the old package whether it would affect the running virtual machine? 2) Is there any way to come back in case of problem? Please advise. TIA B.R. Stephen L -- 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
RE: [PATCH 1/4] Fix tboot enabled macro
Jan Kiszka wrote: > Wang, Shane wrote: >> Avi Kivity wrote: >>> On 05/26/2010 10:25 AM, Jan Kiszka wrote: This is for CONFIG_INTEL_TXT enabled? Good point but needs to be solved differently. tboot, the variable that is checked by the original header, is not exported to modules. I wonder how this worked out for you... Solution should be: hack tboot_enabled to kvm_tboot_enabled and unconditionally define that to 0 for older kernels. If tboot is actually enabled in hardware, KVM may not load but I'm unsure if it's OK to assume tboot == 1 for that case or if that will cause breakages if it's off instead - CC'ing the KVM patch author. >>> Worst case it doesn't load. I don't think it's a problem since >>> enabling tboot will be rare for older kernels. >> >> tboot is not 0 if tboot module is run before kernel. >> If "tboot is enabled in hardware" (I assume you mean if Intel TXT is >> enabled in hardware) but tboot module is not run or old kernels >> don't support tboot module, >> we still have outside_smx bit in feature msr. Why might KVM not load? > > If we have to hard-wire tboot_enabled in kvm-kmod to 0, KVM may not > test all required bits and erroneously assume VTX would be disabled. > > So I wondered what would happen if we hard-wired it to 1, pretending > that the tboot modules is loaded. Would we gain something without > loosing on some other end? If not, I would simply leave things as they > are now (i.e. always assuming tboot absence). > > Thanks, > Jan Why is VTX assumed to be disabled? tboot_enabled == 0 but (msr & FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX) == 1 if you have VT enabled. If you have VT enabled, VMX outside SMX is 1 always. Shane -- 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
