[PATCH] kvm: minor change in kvm_iommu_put_pages
Moving the test right after domain is assigned.
Signed-off-by: Fred R. Oxhey
---
virt/kvm/iommu.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index e9fff98..8d2e1dc 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -287,13 +287,13 @@ static void kvm_iommu_put_pages(struct kvm *kvm,
u64 phys;
domain = kvm->arch.iommu_domain;
- end_gfn = base_gfn + npages;
- gfn = base_gfn;
-
/* check if iommu exists and in use */
if (!domain)
return;
+ end_gfn = base_gfn + npages;
+ gfn = base_gfn;
+
while (gfn < end_gfn) {
unsigned long unmap_pages;
size_t size;
--
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 v5] kvm/fpu: Enable fully eager restore kvm FPU
Romove fpu lazy restore logic, using eager restore totally.
v5 changes from v4:
- remove lazy fpu restore totally, fpu eager restore does not have performance
regression and simple the code.
v4 changes from v3:
- Wrap up some confused code with a clear function lazy_fpu_allowed()
- Update fpu while update cr4 too.
v3 changes from v2:
- Make fpu active explicitly while guest xsave is enabling and non-lazy xstate
bit exist.
v2 changes from v1:
- Expand KVM_XSTATE_LAZY to 64 bits before negating it.
Signed-off-by: Xudong Hao
---
arch/x86/kvm/vmx.c | 9 ++---
arch/x86/kvm/x86.c | 8 +---
include/linux/kvm_host.h | 1 -
3 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6599e45..c1fd2e1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1197,7 +1197,7 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
u32 eb;
eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
-(1u << NM_VECTOR) | (1u << DB_VECTOR);
+(1u << DB_VECTOR);
if ((vcpu->guest_debug &
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
@@ -1206,8 +1206,6 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
eb = ~0;
if (enable_ept)
eb &= ~(1u << PF_VECTOR); /* bypass_guest_pf = 0 */
- if (vcpu->fpu_active)
- eb &= ~(1u << NM_VECTOR);
/* When we are running a nested L2 guest and L1 specified for it a
* certain exception bitmap, we must trap the same exceptions and pass
@@ -3022,9 +3020,6 @@ static void vmx_set_cr0(struct kvm_vcpu *vcpu, unsigned
long cr0)
if (enable_ept)
ept_update_paging_mode_cr0(&hw_cr0, cr0, vcpu);
- if (!vcpu->fpu_active)
- hw_cr0 |= X86_CR0_TS | X86_CR0_MP;
-
vmcs_writel(CR0_READ_SHADOW, cr0);
vmcs_writel(GUEST_CR0, hw_cr0);
vcpu->arch.cr0 = cr0;
@@ -7119,7 +7114,7 @@ void load_vmcs12_host_state(struct kvm_vcpu *vcpu, struct
vmcs12 *vmcs12)
* but we also need to update cr0_guest_host_mask and exception_bitmap.
*/
update_exception_bitmap(vcpu);
- vcpu->arch.cr0_guest_owned_bits = (vcpu->fpu_active ? X86_CR0_TS : 0);
+ vcpu->arch.cr0_guest_owned_bits = X86_CR0_TS;
vmcs_writel(CR0_GUEST_HOST_MASK, ~vcpu->arch.cr0_guest_owned_bits);
/*
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 49fa1f0..cd5aafe 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5275,10 +5275,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
r = 0;
goto out;
}
- if (kvm_check_request(KVM_REQ_DEACTIVATE_FPU, vcpu)) {
- vcpu->fpu_active = 0;
- kvm_x86_ops->fpu_deactivate(vcpu);
- }
if (kvm_check_request(KVM_REQ_APF_HALT, vcpu)) {
/* Page is swapped out. Do synthetic halt */
vcpu->arch.apf.halted = true;
@@ -5320,8 +5316,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
preempt_disable();
kvm_x86_ops->prepare_guest_switch(vcpu);
- if (vcpu->fpu_active)
- kvm_load_guest_fpu(vcpu);
+ kvm_load_guest_fpu(vcpu);
kvm_load_guest_xcr0(vcpu);
vcpu->mode = IN_GUEST_MODE;
@@ -6007,7 +6002,6 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
fpu_save_init(&vcpu->arch.guest_fpu);
__kernel_fpu_end();
++vcpu->stat.fpu_reload;
- kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
trace_kvm_fpu(0);
}
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 99a4762..0b33163 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -122,7 +122,6 @@ static inline bool is_error_page(struct page *page)
#define KVM_REQ_MMU_SYNC 7
#define KVM_REQ_CLOCK_UPDATE 8
#define KVM_REQ_KICK 9
-#define KVM_REQ_DEACTIVATE_FPU10
#define KVM_REQ_EVENT 11
#define KVM_REQ_APF_HALT 12
#define KVM_REQ_STEAL_UPDATE 13
--
1.7.12.1
--
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: 3.7-rc2 build failure on s390x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/6/12 8:02 AM, Cornelia Huck wrote: > On Mon, 05 Nov 2012 11:13:42 -0500 Jeff Mahoney > wrote: > >> >> It's a different build issue with -rc3 (and now -rc4). >> >> linux-3.7-rc4/include/linux/kvm_para.h:9:2: error: implicit >> declaration of function 'kvm_arch_para_features' >> [-Werror=implicit-function-declaration] >> >> Config attached. >> >> -Jeff >> > > Plain vanilla 3.7-rc4 builds fine for me with your config and make > oldconfig. But from your config I see that you seem to have some > patches on top. So my guess would be that you should verify these > patches first :) Yep. Someone on our end added a patch to fix the original issue that was left in after it was fixed differently upstream. Sorry for the noise. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQmWL3AAoJEB57S2MheeWyETEQALv9y0G8PVpIc/152irJd663 RWAYEjTC3PNeRf28hd85l03c+z0qH/MqZXNbc4NdoXhunuRbrARCpXl52eyxQmLs dM6fvNpJoRRHPCS3j96W7s+EPSXahxJBV6RED+iN9hOntgRG9qiW5q+WLPik5Lpf FL4j4/qUQZh0Zyqr3L9X7FnTPxITUVJiilaHmVymvUFQBhlVdSVsPpsSrJvaoNrz cav3ThoW+NHAfyDqQGRJJy4f3hL6zqkQJGgCiH2V7/DaK8LQkxV7L6mWnapH4Xnn CDdL1x3e4htRREdlQAaN/RqHpvvWGlamLMahA0dY47TbN912oIxSBkfhn09XGxBe ODcQgl7UUfknhs5M4nwbiTkCZGPiHeRg8FRAg147bmiy2eCwp7pYgOpgQraKtrMO pfZatfudMXQyC3T/AWsrDXMr4vdYX7WLW78uy3wqjltYSUz5L+5zpqKCAk8kWLm/ G21g4arNV7FWFq/hzl2ceqFPTzFVIsOa6xyh9w5TdHoekzUqsoyvyg6s/vL88XxZ Jgic3dJ7n25vEAHZR0ruO8CsQy537q1Y+pheCjox0fIfAREQkGNPKABLYonjl6xZ m21x90S0lMpyhD+6+sMdYN6d3K8JmGcYaURpBAvAyDz442dRsv7kHcxdCAs+hBEe G2+ewz3gnJvvNXUM8aM4 =Zrok -END PGP SIGNATURE- -- 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] CVE-2012-4461 invalid opcode oops on SET_SREGS with OSXSAVE bit set
On hosts without the XSAVE support unprivileged local user can trigger
oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest
cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN
ioctl.
invalid opcode: [#2] SMP
Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables
...
Pid: 24935, comm: zoog_kvm_monito Tainted: G D 3.2.0-3-686-pae
EIP: 0060:[] EFLAGS: 00210246 CPU: 0
EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm]
EAX: 0001 EBX: 000f387e ECX: EDX:
ESI: EDI: EBP: ef5a0060 ESP: d7c63e70
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0
task.ti=d7c62000)
Stack:
0001 f70a1200 f8b940a9 ef5a0060 00200202 f8769009
ef5a0060 000f387e eda5c020 8722f9c8 00015bae ed84a0c0 ed84a0c0
c12bf02d ae80 ef7f8740 fffb f359b740 ef5a0060 f8b85dc1 ae80
Call Trace:
[] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm]
...
[] ? syscall_call+0x7/0xb
Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74
1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01
d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89
EIP: [] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP
0068:d7c63e70
QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID
and then sets them later. So guest's X86_FEATURE_XSAVE should be masked
out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with
X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with
X86_FEATURE_XSAVE even on hosts that do not support it, might be
susceptible to this attack from inside the guest as well.
Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support.
Signed-off-by: Petr Matousek
---
arch/x86/kvm/cpuid.h |3 +++
arch/x86/kvm/x86.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index a10e460..58fc514 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -24,6 +24,9 @@ static inline bool guest_cpuid_has_xsave(struct kvm_vcpu
*vcpu)
{
struct kvm_cpuid_entry2 *best;
+ if (!static_cpu_has(X86_FEATURE_XSAVE))
+ return 0;
+
best = kvm_find_cpuid_entry(vcpu, 1, 0);
return best && (best->ecx & bit(X86_FEATURE_XSAVE));
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 52ae8b5..1826ed2 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5783,6 +5783,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
int pending_vec, max_bits, idx;
struct desc_ptr dt;
+ if (!guest_cpuid_has_xsave(vcpu) && (sregs->cr4 & X86_CR4_OSXSAVE))
+ return -EINVAL;
+
dt.size = sregs->idt.limit;
dt.address = sregs->idt.base;
kvm_x86_ops->set_idt(vcpu, &dt);
--
1.7.4.4
--
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: 1.1.1 -> 1.1.2 migrate /managedsave issue
Doug Goldstein wrote: > On Sun, Nov 4, 2012 at 3:51 PM, Anthony Liguori wrote: >>> >>> Seems reasonable. Doug, please verify to see if it's the same issue or >>> another one. >>> >>> Juan, how can we fix this? It's clear that the option ROM size has to >>> be fixed and not change whenever the blob is updated. This will fix it >>> for future releases. But what to do about the ones in the field? >> >> This is not a problem upstream because we don't alter the ROMs. If we >> did, we would keep the old ROMs around and set the romfile property in >> the compatible machine. >> >> This is what distros that are shipping ROMs outside of QEMU ought to >> do. It's a bug to unconditionally change the ROMs (in a guest visible >> way) without adding compatibility support. >> >> Regards, >> >> Anthony Liguori >> > > Anthony, > > Gerd updated seabios on August 7th and before that on April 17. The > default VGA ROM size also changed in recent releases. There are no old > versions of the ROMs included once these updates are performed so a > user building a new version from source will hit this problem. Juan > Quintela even mentioned that he has been bit by this issue and had to > use gdb to track it down as did Philipp that responded earlier in the > thread. The patch is a simple fprintf() which would have saved at > least 3 users the effort of tracking down an issue with gdb. So I urge > you to reconsider. I hit this problem. But it was a bug, the problem was to detect it. The problem was doing migration to an old version, we now "round" the RAM amount to a multiple of 8k. If your old ram memory was mulitple of 4k, you get this prolbem with migration. And it only prints "migration failed". Printing a message telling that: memory size of %foo is %d and expected %d would have make error trivial to found. Later, Juan. PD. Problem was really a bit more complex than this, this is a simplification. -- 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: 3.7-rc2 build failure on s390x
On Mon, 05 Nov 2012 11:13:42 -0500 Jeff Mahoney wrote: > > It's a different build issue with -rc3 (and now -rc4). > > linux-3.7-rc4/include/linux/kvm_para.h:9:2: error: implicit declaration of > function 'kvm_arch_para_features' [-Werror=implicit-function-declaration] > > Config attached. > > -Jeff > Plain vanilla 3.7-rc4 builds fine for me with your config and make oldconfig. But from your config I see that you seem to have some patches on top. So my guess would be that you should verify these patches first :) -- 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: I/O errors in guest OS after repeated migration
Am Montag, 29. Oktober 2012, 12:29:01 schrieb Stefan Hajnoczi:
> On Fri, Oct 19, 2012 at 2:55 PM, Guido Winkelmann
> wrote:
> > Am Donnerstag, 18. Oktober 2012, 18:05:39 schrieb Avi Kivity:
> >> On 10/18/2012 05:50 PM, Guido Winkelmann wrote:
> >> > Am Mittwoch, 17. Oktober 2012, 13:25:45 schrieb Brian Jackson:
> >> >>
> >> >> What about newer versions of qemu/kvm? But of course if those work,
> >> >> your
> >> >> next task is going to be git bisect it or file a bug with your distro
> >> >> that
> >> >> is using an ancient version of qemu/kvm.
> >> >
> >> > I've just upgraded both hosts to qemu-kvm 1.2.0
> >> > (qemu-1.2.0-14.fc17.x86_64,
> >> > built from spec files under
> >> > http://pkgs.fedoraproject.org/cgit/qemu.git/).
> >> >
> >> > The bug is still there.
> >>
> >> If you let the guest go idle (no I/O), then migrate it, then restart the
> >> I/O, do the errors show?
> >
> > Just tested - yes, they do.
>
> The -EIO error does not really reveal why there is a problem. You can
> use SystemTap probes in QEMU to find out more about the nature of the
> error.
>
> # stap -e 'probe qemu.kvm.bdrv_*, qemu.kvm.virtio_blk_*,
> qemu.kvm.paio_* { printf("%s(%s)\n", probefunc(), $$parms) }' -x
> $PID_OF_QEMU
This does not work for me. When I try running this, I'm getting many pages of
errors like this:
==
# stap -e 'probe qemu.kvm.bdrv_*, qemu.kvm.virtio_blk_*, qemu.kvm.paio_* {
printf("%s(%s)\n", probefunc(), $$parms) }' -x 1623
parse error: expected statement
saw: keyword at /usr/share/systemtap/tapset/qemu-alpha.stp:1455:3
source: function = $arg3;
^
parse error: expected identifier
saw: operator '=' at /usr/share/systemtap/tapset/qemu-
alpha.stp:1455:12
source: function = $arg3;
^
2 parse errors.
==
Unfortunately, I don't know the first thing about systemtap, so I don't really
know what's happening here...
Guido
--
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 v3 00/35] postcopy live migration
Hi, I didn't have time yet to review in detail your patches, but I have one general comment about the interface to activate postcopy. As postcopy needs to be supported both by source and destination Qemu, for those kind of features we have migration capabilities interface, you can look at the XBZRLE patch series for more details. So in order to activate postcopy the user will need to do: "migrate_set_capabilites postcopy on" on source and destination Qemu before starting the migration process. Regards, Orit On 10/30/2012 10:32 AM, Isaku Yamahata wrote: > This is the v3 patch series of postcopy migration. > > The trees is available at > git://github.com/yamahata/qemu.git qemu-postcopy-oct-30-2012 > git://github.com/yamahata/linux-umem.git linux-umem-oct-29-2012 > > Major changes v2 -> v3: > - implemented pre+post optimization > - auto detection of postcopy by incoming side > - using threads on destination instead of fork > - using blocking io instead of select + non-blocking io loop > - less memory overhead > - various improvement and code simplification > - kernel module name change umem -> uvmem to avoid name conflict. > > Patches organization: > 1-2: trivial fixes > 3-5: prepartion for threading. cherry-picked from migration tree > 6-18: refactoring existing code and preparation > 19-25: implement postcopy live migration itself (essential part) > 26-35: optimization/heuristic for postcopy > > Usage > = > You need load uvmem character device on the host before starting migration. > Postcopy can be used for tcg and kvm accelarator. The implementation depend > on only linux uvmem character device. But the driver dependent code is split > into a file. > I tested only host page size == guest page size case, but the implementation > allows host page size != guest page size case. > > The following options are added with this patch series. > - incoming part > use -incoming as usual. Postcopy is automatically detected. > example: > qemu -incoming tcp:0: -monitor stdio -machine accel=kvm > > - outging part > options for migrate command > migrate [-p [-n] [-m]] URI > [ [ []]] > > Newly added options/arguments > -p: indicate postcopy migration > -n: disable background transferring pages: This is for benchmark/debugging > -m: move background transfer of postcopy mode > : The number of precopy RAM scan before postcopy. >default 0 (0 means no precopy) > : The number of forward pages which is sent with on-demand > : The number of backward pages which is sent with >on-demand > > example: > migrate -p -n tcp:: > migrate -p -n -m tcp:: 42 42 0 > > > TODO > > - benchmark/evaluation > - improve/optimization > At the moment at least what I'm aware of is > - pre+post case > On desitnation side reading dirty bitmap would cause long latency. > create thread for that. > - consider on FUSE/CUSE possibility > > basic postcopy work flow > > qemu on the destination > | > V > open(/dev/uvmem) > | > V > UVMEM_INIT > | > V > Here we have two file descriptors to > umem device and shmem file > | > | umem threads > | on the destination > | > Vcreate pipe to communicate > crete threads, > | | > V mmap(shmem file) > mmap(uvmem device) for guest RAM close(shmem file) > | | > | | > V | > wait for ready from daemon| | > | Here the daemon takes over > send okpipe---> the owner of the socket > | to the source > V | > entering post copy stage | > start guest execution| > | | > V V > access guest RAM read() to get faulted pages > | | > V V > page fault -->page offset is returned > block| > V >
KVM call agenda 2012-11-06
Hi As almost everybody is in Barcelona for KVMForum/LinuxCon, we will not have a call this week. Later, Juan. -- 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
