Re: [qemu-kvm] build fail on i386 RHEL5u4
On 08/16/2010 04:27 AM, Hao, Xudong wrote: Appears to be a gcc bug. I opened https://bugzilla.redhat.com/show_bug.cgi?id=624279 to track this. Meanwhile, installing the gcc44 package and building with it (./configure --cc=gcc44) appears to work. Avi, Gcc44 works for me. I saw Jakub marked this bug closed with only i486 support that, but RHEL5 use -march=i386, so do we have ongoing fix on qemu-kvm? Should be easy to add a ./configure test for this. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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 PATCH v3 0/4] Real mode interrupt injection
On 08/16/2010 02:37 AM, Mohammed Gamal wrote: Here is a full trace of a MINIX guest since bootup. Looks like we get stuck somewhere in the BIOS. https://docs.google.com/leaf?id=0B9UodZT1IuENMzJhNWQxM2YtYzE3YS00YWY4LTk2YTgtZWY3ODNhMWUxMDkxsort=namelayout=listnum=50 qemu-system-x86-28953 [000] 1927.399942: kvm_inj_virq: irq 16 qemu-system-x86-28953 [000] 1927.399949: kvm_inject_realmode_interrupt: cs=c000 qemu-system-x86-28953 [000] 1927.399951: kvm_inject_realmode_interrupt: eip=40a3 qemu-system-x86-28953 [000] 1927.399957: kvm_inject_realmode_interrupt: cs=c000 qemu-system-x86-28953 [000] 1927.399958: kvm_inject_realmode_interrupt: eip=8339 qemu-system-x86-28953 [000] 1927.399960: kvm_entry: vcpu 0 qemu-system-x86-28953 [000] 1927.399965: kvm_exit: reason EXCEPTION_NMI rip 0x8339 qemu-system-x86-28953 [000] 1927.399966: kvm_page_fault: address c8339 error_code 1d qemu-system-x86-28953 [000] 1927.399970: kvm_entry: vcpu 0 qemu-system-x86-28953 [000] 1927.399975: kvm_exit: reason IO_INSTRUCTION rip 0x67d9 qemu-system-x86-28953 [000] 1927.399976: kvm_pio: pio_read at 0x3c4 size 2 count 1 qemu-system-x86-28953 [000] 1927.399985: kvm_entry: vcpu 0 qemu-system-x86-28953 [000] 1927.31: kvm_exit: reason EXCEPTION_NMI rip 0x3d4 This is bogus, it's in the middle of an instruction: f93d1: 2e 67 8b 9a 00 00 f1addr32 mov %cs:-0xf(%edx),%bx f93d8: ff f93d9: 66 0f b7 eb movzwl %bx,%ebp Everything after that is invalid. So we need to know how we got to rip = 0x3d4, it looks like an I/O port used by vga. Please rerun with emulation on all real mode instructions. qemu-system-x86-28953 [000] 1927.32: kvm_page_fault: address f93d4 error_code 1d qemu-system-x86-28953 [000] 1927.36: kvm_entry: vcpu 0 qemu-system-x86-28953 [000] 1927.40: kvm_exit: reason EXCEPTION_NMI rip 0x0 qemu-system-x86-28953 [000] 1927.43: kvm_inj_exception: #DB (0x0) qemu-system-x86-28953 [000] 1927.45: kvm_inject_realmode_interrupt: cs=fff1 qemu-system-x86-28953 [000] 1927.46: kvm_inject_realmode_interrupt: eip=0 qemu-system-x86-28953 [000] 1927.400011: kvm_inject_realmode_interrupt: cs=f000 qemu-system-x86-28953 [000] 1927.400012: kvm_inject_realmode_interrupt: eip=ff53 qemu-system-x86-28953 [000] 1927.400014: kvm_entry: vcpu 0 -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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 emulator: put register operand write back to a function
On 08/16/2010 04:58 AM, Wei Yongjun wrote: It's cleaner to take val and bytes from struct operand, and do the assignment from the callers, no? take val and bytes from struct operand may have other issue, when we writeback the source register, we need do the assignment from the caller, and then change the val back before write src val to dst val. Such as xadd: c-src.val = c-dst.val; write_register_operand(c-src); c-src.val = c-src.orig_val; goto add; Or avoid the 'goto add'. XADD is not ADD. write_register_operand(struct operand *) is easy to understand. With the two additional arguments it becomes confusing since it uses some parts of the operand but ignores others. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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 PATCH v3 0/4] Real mode interrupt injection
On 08/16/2010 12:46 AM, Mohammed Gamal wrote: This patch introduces real mode interrupt injection for VMX. It currently invokes the x86 emulator to emulate interrupts instead of manually setting VMX controls. Needless to say, this is not meant for merging in its current state. The emulator still needs some more work to get this completely operational. Mohammed Gamal (4): x86 emulator: Expose emulate_int_real() x86: Separate emulation context initialization in a separate function x86: Add kvm_inject_realmode_interrupt() wrapper VMX: Emulated real mode interrupt injection I applied the second patch to next, rest are applied to non-atomic-injection branch. 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
Help: compile the Linux kernel (KVM kernel )on Ubuntu 10.04 err
Hi all,
While compiling the kvm linux kernel on my ubuntu 10.04(Linux
-laptop 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC
2010 i686 GNU/Linux), the err below appear, How to figure out please?
=err msg=
In file included from drivers/platform/x86/intel_
scu_ipc.c:26:
kvm/arch/x86/include/asm/mrst.h:14: warning: ‘struct sfi_table_header’
declared inside parameter list
kvm/arch/x86/include/asm/mrst.h:14: warning: its scope is only this
definition or declaration, which is probably not what you want
drivers/platform/x86/intel_scu_ipc.c: In function ‘pwr_reg_rdwr’:
drivers/platform/x86/intel_scu_ipc.c:175: error:
‘MRST_CPU_CHIP_PENWELL’ undeclared (first use in this function)
drivers/platform/x86/intel_scu_ipc.c:175: error: (Each undeclared
identifier is reported only once
drivers/platform/x86/intel_scu_ipc.c:175: error: for each function it
appears in.)
drivers/platform/x86/intel_scu_ipc.c: In function ‘intel_scu_ipc_init’:
drivers/platform/x86/intel_scu_ipc.c:741: error: implicit declaration
of function ‘mrst_identify_cpu’
make[3]: *** [drivers/platform/x86/intel_scu_ipc.o] Error 1
make[2]: *** [drivers/platform/x86] Error 2
make[1]: *** [drivers/platform] Error 2
make: *** [drivers] Error 2
=KVM kernel info=
kvm$ git log
commit 5c739e07acf53aa3212ea28db34397eb936d46b2
Author: Wei Yongjun yj...@cn.fujitsu.com
Date: Tue Aug 10 13:48:22 2010 +0800
KVM: x86 emulator: add bsf/bsr instruction emulation
Add bsf/bsr instruction emulation (opcode 0x0f 0xbc~0xbd)
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
Signed-off-by: Avi Kivity a...@redhat.com
commit 4480639d9a17b4f13d932b1579bb4ad81b70659b
Author: Mohammed Gamal m.gamal...@gmail.com
Date: Sun Aug 8 21:11:38 2010 +0300
KVM: x86 emulator: Fix emulate_grp3 return values
This patch lets emulate_grp3() return X86EMUL_* return codes instead
of hardcoded ones.
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
Signed-off-by: Avi Kivity a...@redhat.com
...
=search the kvm kernel tree=
kvm$ grep MRST_CPU_CHIP_PENWELL . -R
./drivers/platform/x86/intel_scu_ipc.c: if (platform !=
MRST_CPU_CHIP_PENWELL) {
./drivers/platform/x86/intel_scu_ipc.c: if (platform !=
MRST_CPU_CHIP_PENWELL) {
--
zhoupeng
--
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 00/27] KVM PPC PV framework v3
On 06.08.2010, at 18:28, Kumar Gala wrote:
On Jul 29, 2010, at 7:47 AM, Alexander Graf wrote:
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /dev/null;
done
real0m14.659s
user0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /dev/null;
done
real0m7.557s
user0m4.121s
sys 0m3.426s
Do you have #'s for w/o HV to compare to.
Native was around 2-3 seconds overall. So we still have quite a big impact on
performance, but things are improving :).
Alex
--
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 PATCH v3 0/4] Real mode interrupt injection
On 08/16/2010 02:37 AM, Mohammed Gamal wrote: On Mon, Aug 16, 2010 at 12:46 AM, Mohammed Gamalm.gamal...@gmail.com wrote: This patch introduces real mode interrupt injection for VMX. It currently invokes the x86 emulator to emulate interrupts instead of manually setting VMX controls. Needless to say, this is not meant for merging in its current state. The emulator still needs some more work to get this completely operational. Mohammed Gamal (4): x86 emulator: Expose emulate_int_real() x86: Separate emulation context initialization in a separate function x86: Add kvm_inject_realmode_interrupt() wrapper VMX: Emulated real mode interrupt injection arch/x86/include/asm/kvm_emulate.h |3 +- arch/x86/kvm/vmx.c | 65 +++ arch/x86/kvm/x86.c | 75 ++-- arch/x86/kvm/x86.h |1 + 4 files changed, 55 insertions(+), 89 deletions(-) --- Changes since v2: - Refactored emulation context initialization code - Commit eip value from the decode cache to the emulation context in x86.c rather than the emulator - Add kvm_* prefix to inject_realmode_interrupt() global symbol for consistency Here is a full trace of a MINIX guest since bootup. Looks like we get stuck somewhere in the BIOS. https://docs.google.com/leaf?id=0B9UodZT1IuENMzJhNWQxM2YtYzE3YS00YWY4LTk2YTgtZWY3ODNhMWUxMDkxsort=namelayout=listnum=50 I debugged this for a bit - emulate_int_real() is completely broken. emulate_push() doesn't push anything, it only schedules a push; running these back-to-back will result in only the last push to be executed. With that fixed, I get the boot splash. Not 100% perfect but much closer. -- 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 0 of 3] Fix KVM on PowerPC 440GP
On 07.08.2010, at 19:33, hollis_blanch...@mentor.com wrote: Hi Avi, these patches make KVM run on 440GP (the only 440-based SoC that wasn't passing the compatibility check) and fix or enhance a couple very minor issues in related code. Please apply. Alex, please ack. Acked-by: Alexander Graf ag...@suse.de Alex -- 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 23/42] KVM: Activate Virtualization On Demand
On 08.08.2010, at 14:02, Serge Belyshev wrote:
Hi! Since the above patch went in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=10474ae8
I have exactly the same problem as Dieter.
If that's the case I'd say you have a broken BIOS or bootloader.
You are right, it seems to be always cpu0. I'll check my BIOS and flash
a newer version if available.
Please do. If that doesn't help ping me again. I'll write up a quirk patch
then.
My h/w is a bit different (cpu: 9850 B3, mb: GA-MA790FX-DQ6 bios F7b),
but I cannot use latest available BIOS (F7d) as it breaks my SAS controller.
So I guess I need the quirk patch.
Hrm - try to use the following (probably whitespace broken and 100% untested)
hacky patch:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 56c9b6b..bde9ee3 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -429,9 +429,11 @@ static int svm_hardware_enable(void *garbage)
struct desc_struct *gdt;
int me = raw_smp_processor_id();
+#if 0
rdmsrl(MSR_EFER, efer);
if (efer EFER_SVME)
return -EBUSY;
+#endif
if (!has_svm()) {
printk(KERN_ERR svm_hardware_enable: err EOPNOTSUPP on %d\n,
Alex--
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 PATCH v3 0/4] Real mode interrupt injection
On Mon, Aug 16, 2010 at 4:19 PM, Avi Kivity a...@redhat.com wrote: On 08/16/2010 02:37 AM, Mohammed Gamal wrote: On Mon, Aug 16, 2010 at 12:46 AM, Mohammed Gamalm.gamal...@gmail.com wrote: This patch introduces real mode interrupt injection for VMX. It currently invokes the x86 emulator to emulate interrupts instead of manually setting VMX controls. Needless to say, this is not meant for merging in its current state. The emulator still needs some more work to get this completely operational. Mohammed Gamal (4): x86 emulator: Expose emulate_int_real() x86: Separate emulation context initialization in a separate function x86: Add kvm_inject_realmode_interrupt() wrapper VMX: Emulated real mode interrupt injection arch/x86/include/asm/kvm_emulate.h | 3 +- arch/x86/kvm/vmx.c | 65 +++ arch/x86/kvm/x86.c | 75 ++-- arch/x86/kvm/x86.h | 1 + 4 files changed, 55 insertions(+), 89 deletions(-) --- Changes since v2: - Refactored emulation context initialization code - Commit eip value from the decode cache to the emulation context in x86.c rather than the emulator - Add kvm_* prefix to inject_realmode_interrupt() global symbol for consistency Here is a full trace of a MINIX guest since bootup. Looks like we get stuck somewhere in the BIOS. https://docs.google.com/leaf?id=0B9UodZT1IuENMzJhNWQxM2YtYzE3YS00YWY4LTk2YTgtZWY3ODNhMWUxMDkxsort=namelayout=listnum=50 I debugged this for a bit - emulate_int_real() is completely broken. emulate_push() doesn't push anything, it only schedules a push; running these back-to-back will result in only the last push to be executed. So we need write back the decode cache after each push. Or let emulate_push() change the emulation context directly. Please CMIIW With that fixed, I get the boot splash. Not 100% perfect but much closer. -- 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 23/42] KVM: Activate Virtualization On Demand
Alexander Graf ag...@suse.de writes:
Hrm - try to use the following (probably whitespace broken and 100% untested)
hacky patch:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 56c9b6b..bde9ee3 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -429,9 +429,11 @@ static int svm_hardware_enable(void *garbage)
struct desc_struct *gdt;
int me = raw_smp_processor_id();
+#if 0
rdmsrl(MSR_EFER, efer);
if (efer EFER_SVME)
return -EBUSY;
+#endif
I tested a bit different hack keeping rdmsrl but removing the if() and
it works fine for me:
Index: linux/arch/x86/kvm/svm.c
===
--- linux.orig/arch/x86/kvm/svm.c
+++ linux/arch/x86/kvm/svm.c
@@ -429,8 +429,7 @@ static int svm_hardware_enable(void *gar
int me = raw_smp_processor_id();
rdmsrl(MSR_EFER, efer);
- if (efer EFER_SVME)
- return -EBUSY;
+ printk(KERN_DEBUG svm_hardware_enable: efer %x on %d\n, efer, me);
if (!has_svm()) {
printk(KERN_ERR svm_hardware_enable: err EOPNOTSUPP on %d\n,
Here is an example of its output:
[231441.358111] svm_hardware_enable: efer 1d01 on 0
[231441.358117] svm_hardware_enable: efer d01 on 3
[231441.358124] svm_hardware_enable: efer d01 on 2
[231441.358135] svm_hardware_enable: efer d01 on 1
[231675.168967] svm_hardware_enable: efer d01 on 0
[231675.168972] svm_hardware_enable: efer d01 on 1
[231675.168983] svm_hardware_enable: efer d01 on 2
[231675.168995] svm_hardware_enable: efer d01 on 3
After reboot, the first kvm run always reports efer = 1d01 on the first cpu.
In all subsequent runs before reboot efer stays d01 on all cpus.
--
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
JFYI: ext4 bug triggerable by kvm
https://bugzilla.kernel.org/show_bug.cgi?id=16165 When a (raw) guest image is placed on an ext4 filesystem, it is possible to get data corruption, now due to ext4 bug, not kvm bug. Also, ext4 is _very_ slow on O_SYNC writes (which is used in kvm with default cache). JFYI. /mjt -- 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 23/42] KVM: Activate Virtualization On Demand
On 16.08.2010, at 15:49, Serge Belyshev wrote:
Alexander Graf ag...@suse.de writes:
Hrm - try to use the following (probably whitespace broken and 100%
untested) hacky patch:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 56c9b6b..bde9ee3 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -429,9 +429,11 @@ static int svm_hardware_enable(void *garbage)
struct desc_struct *gdt;
int me = raw_smp_processor_id();
+#if 0
rdmsrl(MSR_EFER, efer);
if (efer EFER_SVME)
return -EBUSY;
+#endif
I tested a bit different hack keeping rdmsrl but removing the if() and
it works fine for me:
Index: linux/arch/x86/kvm/svm.c
===
--- linux.orig/arch/x86/kvm/svm.c
+++ linux/arch/x86/kvm/svm.c
@@ -429,8 +429,7 @@ static int svm_hardware_enable(void *gar
int me = raw_smp_processor_id();
rdmsrl(MSR_EFER, efer);
- if (efer EFER_SVME)
- return -EBUSY;
+ printk(KERN_DEBUG svm_hardware_enable: efer %x on %d\n, efer, me);
Ouch, yes. Thanks for not taking my patch ;). The efer read is of course still
mandatory.
if (!has_svm()) {
printk(KERN_ERR svm_hardware_enable: err EOPNOTSUPP on %d\n,
Here is an example of its output:
[231441.358111] svm_hardware_enable: efer 1d01 on 0
[231441.358117] svm_hardware_enable: efer d01 on 3
[231441.358124] svm_hardware_enable: efer d01 on 2
[231441.358135] svm_hardware_enable: efer d01 on 1
[231675.168967] svm_hardware_enable: efer d01 on 0
[231675.168972] svm_hardware_enable: efer d01 on 1
[231675.168983] svm_hardware_enable: efer d01 on 2
[231675.168995] svm_hardware_enable: efer d01 on 3
After reboot, the first kvm run always reports efer = 1d01 on the first cpu.
In all subsequent runs before reboot efer stays d01 on all cpus.
Happy broken BIOS fun. Oh well, I guess you can live with the patched version
and normal end-users will just update their BIOSes.
Alex
--
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 PATCH v3 0/4] Real mode interrupt injection
On 08/16/2010 04:28 PM, Mohammed Gamal wrote: I debugged this for a bit - emulate_int_real() is completely broken. emulate_push() doesn't push anything, it only schedules a push; running these back-to-back will result in only the last push to be executed. So we need write back the decode cache after each push. Or let emulate_push() change the emulation context directly. Please CMIIW I wrote a push_std() that uses -write_std() instead of -write_emulated() and can be used back-to-back. Long term we'll need a write queue but for the short term this will do. I'll clean up my patches and push them later on. -- 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: [RFC PATCH v3 0/4] Real mode interrupt injection
On Mon, Aug 16, 2010 at 05:16:01PM +0300, Avi Kivity wrote: On 08/16/2010 04:28 PM, Mohammed Gamal wrote: I debugged this for a bit - emulate_int_real() is completely broken. emulate_push() doesn't push anything, it only schedules a push; running these back-to-back will result in only the last push to be executed. So we need write back the decode cache after each push. Or let emulate_push() change the emulation context directly. Please CMIIW I wrote a push_std() that uses -write_std() instead of -write_emulated() and can be used back-to-back. Long term we'll need a write queue but for the short term this will do. Why not just call writeback() after the emulate_push()? emulate_pusha() does it. -- 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: JFYI: ext4 bug triggerable by kvm
On 08/16/2010 09:00 AM, Michael Tokarev wrote: https://bugzilla.kernel.org/show_bug.cgi?id=16165 When a (raw) guest image is placed on an ext4 filesystem, it is possible to get data corruption, now due to ext4 bug, not kvm bug. Yeah, there appears to be a few O_DIRECT related issues with ext4. AFAIK, a preallocated raw image should be safe though which is probably the only time you should use O_DIRECT. Also, ext4 is _very_ slow on O_SYNC writes (which is used in kvm with default cache). Yeah, we probably need to switch to sync_file_range() to avoid the journal commit on every write. Regards, Anthony Liguori JFYI. /mjt -- 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: Having trouble with ballooning
Hi there again, just wanted to ask, why I'm getting no answers? Everyone's busy? Has this already been discussed (I wouldn't actually believe, if I see how Qemu behaves for example in scenario 1)? If you'd like to have more details about the issue or anything else, please contact me! Thanks! Moritz Duge 05.08.2010 13:41 by Moritz Duge: Hi, I had some trouble while using the ballooning feature of KVM (using Ubuntu 10.04 with standard software versions). The first scenario: 1. Having a guest started by this command: qemu -enable-kvm -m 768 -balloon virtio -cdrom linux_2.6.34.iso The guest is running Linux 2.6.34 including the ballooning driver. 2. Entering balloon 256 and a few seconds later info balloon in the Qemu monitor. Qemu will report, the guest uses 256mb of memory now. The guest is reporting the same (using free for example). 3. Entering change ide1-cd0 linux_2.6.18.iso to change the guests CD-ROM to another image, containing a Linux kernel without ballooning driver. 4. Rebooting the guest. 5. After booting the 2.6.18-OS, it will report it has 768mb memory (using free). But Qemu monitor will still tell 256, when entering info memory. I know why this happens. But is this a good behaviour? Shouldn't Qemu tell something like maybe 256, but there is no more balloon driver in the guest and maybe it uses the full 768 now??? The second scenario: After the first scenario, the guest can also really start using the additional 512mb of memory (768 - 256)!!! I think this shouldn't happen or at least there should be an option to allow or deny this. Or at least least least this should be printed in big letters in the man-pages or somewhere else where everyone will read it! Because before I experienced this, I assumed I can be sure the guest can't get back the memory which was freed using ballooning. So if I use the memory freed by ballooning for some other qemu-instances and the first one starts to use those memory again, all Qemu instances will crash (this is what actually happens in most cases). What I'm asking for, is a way to force the guest to stay in the memory I assigned by ballooning. And if the guest tries to use more memory (maybe because it just unloaded the ballooning driver) the guest should crash, but the host shouldn't get in any trouble!!! This can be really annoying. I think a very common use-case for virtualization is, to run untrusted software or unsecure webservices in a vm, so the bad software can't do anything to the host or other VMs on the host. But when using ballooning, the bad software can! It's no remote code execution, but the guest can consume a lot of memory and cause the host or at least the other VMs on the host to crash. The third scenario: 1. Booting a machine with a guest not having a ballooning driver. (e.g. qemu -enable-kvm -m 768 -balloon virtio -cdrom linux_2.6.18.iso) 2. Adjusting the memory by balloon 512 in the qemu monitor. 3. Qemu won't report that it couldn't adjust the memory. Instead it will wait until the guest loads a ballooning driver. Is this a good behaviour? Shouldn't there be at least a switch in the qemu monitor for the command balloon. So if I use the switch when changing the memory (e.g. balloon -h 256), qemu won't try to change the memory later and it will tell me error: no ballooning driver found. Thanks for reading and thanks a lot, if there will be a solution for this, specially for scenario two. Greetings Moritz Duge -- 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 PATCH v3 0/4] Real mode interrupt injection
On Mon, Aug 16, 2010 at 5:47 PM, Avi Kivity a...@redhat.com wrote: On 08/16/2010 05:29 PM, Gleb Natapov wrote: I wrote a push_std() that uses -write_std() instead of -write_emulated() and can be used back-to-back. Long term we'll need a write queue but for the short term this will do. Why not just call writeback() after the emulate_push()? emulate_pusha() does it. Good idea. I'll do that. I tried it, but it doesn't seem to make any difference. -- 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: [RFC PATCH v3 0/4] Real mode interrupt injection
On Mon, Aug 16, 2010 at 06:23:18PM +0300, Mohammed Gamal wrote: On Mon, Aug 16, 2010 at 5:47 PM, Avi Kivity a...@redhat.com wrote: On 08/16/2010 05:29 PM, Gleb Natapov wrote: I wrote a push_std() that uses -write_std() instead of -write_emulated() and can be used back-to-back. Long term we'll need a write queue but for the short term this will do. Why not just call writeback() after the emulate_push()? emulate_pusha() does it. Good idea. I'll do that. I tried it, but it doesn't seem to make any difference. It should. Can you post what you've tried? -- 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: [RFC PATCH v3 0/4] Real mode interrupt injection
On 08/16/2010 06:31 PM, Gleb Natapov wrote: On Mon, Aug 16, 2010 at 06:23:18PM +0300, Mohammed Gamal wrote: On Mon, Aug 16, 2010 at 5:47 PM, Avi Kivitya...@redhat.com wrote: On 08/16/2010 05:29 PM, Gleb Natapov wrote: I wrote a push_std() that uses -write_std() instead of -write_emulated() and can be used back-to-back. Long term we'll need a write queue but for the short term this will do. Why not just call writeback() after the emulate_push()? emulate_pusha() does it. Good idea. I'll do that. I tried it, but it doesn't seem to make any difference. It should. Can you post what you've tried? There are other bugs involved. I'll post a patchset soon. -- 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: [RFC PATCH v3 0/4] Real mode interrupt injection
2010/8/16 Gleb Natapov g...@redhat.com: On Mon, Aug 16, 2010 at 06:23:18PM +0300, Mohammed Gamal wrote: On Mon, Aug 16, 2010 at 5:47 PM, Avi Kivity a...@redhat.com wrote: On 08/16/2010 05:29 PM, Gleb Natapov wrote: I wrote a push_std() that uses -write_std() instead of -write_emulated() and can be used back-to-back. Long term we'll need a write queue but for the short term this will do. Why not just call writeback() after the emulate_push()? emulate_pusha() does it. Good idea. I'll do that. I tried it, but it doesn't seem to make any difference. It should. Can you post what you've tried? arch/x86/kvm/emulate.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 32498e3..4002c87 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -1219,14 +1219,23 @@ int emulate_int_real(struct x86_emulate_ctxt *ctxt, /* TODO: Add limit checks */ c-src.val = ctxt-eflags; emulate_push(ctxt, ops); + rc = writeback(ctxt, ops); + if (rc != X86EMUL_CONTINUE) + return rc; ctxt-eflags = ~(EFLG_IF | EFLG_TF | EFLG_AC); c-src.val = ops-get_segment_selector(VCPU_SREG_CS, ctxt-vcpu); emulate_push(ctxt, ops); + rc = writeback(ctxt, ops); + if (rc != X86EMUL_CONTINUE) + return rc; c-src.val = c-eip; emulate_push(ctxt, ops); + rc = writeback(ctxt, ops); + if (rc != X86EMUL_CONTINUE) + return rc; I also added some trace_printk()'s and the values for RSP are not updated after writeback. -- 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 v6 3/3] KVM: MMU: prefetch ptes when intercepted guest #PF
On Mon, Aug 16, 2010 at 09:37:23AM +0800, Xiao Guangrong wrote:
Hi Marcelo,
Thanks for your review and sorry for the delay reply.
Marcelo Tosatti wrote:
+static struct kvm_memory_slot *
+pte_prefetch_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn, bool
no_dirty_log)
+{
+ struct kvm_memory_slot *slot;
+
+ slot = gfn_to_memslot(vcpu-kvm, gfn);
+ if (!slot || slot-flags KVM_MEMSLOT_INVALID ||
+(no_dirty_log slot-dirty_bitmap))
+ slot = NULL;
Why is this no_dirty_log optimization worthwhile?
We disable prefetch the writable pages since 'pte prefetch' will hurt slot's
dirty page tracking that it set the dirty_bitmap bit but the corresponding
page
is not really accessed.
+
+ return slot;
+}
+
+static pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn,
+ bool no_dirty_log)
+{
+ struct kvm_memory_slot *slot;
+ unsigned long hva;
+
+ slot = pte_prefetch_gfn_to_memslot(vcpu, gfn, no_dirty_log);
+ if (!slot) {
+ get_page(bad_page);
+ return page_to_pfn(bad_page);
+ }
+
+ hva = gfn_to_hva_memslot(slot, gfn);
+
+ return hva_to_pfn_atomic(vcpu-kvm, hva);
+}
+
+static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
+ struct kvm_mmu_page *sp,
+ u64 *start, u64 *end)
+{
+ struct page *pages[PTE_PREFETCH_NUM];
+ struct kvm_memory_slot *slot;
+ unsigned hva, access = sp-role.access;
+ int i, ret, npages = end - start;
+ gfn_t gfn;
+
+ gfn = kvm_mmu_page_get_gfn(sp, start - sp-spt);
+ slot = pte_prefetch_gfn_to_memslot(vcpu, gfn, access ACC_WRITE_MASK);
+ if (!slot || slot-npages - (gfn - slot-base_gfn) != npages)
+ return -1;
+
+ hva = gfn_to_hva_memslot(slot, gfn);
+ ret = __get_user_pages_fast(hva, npages, 1, pages);
+ if (ret = 0)
+ return -1;
Better do one at a time with hva_to_pfn_atomic. Or, if you measure that
its worthwhile, do on a separate patch (using a helper as discussed
previously).
Since it should disable 'prefetch' for the writable pages, so i'm not put
these
operations into a common function and define it in kvm_main.c file.
Maybe we do better do these in a wrap function named
pte_prefetch_gfn_to_pages()?
Yes, please have it as a common function in kvm_main.c.
--
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: x86: explain 'no-kvmclock' kernel parameter
no-kvmclock kernel parameter is missing its explanation in Documentation/kernel-parameters.txt. Add it. Signed-off-by: Jiri Kosina jkos...@suse.cz --- Documentation/kernel-parameters.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2c85c06..0f9e299 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1693,6 +1693,8 @@ and is between 256 and 4096 characters. It is defined in the file nojitter[IA64] Disables jitter checking for ITC timers. + no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver + nolapic [X86-32,APIC] Do not enable or use the local APIC. nolapic_timer [X86-32,APIC] Do not use the local APIC timer. -- 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 3/7] AMD IOMMU emulation
On Sun, Aug 15, 2010 at 7:27 PM, Eduard - Gabriel Munteanu eduard.munte...@linux360.ro wrote: This introduces emulation for the AMD IOMMU, described in AMD I/O Virtualization Technology (IOMMU) Specification. Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro --- Makefile.target | 2 + hw/amd_iommu.c | 688 +++ hw/pc.c | 2 + hw/pci_ids.h | 2 + hw/pci_regs.h | 1 + 5 files changed, 695 insertions(+), 0 deletions(-) create mode 100644 hw/amd_iommu.c diff --git a/Makefile.target b/Makefile.target index 70a9c1b..6b80a37 100644 --- a/Makefile.target +++ b/Makefile.target @@ -219,6 +219,8 @@ obj-i386-y += pcspk.o i8254.o obj-i386-$(CONFIG_KVM_PIT) += i8254-kvm.o obj-i386-$(CONFIG_KVM_DEVICE_ASSIGNMENT) += device-assignment.o +obj-i386-y += amd_iommu.o + # Hardware support obj-ia64-y += ide.o pckbd.o vga.o $(SOUND_HW) dma.o $(AUDIODRV) obj-ia64-y += fdc.o mc146818rtc.o serial.o i8259.o ipf.o diff --git a/hw/amd_iommu.c b/hw/amd_iommu.c new file mode 100644 index 000..2e20888 --- /dev/null +++ b/hw/amd_iommu.c @@ -0,0 +1,688 @@ +/* + * AMD IOMMU emulation + * + * Copyright (c) 2010 Eduard - Gabriel Munteanu + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the Software), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +#include pc.h +#include hw.h +#include pci.h +#include qlist.h + +/* Capability registers */ +#define CAPAB_HEADER 0x00 +#define CAPAB_REV_TYPE 0x02 +#define CAPAB_FLAGS 0x03 +#define CAPAB_BAR_LOW 0x04 +#define CAPAB_BAR_HIGH 0x08 +#define CAPAB_RANGE 0x0C +#define CAPAB_MISC 0x10 + +#define CAPAB_SIZE 0x14 + +/* Capability header data */ +#define CAPAB_FLAG_IOTLBSUP (1 0) +#define CAPAB_FLAG_HTTUNNEL (1 1) +#define CAPAB_FLAG_NPCACHE (1 2) +#define CAPAB_INIT_REV (1 3) +#define CAPAB_INIT_TYPE 3 +#define CAPAB_INIT_REV_TYPE (CAPAB_REV | CAPAB_TYPE) +#define CAPAB_INIT_FLAGS (CAPAB_FLAG_NPCACHE | CAPAB_FLAG_HTTUNNEL) +#define CAPAB_INIT_MISC (64 15) | (48 8) +#define CAPAB_BAR_MASK ~((1UL 14) - 1) + +/* MMIO registers */ +#define MMIO_DEVICE_TABLE 0x +#define MMIO_COMMAND_BASE 0x0008 +#define MMIO_EVENT_BASE 0x0010 +#define MMIO_CONTROL 0x0018 +#define MMIO_EXCL_BASE 0x0020 +#define MMIO_EXCL_LIMIT 0x0028 +#define MMIO_COMMAND_HEAD 0x2000 +#define MMIO_COMMAND_TAIL 0x2008 +#define MMIO_EVENT_HEAD 0x2010 +#define MMIO_EVENT_TAIL 0x2018 +#define MMIO_STATUS 0x2020 + +#define MMIO_SIZE 0x4000 + +#define MMIO_DEVTAB_SIZE_MASK ((1ULL 12) - 1) +#define MMIO_DEVTAB_BASE_MASK (((1ULL 52) - 1) ~MMIO_DEVTAB_SIZE_MASK) +#define MMIO_DEVTAB_ENTRY_SIZE 32 +#define MMIO_DEVTAB_SIZE_UNIT 4096 + +#define MMIO_CMDBUF_SIZE_BYTE (MMIO_COMMAND_BASE + 7) +#define MMIO_CMDBUF_SIZE_MASK 0x0F +#define MMIO_CMDBUF_BASE_MASK MMIO_DEVTAB_BASE_MASK +#define MMIO_CMDBUF_DEFAULT_SIZE 8 +#define MMIO_CMDBUF_HEAD_MASK (((1ULL 19) - 1) ~0x0F) +#define MMIO_CMDBUF_TAIL_MASK MMIO_EVTLOG_HEAD_MASK + +#define MMIO_EVTLOG_SIZE_BYTE (MMIO_EVENT_BASE + 7) +#define MMIO_EVTLOG_SIZE_MASK MMIO_CMDBUF_SIZE_MASK +#define MMIO_EVTLOG_BASE_MASK MMIO_CMDBUF_BASE_MASK +#define MMIO_EVTLOG_DEFAULT_SIZE MMIO_CMDBUF_DEFAULT_SIZE +#define MMIO_EVTLOG_HEAD_MASK (((1ULL 19) - 1) ~0x0F) +#define MMIO_EVTLOG_TAIL_MASK MMIO_EVTLOG_HEAD_MASK + +#define MMIO_EXCL_BASE_MASK MMIO_DEVTAB_BASE_MASK +#define MMIO_EXCL_ENABLED_MASK (1ULL 0) +#define MMIO_EXCL_ALLOW_MASK (1ULL 1) +#define MMIO_EXCL_LIMIT_MASK MMIO_DEVTAB_BASE_MASK +#define MMIO_EXCL_LIMIT_LOW 0xFFF + +#define
Re: JFYI: ext4 bug triggerable by kvm
On Mon, Aug 16, 2010 at 09:43:09AM -0500, Anthony Liguori wrote: Also, ext4 is _very_ slow on O_SYNC writes (which is used in kvm with default cache). Yeah, we probably need to switch to sync_file_range() to avoid the journal commit on every write. No, we don't. sync_file_range does not actually provide any data integrity. -- 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
RHEL 4.5 guest virtual network performace
Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results ( 4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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: RHEL 4.5 guest virtual network performace
On 08/16/2010 10:00 PM, Alex Rixhardson wrote: Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results ( 4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). Please try netperf, iperf known to be buggy and might consume cpu w/o real justification The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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: JFYI: ext4 bug triggerable by kvm
On 08/16/2010 01:42 PM, Christoph Hellwig wrote: On Mon, Aug 16, 2010 at 09:43:09AM -0500, Anthony Liguori wrote: Also, ext4 is _very_ slow on O_SYNC writes (which is used in kvm with default cache). Yeah, we probably need to switch to sync_file_range() to avoid the journal commit on every write. No, we don't. sync_file_range does not actually provide any data integrity. What do you mean by data integrity? For each write in cache=writethrough, we don't have to ensure the data is on the platter. We really just need to ensure that the data has been sent to next level in the storage hierarchy and that it has been acknowledged as having been written. We don't need to actually inject a barrier. My understanding is that on ext4/btrfs, an O_SYNC write injects a barrier for every write which is not the behavior we're looking for. As I understand it, sync_file_range() would give us the above guarantee without the barrier and for explicit barriers, we would use fsync. Regards, Anthony Liguori -- 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: RHEL 4.5 guest virtual network performace
Thanks for the suggestion. I tried with the netperf. I ran netserver on host and netperf on RHEL 5.5 and RHEL 4.5 guests. This are the results of 60 seconds long tests: RHEL 4.5 guest: Throughput (10^6bits/sec) = 145.80 RHEL 5.5 guest: Throughput (10^6bits/sec) = 3760.24 The results are really bad on RHEL 4.5 guest. What could be wrong? Regards, Alex On Mon, Aug 16, 2010 at 9:49 PM, Dor Laor dl...@redhat.com wrote: On 08/16/2010 10:00 PM, Alex Rixhardson wrote: Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results ( 4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). Please try netperf, iperf known to be buggy and might consume cpu w/o real justification The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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: RHEL 4.5 guest virtual network performace
On 08/17/2010 12:22 AM, Alex Rixhardson wrote: Thanks for the suggestion. I tried with the netperf. I ran netserver on host and netperf on RHEL 5.5 and RHEL 4.5 guests. This are the results of 60 seconds long tests: RHEL 4.5 guest: Throughput (10^6bits/sec) = 145.80 At least it bought you another 5Mb/s over iperf ... It might be time related, 5.5 has kvmclock but rhel4 does not. If it's 64 bit guest add this to the 4.5 guest cmdline 'notsc divider=10'. If it's 32 use 'clock=pmtmr divider=10'. The divider is probably new and is in rhel4.8 only, it's ok w/o it too. What's the host load for the 4.5 guest? RHEL 5.5 guest: Throughput (10^6bits/sec) = 3760.24 The results are really bad on RHEL 4.5 guest. What could be wrong? Regards, Alex On Mon, Aug 16, 2010 at 9:49 PM, Dor Laordl...@redhat.com wrote: On 08/16/2010 10:00 PM, Alex Rixhardson wrote: Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results (4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). Please try netperf, iperf known to be buggy and might consume cpu w/o real justification The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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 -- 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
KVM Forum 2010: presentations online
KVM Forum 2010 was quite a success, many thanks to all who participated! For those who couldn't attend, the presentations are available online now: (thanks to Andrew Cathrow for pushing them all up) http://www.linux-kvm.org/page/KVM_Forum_2010#Presentations We were also able to video the speakers, and will send a note when the videos are available. (and thanks again to Andrew Cathrow for making this happen) thanks, -chris -- 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: RHEL 4.5 guest virtual network performace
I tried with 'notsc divider=10' (since it's 64 bit guest), but the results are the still same :-(. The guest is idle at the time of testing. It has 2 CPU and 1024 MB RAM available. On Mon, Aug 16, 2010 at 11:35 PM, Dor Laor dl...@redhat.com wrote: On 08/17/2010 12:22 AM, Alex Rixhardson wrote: Thanks for the suggestion. I tried with the netperf. I ran netserver on host and netperf on RHEL 5.5 and RHEL 4.5 guests. This are the results of 60 seconds long tests: RHEL 4.5 guest: Throughput (10^6bits/sec) = 145.80 At least it bought you another 5Mb/s over iperf ... It might be time related, 5.5 has kvmclock but rhel4 does not. If it's 64 bit guest add this to the 4.5 guest cmdline 'notsc divider=10'. If it's 32 use 'clock=pmtmr divider=10'. The divider is probably new and is in rhel4.8 only, it's ok w/o it too. What's the host load for the 4.5 guest? RHEL 5.5 guest: Throughput (10^6bits/sec) = 3760.24 The results are really bad on RHEL 4.5 guest. What could be wrong? Regards, Alex On Mon, Aug 16, 2010 at 9:49 PM, Dor Laordl...@redhat.com wrote: On 08/16/2010 10:00 PM, Alex Rixhardson wrote: Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results ( 4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). Please try netperf, iperf known to be buggy and might consume cpu w/o real justification The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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 -- 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: RHEL 4.5 guest virtual network performace
On 08/17/2010 12:51 AM, Alex Rixhardson wrote: I tried with 'notsc divider=10' (since it's 64 bit guest), but the results are the still same :-(. The guest is idle at the time of testing. It has 2 CPU and 1024 MB RAM available. Hmm, are you using e1000 or virtio for the 4.5 guest? e1000 should be slow since it's less suitable for virtualization (3 mmio/packet) On Mon, Aug 16, 2010 at 11:35 PM, Dor Laordl...@redhat.com wrote: On 08/17/2010 12:22 AM, Alex Rixhardson wrote: Thanks for the suggestion. I tried with the netperf. I ran netserver on host and netperf on RHEL 5.5 and RHEL 4.5 guests. This are the results of 60 seconds long tests: RHEL 4.5 guest: Throughput (10^6bits/sec) = 145.80 At least it bought you another 5Mb/s over iperf ... It might be time related, 5.5 has kvmclock but rhel4 does not. If it's 64 bit guest add this to the 4.5 guest cmdline 'notsc divider=10'. If it's 32 use 'clock=pmtmr divider=10'. The divider is probably new and is in rhel4.8 only, it's ok w/o it too. What's the host load for the 4.5 guest? RHEL 5.5 guest: Throughput (10^6bits/sec) = 3760.24 The results are really bad on RHEL 4.5 guest. What could be wrong? Regards, Alex On Mon, Aug 16, 2010 at 9:49 PM, Dor Laordl...@redhat.comwrote: On 08/16/2010 10:00 PM, Alex Rixhardson wrote: Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results ( 4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). Please try netperf, iperf known to be buggy and might consume cpu w/o real justification The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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 -- 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: KVM Forum 2010: presentations online
* Dor Laor (dl...@redhat.com) wrote: On 08/17/2010 12:50 AM, Chris Wright wrote: KVM Forum 2010 was quite a success, many thanks to all who participated! For those who couldn't attend, the presentations are available online now: (thanks to Andrew Cathrow for pushing them all up) http://www.linux-kvm.org/page/KVM_Forum_2010#Presentations I Beat you in a second ;-) Assuming accurate local clocks...6 seconds even ;) -- 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: RHEL 4.5 guest virtual network performace
virtio...I think :-). How could I confirm that? Regards, Alex On Mon, Aug 16, 2010 at 11:56 PM, Dor Laor dl...@redhat.com wrote: On 08/17/2010 12:51 AM, Alex Rixhardson wrote: I tried with 'notsc divider=10' (since it's 64 bit guest), but the results are the still same :-(. The guest is idle at the time of testing. It has 2 CPU and 1024 MB RAM available. Hmm, are you using e1000 or virtio for the 4.5 guest? e1000 should be slow since it's less suitable for virtualization (3 mmio/packet) On Mon, Aug 16, 2010 at 11:35 PM, Dor Laordl...@redhat.com wrote: On 08/17/2010 12:22 AM, Alex Rixhardson wrote: Thanks for the suggestion. I tried with the netperf. I ran netserver on host and netperf on RHEL 5.5 and RHEL 4.5 guests. This are the results of 60 seconds long tests: RHEL 4.5 guest: Throughput (10^6bits/sec) = 145.80 At least it bought you another 5Mb/s over iperf ... It might be time related, 5.5 has kvmclock but rhel4 does not. If it's 64 bit guest add this to the 4.5 guest cmdline 'notsc divider=10'. If it's 32 use 'clock=pmtmr divider=10'. The divider is probably new and is in rhel4.8 only, it's ok w/o it too. What's the host load for the 4.5 guest? RHEL 5.5 guest: Throughput (10^6bits/sec) = 3760.24 The results are really bad on RHEL 4.5 guest. What could be wrong? Regards, Alex On Mon, Aug 16, 2010 at 9:49 PM, Dor Laordl...@redhat.com wrote: On 08/16/2010 10:00 PM, Alex Rixhardson wrote: Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results ( 4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). Please try netperf, iperf known to be buggy and might consume cpu w/o real justification The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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 -- 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
KVM call agenda for August 17
Please send in any agenda items you are interested in covering. thanks, -chris -- 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: RHEL 4.5 guest virtual network performace
Thank you a lot for the tip - you were right. The 5.5 guest is using virtio, but 4.5 is not. So, this is the reason. Adding model type='virtio' / to the config file unfortunately doesn't help - the network card is not recognized by the guest. Do I need to install something extra on the guest RHEL 4.5? Regards, Alex On Tue, Aug 17, 2010 at 12:05 AM, Alex Rixhardson alexrixhard...@gmail.com wrote: virtio...I think :-). How could I confirm that? Regards, Alex On Mon, Aug 16, 2010 at 11:56 PM, Dor Laor dl...@redhat.com wrote: On 08/17/2010 12:51 AM, Alex Rixhardson wrote: I tried with 'notsc divider=10' (since it's 64 bit guest), but the results are the still same :-(. The guest is idle at the time of testing. It has 2 CPU and 1024 MB RAM available. Hmm, are you using e1000 or virtio for the 4.5 guest? e1000 should be slow since it's less suitable for virtualization (3 mmio/packet) On Mon, Aug 16, 2010 at 11:35 PM, Dor Laordl...@redhat.com wrote: On 08/17/2010 12:22 AM, Alex Rixhardson wrote: Thanks for the suggestion. I tried with the netperf. I ran netserver on host and netperf on RHEL 5.5 and RHEL 4.5 guests. This are the results of 60 seconds long tests: RHEL 4.5 guest: Throughput (10^6bits/sec) = 145.80 At least it bought you another 5Mb/s over iperf ... It might be time related, 5.5 has kvmclock but rhel4 does not. If it's 64 bit guest add this to the 4.5 guest cmdline 'notsc divider=10'. If it's 32 use 'clock=pmtmr divider=10'. The divider is probably new and is in rhel4.8 only, it's ok w/o it too. What's the host load for the 4.5 guest? RHEL 5.5 guest: Throughput (10^6bits/sec) = 3760.24 The results are really bad on RHEL 4.5 guest. What could be wrong? Regards, Alex On Mon, Aug 16, 2010 at 9:49 PM, Dor Laordl...@redhat.com wrote: On 08/16/2010 10:00 PM, Alex Rixhardson wrote: Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results ( 4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). Please try netperf, iperf known to be buggy and might consume cpu w/o real justification The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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 -- 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: [PATCH] kvm: make mmu_shrink() fit shrinker's requirement
On Sun, Aug 15, 2010 at 4:14 AM, Avi Kivity a...@redhat.com wrote: On 08/13/2010 11:10 PM, Dave Hansen wrote: On Thu, 2010-08-05 at 12:28 +0300, Avi Kivity wrote: On 08/04/2010 10:13 AM, Lai Jiangshan wrote: mmu_shrink() should attempt to free @nr_to_scan entries. This conflicts with Dave's patchset. Dave, what's going on with those patches? They're starting to smell. These seem to fix the original problem reporter's issue. They were run with 64 guests on a 32GB machine. No stability problems popped up in this testing, or since I last sent the patches to you. The results from both the test with only the first four patches and with the entire set of nine looked pretty identical. That tells me that we should only push the first four for now: abstract kvm x86 mmu-n_free_mmu_pages rename x86 kvm-arch.n_alloc_mmu_pages replace x86 kvm n_free_mmu_pages with n_used_mmu_pages create aggregate kvm_total_used_mmu_pages value Well, patches 3 and 4 have unaddressed review comments. Please fix them up. If you don't have the time, let me know and I'll do it instead. Dave's out on vacation now so it's probably best to assume he wont get those fixups done very quickly. Marcelo's comment on patch 3 is simple. The conversation regarding patch 4 back in June though doesn't read like it clearly concluded...I'd be happy to work something up, but if you've got strong preferences on which route to use for protecting the count maybe I should leave it to you? Tim -- 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 1/2 v4] KVM: x86 emulator: put register operand write back to a function
Introduce function write_register_operand() to write back the
register operand.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c | 55 ---
1 files changed, 23 insertions(+), 32 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index c476a67..d690daf 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1020,6 +1020,25 @@ exception:
return X86EMUL_PROPAGATE_FAULT;
}
+static void write_register_operand(struct operand *op)
+{
+ /* The 4-byte case *is* correct: in 64-bit mode we zero-extend. */
+ switch (op-bytes) {
+ case 1:
+ *(u8 *)op-addr.reg = (u8)op-val;
+ break;
+ case 2:
+ *(u16 *)op-addr.reg = (u16)op-val;
+ break;
+ case 4:
+ *op-addr.reg = (u32)op-val;
+ break; /* 64b: zero-extend */
+ case 8:
+ *op-addr.reg = op-val;
+ break;
+ }
+}
+
static inline int writeback(struct x86_emulate_ctxt *ctxt,
struct x86_emulate_ops *ops)
{
@@ -1029,23 +1048,7 @@ static inline int writeback(struct x86_emulate_ctxt
*ctxt,
switch (c-dst.type) {
case OP_REG:
- /* The 4-byte case *is* correct:
-* in 64-bit mode we zero-extend.
-*/
- switch (c-dst.bytes) {
- case 1:
- *(u8 *)c-dst.addr.reg = (u8)c-dst.val;
- break;
- case 2:
- *(u16 *)c-dst.addr.reg = (u16)c-dst.val;
- break;
- case 4:
- *c-dst.addr.reg = (u32)c-dst.val;
- break; /* 64b: zero-ext */
- case 8:
- *c-dst.addr.reg = c-dst.val;
- break;
- }
+ write_register_operand(c-dst);
break;
case OP_MEM:
if (c-lock_prefix)
@@ -2971,25 +2974,13 @@ special_insn:
case 0x86 ... 0x87: /* xchg */
xchg:
/* Write back the register source. */
- switch (c-dst.bytes) {
- case 1:
- *(u8 *) c-src.addr.reg = (u8) c-dst.val;
- break;
- case 2:
- *(u16 *) c-src.addr.reg = (u16) c-dst.val;
- break;
- case 4:
- *c-src.addr.reg = (u32) c-dst.val;
- break; /* 64b reg: zero-extend */
- case 8:
- *c-src.addr.reg = c-dst.val;
- break;
- }
+ c-src.val = c-dst.val;
+ write_register_operand(c-src);
/*
* Write back the memory destination with implicit LOCK
* prefix.
*/
- c-dst.val = c-src.val;
+ c-dst.val = c-src.orig_val;
c-lock_prefix = 1;
break;
case 0x88 ... 0x8b: /* mov */
--
1.7.0.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
[PATCH 2/2 v4] KVM: x86 emulator: add XADD instruction emulation
Add XADD instruction emulation (opcode 0x0f 0xc0~0xc1)
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index d690daf..41ca98b 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2386,7 +2386,8 @@ static struct opcode twobyte_table[256] = {
D(DstReg | SrcMem | ModRM), D(DstReg | SrcMem | ModRM),
D(ByteOp | DstReg | SrcMem | ModRM | Mov), D(DstReg | SrcMem16 | ModRM
| Mov),
/* 0xC0 - 0xCF */
- N, N, N, D(DstMem | SrcReg | ModRM | Mov),
+ D(ByteOp | DstMem | SrcReg | ModRM | Lock), D(DstMem | SrcReg | ModRM |
Lock),
+ N, D(DstMem | SrcReg | ModRM | Mov),
N, N, N, GD(0, group9),
N, N, N, N, N, N, N, N,
/* 0xD0 - 0xDF */
@@ -3532,6 +3533,12 @@ twobyte_insn:
c-dst.val = (c-d ByteOp) ? (s8) c-src.val :
(s16) c-src.val;
break;
+ case 0xc0 ... 0xc1: /* xadd */
+ emulate_2op_SrcV(add, c-src, c-dst, ctxt-eflags);
+ /* Write back the register source. */
+ c-src.val = c-dst.orig_val;
+ write_register_operand(c-src);
+ break;
case 0xc3: /* movnti */
c-dst.bytes = c-op_bytes;
c-dst.val = (c-op_bytes == 4) ? (u32) c-src.val :
--
1.7.0.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: RHEL 4.5 guest virtual network performace
On 08/16/10 17:09, Alex Rixhardson wrote: Thank you a lot for the tip - you were right. The 5.5 guest is using virtio, but 4.5 is not. So, this is the reason. Adding model type='virtio' / to the config file unfortunately doesn't help - the network card is not recognized by the guest. Do I need to install something extra on the guest RHEL 4.5? RHEL4.8 is the first RHEL4 version to support virtio devices. David Regards, Alex On Tue, Aug 17, 2010 at 12:05 AM, Alex Rixhardson alexrixhard...@gmail.com wrote: virtio...I think :-). How could I confirm that? Regards, Alex On Mon, Aug 16, 2010 at 11:56 PM, Dor Laor dl...@redhat.com wrote: On 08/17/2010 12:51 AM, Alex Rixhardson wrote: I tried with 'notsc divider=10' (since it's 64 bit guest), but the results are the still same :-(. The guest is idle at the time of testing. It has 2 CPU and 1024 MB RAM available. Hmm, are you using e1000 or virtio for the 4.5 guest? e1000 should be slow since it's less suitable for virtualization (3 mmio/packet) On Mon, Aug 16, 2010 at 11:35 PM, Dor Laordl...@redhat.com wrote: On 08/17/2010 12:22 AM, Alex Rixhardson wrote: Thanks for the suggestion. I tried with the netperf. I ran netserver on host and netperf on RHEL 5.5 and RHEL 4.5 guests. This are the results of 60 seconds long tests: RHEL 4.5 guest: Throughput (10^6bits/sec) = 145.80 At least it bought you another 5Mb/s over iperf ... It might be time related, 5.5 has kvmclock but rhel4 does not. If it's 64 bit guest add this to the 4.5 guest cmdline 'notsc divider=10'. If it's 32 use 'clock=pmtmr divider=10'. The divider is probably new and is in rhel4.8 only, it's ok w/o it too. What's the host load for the 4.5 guest? RHEL 5.5 guest: Throughput (10^6bits/sec) = 3760.24 The results are really bad on RHEL 4.5 guest. What could be wrong? Regards, Alex On Mon, Aug 16, 2010 at 9:49 PM, Dor Laordl...@redhat.comwrote: On 08/16/2010 10:00 PM, Alex Rixhardson wrote: Hi guys, I have the following configuration: 1. host is RHEL 5.5, 64bit with KVM (version that comes out of the box with RHEL 5.5) 2. two guests: 2a: RHEL 5.5, 32bit, 2b: RHEL 4.5, 64bit If I run iperf between host RHEL 5.5 and guest RHEL 5.5 inside the virtual network subnet I get great results ( 4Gbit/sec). But if I run iperf between guest RHEL 4.5 and either of the two RHELs 5.5 I get bad network performance (around 140Mbit/sec). Please try netperf, iperf known to be buggy and might consume cpu w/o real justification The configuration was made thru virtual-manager utility, nothing special. I just added virtual network device to both guests. Could you guys give me some tips on what should I check? Regards, Alex -- 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 -- 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 -- 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 RESEND] KVM: PPC: fix leakage of error page in kvmppc_patch_dcbz()
Add kvm_release_page_clean() after is_error_page() to avoid
leakage of error page.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/powerpc/kvm/book3s.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index eee97b5..7656b6d 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -455,8 +455,10 @@ static void kvmppc_patch_dcbz(struct kvm_vcpu *vcpu,
struct kvmppc_pte *pte)
int i;
hpage = gfn_to_page(vcpu-kvm, pte-raddr PAGE_SHIFT);
- if (is_error_page(hpage))
+ if (is_error_page(hpage)) {
+ kvm_release_page_clean(hpage);
return;
+ }
hpage_offset = pte-raddr ~PAGE_MASK;
hpage_offset = ~0xFFFULL;
--
1.7.0.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
about page fault handler?
hi all, i am reading kvm code , the folllowing is my understanding. 1, see if guest page table is not mapped , inject fault to the guest. 2, see if gpte dirty is set ,in order to synchronize the pte dirty with spte 3, if not , see if spte it not mapped or write protection ,to handler it. i do not know whether my analysis is right . or can any body detail it ? the page fault handler processing. thanks. -- 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: FW: intel_scu_ipc
This problem seem exist in other distribution eg.
http://stackoverflow.com/questions/3434676/error-while-compiling-the-linux-kernel-2-6-35
http://www.spinics.net/lists/linux-wireless/msg54197.html
How can the kvm to compile it if without disabling intel_scu_ipc?.
CC to KVM-ML
2010/8/17 Hong Liu hong@intel.com:
On Tue, 2010-08-17 at 13:12 +0800, Zhou Peng wrote:
I don't know :)
I get the kernel(http://www.linux-kvm.org/page/Code) by
git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
Looks like it merged the intel_scu_ipc code while forgetting the mrst.h
change.
2010/8/17 Hong Liu hong@intel.com:
On Tue, 2010-08-17 at 12:54 +0800, Zhou Peng wrote:
Hi,
But MRST_CPU_CHIP_PENWELL is missing in my source. The complete file is
below.
So... which kernel are you using for compile?
Thanks,
Hong
---
kvm$ find -name mrst.h
./include/config/x86/mrst.h
./arch/x86/include/asm/mrst.h
kvm$ vim arch/x86/include/asm/mrst.h
kvm$ vim include/config/x86/mrst.h
kvm$ cat include/config/x86/mrst.h
kvm$ cat arch/x86/include/asm/mrst.h
/*
* mrst.h: Intel Moorestown platform specific setup code
*
* (C) Copyright 2009 Intel Corporation
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; version 2
* of the License.
*/
#ifndef _ASM_X86_MRST_H
#define _ASM_X86_MRST_H
extern int pci_mrst_init(void);
int __init sfi_parse_mrtc(struct sfi_table_header *table);
#define SFI_MTMR_MAX_NUM 8
#define SFI_MRTC_MAX 8
#endif /* _ASM_X86_MRST_H */
Thanks,
2010/8/17 Hong Liu hong@intel.com:
On Tue, 2010-08-17 at 11:38 +0800, Ds, Sreedhara wrote:
-Original Message-
From: Zhou Peng [mailto:ailvpen...@gmail.com]
Sent: Tuesday, August 17, 2010 8:26 AM
To: Ds, Sreedhara
Subject: intel_scu_ipc
Hi Sreedhara DS,
Where does MRST_CPU_CHIP_PENWELL be defined please?
It is defined in asm/mrst.h, please check the
arch/x86/include/asm/mrst.h file, seems there is problem with the
sfi_table_header structure which defined in include/linux/sfi.h.
Thanks,
Hong
While compiling the kvm linux kernel on my ubuntu 10.04(Linux
-laptop 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC
2010 i686 GNU/Linux), the err below appear, How to figure out please?
=err msg=
drivers/platform/x86/intel_scu_ipc.c: In function 'pwr_reg_rdwr':
drivers/platform/x86/intel_scu_ipc.c:175: error:
'MRST_CPU_CHIP_PENWELL' undeclared (first use in this function)
drivers/platform/x86/intel_scu_ipc.c:175: error: (Each undeclared
identifier is rep
orted only once
drivers/platform/x86/intel_scu_ipc.c:175: error: for each function it
appears in.)
drivers/platform/x86/intel_scu_ipc.c: In function
'intel_scu_ipc_init':
drivers/platform/x86/intel_scu_ipc.c:741: error: implicit declaration
of function '
mrst_identify_cpu'
make[3]: *** [drivers/platform/x86/intel_scu_ipc.o] Error 1
make[2]: *** [drivers/platform/x86] Error 2
make[1]: *** [drivers/platform] Error 2
make: *** [drivers] Error 2
=search the kvm kernel tree=
kvm$ grep MRST_CPU_CHIP_PENWELL . -R
./drivers/platform/x86/intel_scu_ipc.c: if (platform
!=MRST_CPU_CHIP_PENWELL) {
./drivers/platform/x86/intel_scu_ipc.c: if (platform
!=MRST_CPU_CHIP_PENWELL) {
Thanks,
Best,
--
Zhou Peng
--
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 00/27] KVM PPC PV framework v3
On 06.08.2010, at 18:28, Kumar Gala wrote:
On Jul 29, 2010, at 7:47 AM, Alexander Graf wrote:
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /dev/null;
done
real0m14.659s
user0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /dev/null;
done
real0m7.557s
user0m4.121s
sys 0m3.426s
Do you have #'s for w/o HV to compare to.
Native was around 2-3 seconds overall. So we still have quite a big impact on
performance, but things are improving :).
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc 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 of 3] Fix KVM on PowerPC 440GP
On 07.08.2010, at 19:33, hollis_blanch...@mentor.com wrote: Hi Avi, these patches make KVM run on 440GP (the only 440-based SoC that wasn't passing the compatibility check) and fix or enhance a couple very minor issues in related code. Please apply. Alex, please ack. Acked-by: Alexander Graf ag...@suse.de Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
