[COMMIT] [WIN-GUEST_DRIVERS] Add IP checksum related missing code from the NDIS 5 driver. Already was implemented in NDIS 6 driver.
repository: C:/dev/kvm-guest-drivers-windows
branch: master
commit 43bc20276c98dc155ed3cfc0ba0c716ae8a8e574
Author: Yan Vugenfirer yvuge...@redhat.com
Date: Sun Nov 15 18:30:05 2009 +0200
[WIN-GUEST_DRIVERS] Add IP checksum related missing code from the NDIS 5
driver.
Already was implemented in NDIS 6 driver.
Signed-off-by: Yan Vugenfirer yvuge...@redhat.com
diff --git a/NetKVM/wxp/ParaNdis5-Impl.c b/NetKVM/wxp/ParaNdis5-Impl.c
index 9abbb98..0808811 100644
--- a/NetKVM/wxp/ParaNdis5-Impl.c
+++ b/NetKVM/wxp/ParaNdis5-Impl.c
@@ -86,6 +86,13 @@ NDIS_HANDLE ParaNdis_OpenNICConfiguration(PARANDIS_ADAPTER
*pContext)
return cfg;
}
+void ParaNdis_RestoreDeviceConfigurationAfterReset(
+ PARANDIS_ADAPTER *pContext)
+{
+
+}
+
+
/**
Indicates connect/disconnect events
Parameters:
@@ -724,12 +731,14 @@ tMapperResult ParaNdis_PacketMapper(
tTcpIpPacketParsingResult packetReview;
ULONG dummyTransferSize = 0;
ULONG saveBuffers = res.nBuffersMapped;
+ ULONG flags = pcrIpChecksum | pcrTcpChecksum |
pcrFixPHChecksum;
PVOID pIpHeader = RtlOffsetToPointer(pBuffer,
pContext-Offload.ipHeaderOffset);
res.nBuffersMapped = 0;
+ if (pContext-bFixIPChecksum) flags |=
pcrFixIPChecksum;
packetReview = ParaNdis_CheckSumVerify(
pIpHeader,
lengthGet -
pContext-Offload.ipHeaderOffset,
- pcrIpChecksum | pcrTcpChecksum |
pcrFixIPChecksum | pcrFixPHChecksum,
+ flags,
__FUNCTION__);
/* uncomment to verify */
/*
diff --git a/NetKVM/wxp/netkvm.inf b/NetKVM/wxp/netkvm.inf
index 5b0d13f..7bdd8fe 100644
--- a/NetKVM/wxp/netkvm.inf
+++ b/NetKVM/wxp/netkvm.inf
@@ -149,6 +149,11 @@ HKR, Ndi\Params\IPPacketsCheck,type,
0, enum
HKR, Ndi\Params\IPPacketsCheck\enum,1, 0,
%Enable%
HKR, Ndi\Params\IPPacketsCheck\enum,0, 0,
%Disable%
+HKR, Ndi\Params\IPChecksumFix, ParamDesc, 0,
%IPChecksumFix%
+HKR, Ndi\Params\IPChecksumFix, Default,0,
1
+HKR, Ndi\Params\IPChecksumFix, type, 0,
enum
+HKR, Ndi\Params\IPChecksumFix\enum,1,0,
%Enable%
+HKR, Ndi\Params\IPChecksumFix\enum,0,0,
%Disable%
HKR, Ndi\params\DebugLevel,ParamDesc, 0,
%DebugLevel%
HKR, Ndi\params\DebugLevel,type, 0, int
@@ -263,6 +268,7 @@ Offload.TxTCP = Offload Tx TCP checksum
OffLoad.TxUDP = Offload Tx UDP checksum
Offload.TxLSO = Offload Tx LSO
HwOffload = Hardware checksumming
+IPChecksumFix = Fix IP checksum on LSO
IPPacketsCheck = Analyze IP packets
PriorityVlanTag = Priority and VLAN tagging
PriorityOnly = Priority
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: virtio disk slower than IDE?
On 11/14/2009 04:23 PM, Gordan Bobic wrote: I just tried paravirtualized virtio block devices, and my tests show that they are approximately 30% slower than emulated IDE devices. I'm guessing this isn't normal. Is this a known issue or am I likely to have mosconfigured something? I'm using 64-bit RHEL/CentOS 5 (both host and guest). Please try to change the io scheduler on the host to io scheduler, it should boost your performance back. Thanks. Gordan -- 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
buildbot failure in qemu-kvm on default_i386_debian_5_0
The Buildbot has detected a new failure of default_i386_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_debian_5_0/builds/154 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Avi Kivity a...@redhat.com BUILD FAILED: failed git sincerely, -The Buildbot -- 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: [RFC] KVM Fault Tolerance: Kemari for KVM
On 11/09/2009 05:53 AM, Fernando Luis Vázquez Cao wrote: Kemari runs paired virtual machines in an active-passive configuration and achieves whole-system replication by continuously copying the state of the system (dirty pages and the state of the virtual devices) from the active node to the passive node. An interesting implication of this is that during normal operation only the active node is actually executing code. Can you characterize the performance impact for various workloads? I assume you are running continuously in log-dirty mode. Doesn't this make memory intensive workloads suffer? The synchronization process can be broken down as follows: - Event tapping: On KVM all I/O generates a VMEXIT that is synchronously handled by the Linux kernel monitor i.e. KVM (it is worth noting that this applies to virtio devices too, because they use MMIO and PIO just like a regular PCI device). Some I/O (virtio-based) is asynchronous, but you still have well-known tap points within qemu. - Notification to qemu: Taking a page from live migration's playbook, the synchronization process is user-space driven, which means that qemu needs to be woken up at each synchronization point. That is already the case for qemu-emulated devices, but we also have in-kernel emulators. To compound the problem, even for user-space emulated devices accesses to coalesced MMIO areas can not be detected. As a consequence we need a mechanism to communicate KVM-handled events to qemu. Do you mean the ioapic, pic, and lapic? Perhaps its best to start with those in userspace (-no-kvm-irqchip). Why is access to those chips considered a synchronization point? - Virtual machine synchronization: All the dirty pages since the last synchronization point and the state of the virtual devices is sent to the fallback node from the user-space qemu process. For this the existing savevm infrastructure and KVM's dirty page tracking capabilities can be reused. Regarding in-kernel devices, with the likely advent of in-kernel virtio backends we need a generic way to access their state from user-space, for which, again, the kvm_run share memory area could be used. I wonder if you can pipeline dirty memory synchronization. That is, write-protect those pages that are dirty, start copying them to the other side, and continue execution, copying memory if the guest faults it again. How many pages do you copy per synchronization point for reasonably difficult workloads? -- 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
Re: virtio disk slower than IDE?
Dor Laor wrote: On 11/14/2009 04:23 PM, Gordan Bobic wrote: I just tried paravirtualized virtio block devices, and my tests show that they are approximately 30% slower than emulated IDE devices. I'm guessing this isn't normal. Is this a known issue or am I likely to have mosconfigured something? I'm using 64-bit RHEL/CentOS 5 (both host and guest). Please try to change the io scheduler on the host to io scheduler, it should boost your performance back. I presume you mean the deadline io scheduler. I tried that (kernel parameter elevator=deadline) and it made no measurable difference compared to the cfq scheduler. Gordan -- 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
Virtualization Performance: Intel vs. AMD
Hi, I am currently in the process of setting up the configuration for some new workstations. I don't yet know if I'll use an Intel or an AMD plattform. Now my question is: Are there any important differences in terms of virtualization performance and/or features between the current Intel/AMD CPUs (e.g. Core i7 Lynnfield and Phenom II X4 Deneb)? Best regards, Andreas -- 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/2] KVM: x86: handle double and triple faults for every exception
Another micro difference is this:
@@ -184,24 +196,6 @@ void kvm_inject_page_fault(struct kvm_vc
{
++vcpu-stat.pf_guest;
- if (vcpu-arch.exception.pending) {
- switch(vcpu-arch.exception.nr) {
- case DF_VECTOR:
- /* triple fault - shutdown */
- set_bit(KVM_REQ_TRIPLE_FAULT,vcpu-requests);
- return;
- case PF_VECTOR:
- vcpu-arch.exception.nr = DF_VECTOR;
- vcpu-arch.exception.error_code = 0;
- return;
- default:
- /* replace previous exception with a new one in a hope
- that instruction re-execution will regenerate lost
- exception */
- vcpu-arch.exception.pending = false;
- break;
- }
- }
vcpu-arch.cr2 = addr;
kvm_queue_exception_e(vcpu, PF_VECTOR, error_code);
}
So far cr2 was not touched on DF, now it is.
Yep. The PF was overwritten with DF, which means the cr2 value will not
be interpreted by the guest?
The note under interrupt 14 documentation in 5.15 indicates that cr2 is
updated when the page fault is detected, not delivered, so it is correct
to update cr2 immediately.
--
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
Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception
On 11/12/2009 02:26 PM, Gleb Natapov wrote:
- if (vcpu-arch.exception.pending) {
- switch(vcpu-arch.exception.nr) {
- case DF_VECTOR:
- /* triple fault - shutdown */
- set_bit(KVM_REQ_TRIPLE_FAULT,vcpu-requests);
- return;
- case PF_VECTOR:
- vcpu-arch.exception.nr = DF_VECTOR;
- vcpu-arch.exception.error_code = 0;
- return;
- default:
- /* replace previous exception with a new one in a hope
- that instruction re-execution will regenerate lost
- exception */
- vcpu-arch.exception.pending = false;
- break;
When exceptions are handled serially previous exception have to be
replaced by new one. Think about #PF during #DE. #PF should be handled first
before #DE can proceed.
replacing exceptions is dangerous in the case of debug exceptions and
machine checks, since restarting execution won't recover them.
--
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
Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception
On Sun, Nov 15, 2009 at 02:41:58PM +0200, Avi Kivity wrote:
On 11/12/2009 02:26 PM, Gleb Natapov wrote:
- if (vcpu-arch.exception.pending) {
- switch(vcpu-arch.exception.nr) {
- case DF_VECTOR:
- /* triple fault - shutdown */
- set_bit(KVM_REQ_TRIPLE_FAULT,vcpu-requests);
- return;
- case PF_VECTOR:
- vcpu-arch.exception.nr = DF_VECTOR;
- vcpu-arch.exception.error_code = 0;
- return;
- default:
- /* replace previous exception with a new one in a hope
- that instruction re-execution will regenerate lost
- exception */
- vcpu-arch.exception.pending = false;
- break;
When exceptions are handled serially previous exception have to be
replaced by new one. Think about #PF during #DE. #PF should be handled first
before #DE can proceed.
replacing exceptions is dangerous in the case of debug exceptions
and machine checks, since restarting execution won't recover them.
But not replacing them is not better. No point in re-injecting
exception that causes another exception.
--
Gleb.
--
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 0/2] Handle multiple exceptions (fixes Win2003 reboot by triple fault)
On 11/12/2009 03:05 PM, Gleb Natapov wrote:
On Thu, Nov 12, 2009 at 01:41:31PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Wed, Nov 11, 2009 at 05:29:47PM -0200, Marcelo Tosatti wrote:
I suppose a complete fix would be to follow the Conditions for
Generating a Double Fault with support for handling exceptions
serially.
But this works for me.
I prefer proper solution. Like one attached (this is combination of ths
patch by Eddie Dong and my fix):
Nice, preferred here as well. I only have a minor comment below.
Move Double-Fault generation logic out of page fault
exception generating function to cover more generic case.
Signed-off-by: Eddie Dongeddie.d...@intel.com
Signed-off-by: Gleb Natapovg...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 76c8375..88c4490 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -248,12 +248,61 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
}
EXPORT_SYMBOL_GPL(kvm_set_apic_base);
+#define EXCPT_BENIGN 0
+#define EXCPT_CONTRIBUTORY 1
+#define EXCPT_PF 2
+
+static int exception_class(int vector)
+{
+ if (vector == 14)
+ return EXCPT_PF;
+ else if (vector == DE_VECTOR || (vector= TS_VECTOR vector=
GP_VECTOR))
+ return EXCPT_CONTRIBUTORY;
+ else
+ return EXCPT_BENIGN;
+}
It's actually less readable. I know 11 is between 10 and 13, but is
NP_VECTOR between TS_VECTOR and GP_VECTOR?
This is better as a switch, or even:
u8 exception_class[] = {
[PF_VECTOR] EXPT_PF,
etc.
--
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
Re: [PATCH 1/1] Fix unable to detect libpci
On 11/13/2009 08:22 AM, Sheng Yang wrote: commit 75fe7882 Test for libpci, not only for header compile a libpci test file. But the pciutils with defined PCI_COMPRESSED_IDS also need zlib when compile, otherwise the compile would fail, and detection fail then Applied, thanks. -- 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
Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception
On 11/15/2009 02:51 PM, Gleb Natapov wrote: replacing exceptions is dangerous in the case of debug exceptions and machine checks, since restarting execution won't recover them. But not replacing them is not better. No point in re-injecting exception that causes another exception. Right, just pointing out there's still a small hole left. Replacing is much better ignoring. -- 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
Re: virtio disk slower than IDE?
On 11/15/2009 02:00 PM, Gordan Bobic wrote: Dor Laor wrote: On 11/14/2009 04:23 PM, Gordan Bobic wrote: I just tried paravirtualized virtio block devices, and my tests show that they are approximately 30% slower than emulated IDE devices. I'm guessing this isn't normal. Is this a known issue or am I likely to have mosconfigured something? I'm using 64-bit RHEL/CentOS 5 (both host and guest). Please try to change the io scheduler on the host to io scheduler, it should boost your performance back. I presume you mean the deadline io scheduler. I tried that (kernel parameter elevator=deadline) and it made no measurable difference compared to the cfq scheduler. What version of kvm do you use? Is it rhel5.4? Can you post the qemu cmdline and the perf test in the guest? Lastly, do you use cache=wb on qemu? it's just a fun mode, we use cache=off only. Gordan -- 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
RE: Virtualization Performance: Intel vs. AMD
Andreas: Now my question is: Are there any important differences in terms of virtualization performance and/or features between the current Intel/AMD CPUs I prefer AMD CPUs, they give you a better bang for the buck. Besides that, I don't think they would be any technical differences, they are supposed to be completely compatible. I have seen no evidence to the contrary. Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! 7 day no risk trial, Google Checkout accepted -- 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: x86: Add KVM_GET/SET_VCPU_EVENTS
On 11/12/2009 02:04 AM, Jan Kiszka wrote: This new IOCTL exports all yet user-invisible states related to exceptions, interrupts, and NMIs. Together with appropriate user space changes, this fixes sporadic problems of vmsave/restore, live migration and system reset. Applied, thanks. I added a flags field to the structure in case we discover a new bit that needs to fit in there. Please take a look (separate commit in kvm-next). -- 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
buildbot failure in qemu-kvm on default_x86_64_debian_5_0
The Buildbot has detected a new failure of default_x86_64_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_debian_5_0/builds/153 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Alexander Graf ag...@suse.de,Andrzej Zaborowski bal...@zabor.org,Anthony Liguori aligu...@us.ibm.com,Artyom Tarasenko atar4q...@gmail.com,Avi Kivity a...@redhat.com,Gerd Hoffmann kra...@redhat.com,Gleb Natapov g...@redhat.com,Kevin Wolf kw...@redhat.com,Marcelo Tosatti mtosa...@redhat.com,Mark McLoughlin mar...@redhat.com,Michael S. Tsirkin m...@redhat.com,Peter Hjalmarsson x...@rymdraket.net,Sheng Yang sh...@linux.intel.com,Stefan Weil w...@mail.berlios.de,dummy BUILD FAILED: failed git sincerely, -The Buildbot -- 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: [RFC] KVM Fault Tolerance: Kemari for KVM
On 11/13/2009 01:48 PM, Yoshiaki Tamura wrote: Hi, Thanks for your comments! Dor Laor wrote: On 11/09/2009 05:53 AM, Fernando Luis Vázquez Cao wrote: Hi all, It has been a while coming, but we have finally started work on Kemari's port to KVM. For those not familiar with it, Kemari provides the basic building block to create a virtualization-based fault tolerant machine: a virtual machine synchronization mechanism. Traditional high availability solutions can be classified in two groups: fault tolerant servers, and software clustering. Broadly speaking, fault tolerant servers protect us against hardware failures and, generally, rely on redundant hardware (often proprietary), and hardware failure detection to trigger fail-over. On the other hand, software clustering, as its name indicates, takes care of software failures and usually requires a standby server whose software configuration for the part we are trying to make fault tolerant must be identical to that of the active server. Both solutions may be applied to virtualized environments. Indeed, the current incarnation of Kemari (Xen-based) brings fault tolerant server-like capabilities to virtual machines and integration with existing HA stacks (Heartbeat, RHCS, etc) is under consideration. After some time in the drawing board we completed the basic design of Kemari for KVM, so we are sending an RFC at this point to get early feedback and, hopefully, get things right from the start. Those already familiar with Kemari and/or fault tolerance may want to skip the Background and go directly to the design and implementation bits. This is a pretty long write-up, but please bear with me. == Background == We started to play around with continuous virtual synchronization technology about 3 years ago. As development progressed and, most importantly, we got the first Xen-based working prototypes it became clear that we needed a proper name for our toy: Kemari. The goal of Kemari is to provide a fault tolerant platform for virtualization environments, so that in the event of a hardware failure the virtual machine fails over from compromised to properly operating hardware (a physical machine) in a way that is completely transparent to the guest operating system. Although hardware based fault tolerant servers and HA servers (software clustering) have been around for a (long) while, they typically require specifically designed hardware and/or modifications to applications. In contrast, by abstracting hardware using virtualization, Kemari can be used on off-the-shelf hardware and no application modifications are needed. After a period of in-house development the first version of Kemari for Xen was released in Nov 2008 as open source. However, by then it was already pretty clear that a KVM port would have several advantages. First, KVM is integrated into the Linux kernel, which means one gets support for a wide variety of hardware for free. Second, and in the same vein, KVM can also benefit from Linux' low latency networking capabilities including RDMA, which is of paramount importance for a extremely latency-sensitive functionality like Kemari. Last, but not the least, KVM and its community is growing rapidly, and there is increasing demand for Kemari-like functionality for KVM. Although the basic design principles will remain the same, our plan is to write Kemari for KVM from scratch, since there does not seem to be much opportunity for sharing between Xen and KVM. == Design outline == The basic premise of fault tolerant servers is that when things go awry with the hardware the running system should transparently continue execution on an alternate physical host. For this to be possible the state of the fallback host has to be identical to that of the primary. Kemari runs paired virtual machines in an active-passive configuration and achieves whole-system replication by continuously copying the state of the system (dirty pages and the state of the virtual devices) from the active node to the passive node. An interesting implication of this is that during normal operation only the active node is actually executing code. Another possible approach is to run a pair of systems in lock-step (à la VMware FT). Since both the primary and fallback virtual machines are active keeping them synchronized is a complex task, which usually involves carefully injecting external events into both virtual machines so that they result in identical states. The latter approach is extremely architecture specific and not SMP friendly. This spurred us to try the design that became Kemari, which we believe lends itself to further optimizations. == Implementation == The first step is to encapsulate the machine to be protected within a virtual machine. Then the live migration functionality is leveraged to keep the virtual machines synchronized. Whereas during live migration dirty pages can be sent asynchronously from the primary to the fallback server until the ratio of
Re: [PATCH] qemu-kvm: Fix savevm under -no-kvm
On 11/12/2009 01:12 AM, Jan Kiszka wrote: Although this code is currently under rework for upstream merge, let's make savevm work again when kvm is disabled until we switch over. The change basically aligns us with the logic used for the ioapic. Applied, thanks. -- 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
Re: [PATCH] qemu-kvm: Reenable iothread mutex wrappers on !CONFIG_KVM
On 11/12/2009 01:49 AM, Jan Kiszka wrote: Needed to avoid some missing symbols when KVM is disabled. Applied, thanks. -- 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
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
On 11/12/2009 02:05 AM, Jan Kiszka wrote:
This patch extends the qemu-kvm state sync logic with support for
KVM_GET/SET_VCPU_EVENTS, giving access to yet missing exception,
interrupt and NMI states.
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 6bd447f..1eda7c5 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -452,6 +452,11 @@ static const VMStateDescription vmstate_cpu = {
VMSTATE_INT32_V(interrupt_injected, CPUState, 9),
VMSTATE_UINT32_V(mp_state, CPUState, 9),
VMSTATE_UINT64_V(tsc, CPUState, 9),
+VMSTATE_UINT8_V(soft_interrupt, CPUState, 11),
+VMSTATE_UINT8_V(nmi_injected, CPUState, 11),
+VMSTATE_UINT8_V(nmi_pending, CPUState, 11),
+VMSTATE_UINT8_V(has_error_code, CPUState, 11),
+VMSTATE_UINT32_V(sipi_vector, CPUState, 11),
/* MCE */
VMSTATE_UINT64_V(mcg_cap, CPUState, 10),
VMSTATE_UINT64_V(mcg_status, CPUState, 10),
Is there a reason why you add 11 between 9 and 10? We'll probably see
another 11 when someone else adds the next state.
--
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
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
Avi Kivity wrote:
On 11/12/2009 02:05 AM, Jan Kiszka wrote:
This patch extends the qemu-kvm state sync logic with support for
KVM_GET/SET_VCPU_EVENTS, giving access to yet missing exception,
interrupt and NMI states.
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 6bd447f..1eda7c5 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -452,6 +452,11 @@ static const VMStateDescription vmstate_cpu = {
VMSTATE_INT32_V(interrupt_injected, CPUState, 9),
VMSTATE_UINT32_V(mp_state, CPUState, 9),
VMSTATE_UINT64_V(tsc, CPUState, 9),
+VMSTATE_UINT8_V(soft_interrupt, CPUState, 11),
+VMSTATE_UINT8_V(nmi_injected, CPUState, 11),
+VMSTATE_UINT8_V(nmi_pending, CPUState, 11),
+VMSTATE_UINT8_V(has_error_code, CPUState, 11),
+VMSTATE_UINT32_V(sipi_vector, CPUState, 11),
/* MCE */
VMSTATE_UINT64_V(mcg_cap, CPUState, 10),
VMSTATE_UINT64_V(mcg_status, CPUState, 10),
Is there a reason why you add 11 between 9 and 10? We'll probably see
another 11 when someone else adds the next state.
Logical grouping (/* KVM-related states */). If anyone once tries to
add non-KVM stuff here just because it's version 12, it should be
rejected. I don't think you have to sort VMSTATE entries by their
version number. Am I right, Juan?
Jan
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
On 11/15/2009 04:21 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 11/12/2009 02:05 AM, Jan Kiszka wrote:
This patch extends the qemu-kvm state sync logic with support for
KVM_GET/SET_VCPU_EVENTS, giving access to yet missing exception,
interrupt and NMI states.
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 6bd447f..1eda7c5 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -452,6 +452,11 @@ static const VMStateDescription vmstate_cpu = {
VMSTATE_INT32_V(interrupt_injected, CPUState, 9),
VMSTATE_UINT32_V(mp_state, CPUState, 9),
VMSTATE_UINT64_V(tsc, CPUState, 9),
+VMSTATE_UINT8_V(soft_interrupt, CPUState, 11),
+VMSTATE_UINT8_V(nmi_injected, CPUState, 11),
+VMSTATE_UINT8_V(nmi_pending, CPUState, 11),
+VMSTATE_UINT8_V(has_error_code, CPUState, 11),
+VMSTATE_UINT32_V(sipi_vector, CPUState, 11),
/* MCE */
VMSTATE_UINT64_V(mcg_cap, CPUState, 10),
VMSTATE_UINT64_V(mcg_status, CPUState, 10),
Is there a reason why you add 11 between 9 and 10? We'll probably see
another 11 when someone else adds the next state.
Logical grouping (/* KVM-related states */).
These aren't kvm-related, just not implemented in tcg yet. Nothing
kvmish about them - it's all architectural state.
If anyone once tries to
add non-KVM stuff here just because it's version 12, it should be
rejected. I don't think you have to sort VMSTATE entries by their
version number. Am I right, Juan?
I'm worried about something else - someone looking at the end, seeing
version 10, and appending new state with version 11.
--
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
Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception
Avi Kivity wrote: On 11/15/2009 02:51 PM, Gleb Natapov wrote: replacing exceptions is dangerous in the case of debug exceptions and machine checks, since restarting execution won't recover them. But not replacing them is not better. No point in re-injecting exception that causes another exception. Right, just pointing out there's still a small hole left. Replacing is much better ignoring. Is the hardware doing some queuing in this case? Would it be overly complicated to adopt the real behavior here? Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
Avi Kivity wrote:
On 11/15/2009 04:21 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 11/12/2009 02:05 AM, Jan Kiszka wrote:
This patch extends the qemu-kvm state sync logic with support for
KVM_GET/SET_VCPU_EVENTS, giving access to yet missing exception,
interrupt and NMI states.
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 6bd447f..1eda7c5 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -452,6 +452,11 @@ static const VMStateDescription vmstate_cpu = {
VMSTATE_INT32_V(interrupt_injected, CPUState, 9),
VMSTATE_UINT32_V(mp_state, CPUState, 9),
VMSTATE_UINT64_V(tsc, CPUState, 9),
+VMSTATE_UINT8_V(soft_interrupt, CPUState, 11),
+VMSTATE_UINT8_V(nmi_injected, CPUState, 11),
+VMSTATE_UINT8_V(nmi_pending, CPUState, 11),
+VMSTATE_UINT8_V(has_error_code, CPUState, 11),
+VMSTATE_UINT32_V(sipi_vector, CPUState, 11),
/* MCE */
VMSTATE_UINT64_V(mcg_cap, CPUState, 10),
VMSTATE_UINT64_V(mcg_status, CPUState, 10),
Is there a reason why you add 11 between 9 and 10? We'll probably see
another 11 when someone else adds the next state.
Logical grouping (/* KVM-related states */).
These aren't kvm-related, just not implemented in tcg yet. Nothing
kvmish about them - it's all architectural state.
Most of them are KVM-specific. TCG don't have to deal with event
re-injection due to host page faults etc. on first try.
If anyone once tries to
add non-KVM stuff here just because it's version 12, it should be
rejected. I don't think you have to sort VMSTATE entries by their
version number. Am I right, Juan?
I'm worried about something else - someone looking at the end, seeing
version 10, and appending new state with version 11.
Again, that's something proper review should catch (just like checking
for the right place when adding a new IOCTL to kvm.h).
Jan
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] KVM: x86: Add KVM_GET/SET_VCPU_EVENTS
Avi Kivity wrote: On 11/12/2009 02:04 AM, Jan Kiszka wrote: This new IOCTL exports all yet user-invisible states related to exceptions, interrupts, and NMIs. Together with appropriate user space changes, this fixes sporadic problems of vmsave/restore, live migration and system reset. Applied, thanks. I added a flags field to the structure in case we discover a new bit that needs to fit in there. Please take a look (separate commit in kvm-next). Looks ok. Jan signature.asc Description: OpenPGP digital signature
Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception
On 11/15/2009 04:29 PM, Jan Kiszka wrote: Avi Kivity wrote: On 11/15/2009 02:51 PM, Gleb Natapov wrote: replacing exceptions is dangerous in the case of debug exceptions and machine checks, since restarting execution won't recover them. But not replacing them is not better. No point in re-injecting exception that causes another exception. Right, just pointing out there's still a small hole left. Replacing is much better ignoring. Is the hardware doing some queuing in this case? Gleb has verified by testing, and Intel has confirmed, that the hardware does not queue, and will in fact lose traps and NMIs in such a case. So the small hole is actually present in the processor and we're better off not queueing! I've forgotten about this but Gleb reminded me. Would it be overly complicated to adopt the real behavior here? Not only would it be difficult, it would also be incorrect. -- 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
Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception
Avi Kivity wrote: On 11/15/2009 04:29 PM, Jan Kiszka wrote: Avi Kivity wrote: On 11/15/2009 02:51 PM, Gleb Natapov wrote: replacing exceptions is dangerous in the case of debug exceptions and machine checks, since restarting execution won't recover them. But not replacing them is not better. No point in re-injecting exception that causes another exception. Right, just pointing out there's still a small hole left. Replacing is much better ignoring. Is the hardware doing some queuing in this case? Gleb has verified by testing, and Intel has confirmed, that the hardware does not queue, and will in fact lose traps and NMIs in such a case. So the small hole is actually present in the processor and we're better off not queueing! I've forgotten about this but Gleb reminded me. Would it be overly complicated to adopt the real behavior here? Not only would it be difficult, it would also be incorrect. I'm all for correctness - so this correctly drop events. :) Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
On 11/15/2009 04:31 PM, Jan Kiszka wrote: Is there a reason why you add 11 between 9 and 10? We'll probably see another 11 when someone else adds the next state. Logical grouping (/* KVM-related states */). These aren't kvm-related, just not implemented in tcg yet. Nothing kvmish about them - it's all architectural state. Most of them are KVM-specific. TCG don't have to deal with event re-injection due to host page faults etc. on first try. Right, tcg can do some things atomically. There's some non-kvm state in there. If anyone once tries to add non-KVM stuff here just because it's version 12, it should be rejected. I don't think you have to sort VMSTATE entries by their version number. Am I right, Juan? I'm worried about something else - someone looking at the end, seeing version 10, and appending new state with version 11. Again, that's something proper review should catch (just like checking for the right place when adding a new IOCTL to kvm.h). And we know how well that works. We should try to make things work by default and leave the review to catch the really difficult things (like trailing whitespace). At least add a comment at the end warning people that simple append will fail. -- 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
buildbot failure in qemu-kvm on default_i386_out_of_tree
The Buildbot has detected a new failure of default_i386_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/93 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Avi Kivity a...@redhat.com,Jan Kiszka jan.kis...@web.de BUILD FAILED: failed git sincerely, -The Buildbot -- 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 2/2] qemu-kvm: x86: Add support for VCPU event states
Avi Kivity wrote: On 11/15/2009 04:31 PM, Jan Kiszka wrote: Is there a reason why you add 11 between 9 and 10? We'll probably see another 11 when someone else adds the next state. Logical grouping (/* KVM-related states */). These aren't kvm-related, just not implemented in tcg yet. Nothing kvmish about them - it's all architectural state. Most of them are KVM-specific. TCG don't have to deal with event re-injection due to host page faults etc. on first try. Right, tcg can do some things atomically. There's some non-kvm state in there. If anyone once tries to add non-KVM stuff here just because it's version 12, it should be rejected. I don't think you have to sort VMSTATE entries by their version number. Am I right, Juan? I'm worried about something else - someone looking at the end, seeing version 10, and appending new state with version 11. Again, that's something proper review should catch (just like checking for the right place when adding a new IOCTL to kvm.h). And we know how well that works. We should try to make things work by default and leave the review to catch the really difficult things (like trailing whitespace). At least add a comment at the end warning people that simple append will fail. Where should I add /* next version to use: 13 */, and who will take care that this comment will also be kept up to date? The CPU vmstate is already ordered according to logical groups, just look at earlier field. Only recent KVM additions happened to create some version ordering as well. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
On 11/15/2009 05:02 PM, Jan Kiszka wrote: Where should I add /* next version to use: 13 */, and who will take care that this comment will also be kept up to date? The CPU vmstate is already ordered according to logical groups, just look at earlier field. Only recent KVM additions happened to create some version ordering as well. Er, now I'm confused. 11 and 12 indeed do already exist, so how can you update 11 retroactively? Shouldn't you create 13 now? (and I meant: /* The above list is not sorted wrt version, watch out! */, but now I feel I'm missing something). -- 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
monitoring guest sidt execution
Hi to all, I'm trying to intercept the guest sidt instruction execution from the host i've added the bit to the control structure: control-intercept = | (1ULL INTERCEPT_STORE_IDTR); then I have defined the sidt handler to manage the STORE_IDTR action: [SVM_EXIT_IDTR_READ]= idtr_write_interception, So, in the idtr_write_interception handler there is the invocation of the emulate_instruction(svm- vcpu, kvm_run, 0, 0, 0); function. Following the execution flow i found that the emulation failed in the x86_emulate.c source file and precisely in the if (c-d == 0) conditional statement but i really don't know why it happens and how to fix it. could you please give me some hints with respect to this issue? thanks in advance, Matteo -- 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 2/2] qemu-kvm: x86: Add support for VCPU event states
Avi Kivity wrote: On 11/15/2009 05:02 PM, Jan Kiszka wrote: Where should I add /* next version to use: 13 */, and who will take care that this comment will also be kept up to date? The CPU vmstate is already ordered according to logical groups, just look at earlier field. Only recent KVM additions happened to create some version ordering as well. Er, now I'm confused. 11 and 12 indeed do already exist, so how can you update 11 retroactively? Oh, right, good that we discuss this. My patch dated back before the kvmclock addition, which IMHO incorrectly bumped the version numbers. I think the current policy in upstream is that we only increment once per qemu release, not per bit added. Shouldn't you create 13 now? No, I rather think Glauber's 12 should be downgraded to 11 - unless it misses the qemu merge windows for 0.12. My extensions definitely target that release, thus will likely carry 11 in upstream. And we should really try to avoid diverging again. (and I meant: /* The above list is not sorted wrt version, watch out! */, but now I feel I'm missing something). Ok, can add such a note at the end. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
On 11/15/2009 05:41 PM, Jan Kiszka wrote: Avi Kivity wrote: On 11/15/2009 05:02 PM, Jan Kiszka wrote: Where should I add /* next version to use: 13 */, and who will take care that this comment will also be kept up to date? The CPU vmstate is already ordered according to logical groups, just look at earlier field. Only recent KVM additions happened to create some version ordering as well. Er, now I'm confused. 11 and 12 indeed do already exist, so how can you update 11 retroactively? Oh, right, good that we discuss this. My patch dated back before the kvmclock addition, which IMHO incorrectly bumped the version numbers. I think the current policy in upstream is that we only increment once per qemu release, not per bit added. What about stable releases? If we need to port a commit which adds a bit, we need to port the entire thing. (well version numbers don't work with nonlinear development anyway). Shouldn't you create 13 now? No, I rather think Glauber's 12 should be downgraded to 11 - unless it misses the qemu merge windows for 0.12. My extensions definitely target that release, thus will likely carry 11 in upstream. And we should really try to avoid diverging again. Agree. Will commit the patches. (and I meant: /* The above list is not sorted wrt version, watch out! */, but now I feel I'm missing something). Ok, can add such a note at the end. In upstream... -- 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
Re: Virtualization Performance: Intel vs. AMD
On Sunday 15 November 2009 14:05:52 Neil Aggarwal wrote: I prefer AMD CPUs, they give you a better bang for the buck. Besides that, I don't think they would be any technical differences, they are supposed to be completely compatible. I have seen no evidence to the contrary. Isn't AMD the only one who has hardware support for nested virtualization? Or isn't that true any longer? Anyways, I'm just curious, as this feature is primarily interesting for development, IMHO. -t -- 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: Virtualization Performance: Intel vs. AMD
On Sunday 15 November 2009 13:22:36 Andreas Winkelbauer wrote: Now my question is: Are there any important differences in terms of virtualization performance and/or features between the current Intel/AMD CPUs (e.g. Core i7 Lynnfield and Phenom II X4 Deneb)? The Core i7 has hyperthreading, so you see 8 logical CPUs. But don't ask me if that's really an advantage for doing virtualization ;-) -t -- 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: Virtualization Performance: Intel vs. AMD
The Core i7 has hyperthreading, so you see 8 logical CPUs. Are you saying the AMD processors do not have hyperthreading? I have a machine with two six-core AMD Opterons. top shows me 12 logical CPUs. Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! 7 day no risk trial, Google Checkout accepted -- 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: Virtualization Performance: Intel vs. AMD
On Sun November 15 2009, Neil Aggarwal wrote: The Core i7 has hyperthreading, so you see 8 logical CPUs. Are you saying the AMD processors do not have hyperthreading? Course not. Hyperthreading is dubious at best. I have a machine with two six-core AMD Opterons. top shows me 12 logical CPUs. If it had Hyperthreading, you'd see 24 logical cpus. 6 + 6 == 12 * 2(ht) == 24. Those six cores in each cpu are actual physcial cores. Not fake logical cores. Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! 7 day no risk trial, Google Checkout accepted -- 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 -- Thomas Fjellstrom tfjellst...@shaw.ca -- 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: Virtualization Performance: Intel vs. AMD
Those six cores in each cpu are actual physcial cores. Not fake logical cores. OK, I see what you are saying now. Thanks for the clarification. Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net CentOS 5.4 VPS with unmetered bandwidth only $25/month! 7 day no risk trial, Google Checkout accepted -- 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 test: migration subtest: Handle case where session2 does not exist
In one of the code blocks of the migration test, a finally clause tries to send a command to a session. However, if we are not successful in actually creating a session, that object will hold None, which doesn't have an is_alive attribute, generating an unhandled exception. Fix that by checking if the session2 object is not None before trying to use the method is_alive() Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests/migration.py |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/client/tests/kvm/tests/migration.py b/client/tests/kvm/tests/migration.py index 7b80e51..21df1e2 100644 --- a/client/tests/kvm/tests/migration.py +++ b/client/tests/kvm/tests/migration.py @@ -74,9 +74,10 @@ def run_migration(test, params, env): finally: # Kill the background process -if session2.is_alive(): -session2.get_command_output(params.get(migration_bg_kill_command, - )) +if session2: +if session2.is_alive(): +session2.get_command_output( +params.get(migration_bg_kill_command, )) session2.close() session.close() -- 1.6.2.5 -- 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: Virtualization Performance: Intel vs. AMD
Thomas Fjellstrom wrote: On Sun November 15 2009, Neil Aggarwal wrote: The Core i7 has hyperthreading, so you see 8 logical CPUs. Are you saying the AMD processors do not have hyperthreading? Course not. Hyperthreading is dubious at best. That's a rather questionable answer to a rather broad issue. SMT is useful, especially on processors with deep pipelines (think Pentium 4 - and in general, deeper pipelines tend to be required for higher clock speeds), because it reduces the number of context switches. Context switches are certainly one of the most expensive operations if not the most expensive operation you can do on a processor, and typically requires flushing the pipelines. Double the number of hardware threads, and you halve the number of context switches. This typically isn't useful if your CPU is processing one single-threaded application 99% of the time, but on a loaded server it can make a significant difference to throughput. Gordan -- 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: virtio disk slower than IDE?
Dor Laor wrote: On 11/15/2009 02:00 PM, Gordan Bobic wrote: Dor Laor wrote: On 11/14/2009 04:23 PM, Gordan Bobic wrote: I just tried paravirtualized virtio block devices, and my tests show that they are approximately 30% slower than emulated IDE devices. I'm guessing this isn't normal. Is this a known issue or am I likely to have mosconfigured something? I'm using 64-bit RHEL/CentOS 5 (both host and guest). Please try to change the io scheduler on the host to io scheduler, it should boost your performance back. I presume you mean the deadline io scheduler. I tried that (kernel parameter elevator=deadline) and it made no measurable difference compared to the cfq scheduler. What version of kvm do you use? Is it rhel5.4? It's RHEL 5.4. $ rpm -qa | grep -i kvm kmod-kvm-83-105.el5_4.9 kvm-83-105.el5_4.9 Can you post the qemu cmdline and the perf test in the guest? Here is what is in the libvirt log: For IDE emulation: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root /usr/libexec/qemu-kvm -S -M pc -m 2048 -smp 4 -name RHEL_5_x86-64 -uuid cb44b2c5-e64b-848f-77af-f8e7f02fa2ca -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//RHEL_5_x86-64.pid -boot c -drive file=/var/lib/libvirt/images/RHEL_5_x86-64.img,if=ide,index=0,boot=on -net nic,macaddr=54:52:00:5a:67:4b,vlan=0,model=e1000 -net tap,fd=15,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-gb For virtio: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root /usr/libexec/qemu-kvm -S -M pc -m 2048 -smp 4 -name RHEL_5_x86-64 -uuid cb44b2c5-e64b-848f-77af-f8e7f02fa2ca -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//RHEL_5_x86-64.pid -boot c -drive file=/var/lib/libvirt/images/CentOS_5_x86-64.img,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:5a:67:4b,vlan=0,model=e1000 -net tap,fd=15,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-gb The test is building the Linux kernel (only taking the second run to give the test the benefit of local cache): make clean; make -j8 all; make clean; sync; time make -j8 all This takes about 10 minutes with IDE disk emulation and about 13 minutes with virtio. I ran the tests multiple time with most non-essential services on the host switched off (including cron/atd), and the guest in single-user mode to reduce the noise in the test to the minimum, and the results are pretty consistent, with virtio being about 30% behind. Lastly, do you use cache=wb on qemu? it's just a fun mode, we use cache=off only. I don't see the option being set in the logs, so I'd guess it's whatever qemu-kvm defaults to. Gordan -- 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: Virtualization Performance: Intel vs. AMD
On Sun November 15 2009, Gordan Bobic wrote: Thomas Fjellstrom wrote: On Sun November 15 2009, Neil Aggarwal wrote: The Core i7 has hyperthreading, so you see 8 logical CPUs. Are you saying the AMD processors do not have hyperthreading? Course not. Hyperthreading is dubious at best. That's a rather questionable answer to a rather broad issue. SMT is useful, especially on processors with deep pipelines (think Pentium 4 - and in general, deeper pipelines tend to be required for higher clock speeds), because it reduces the number of context switches. Context switches are certainly one of the most expensive operations if not the most expensive operation you can do on a processor, and typically requires flushing the pipelines. Double the number of hardware threads, and you halve the number of context switches. Hardware context switches aren't free either. And while it really has nothing to do with this discussion, the P4 arch was far from perfect (many would say, far from GOOD). This typically isn't useful if your CPU is processing one single-threaded application 99% of the time, but on a loaded server it can make a significant difference to throughput. I'll buy that. Though you'll have to agree that the initial Hyperthread implementation in intel cpus was really bad. I hear good things about the latest version though. But hey, if you can stick more cores in, or do what AMD is doing with its upcoming line, why not do that? Hyperthreading seems like more of a gimmick than anything. What seems to help the most with the new Intel arch is the auto overclocking when some cores are idle. Far more of a performance improvement than Hyperthreading will ever be it seems. But maybe that's just me. Gordan -- 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 -- Thomas Fjellstrom tfjellst...@shaw.ca -- 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: Virtualization Performance: Intel vs. AMD
Thomas Fjellstrom wrote: The Core i7 has hyperthreading, so you see 8 logical CPUs. Are you saying the AMD processors do not have hyperthreading? Course not. Hyperthreading is dubious at best. That's a rather questionable answer to a rather broad issue. SMT is useful, especially on processors with deep pipelines (think Pentium 4 - and in general, deeper pipelines tend to be required for higher clock speeds), because it reduces the number of context switches. Context switches are certainly one of the most expensive operations if not the most expensive operation you can do on a processor, and typically requires flushing the pipelines. Double the number of hardware threads, and you halve the number of context switches. Hardware context switches aren't free either. And while it really has nothing to do with this discussion, the P4 arch was far from perfect (many would say, far from GOOD). I actually disagree with a lot of criticism of P4. The reason why it's performance _appeared_ to be poor was because it was more reliant on compilers doing their job well. Unfortunately, most compilers generate very poor code, and most programmers aren't even aware of the improvements that can be had in this area with a bit of extra work and a decent compiler. Performance differences of 7+ times (700%) aren't unheard of on Pentium 4 between, say, ICC and GCC generated code. P4 wasn't a bad design - the compilers just weren't good enough to leverage it to anywhere near it's potential. This typically isn't useful if your CPU is processing one single-threaded application 99% of the time, but on a loaded server it can make a significant difference to throughput. I'll buy that. Though you'll have to agree that the initial Hyperthread implementation in intel cpus was really bad. I hear good things about the latest version though. As measured by what? A single-threaded desktop benchmark? But hey, if you can stick more cores in, or do what AMD is doing with its upcoming line, why not do that? Hyperthreading seems like more of a gimmick than anything. If there weren't clear and quantifiable benefits then IBM wouldn't be putting it in it's Power series of high end processors, it wouldn't be in the X-Box 360's Xenon (PPC970 variant), and Sun wouldn't be going massively SMT in the Niagara SPARCs. Silicon die space is _expensive_ - it wouldn't be getting wasted on gimmicks. What seems to help the most with the new Intel arch is the auto overclocking when some cores are idle. Far more of a performance improvement than Hyperthreading will ever be it seems. Which is targeted at gamers and desktop enthusiasts who think that FPS in Crysis is a meaningful measure of performance for most applications. Server load profile is a whole different ball game. Anyway, let's get this back on topic for the list before we get told off (of course, I'm more than happy to continue the discussion off list). Gordan -- 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] Make a standalone client to be able to use global_config.ini
In order to make it possible the autotest client to use the global_config.ini configuration files: * Modified global_config.py to support verifying if the configuration file is under autotest's root directory, or the client directory * Extended the autotest client install methods to copy over the configuration files with the client. While there, fixed a small bug: server/autotest.py was making reference to an exception class not present under common_lib.error Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/common_lib/error.py |5 + client/common_lib/global_config.py | 34 -- server/autotest.py | 33 +++-- utils/packager.py | 18 +++--- 4 files changed, 71 insertions(+), 19 deletions(-) diff --git a/client/common_lib/error.py b/client/common_lib/error.py index 08401ce..9e0002d 100644 --- a/client/common_lib/error.py +++ b/client/common_lib/error.py @@ -185,6 +185,11 @@ class AutoservError(Exception): pass +class AutoservInstallError(Exception): +Autoserv failed in installing autotest on a client machine +pass + + class AutoservSSHTimeout(AutoservError): SSH experienced a connection timeout pass diff --git a/client/common_lib/global_config.py b/client/common_lib/global_config.py index 2bbeca0..f27a14c 100644 --- a/client/common_lib/global_config.py +++ b/client/common_lib/global_config.py @@ -8,12 +8,6 @@ __author__ = 'raph...@google.com (Travis Miller)' import os, sys, ConfigParser from autotest_lib.client.common_lib import error -dirname = os.path.dirname(sys.modules[__name__].__file__) -DEFAULT_CONFIG_FILE = os.path.abspath(os.path.join(dirname, -../../global_config.ini)) -DEFAULT_SHADOW_FILE = os.path.abspath(os.path.join(dirname, -../../shadow_config.ini)) - class ConfigError(error.AutotestError): pass @@ -23,6 +17,34 @@ class ConfigValueError(ConfigError): pass + +common_lib_dir = os.path.dirname(sys.modules[__name__].__file__) +client_dir = os.path.dirname(common_lib_dir) +root_dir = os.path.dirname(client_dir) + +# Check if the config files are at autotest's root dir +# This will happen if client is executing inside a full autotest tree, or if +# other entry points are being executed +global_config_path_root = os.path.join(root_dir, 'global_config.ini') +shadow_config_path_root = os.path.join(root_dir, 'shadow_config.ini') +config_in_root = (os.path.exists(global_config_path_root) and + os.path.exists(shadow_config_path_root)) + +# Check if the config files are at autotest's client dir +# This will happen if a client stand alone execution is happening +global_config_path_client = os.path.join(client_dir, 'global_config.ini') +shadow_config_path_client = os.path.join(client_dir, 'shadow_config.ini') +config_in_client = (os.path.exists(global_config_path_client) and +os.path.exists(shadow_config_path_client)) + +if config_in_root: +DEFAULT_CONFIG_FILE = global_config_path_root +DEFAULT_SHADOW_FILE = shadow_config_path_root +elif config_in_client: +DEFAULT_CONFIG_FILE = global_config_path_client +DEFAULT_SHADOW_FILE = shadow_config_path_client + + class global_config(object): _NO_DEFAULT_SPECIFIED = object() diff --git a/server/autotest.py b/server/autotest.py index 3d307a9..120ab61 100644 --- a/server/autotest.py +++ b/server/autotest.py @@ -151,12 +151,25 @@ class BaseAutotest(installable_object.InstallableObject): self.installed = True -def _install_using_send_file(self, host, autodir): -dirs_to_exclude = set([tests, site_tests, deps, profilers]) -light_files = [os.path.join(self.source_material, f) - for f in os.listdir(self.source_material) - if f not in dirs_to_exclude] -host.send_file(light_files, autodir, delete_dest=True) +def _install_using_send_file(self, host, autodir, full): +if full: +dirs_to_exclude = set([]) +else: +dirs_to_exclude = set([tests, site_tests, deps, profilers]) + +files = [] +for f in os.listdir(self.source_material): +if f not in dirs_to_exclude: +files.append(os.path.join(self.source_material, f)) + +# We will also add the global configuration files to the bundle +root_dir = os.path.dirname(self.serverdir) +global_config = os.path.join(root_dir, 'global_config.ini') +shadow_config = os.path.join(root_dir, 'shadow_config.ini') +files.append(global_config) +files.append(shadow_config) +# Copy the files to the host +host.send_file(files, autodir, delete_dest=True) # create empty dirs for all the stuff we excluded commands = [] @@ -165,7 +178,8 @@ class
Re: [PATCH] KVM test: migration subtest: Handle case where session2 does not exist
- Lucas Meneghel Rodrigues l...@redhat.com wrote: In one of the code blocks of the migration test, a finally clause tries to send a command to a session. However, if we are not successful in actually creating a session, that object will hold None, which doesn't have an is_alive attribute, generating an unhandled exception. Fix that by checking if the session2 object is not None before trying to use the method is_alive() Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- client/tests/kvm/tests/migration.py |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/client/tests/kvm/tests/migration.py b/client/tests/kvm/tests/migration.py index 7b80e51..21df1e2 100644 --- a/client/tests/kvm/tests/migration.py +++ b/client/tests/kvm/tests/migration.py @@ -74,9 +74,10 @@ def run_migration(test, params, env): finally: # Kill the background process -if session2.is_alive(): - session2.get_command_output(params.get(migration_bg_kill_command, - )) +if session2: +if session2.is_alive(): Sorry, my fault. Minor suggestion: these two lines can be merged into 'if session2 and session2.is_alive()' because the second part is not evaluated if the first part evaluates to False, so it's safe. +session2.get_command_output( + params.get(migration_bg_kill_command, )) session2.close() session.close() -- 1.6.2.5 -- 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
