[PATCH] 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
---
arch/x86/kvm/emulate.c | 28 ++--
1 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index fb4ac8c..831aa6e 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2342,8 +2342,8 @@ static struct opcode twobyte_table[256] = {
/* 0xB8 - 0xBF */
N, N,
G(BitOp, group8), D(DstMem | SrcReg | ModRM | BitOp | Lock),
- N, N, D(ByteOp | DstReg | SrcMem | ModRM | Mov),
- D(DstReg | SrcMem16 | ModRM | Mov),
+ 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),
N, N, N, GD(0, group9),
@@ -3464,6 +3464,30 @@ twobyte_insn:
btc: /* btc */
emulate_2op_SrcV_nobyte(btc, c-src, c-dst, ctxt-eflags);
break;
+ case 0xbc: {/* bsf */
+ int zf;
+ __asm__ (bsf %2, %0; setz %b1
+: =r(c-dst.val), =q(zf)
+: r(c-src.val), 1 (0));
+ ctxt-eflags = ~X86_EFLAGS_ZF;
+ if (zf) {
+ ctxt-eflags |= X86_EFLAGS_ZF;
+ c-dst.type = OP_NONE; /* Disable writeback. */
+ }
+ break;
+ }
+ case 0xbd: {/* bsr */
+ int zf;
+ __asm__ (bsr %2, %0; setz %b1
+: =r(c-dst.val), =q(zf)
+: r(c-src.val), 1 (0));
+ ctxt-eflags = ~X86_EFLAGS_ZF;
+ if (zf) {
+ ctxt-eflags |= X86_EFLAGS_ZF;
+ c-dst.type = OP_NONE; /* Disable writeback. */
+ }
+ break;
+ }
case 0xbe ... 0xbf: /* movsx */
c-dst.bytes = c-op_bytes;
c-dst.val = (c-d ByteOp) ? (s8) 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
[PATCH] test: add test for bsf/bsr instruction
This patch add test for bsf/bsr instruction.
Signed-off-by: Wei Yongjunyj...@cn.fujitsu.com
---
x86/emulator.c | 64
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/x86/emulator.c b/x86/emulator.c
index aef5d90..348d548 100644
--- a/x86/emulator.c
+++ b/x86/emulator.c
@@ -462,6 +462,69 @@ void test_setcc(void *mem)
report(setnle r/m8, *memb == 0);
}
+void test_bsfbsr(void *mem)
+{
+ unsigned long *memq = mem, rax;
+
+ asm volatile(movw $0xC000, (%[memq])\n\t
+bsfw (%[memq]), %%ax\n\t
+::[memq]r(memq));
+ asm (mov %%rax, %[rax]: [rax]=m(rax));
+ report(bsfw r/m, reg, rax == 14);
+
+ asm volatile(movl $0xC000, (%[memq])\n\t
+bsfl (%[memq]), %%eax\n\t
+::[memq]r(memq));
+ asm (mov %%rax, %[rax]: [rax]=m(rax));
+ report(bsfl r/m, reg, rax == 30);
+
+ asm volatile(movq $0xC000, %%rax\n\t
+movq %%rax, (%[memq])\n\t
+bsfq (%[memq]), %%rax\n\t
+::[memq]r(memq));
+ asm (mov %%rax, %[rax]: [rax]=m(rax));
+ report(bsfq r/m, reg, rax == 46);
+
+ asm volatile(movq $0, %%rax\n\t
+movq %%rax, (%[memq])\n\t
+bsfq (%[memq]), %%rax\n\t
+jnz 1f\n\t
+movl $1, %[rax]\n\t
+1:\n\t
+:[rax]=m(rax)
+:[memq]r(memq));
+ report(bsfq r/m, reg, rax == 1);
+
+ asm volatile(movw $0xC000, (%[memq])\n\t
+bsrw (%[memq]), %%ax\n\t
+::[memq]r(memq));
+ asm (mov %%rax, %[rax]: [rax]=m(rax));
+ report(bsrw r/m, reg, rax == 15);
+
+ asm volatile(movl $0xC000, (%[memq])\n\t
+bsrl (%[memq]), %%eax\n\t
+::[memq]r(memq));
+ asm (mov %%rax, %[rax]: [rax]=m(rax));
+ report(bsrl r/m, reg, rax == 31);
+
+ asm volatile(movq $0xC000, %%rax\n\t
+movq %%rax, (%[memq])\n\t
+bsrq (%[memq]), %%rax\n\t
+::[memq]r(memq));
+ asm (mov %%rax, %[rax]: [rax]=m(rax));
+ report(bsrq r/m, reg, rax == 47);
+
+ asm volatile(movq $0, %%rax\n\t
+movq %%rax, (%[memq])\n\t
+bsrq (%[memq]), %%rax\n\t
+jnz 1f\n\t
+movl $1, %[rax]\n\t
+1:\n\t
+:[rax]=m(rax)
+:[memq]r(memq));
+ report(bsrq r/m, reg, rax == 1);
+}
+
int main()
{
void *mem;
@@ -495,6 +558,7 @@ int main()
test_incdecnotneg(mem);
test_btc(mem);
test_setcc(mem);
+ test_bsfbsr(mem);
printf(\nSUMMARY: %d tests, %d failures\n, tests, fails);
return fails ? 1 : 0;
--
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
KSM with Debian GNU/Linux
Hi all! I have understood that in addition to support from the kernel and qemu-kvm, there must be support in libc. So in testing I was doing on Lenny, it did not work using libc from Debian repositories. Now that squeeze is frozen, anyone knows if it will support KSM? Has anyone had success making KSM works on Lenny? Michael? Thanks in advance for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
Re: KSM with Debian GNU/Linux
09.08.2010 14:16, Daniel Bareiro wrote: Hi all! I have understood that in addition to support from the kernel and qemu-kvm, there must be support in libc. So in testing I was doing on Lenny, it did not work using libc from Debian repositories. Now that squeeze is frozen, anyone knows if it will support KSM? KSM is working in qemu-kvm packages in bpo, for quite long time already. It has nothing to do with libc, and now it does not even require recent-enough kernel headers to compile. What's needed is recent-enough kernel that actually implements the feature. The kernel in Lenny does not KSM support, but the one in bpo has. Also note that Lenny's kernel is too old for kvm. /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: KSM with Debian GNU/Linux
Hi, I don't have clue what glibc is contained in debian, but it seems to me that at least compile-time KSM support DOES depend on glibc. I'm using RHEL5-based system and KSM support doesn't get compiled in by default. But since I use new kernel, I add following to CFLAGS while compiling qemu-kvm and then it works: -DMADV_MERGEABLE=12 -DMADV_UNMERGEABLE=13 just my 5cents regards nik On Mon, Aug 09, 2010 at 02:27:12PM +0400, Michael Tokarev wrote: 09.08.2010 14:16, Daniel Bareiro wrote: Hi all! I have understood that in addition to support from the kernel and qemu-kvm, there must be support in libc. So in testing I was doing on Lenny, it did not work using libc from Debian repositories. Now that squeeze is frozen, anyone knows if it will support KSM? KSM is working in qemu-kvm packages in bpo, for quite long time already. It has nothing to do with libc, and now it does not even require recent-enough kernel headers to compile. What's needed is recent-enough kernel that actually implements the feature. The kernel in Lenny does not KSM support, but the one in bpo has. Also note that Lenny's kernel is too old for kvm. /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 -- - Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - -- 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: KSM with Debian GNU/Linux
09.08.2010 15:00, Nikola Ciprich пишет: Hi, I don't have clue what glibc is contained in debian, but it seems to me that at least compile-time KSM support DOES depend on glibc. I'm using RHEL5-based system and KSM support doesn't get compiled in by default. For KSM to be compiled in, one need to have kernel headers of the corresponding system interface (madvise() system call). That is not part of glibc (even while madvise function is declared by glibc) but part of kernel headers which glibc uses itself during compilation. In debian that comes in linux-libc-dev package, some other distribution may bundle it together with glibc but that's pure packaging stuff, these headers does not come from glibc sources. But since I use new kernel, I add following to CFLAGS while compiling qemu-kvm and then it works: -DMADV_MERGEABLE=12 -DMADV_UNMERGEABLE=13 This is what the patch in debian package does, to get KSM-ready binary even without recent-enough kernel headers (like on Lenny). /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: KSM with Debian GNU/Linux
On Monday, 09 August 2010 14:27:12 +0400, Michael Tokarev wrote: I have understood that in addition to support from the kernel and qemu-kvm, there must be support in libc. So in testing I was doing on Lenny, it did not work using libc from Debian repositories. Now that squeeze is frozen, anyone knows if it will support KSM? KSM is working in qemu-kvm packages in bpo, for quite long time already. It has nothing to do with libc, and now it does not even require recent-enough kernel headers to compile. What's needed is recent-enough kernel that actually implements the feature. The kernel in Lenny does not KSM support, but the one in bpo has. Also note that Lenny's kernel is too old for kvm. I'm using Linux 2.6.32.3 compiled by myself with the kernel.org source code with support for KSM: # cat /boot/config-2.6.32.3-dgb | grep KSM CONFIG_KSM=y I'm also using qemu-kvm 0.12.1.2 compiled by myself with the source code of SourceForge. These are the checks that I was doing in the VMHost: # ll /sys/kernel/mm/ksm/ total 0 -r--r--r-- 1 root root 4096 ago 9 06:28 full_scans -rw-r--r-- 1 root root 4096 ago 9 06:28 max_kernel_pages -r--r--r-- 1 root root 4096 ago 9 06:28 pages_shared -r--r--r-- 1 root root 4096 ago 9 06:28 pages_sharing -rw-r--r-- 1 root root 4096 ago 9 06:28 pages_to_scan -r--r--r-- 1 root root 4096 ago 9 06:28 pages_unshared -r--r--r-- 1 root root 4096 ago 9 06:28 pages_volatile -rw-r--r-- 1 root root 4096 ago 9 06:27 run -rw-r--r-- 1 root root 4096 ago 9 06:28 sleep_millisecs # cat /sys/kernel/mm/ksm/max_kernel_pages 253500 But KSM seems not work: # cat /sys/kernel/mm/ksm/pages_sharing 0 Should I have some additional consideration when compiling qemu-kvm? Thanks for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
Re: KSM with Debian GNU/Linux
On Monday, 09 August 2010 13:00:49 +0200, Nikola Ciprich wrote: Hi, Hi, Nikola. I don't have clue what glibc is contained in debian, but it seems to me that at least compile-time KSM support DOES depend on glibc. I'm using RHEL5-based system and KSM support doesn't get compiled in by default. But since I use new kernel, I add following to CFLAGS while compiling qemu-kvm and then it works: -DMADV_MERGEABLE=12 -DMADV_UNMERGEABLE=13 My comments on the dependency of glibc support was based on reading this bug report [1]. Regards, Daniel [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556631 -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
Re: KSM with Debian GNU/Linux
09.08.2010 18:27, Daniel Bareiro wrote: On Monday, 09 August 2010 14:27:12 +0400, Michael Tokarev wrote: I have understood that in addition to support from the kernel and qemu-kvm, there must be support in libc. So in testing I was doing on Lenny, it did not work using libc from Debian repositories. Now that squeeze is frozen, anyone knows if it will support KSM? KSM is working in qemu-kvm packages in bpo, for quite long time already. It has nothing to do with libc, and now it does not even require recent-enough kernel headers to compile. What's needed is recent-enough kernel that actually implements the feature. The kernel in Lenny does not KSM support, but the one in bpo has. Also note that Lenny's kernel is too old for kvm. I'm using Linux 2.6.32.3 compiled by myself with the kernel.org source code with support for KSM: # cat /boot/config-2.6.32.3-dgb | grep KSM CONFIG_KSM=y I'm also using qemu-kvm 0.12.1.2 compiled by myself with the source code of SourceForge. Note that this one has numerous bugs, some of which involves data corruption. JFYI. These are the checks that I was doing in the VMHost: # ll /sys/kernel/mm/ksm/ total 0 -r--r--r-- 1 root root 4096 ago 9 06:28 full_scans -rw-r--r-- 1 root root 4096 ago 9 06:28 max_kernel_pages -r--r--r-- 1 root root 4096 ago 9 06:28 pages_shared -r--r--r-- 1 root root 4096 ago 9 06:28 pages_sharing -rw-r--r-- 1 root root 4096 ago 9 06:28 pages_to_scan -r--r--r-- 1 root root 4096 ago 9 06:28 pages_unshared -r--r--r-- 1 root root 4096 ago 9 06:28 pages_volatile -rw-r--r-- 1 root root 4096 ago 9 06:27 run -rw-r--r-- 1 root root 4096 ago 9 06:28 sleep_millisecs # cat /sys/kernel/mm/ksm/max_kernel_pages 253500 But KSM seems not work: # cat /sys/kernel/mm/ksm/pages_sharing 0 Did you actually enable it in the kernel? Did you read the ksm docs shipped with the kernel? Should I have some additional consideration when compiling qemu-kvm? Please note what Nikola Ciprich said. If you don't have kernel headers that defines MADV_MERGEABLE, you'll have to define it when compiling kvm. Note again that debian qemu-kvm package (you're asking about debian after all) includes support for KSM. It also includes a small patch to #define that symbol. /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] kvm: make mmu_shrink() fit shrinker's requirement
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. The hardware and test rig that actually found the original scalability problem is a bit contended with issues at the moment, so I've been unable to get the original issue reproduced. But, I think the patches should be able to stand on their own. Even in my testing, it's obvious that the shrinker code gets queries (via nr_to_shrink=0) *way* more often than it's actually called upon to shrink things. Even if we have to come back with some more patches than this in the future for the original problem that was found, we should feel confident that this patch set is worthwhile and does some real, quantifiable good on its own. I'll go and immediately test that the first four patches in the series are still behaving themselves in the way that I expect. -- Dave -- 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] server/autotest.py: Make an error message become an info message
If we can't install the client using the autotest internal package management system, give the user a less intimidating message, after all we'll fall back to use other methods to install the client. Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com --- server/autotest.py |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/server/autotest.py b/server/autotest.py index f918b27..eb25095 100644 --- a/server/autotest.py +++ b/server/autotest.py @@ -213,11 +213,10 @@ class BaseAutotest(installable_object.InstallableObject): try: self._install_using_packaging(host, autodir) return -except global_config.ConfigError, e: +except (error.PackageInstallError, error.AutoservRunError, +global_config.ConfigError), e: logging.info(Could not install autotest using the packaging - system: %s, e) -except (error.PackageInstallError, error.AutoservRunError), e: -logging.error(Could not install autotest from repos) + system: %s. Trying other methods, e) # try to install from file or directory if self.source_material: -- 1.7.1.1 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Credit-Based CPU Scheduling Modifying VM Disk Size
Just wondering if KVM supports (if not now then will it in future releases) the following: - Credit-Based CPU Scheduling like Xen. I tried the following command using RHEL 5.5 and it does not work: $ virsh schedinfo RHEL5u3-tomcat Scheduler : Unknown error: this function is not supported by the hypervisor: virDomainGetSchedulerType - Modify VM's Disk Size Thanks, Mike -- 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: Credit-Based CPU Scheduling Modifying VM Disk Size
On Mon, Aug 09, 2010 at 04:33:46PM -0400, Michael Li wrote: Just wondering if KVM supports (if not now then will it in future releases) the following: - Credit-Based CPU Scheduling like Xen. I tried the following command using RHEL 5.5 and it does not work: $ virsh schedinfo RHEL5u3-tomcat Scheduler : Unknown error: this function is not supported by the hypervisor: virDomainGetSchedulerType libvirt only supports the schedinfo command / API against KVM when you have the 'cpu' CGroups controller mounted. Cgroups isn't available for RHEL-5.5 hosts though, so you'd have to wait for RHEL6 in this case. - Modify VM's Disk Size qemu-img can copy disks, resizing as it does it. For raw disks just dd extra sace onto the end of it (with a suitable seek= param to avoid killing your existing data :-) Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about starting 2 VMs using Qemu
Try removing ifname=tap0 and a different macaddr for second instance. --Nirmal On Fri, Aug 6, 2010 at 7:09 AM, Anjali Kulkarni anj...@juniper.net wrote: Hi, I can start my freebsd based image in Qemu, and I use tap interface for connectivity to the host or external world, but when I try to fire up 2 instances, using tap, it fails. For the second invocation, it gives me the error: [r...@ipg-virt01 tmp]# ./qemu-system-x86_64 -m 512 anjali.img -net nic,model=yukon,macaddr=52:54:00:00:aa:02 -net tap,ifname=tap0,script=no warning: could not configure /dev/net/tun: no virtual network emulation Could not initialize device 'tap' Am I doing something wrong? The first instance is running fine. Anjali -- 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 1/3 v2] KVM: x86 emulator: fix negative bit offset BitOp instruction emulation
On 08/08/2010 11:34 PM, Wei Yongjun wrote: If bit offset operands is a negative number, BitOp instruction will return wrong value. This patch fix it. Thanks, applied all three patches. -- 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 2/3] x86: Add inject_realmode_interrupt() wrapper
On 08/08/2010 03:24 PM, Mohammed Gamal wrote:
This adds a wrapper function inject_realmode_interrupt() around the
emulator function emulate_int_real() to allow real mode interrupt injection.
Signed-off-by: Mohammed Gamalm.gamal...@gmail.com
---
arch/x86/kvm/x86.c | 14 ++
arch/x86/kvm/x86.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
Really has no business in x86.c, as it's there to work around a vmx
specific problem.
+int inject_realmode_interrupt(struct kvm_vcpu *vcpu, int irq)
+{
+ struct x86_emulate_ctxt *ctxt =vcpu-arch.emulate_ctxt;
+ int rc;
+
+ rc = emulate_int_real(ctxt,emulate_ops, irq);
+
+ if (rc != X86EMUL_CONTINUE)
+ return EMULATE_FAIL;
+
+ return EMULATE_DONE;
+}
+EXPORT_SYMBOL_GPL(inject_realmode_interrupt);
Doesn't seem to add much value. I'd say just export emulate_int_real()
and call it from vmx.c.
Hmm, you aren't initializing the context. So I guess you do need this
function (and I guess it's better to keep it in x86.c near the rest of
the emulation stuff, just make sure the emulation context is initialized).
--
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 3/3] VMX: Emulated real mode interrupt injection
On 08/08/2010 03:24 PM, Mohammed Gamal wrote:
Signed-off-by: Mohammed Gamalm.gamal...@gmail.com
---
arch/x86/kvm/vmx.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 652d317..d6cb7eb 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2838,16 +2838,7 @@ static void vmx_inject_irq(struct kvm_vcpu *vcpu)
++vcpu-stat.irq_injections;
if (vmx-rmode.vm86_active) {
- vmx-rmode.irq.pending = true;
- vmx-rmode.irq.vector = irq;
- vmx-rmode.irq.rip = kvm_rip_read(vcpu);
- if (vcpu-arch.interrupt.soft)
- vmx-rmode.irq.rip +=
- vmx-vcpu.arch.event_exit_inst_len;
This has to be covered somehow. Not sure exactly - probably keep the
same code. Jan?
- vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
-irq | INTR_TYPE_SOFT_INTR | INTR_INFO_VALID_MASK);
- vmcs_write32(VM_ENTRY_INSTRUCTION_LEN, 1);
- kvm_rip_write(vcpu, vmx-rmode.irq.rip - 1);
+ inject_realmode_interrupt(vcpu, irq);
return;
}
Error checks?
Need to do same to vmx_inject_nmi().
fixup_rmode_irq() just became dead code, you can remove it. Also remove
the entire vmx-rmode.irq thing.
--
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] KVM: x86 emulator: add bsf/bsr instruction emulation
On 08/09/2010 06:00 AM, Wei Yongjun wrote:
Add bsf/bsr instruction emulation (opcode 0x0f 0xbc~0xbd)
@@ -3464,6 +3464,30 @@ twobyte_insn:
btc: /* btc */
emulate_2op_SrcV_nobyte(btc, c-src, c-dst, ctxt-eflags);
break;
+ case 0xbc: {/* bsf */
+ int zf;
+ __asm__ (bsf %2, %0; setz %b1
+ : =r(c-dst.val), =q(zf)
+ : r(c-src.val), 1 (0));
Won't the high bytes of zf remain clear? Please examine the assembly.
Declaring it u8 is probably better.
--
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 5/24] Introduce vmcs12: a VMCS structure for L1
On 08/08/2010 11:09 AM, Nadav Har'El wrote: +page table (with bypass_guest_pf disabled). Might as well remove this, since nvmx will not be merged with such a gaping hole. In theory I ought to reject anything that doesn't comply with the spec. In practice I'll accept deviations from the spec, so long as - those features aren't used by common guests - when the features are attempted to be used, kvm will issue a warning Ok, I plugged the big gaping hole and left a small invisible hole ;-) The situation now is that you no longer have to run kvm with bypass_guest_pf, not on L0 and not on L1. L1 guests will run normally, possibly with bypass_guest_pf enabled. However, when L2 guests run every page-fault will cause an exit - regardless of what L0 or L1 tried to define via PFEC_MASK, PFEC_MATCH and EB[pf]. The reason why I said there is a small hole left is that now there is the possibility that we inject L1 with a page fault that it didn't expect to get. But in practice, this does not seem to cause any problems for neither KVM nor VMWare Server. Not nice, but acceptable. Spurious page faults are accepted by guests since they're often the result of concurrent faults on the same address. I don't think PFEC matching ought to present any implementation difficulty. Well, it is more complicated than it first appeared (at least to me). One problem is that there is no real way (at least none that I thought of) to or the pf-trapping desires of L0 and L1. If they use the same sense (bit 14 of EXCEPTION_BITMAP), you can AND the two PFEC_MASKs, and drop any bits remaining where PFEC_MATCH is different. Not worth it, probably. I solved this by traping all page faults, which is unfortunate. The second problem, related to the first one, when L0 gets a page fault while running L2, it is now quite diffcult to figure out whether it should be injected into L1, i.e., whether L1 asked for this specific page-fault trap to happen. We need check whether the page_fault_error_code match's the L1-specified pfec_mask and pfec_match (and eb.pf), but it's actually more complicated, because the page_fault_error_code we got from the processor refers to the shadow page tables, and we need to translate it back to what it would mean for L1's page tables. You can recover original PFEC by doing a walk_addr(). Doing this correctly would require me to spend quite a bit more time to understand exactly how the shadow page tables code works, and I hesitate whether I should do that now, when I know that common guest hypervisors work perfectly without fixing this issue, and when most people would rather use EPT and not shadow page tables anyway. In any case, I left a TODO in the code about this, so it won't be forgotten. Sure. -- 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: Credit-Based CPU Scheduling Modifying VM Disk Size
On 08/09/10 15:51, Daniel P. Berrange wrote: - Modify VM's Disk Size qemu-img can copy disks, resizing as it does it. For raw disks just dd extra sace onto the end of it (with a suitable seek= param to avoid killing your existing data :-) Daniel New versions of qemu-img have a 'resize' command to change the disk size. David -- 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 v2] 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
---
v1 - v2: use 'u8 zf' instead of int.
---
arch/x86/kvm/emulate.c | 28 ++--
1 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 66139ad..7cbcb66 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2381,8 +2381,8 @@ static struct opcode twobyte_table[256] = {
/* 0xB8 - 0xBF */
N, N,
G(BitOp, group8), D(DstMem | SrcReg | ModRM | BitOp | Lock),
- N, N, D(ByteOp | DstReg | SrcMem | ModRM | Mov),
- D(DstReg | SrcMem16 | ModRM | Mov),
+ 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),
N, N, N, GD(0, group9),
@@ -3500,6 +3500,30 @@ twobyte_insn:
btc: /* btc */
emulate_2op_SrcV_nobyte(btc, c-src, c-dst, ctxt-eflags);
break;
+ case 0xbc: {/* bsf */
+ u8 zf;
+ __asm__ (bsf %2, %0; setz %1
+: =r(c-dst.val), =q(zf)
+: r(c-src.val));
+ ctxt-eflags = ~X86_EFLAGS_ZF;
+ if (zf) {
+ ctxt-eflags |= X86_EFLAGS_ZF;
+ c-dst.type = OP_NONE; /* Disable writeback. */
+ }
+ break;
+ }
+ case 0xbd: {/* bsr */
+ u8 zf;
+ __asm__ (bsr %2, %0; setz %1
+: =r(c-dst.val), =q(zf)
+: r(c-src.val));
+ ctxt-eflags = ~X86_EFLAGS_ZF;
+ if (zf) {
+ ctxt-eflags |= X86_EFLAGS_ZF;
+ c-dst.type = OP_NONE; /* Disable writeback. */
+ }
+ break;
+ }
case 0xbe ... 0xbf: /* movsx */
c-dst.bytes = c-op_bytes;
c-dst.val = (c-d ByteOp) ? (s8) 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
