Re: Windows XP x64 SP2 KVM Guest Virtio Drivers
On Mon, 2014-03-10 at 23:24 -0600, OwN-3m-All wrote: I was hoping for a virtio storage driver. I'd like to use a virtio disk rather than ide. However, it does not seem to be possible with XP x64 because such a driver does not exist? Also, the viostor driver for Server 2003 x64 does not work for XP x64. That's strange. While WXP 64-bit is not officially supported, I remember I tested W2K3 64-bit viostor driver on WXP 64-bit SP2. You said it fails with BSOD. Can you tell me the bug check code please? Cheers, Vadim. On 2/16/2014 6:05 AM, Yan Vugenfirer wrote: Hi, WinXP 64bit is a strange bird. Which driver did you tried to install: virtio-net, virtio-block or something else? Best regards, Yan. On Feb 14, 2014, at 3:37 AM, OwN-3m-All own3m...@gmail.com wrote: Hi Guys, Does a virtio KVM driver exist for Windows XP x64 SP2? If not, would it be possible to create one / adapt the Server 2003 version somehow? I tried using the Server 2003 x64 drivers (from http://www.linux-kvm.org/page/WindowsGuestDrivers), but they didn't work. The drivers would install, but then XP x64 would just blue screen and never boot up again. Hoping there's a driver! -- 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 -- 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
[Bug 67061] [BISECTED][Nested]L2 guest boot up fail(kvm on kvm).
https://bugzilla.kernel.org/show_bug.cgi?id=67061 Paolo Bonzini bonz...@gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||bonz...@gnu.org Resolution|--- |CODE_FIX --- Comment #4 from Paolo Bonzini bonz...@gnu.org --- I agree with the explanation in comment 3. -- You are receiving this mail because: You are watching the assignee of the bug. -- 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: Question about suspended virtual machine resources on a kvm hypervisor
Il 10/03/2014 21:33, William Heath ha scritto: Hi All, I am working with OnApp for a cloud solution. In order to do billing correctly, I am curious what resources are freed up when a virtual machine is suspended on a kvm hypervisor. Are cpu, ram, and disk all freed up or what is reallocated to other virtual machines etc...? A suspended VM uses no CPU. It still uses RAM, and files are still open even though no I/O should happen. Paolo -- 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: Question about suspended virtual machine resources on a kvm hypervisor
So is the CPU re-allocated to other virtual machines that need them? I take it then that RAM and disk usage are not reallocated? -Tim On Mon, Mar 10, 2014 at 9:49 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 10/03/2014 21:33, William Heath ha scritto: Hi All, I am working with OnApp for a cloud solution. In order to do billing correctly, I am curious what resources are freed up when a virtual machine is suspended on a kvm hypervisor. Are cpu, ram, and disk all freed up or what is reallocated to other virtual machines etc...? A suspended VM uses no CPU. It still uses RAM, and files are still open even though no I/O should happen. Paolo -- 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: Question about suspended virtual machine resources on a kvm hypervisor
Il 11/03/2014 09:10, William Heath ha scritto: So is the CPU re-allocated to other virtual machines that need them? In KVM, virtual CPUs are just threads; if a thread does not want to run, the Linux scheduler does not give it any CPU. If the virtual machine monitor you're using is QEMU, the virtual CPU threads of a suspended VM will be waiting on a condition variable until the VM is resumed. I take it then that RAM and disk usage are not reallocated? No. But RAM can be swapped out, for both suspended and running VMs. Paolo -- 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
How to apply for Google Summer of Code
Dear students, Applications for Google Summer of Code opened on Monday, 10th of March and will continue until Friday, 21st of March. The common question we are getting is How do I apply? :). Here is the application checklist: 1. Choose a project idea and get in touch with the mentor. The project ideas and mentors are listed here: http://qemu-project.org/Google_Summer_of_Code_2014 2. Put together a rough project plan (design + schedule) that breaks down the solution you are proposing. You can email a draft to your mentor for feedback or ask for clarifications about the project idea. 3. Go to http://google-melange.com/, log in and submit your application form for QEMU. The application template is here: https://www.google-melange.com/gsoc/org2/google/gsoc2014/qemu Remember the deadline for applications Friday, 21st of March. You can reach mentors on #qemu-gsoc on irc.oftc.net or via email. Stefan -- 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: Enhancement for PLE handler in KVM
Il 11/03/2014 15:12, Li, Bin (Bin) ha scritto: - For the guest OS which doesn't use the hyper call interface, there will be no impact to them. The proposed ple handler enhancement has structured to use the hint only if the guest OS using the new proposed hyper call. And it is per VM only. The VM which running general guest OS ( linux / windows) will still use the today's ple hanlder to boost vCPUs. While the other VM, which using new hyper call indicating the lock get and release, the ple handler for this VM will boost the lock holder only. No, if there is a jitter problem we want to fix it for all guest OSes, not just for those that use a big kernel lock. - The main advantage of this proposal is that, it reliably solves the problem. Any other option which could prevent the problem from happening thoroughly? You haven't proved this yet. My impression is that, on a non-overcommitted system, your proposal is exactly the same as a fair lock with paravirtualization (except more expensive for the lock taker, even when there is no contention). I think I understand why, on an overcommitted system, you could still have jitter with pv ticketlocks and not with your infrastructure. The reason is that pv ticketlocks do not attempt to donate the quantum to the lock holder. Is there anything we can do to fix *this*? I would accept a new hypercall KVM_HC_HALT_AND_YIELD_TO_CPU that takes an APIC id, donates the quantum to that CPU, and puts the originating CPU in halted state. If this is not enough, it's up to you to disprove this and explain why the two have different jitter characteristics. To do this, you need to implement paravirtualized fair locks in your kernel (and possibly halt-and-yield), measure the difference in jitter, *trace what's happening on the host to characterize the benefits of your solution*, etc. - Using hyper call to mark lock status does increase cpu consumption. But the impact to the system is very much depending on lock usage character in the guest OS. For the guest OS, which typically doing less frequent kernel lock, but longer operation for each kernel lock, the overall impact from hype call could *NOT *be an issue. Again, if there is a jitter problem we want to fix it for all locks, like we did for pv ticketlocks. Paolo -- 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: SVM: fix cr8 intercept window
We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.
Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.
Cc: sta...@vger.kernel.org
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/svm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 64d9bb9..f676c18 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3003,10 +3003,8 @@ static int cr8_write_interception(struct vcpu_svm *svm)
u8 cr8_prev = kvm_get_cr8(svm-vcpu);
/* instruction emulation calls kvm_set_cr8() */
r = cr_interception(svm);
- if (irqchip_in_kernel(svm-vcpu.kvm)) {
- clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+ if (irqchip_in_kernel(svm-vcpu.kvm))
return r;
- }
if (cr8_prev = kvm_get_cr8(svm-vcpu))
return r;
kvm_run-exit_reason = KVM_EXIT_SET_TPR;
@@ -3568,6 +3566,8 @@ static void update_cr8_intercept(struct kvm_vcpu *vcpu,
int tpr, int irr)
if (is_guest_mode(vcpu) (vcpu-arch.hflags HF_VINTR_MASK))
return;
+ clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+
if (irr == -1)
return;
--
1.8.5.3
--
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
[no subject]
unsubscribe kvm -- 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: Linux 3.13: BUG: soft lockup - CPU#1 stuck for 22s! [qemu-kvm:2653]
Hi all, Over the weekend, Linux 3.13.6 was installed on my machine. When I started gnome-boxes on Monday morning, my VM halted during boot. Only a portion of the VESA BIOS init output was displayed on-screen before the halt. Backtraces occasionally appeared in dmesg (http://pastebin.com/uUiNLmJ6). Some other programs were prevented from performing some tasks while the VM was running. While investigating, I was directed to an earlier KVM bug report (https://lkml.org/lkml/2014/2/11/487). I downgraded to Linux 3.12.9 and rebooted, and now my VM is starting. Unfortunately, I'm very new to Linux, so I'm not sure what the next steps would be. Host system info: Arch Linux (current with updates), 64-bit with UEFI boot Intel Haswell CPU (i5-4670K) 32GB RAM Intel 240GB SSD GNOME 3.10.x gnome-boxes 3.10.x Guest OS info: Windows 7, 64-bit 2GB of RAM allocated Beyond setting disk and RAM sizes when initializing the VM, I have trusted the gnome-boxes defaults and have not altered the machine configuration in any way. Let me know if there is any additional logging that would be useful. I can certainly re-install the problematic kernel outside of business hours. -- 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: SVM: fix cr8 intercept window
On Tue, Mar 11, 2014 at 07:11:18PM +0100, Radim Krčmář wrote:
We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.
Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.
Cc: sta...@vger.kernel.org
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/svm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 64d9bb9..f676c18 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3003,10 +3003,8 @@ static int cr8_write_interception(struct vcpu_svm *svm)
u8 cr8_prev = kvm_get_cr8(svm-vcpu);
/* instruction emulation calls kvm_set_cr8() */
r = cr_interception(svm);
- if (irqchip_in_kernel(svm-vcpu.kvm)) {
- clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+ if (irqchip_in_kernel(svm-vcpu.kvm))
return r;
- }
if (cr8_prev = kvm_get_cr8(svm-vcpu))
return r;
kvm_run-exit_reason = KVM_EXIT_SET_TPR;
@@ -3568,6 +3566,8 @@ static void update_cr8_intercept(struct kvm_vcpu *vcpu,
int tpr, int irr)
if (is_guest_mode(vcpu) (vcpu-arch.hflags HF_VINTR_MASK))
return;
+ clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+
if (irr == -1)
return;
Shouldnt IRR be injected if TPR IRR ? (via KVM_REQ_EVENT).
1) IRR has interrupt 10.
2) TPR now 9 due to CR8 write.
3) 10 should be injected.
Also not clearing the intercept can cause continuous CR8 writes to
exit until KVM_REQ_EVENT ?
--
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
