[kvm-devel] KVM Test result, kernel 6617597e.. , userspace c109b253..
Hi, We run some tests against latest kvm.git 6617597ecdbdff1419d2e942b6aa301f82fe4598 and kvm-userspace.git c109b253be21f951cf4e86d6135e50e65c2eb4f6. One issue fixed: The 64bit crash issue has been fixed. Following Issues still exist 1. guest timer 2 times faster than network timer https://sourceforge.net/tracker/index.php?func=detail&aid=1791444&group_ id=180599&atid=893831 2. 64bit 4GB guest cannot start network https://sourceforge.net/tracker/index.php?func=detail&aid=1792984&group_ id=180599&atid=893831 3. high cpu usage of 32bit windows xp/2003 https://sourceforge.net/tracker/index.php?func=detail&aid=1792999&group_ id=180599&atid=893831 4. Create multiple guests simultaneously or create one guest many times may fail https://sourceforge.net/tracker/index.php?func=detail&aid=1741312&group_ id=180599&atid=893831 5. Can not boot IA32e RHEL 4u3 guest with -no-acpi https://sourceforge.net/tracker/index.php?func=detail&aid=1741314&group_ id=180599&atid=893831 6. Some ltp test cases fail https://sourceforge.net/tracker/index.php?func=detail&aid=1741316&group_ id=180599&atid=893831 7. Cannot boot window 2k guest https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1768187&gro up_id=180599 8. Linux guest crash without nolapic, 2.6.22 kernel. https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1769884&gro up_id=180599 thanks Yunfeng - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/5] Split the emulator: decode & execute
Avi Kivity wrote:
> Laurent Vivier wrote:
>> These patches split the emulator in two parts: one to decode the
>> instruction,
>> the other to execute it. The decode part is then called only when needed.
>>
>>
>
> Patchset looks good, but fails booting FC6 x86-64 on Intel. It may be a
> merge error (did not apply cleanly due to other changes). I pushed this
> as a 'split-emulator' branch on the kvm.git repository.
>
I think I found the bug (not a merge error...): I just supposed that an
instruction fetch cannot failed.
I wrote:
r = x86_decode_insn(&emulate_ctxt, &emulate_ops);
if (r)
return EMULATE_FAIL;
vcpu->mmio_is_write = 0;
vcpu->pio.string = 0;
r = x86_emulate_insn(&emulate_ctxt, &emulate_ops);
...
It should be:
vcpu->mmio_is_write = 0;
vcpu->pio.string = 0;
r = x86_decode_insn(&emulate_ctxt, &emulate_ops);
if (r == 0) {
r = x86_emulate_insn(&emulate_ctxt, &emulate_ops);
if (vcpu->pio.string)
return EMULATE_DO_MMIO;
}
if ((r || vcpu->mmio_is_write) && run) {
...
}
if (r) {
...
}
Laurent
--
- [EMAIL PROTECTED] --
"Software is hard" - Donald Knuth
signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio & hypercall interface?
Rusty Russell wrote: > Hi all, > > I've finally started looking at Dor's git tree, and it struck me that > it conflicts with Anthony's hypercall patches. FWIW I like Anthony's > patching thing, and don't really care about arg order. It'd be nice if > we could pull in the same direction tho 8) > I prefer Anthony's hypercalls too. Anthony, can you resend the patchset? Last I looked I was unable to get a coherent set. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio & hypercall interface?
Avi Kivity wrote: > Rusty Russell wrote: > >> Hi all, >> >> I've finally started looking at Dor's git tree, and it struck me that >> it conflicts with Anthony's hypercall patches. FWIW I like Anthony's >> patching thing, and don't really care about arg order. It'd be nice if >> we could pull in the same direction tho 8) >> >> > > I prefer Anthony's hypercalls too. Anthony, can you resend the > patchset? Last I looked I was unable to get a coherent set. > > Yeah, I'll rebase and send out today. Regards, Anthony Liguori - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-36 release
Gildas wrote: > Hi, > > Some updates since kvm-37 > > Compilation worked fine for me on an intel Core2 64bits machine > running ubuntu feisty with kernel 2.6.20 x86_64. > > Loading modules went ok. > > * Running a windows xp image with "/usr/local/bin/qemu-system-x86_64 > -smp 2 -m 768 -hda win_xp.qcow -net user -net nic -monitor > tcp::,server -vnc :1 -redir tcp:3389::3389 &" result in : > exception 6 (0) > > Which HAL does this image use? > * I've found out that "-net nic -net user" don't interact nicely with > "-smp 2", as the following test with a debian image (kernel 2.6.18 > 64bits)shows: > -smp 2 -net user (without -net nic)-> boots fine > -smp 2 -net nic (without -net user)-> boots fine > -net nice -net user (without -smp 2) -> boots fine > -smp 2 -net user -net nic -> crash with: > > How does -no-kvm-irqchip affect this? > Also, when it boots correctly with "-smp 2" it shows 2 processors in > /proc/cpuinfo, but I have messages as follows at bootup: > " ACPI : Getting cpuindex for acpiid 0x2 > ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device > not present [20060707]" > (not sure if this is related but I don't remember having seen them before) > > This is due to some ACPI work that exposes 16 processors so that Windows SMP does not grumble at us. We should make the ACPI objects conditional on the processors actually existing. Igor? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio & hypercall interface?
Anthony Liguori wrote: > Dor Laor wrote: > >>> Hi all, >>> >>> I've finally started looking at Dor's git tree, and it struck me >>> >>> >> that >> >> >>> it conflicts with Anthony's hypercall patches. FWIW I like Anthony's >>> patching thing, and don't really care about arg order. It'd be nice if >>> we could pull in the same direction tho 8) >>> >>> Thanks, >>> Rusty. >>> >>> >> Good news you're looking at my tree, since the forum I didn't do much >> since I had to catch up some gazlion other tasks, never the less >> starting on Sunday I'm back again. >> >> Actually, I wanted to rebase my hypercalls over Anhtony's too (except >> for allowing userspace handling). >> > > I thought we discussed just providing a signaling message to userspace > for virtio? It's not strictly necessary to expose hypercalls to > userspace in order to implement a virtio backend in userspace. > > Yes, that's what I'd like to see too. Signal a channel. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] (big) real mode emulation - initialization fixes
Nitin A Kamble wrote:
> Hi Avi,
> Attached is the patch to initialize src.val & dst.val. Without this,
> certain instructions are getting affected in their emulation.
>
> Please apply.
>
>
This seems like it is papering over other bugs. Some instructions use
src.val or dst.val without having decoded the src or dst operand.
Which instructions are these? Can we fix them instead?
> Intialize src.val & dst.val, to fix bugs in certain instruction
> emulations.
>
> Signed-off-by: Nitin A Kamble <[EMAIL PROTECTED]>
>
> diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
> index c2540c3..90ee392 100644
> --- a/drivers/kvm/x86_emulate.c
> +++ b/drivers/kvm/x86_emulate.c
> @@ -832,6 +832,7 @@ done_prefixes:
> srcmem_common:
> src.type = OP_MEM;
> src.ptr = (unsigned long *)cr2;
> + src.val = 0;
> if ((rc = ops->read_emulated((unsigned long)src.ptr,
>&src.val, src.bytes, ctxt->vcpu))
> != 0)
> goto done;
> @@ -896,6 +897,7 @@ done_prefixes:
> dst.type = OP_MEM;
> dst.ptr = (unsigned long *)cr2;
> dst.bytes = (d & ByteOp) ? 1 : op_bytes;
> + dst.val = 0;
> if (d & BitOp) {
> unsigned long mask = ~(dst.bytes * 8 - 1);
>
>
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] current git master external module crashes my server
Sebastian Färber wrote: > Hi, > > i just upgraded to lastet git and now get the following error in dmesg: > -- > emulation failed (mmio) rip c2008430 60 17 97 f8 > -- > Sorry, I can't really track down what 'latest git' means. Can you re-fetch and try again, and if it fails post the HEAD commit hash? Also repost your guest OS details. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-38 release
Haydn Solomon wrote: > You guys are quick! Ok, kvm-39 allows me to run my windows xp machine > now. I just have one question that I'm not sure of.. should reboot be > working now? I tried rebooting the windows xp and got the following > output. > Reboot was improved in kvm-39, but not completely fixed. I'll nail it down in kvm-40 or kvm-41. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-36 release
Wei Huang wrote:
> The compilation errors also showed up on my boxes. The attached patch
> fixes the errors by renaming variables.
>
> Signed-off-by: Wei Huang <[EMAIL PROTECTED]>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 99e4917..f04ca6b 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -2967,25 +2967,25 @@ static long kvm_vcpu_ioctl(struct file *
> break;
> }
> case KVM_GET_LAPIC: {
> - struct kvm_lapic_state lapic;
> + struct kvm_lapic_state lapic_state;
>
> - memset(&lapic, 0, sizeof lapic);
> - r = kvm_vcpu_ioctl_get_lapic(vcpu, &lapic);
> + memset(&lapic_state, 0, sizeof lapic_state);
> + r = kvm_vcpu_ioctl_get_lapic(vcpu, &lapic_state);
> if (r)
I committed an equivalent fix, but one that only affects the external
module, since the issue is not present with current kernels.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/5] Split the emulator: decode & execute
Laurent Vivier wrote: > Avi Kivity wrote: > >> Laurent Vivier wrote: >> >>> These patches split the emulator in two parts: one to decode the >>> instruction, >>> the other to execute it. The decode part is then called only when needed. >>> >>> >>> >> Patchset looks good, but fails booting FC6 x86-64 on Intel. It may be a >> merge error (did not apply cleanly due to other changes). I pushed this >> as a 'split-emulator' branch on the kvm.git repository. >> >> > > I think I found the bug (not a merge error...): I just supposed that an > instruction fetch cannot failed. > > Interesting. I don't see how an instruction fetch can fail on uniprocessor. Can you give details of the failure? Instruction fetches can fail on SMP so a fix is certainly needed. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH -rc][RESEND] KVM: MMU: Fix rare oops on guest context switch
A guest context switch to an uncached cr3 can require allocation of
shadow pages, but we only recycle shadow pages in kvm_mmu_page_fault().
Move shadow page recycling to mmu_topup_memory_caches(), which is called
from both the page fault handler and from guest cr3 reload.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h | 10 +++---
drivers/kvm/mmu.c |5 +++--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 3ac9cbc..336be86 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -619,7 +619,7 @@ unsigned long segment_base(u16 selector);
void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *old, const u8 *new, int bytes);
int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu, gva_t gva);
-void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
+void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
int kvm_mmu_load(struct kvm_vcpu *vcpu);
void kvm_mmu_unload(struct kvm_vcpu *vcpu);
@@ -628,11 +628,15 @@ int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run
*run);
static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
u32 error_code)
{
- if (unlikely(vcpu->kvm->n_free_mmu_pages < KVM_MIN_FREE_MMU_PAGES))
- kvm_mmu_free_some_pages(vcpu);
return vcpu->mmu.page_fault(vcpu, gva, error_code);
}
+static inline void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
+{
+ if (unlikely(vcpu->kvm->n_free_mmu_pages < KVM_MIN_FREE_MMU_PAGES))
+ __kvm_mmu_free_some_pages(vcpu);
+}
+
static inline int kvm_mmu_reload(struct kvm_vcpu *vcpu)
{
if (likely(vcpu->mmu.root_hpa != INVALID_PAGE))
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index 1a87ba9..23965aa 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -273,12 +273,14 @@ static int mmu_topup_memory_caches(struct kvm_vcpu *vcpu)
int r;
r = __mmu_topup_memory_caches(vcpu, GFP_NOWAIT);
+ kvm_mmu_free_some_pages(vcpu);
if (r < 0) {
spin_unlock(&vcpu->kvm->lock);
kvm_arch_ops->vcpu_put(vcpu);
r = __mmu_topup_memory_caches(vcpu, GFP_KERNEL);
kvm_arch_ops->vcpu_load(vcpu);
spin_lock(&vcpu->kvm->lock);
+ kvm_mmu_free_some_pages(vcpu);
}
return r;
}
@@ -1208,7 +1210,7 @@ int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu,
gva_t gva)
return kvm_mmu_unprotect_page(vcpu, gpa >> PAGE_SHIFT);
}
-void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
+void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
{
while (vcpu->kvm->n_free_mmu_pages < KVM_REFILL_PAGES) {
struct kvm_mmu_page *page;
@@ -1218,7 +1220,6 @@ void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
kvm_mmu_zap_page(vcpu->kvm, page);
}
}
-EXPORT_SYMBOL_GPL(kvm_mmu_free_some_pages);
static void free_mmu_pages(struct kvm_vcpu *vcpu)
{
--
1.5.3
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-38 release
On 9/14/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > Haydn Solomon wrote: > > You guys are quick! Ok, kvm-39 allows me to run my windows xp machine > > now. I just have one question that I'm not sure of.. should reboot be > > working now? I tried rebooting the windows xp and got the following > > output. > > > > Reboot was improved in kvm-39, but not completely fixed. I'll nail it > down in kvm-40 or kvm-41. You can reboot linux guests passing "reboot=b" on kernel command line. Don't know about win... Luca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] (big) real mode emulation - initialization fixes
On Fri, 2007-09-14 at 10:08 -0700, Avi Kivity wrote: > This seems like it is papering over other bugs. Some instructions use > src.val or dst.val without having decoded the src or dst operand. > > Which instructions are these? Can we fix them instead? Instructions using 8bit operands such as al, ah are affected. Especially utilizing signed operands. By not using this initialization these operands are getting wrong value from remaining stale bits. -- Thanks & Regards, Nitin Open Source Technology Center, Intel Corporation - The mind is like a parachute; it works much better when it's open signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] (big) real mode emulation - initialization fixes
Nitin A Kamble wrote: > On Fri, 2007-09-14 at 10:08 -0700, Avi Kivity wrote: > >> This seems like it is papering over other bugs. Some instructions use >> src.val or dst.val without having decoded the src or dst operand. >> >> Which instructions are these? Can we fix them instead? >> > > Instructions using 8bit operands such as al, ah are affected. > Especially utilizing signed operands. By not using this initialization > these operands are getting wrong value from remaining stale bits. > > I see. SrcMem decode does ->read_emulated() into src.val, leaving stale bits. I agree your patch is the best way to fix it. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] (big) real mode emulation - jmp abs
Hi Avi,
Attached is the patch to implement instruction:
jump absolute
opcode: 0xff /4
Please apply.
--
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better when it's open
commit d67d775e429b32da323715f52f4ef4ce03a9031c
Author: Nitin A Kamble <[EMAIL PROTECTED]>
Date: Fri Sep 14 14:25:23 2007 -0700
Implement emulation of instruction:
jump absolute r/m
opcode: 0xff /4
Signed-off-by: Nitin A Kamble <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 58e8394..ab7db47 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1229,6 +1229,12 @@ push:
case 1: /* dec */
emulate_1op("dec", dst, _eflags);
break;
+ case 4: /* jmp abs */
+ if (b == 0xff)
+_eip = dst.val;
+ else
+goto cannot_emulate;
+ break;
case 6: /* push */
/* 64-bit mode: PUSH always pushes a 64-bit operand. */
if (mode == X86EMUL_MODE_PROT64) {
signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] (big) real mode emulation - dec reg
Hi Avi,
Attached is the patch to implement emulation of instruction:
dec reg
opcodes: 0x48 - 0x4f
Please apply.
--
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better when it's open
commit ea06cdff59c8f9d74be2f6d7b7c4137a7c150a50
Author: Nitin A Kamble <[EMAIL PROTECTED]>
Date: Fri Sep 14 14:55:33 2007 -0700
Implement emulation of instruction:
dec reg
opcode: 0x48 - 0x4f
Signed-off-by: Nitin A Kamble <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index f5a4f4a..64909ff 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -100,7 +100,8 @@ static u8 opcode_table[256] = {
ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
/* 0x48 - 0x4F */
- 0, 0, 0, 0, 0, 0, 0, 0,
+ ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
+ ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
/* 0x50 - 0x57 */
ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
@@ -1409,6 +1410,22 @@ pop_instruction:
}
no_wb = 1; /* Disable writeback. */
break;
+ case 0x48 ... 0x4f: /* dec r16/r32 */
+ dst.ptr = (unsigned long *)&_regs[b & 0x7];
+ dst.val = *dst.ptr;
+ switch (op_bytes) {
+ case 2:
+ *(u16 *)dst.ptr = (u16)dst.val - 1;
+ break;
+ case 4:
+ *dst.ptr = (u32)dst.val - 1;
+ break; /* 64b: zero-ext */
+ case 8:
+ *dst.ptr = dst.val - 1;
+ break;
+ }
+ no_wb = 1; /* Disable writeback. */
+ break;
case 0xa4 ... 0xa5: /* movs */
dst.type = OP_MEM;
dst.bytes = (d & ByteOp) ? 1 : op_bytes;
signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] (big) real mode emulation - inc reg
Hi Avi,
Attached is the patch to implement instructions:
inc reg
opcode: 0x40 - 0x47
Please apply.
--
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better when it's open
commit c47e7ccd17a9fe79e0f5e8b3198d6cd84e7c85ed
Author: Nitin A Kamble <[EMAIL PROTECTED]>
Date: Fri Sep 14 14:47:42 2007 -0700
Implement emulation of instruction:
inc reg
opcode: 0x40 - 0x47
Signed-off-by: Nitin A Kamble <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index ab7db47..f5a4f4a 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -96,8 +96,11 @@ static u8 opcode_table[256] = {
ByteOp | DstMem | SrcReg | ModRM, DstMem | SrcReg | ModRM,
ByteOp | DstReg | SrcMem | ModRM, DstReg | SrcMem | ModRM,
0, 0, 0, 0,
- /* 0x40 - 0x4F */
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ /* 0x40 - 0x47 */
+ ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
+ ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
+ /* 0x48 - 0x4F */
+ 0, 0, 0, 0, 0, 0, 0, 0,
/* 0x50 - 0x57 */
ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
@@ -1390,6 +1393,22 @@ pop_instruction:
_eip = ctxt->vcpu->rip;
}
switch (b) {
+ case 0x40 ... 0x47: /* inc reg */
+ dst.ptr = (unsigned long *)&_regs[b & 0x7];
+ dst.val = *dst.ptr;
+ switch (op_bytes) {
+ case 2:
+*(u16 *)dst.ptr = (u16)dst.val + 1;
+break;
+ case 4:
+*dst.ptr = (u32)dst.val + 1;
+break; /* 64b: zero-ext */
+ case 8:
+*dst.ptr = dst.val + 1;
+break;
+ }
+ no_wb = 1; /* Disable writeback. */
+ break;
case 0xa4 ... 0xa5: /* movs */
dst.type = OP_MEM;
dst.bytes = (d & ByteOp) ? 1 : op_bytes;
signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Fedora 7 build kvm
Greetings, I am trying to duplicate what I have done with the Free version of VmWare server, with KVM. Linux, Fedora 7 host and Fedora Core 3 guest.. Since the KVM with fedora 7 is not current I decided to try and build KVM from source. After discovering the gcc 3.4. requirement, I did build/install gcc 3.4.6.I now have the issues in the attachment. One of my questions is: Why does KVM require gcc 3.4?, when the Kernel builds with 4.x. I built and am running kernel 2.6.22.5, with gcc 4.1.2, which is what comes with Fedora 7. Should I just hack the build process for KVM and remove the requirement for gcc 3.4? Should I expect the performance of a KVM configuration to exhibit better performance characteristics than the free version of VmWare server? Thank you for any help or comments you car to supply. Regards: Phillip Lahman make.list Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-38 release
My main virtual machine I work with is windows xp. Thanks for the reply and I'm looking forward to future releases! On 9/14/07, Luca <[EMAIL PROTECTED]> wrote: > > On 9/14/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > > Haydn Solomon wrote: > > > You guys are quick! Ok, kvm-39 allows me to run my windows xp machine > > > now. I just have one question that I'm not sure of.. should reboot be > > > working now? I tried rebooting the windows xp and got the following > > > output. > > > > > > > Reboot was improved in kvm-39, but not completely fixed. I'll nail it > > down in kvm-40 or kvm-41. > > You can reboot linux guests passing "reboot=b" on kernel command line. > Don't know about win... > > Luca > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] breaking kvm :-)
Hi Ron, This would be interesting to try, especially if booting is noticeably faster that bochs. Did you get that how-to up? Thanks, Cam ron minnich wrote: > Somebody here at OLS was asking me about linuxbios on kvm. Well, that > was too much to resist. > > Short form: it works, uses a grub-like interface that does not use > BIOS callbacks. It's noticeably faster to boot than Bochs. I realize > that it's all pretty fast but linuxbios is 32-bit code, so there is > pretty much no emulation to worry about. > > So, if anyone gets annoyed watching bochs boot, I can put a howto on > the linuxbios wiki. It's pretty trivial to set up. > > ron > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] breaking kvm :-)
On 9/14/07, Cam Macdonell <[EMAIL PROTECTED]> wrote: > > Hi Ron, > > This would be interesting to try, especially if booting is noticeably > faster that bochs. It would definitely be interesting to try. Cheers, Jorge - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Refactor hypercall infrastructure
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used the wrong hypercall instruction for the
underlying architecture and replacing it with the right one lazily.
It also introduces the infrastructure to probe for hypercall available via
CPUID leaves 0x4002. CPUID leaf 0x4003 should be filled out by
userspace.
A fall-out of this patch is that the unhandled hypercalls no longer trap to
userspace. There is very little reason though to use a hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE_VECTOR 0
+#define UD_VECTOR 6
#define NM_VECTOR 7
#define DF_VECTOR 8
#define TS_VECTOR 10
@@ -317,9 +318,6 @@ struct kvm_vcpu {
unsigned long cr0;
unsigned long cr2;
unsigned long cr3;
- gpa_t para_state_gpa;
- struct page *para_state_page;
- gpa_t hypercall_gpa;
unsigned long cr4;
unsigned long cr8;
u64 pdptrs[4]; /* pae */
@@ -622,7 +620,9 @@ void __kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
int kvm_mmu_load(struct kvm_vcpu *vcpu);
void kvm_mmu_unload(struct kvm_vcpu *vcpu);
-int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_emulate_hypercall(struct kvm_vcpu *vcpu);
+
+int kvm_fix_hypercall(struct kvm_vcpu *vcpu);
static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
u32 error_code)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 99e4917..5211d19 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1383,51 +1384,61 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu)
}
EXPORT_SYMBOL_GPL(kvm_emulate_halt);
-int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run)
+int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
- unsigned long nr, a0, a1, a2, a3, a4, a5, ret;
+ unsigned long nr, a0, a1, a2, a3, ret;
kvm_x86_ops->cache_regs(vcpu);
- ret = -KVM_EINVAL;
-#ifdef CONFIG_X86_64
- if (is_long_mode(vcpu)) {
- nr = vcpu->regs[VCPU_REGS_RAX];
- a0 = vcpu->regs[VCPU_REGS_RDI];
- a1 = vcpu->regs[VCPU_REGS_RSI];
- a2 = vcpu->regs[VCPU_REGS_RDX];
- a3 = vcpu->regs[VCPU_REGS_RCX];
- a4 = vcpu->regs[VCPU_REGS_R8];
- a5 = vcpu->regs[VCPU_REGS_R9];
- } else
-#endif
- {
- nr = vcpu->regs[VCPU_REGS_RBX] & -1u;
- a0 = vcpu->regs[VCPU_REGS_RAX] & -1u;
- a1 = vcpu->regs[VCPU_REGS_RCX] & -1u;
- a2 = vcpu->regs[VCPU_REGS_RDX] & -1u;
- a3 = vcpu->regs[VCPU_REGS_RSI] & -1u;
- a4 = vcpu->regs[VCPU_REGS_RDI] & -1u;
- a5 = vcpu->regs[VCPU_REGS_RBP] & -1u;
- }
+
+ nr = vcpu->regs[VCPU_REGS_RAX];
+ a0 = vcpu->regs[VCPU_REGS_RBX];
+ a1 = vcpu->regs[VCPU_REGS_RCX];
+ a2 = vcpu->regs[VCPU_REGS_RDX];
+ a3 = vcpu->regs[VCPU_REGS_RSI];
+
+ if (!is_long_mode(vcpu)) {
+ nr &= ~1u;
+ a0 &= ~1u;
+ a1 &= ~1u;
+ a2 &= ~1u;
+ a3 &= ~1u;
+ }
+
switch (nr) {
default:
- run->hypercall.nr = nr;
- run->hypercall.args[0] = a0;
- run->hypercall.args[1] = a1;
- run->hypercall.args[2] = a2;
- run->hypercall.args[3] = a3;
- run->hypercall.args[4] = a4;
- run->hypercall.args[5] = a5;
- run->hypercall.ret = ret;
- run->hypercall.longmode = is_long_mode(vcpu);
- kvm_x86_ops->decache_regs(vcpu);
- return 0;
+ ret = -KVM_ENOSYS;
+ break;
}
vcpu->regs[VCPU_REGS_RAX] = ret;
kvm_x86_ops->decache_regs(vcpu);
- return 1;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(kvm_emulate_hypercall);
+
+int kvm_fix_hypercall(struct kvm_vcpu *vcpu)
+{
+ char instruction[3];
+ int ret = 0;
+
+ mutex_lock(&vcpu->kvm->lock);
+
+ /*
+* Blow out the MMU to ensure that no other VCPU has an active mapping
+* to ensure that the updated hypercall appears atomically across all
+* VCPUs.
+*/
+ kvm_mmu_zap_all(vcpu->kvm);
+
+ kvm_x86_ops->cache_regs(vcpu);
+ kvm_x86_ops->patch_hypercall(vcpu, instruction);
+ if (emulator_write_emulated(vcpu->rip, instruction, 3, vcpu)
+ != X86EMUL_CONTINUE)
+
[kvm-devel] [PATCH] Add the paravirtualization CPUID entry to QEMU
This adds a CPUID entry for the paravirtualization feature bitmap. We can do
this unconditionally because the guest requires that both the feature CPUID
entry and the signature CPUID entry exists to enable paravirtualization.
This means that guest will never enable paravirtualization if either userspace
or kernelspace doesn't support paravirtualization.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 4843a74..bea871d 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -1113,12 +1113,18 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
uint32_t function,
int kvm_qemu_init_env(CPUState *cenv)
{
struct kvm_cpuid_entry cpuid_ent[100];
+struct kvm_cpuid_entry *pv_features;
int cpuid_nent = 0;
CPUState copy;
uint32_t i, limit;
copy = *cenv;
+pv_features = &cpuid_ent[cpuid_nent++];
+memset(pv_features, 0, sizeof(*pv_features));
+pv_features->function = 0x4003;
+pv_features->eax = 0;
+
copy.regs[R_EAX] = 0;
qemu_kvm_cpuid_on_env(©);
limit = copy.regs[R_EAX];
diff --git a/user/kvmctl.h b/user/kvmctl.h
index 109d81c..74db1ba 100644
--- a/user/kvmctl.h
+++ b/user/kvmctl.h
@@ -10,6 +10,7 @@
#endif
#include
+#include
#include
#include
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Attached is the patch I'm using to test it. I'm going to take a look at
Rusty's pv_ops implementation for kvm-lite so that we can submit a
single common one instead of introducing mine and having unnecessary churn.
Regards,
Anthony Liguori
Subject: [PATCH 2/3] KVM paravirt-ops implementation (v2)
From: Anthony Liguori <[EMAIL PROTECTED]>
Cc: Avi Kivity <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
A very simple paravirt_ops implementation for KVM. Future patches will add
more sophisticated optimizations. The goal of having this presenting this now
is to validate the new hypercall infrastructure and to make my patch queue
smaller.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 97b64d7..95a67d4 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -237,6 +237,13 @@ config VMI
at the moment), by linking the kernel to a GPL-ed ROM module
provided by the hypervisor.
+config KVM_GUEST
+ bool "KVM paravirt-ops support"
+ depends on PARAVIRT
+ help
+ This option enables various optimizations for running under the KVM
+ hypervisor.
+
config ACPI_SRAT
bool
default y
diff --git a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
index 9d33b00..6308fcf 100644
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_K8_NB) += k8.o
obj-$(CONFIG_MGEODE_LX) += geode.o
obj-$(CONFIG_VMI) += vmi.o vmiclock.o
+obj-$(CONFIG_KVM_GUEST) += kvm.o
obj-$(CONFIG_PARAVIRT) += paravirt.o
obj-y+= pcspeaker.o
diff --git a/arch/i386/kernel/kvm.c b/arch/i386/kernel/kvm.c
new file mode 100644
index 000..42ffe25
--- /dev/null
+++ b/arch/i386/kernel/kvm.c
@@ -0,0 +1,55 @@
+/*
+ * KVM paravirt_ops implementation
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corporation, 2007
+ * Authors: Anthony Liguori <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+
+/*
+ * No need for any "IO delay" on KVM
+ */
+static void kvm_io_delay(void)
+{
+}
+
+static __init void paravirt_setup(void)
+{
+ int i;
+
+ paravirt_ops.name = "KVM";
+
+ if (kvm_para_has_feature(KVM_PARA_FEATURE_NOP_IO_DELAY))
+ paravirt_ops.io_delay = kvm_io_delay;
+
+ paravirt_ops.paravirt_enabled = 1;
+
+ printk(KERN_INFO "KVM: Issuing hypercall\n");
+ for (i = 0; i < 2; i++)
+ i += kvm_hypercall0(0);
+ printk(KERN_INFO "KVM: done hypercall\n");
+}
+
+void __init kvm_guest_init(void)
+{
+ printk(KERN_INFO "KVM: kvm guest init\n");
+
+ if (kvm_para_available())
+ paravirt_setup();
+}
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 5211d19..d04cead 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1405,6 +1405,11 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
}
switch (nr) {
+ case 0:
+ printk("KVM: guest hypercall: %lx %lx %lx %lx\n",
+ a0, a1, a2, a3);
+ ret = 0;
+ break;
default:
ret = -KVM_ENOSYS;
break;
@@ -1430,6 +1435,7 @@ int kvm_fix_hypercall(struct kvm_vcpu *vcpu)
kvm_mmu_zap_all(vcpu->kvm);
kvm_x86_ops->cache_regs(vcpu);
+ printk(KERN_INFO "kvm: patching hypercall at %lx\n", vcpu->rip);
kvm_x86_ops->patch_hypercall(vcpu, instruction);
if (emulator_write_emulated(vcpu->rip, instruction, 3, vcpu)
!= X86EMUL_CONTINUE)
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index 448112a..89d807a 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -4,7 +4,15 @@
#ifdef __KERNEL__
#include
-#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
+#ifdef CONFIG_KVM_GUEST
+void __init kvm_guest_init(void);
+#else
+static inline void kvm_guest_init(void)
+{
+}
+#endif
+
+#define KVM_HYPERCALL ".byte 0x0f,0x01,0xd9"
static inline long kvm_hypercall0(unsigned int nr)
{
@@ -83,4 +91,6 @@ static inline int kvm_para_has_feature(unsigned int feature)
#define KVM_ENOSYS 1000
+#define KVM_PARA_FEATURE_NOP_IO_DELAY 0
+
#endif
diff --git a/init/main.c b/init/main.c
index 9def935..61d8328 100644
--- a/init/main.c
+++ b/init/main.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
@@ -569,6 +570,7 @@ asmlinkage void __init start_kernel(void)
}
sort_main_extable();
trap_init();
+ kvm_guest_init();
rcu_init();
init_IRQ();
pidhash_init();
Re: [kvm-devel] [PATCH] Add support for a basic boot menu to the bios
Hi Jeremy, I gave this patch a try today against the latest git 1edeb9c05aa034633978f31e2c773a1be55ed337 and I cannot get past the "Press F10..." prompt. I'm on an Intel Core 2 Duo processor. It does work though with -no-kvm. Have you tested this patch with KVM? Regards, Anthony Liguori Jeremy Katz wrote: > I sent this to the bochs list earlier today, but given that kvm is > already carrying patches for the BIOS, it may be worthwhile/interesting > to add this also as it can make the user experience substantially nicer. > > -- Begin forwarded message -- > > The attached patch adds support for a relatively basic boot device > selection menu to the bochs bios code. > Hi J > Instead of immediately booting from the boot device set in the cmos, we > wait for 3 seconds for the user to press F10; if they press it, then we > show a basic boot menu that they can select what device to boot from. > Otherwise, we continue on with what was setup before running the virtual > machine. The advantage is that users can change their boot device just > on rebooting a virtual machine rather than having to stop and then > restart it. > > This includes the wait routines added by VirtualBox > (http://www.virtualbox.org) in their modifications to the rombios as > they made things a bit easier. > > Jeremy > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Disk migration
I see that vmware just demonstrated migration of virtual disks. I know that kvm is very young but I think has come a long way in a very short period. I just wanted to get some feedback/discussion on how difficult this would be to implement in kvm/qemu and if this would be anywhere in future plans for development? Would this be less complicated than live migration of memory? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Anthony Liguori wrote: > This patch refactors the current hypercall infrastructure to better support > live > migration and SMP. It eliminates the hypercall page by trapping the UD > exception that would occur if you used the wrong hypercall instruction for the > underlying architecture and replacing it with the right one lazily. > I guess it would be pretty rude/unlikely for these opcodes to get reused in other implementations... But couldn't you make the page trap instead, rather than relying on an instruction fault? > It also introduces the infrastructure to probe for hypercall available via > CPUID leaves 0x4002. CPUID leaf 0x4003 should be filled out by > userspace. > Is this compatible with Xen's (and other's) use of cpuid? That is, 0x4000 returns a hypervisor-specific signature in e[bcd]x, and eax has the max hypervisor leaf. J - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: > >> This patch refactors the current hypercall infrastructure to better support >> live >> migration and SMP. It eliminates the hypercall page by trapping the UD >> exception that would occur if you used the wrong hypercall instruction for >> the >> underlying architecture and replacing it with the right one lazily. >> >> > > I guess it would be pretty rude/unlikely for these opcodes to get reused > in other implementations... But couldn't you make the page trap > instead, rather than relying on an instruction fault? > The whole point of using the instruction is to allow hypercalls to be used in many locations. This has the nice side effect of not requiring a central hypercall initialization routine in the guest to fetch the hypercall page. A PV driver can be completely independent of any other code provided that it restricts itself to it's hypercall namespace. >> It also introduces the infrastructure to probe for hypercall available via >> CPUID leaves 0x4002. CPUID leaf 0x4003 should be filled out by >> userspace. >> >> > > Is this compatible with Xen's (and other's) use of cpuid? That is, > 0x4000 returns a hypervisor-specific signature in e[bcd]x, and eax > has the max hypervisor leaf. > Xen is currently using 0/1/2. I had thought it was only using 0/1. The intention was not to squash Xen's current CPUID usage so that it would still be possible for Xen to make use of the guest code. Can we agree that Xen won't squash leaves 3/4 or is it not worth trying to be compatible at this point? Regards, Anthony Liguori > J > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Disk migration
Haydn Solomon wrote: > I see that vmware just demonstrated migration of virtual disks. I know > that kvm is very young but I think has come a long way in a very short > period. I just wanted to get some feedback/discussion on how difficult > this would be to implement in kvm/qemu and if this would be anywhere > in future plans for development? Would this be less complicated than > live migration of memory? Disk migration is super easy to implement in KVM. There are two basic models you can follow to do disk migration. In a push model, you would apply a similar algorithm to the memory migration algorithm whereas you pushed the whole disk over in chunks keeping track of what bits on disk have been dirtied. You'd converge after a certain number of iterations and then perform the memory migration. A pull model would immediately do the memory migration and allow QEMU to continue running on the source node acting as an IO server. Any disk IO from the guest would either go directly to disk if the block was present or would be fetched from the QEMU instance on the source node. The only trick here is that you'd want to continue transferring blocks even when the guest isn't accessing the disk. The push model may require parallelization of the disk and memory convergence depending on how much disk activity the guest is doing. That's a pretty interesting problem but it shouldn't be too hard to solve. The push model has the advantage of having the smallest performance impact over time. The pull model has an advantage of immediately reducing CPU usage on the source node at the expense of a potentially severe degradation in performance of the guest. Both models probably require roughly the same amount of time for migration completion. Very good thing for someone looking for a fun task in KVM :-) Regards, Anthony Liguori > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote: > Jeremy Fitzhardinge wrote: > > Anthony Liguori wrote: > > > >> This patch refactors the current hypercall infrastructure to better > >> support live > >> migration and SMP. It eliminates the hypercall page by trapping the UD > >> exception that would occur if you used the wrong hypercall instruction for > >> the > >> underlying architecture and replacing it with the right one lazily. > >> > >> > > > > I guess it would be pretty rude/unlikely for these opcodes to get reused > > in other implementations... But couldn't you make the page trap > > instead, rather than relying on an instruction fault? > > > > The whole point of using the instruction is to allow hypercalls to be > used in many locations. This has the nice side effect of not requiring > a central hypercall initialization routine in the guest to fetch the > hypercall page. A PV driver can be completely independent of any other > code provided that it restricts itself to it's hypercall namespace. But if the instruction is architecture dependent, and you run on the wrong architecture, now you have to patch many locations at fault time, introducing some nasty runtime code / data cache overlap performance problems. Granted, they go away eventually. I prefer the idea of a hypercall page, but not a central initialization. Rather, a decentralized approach where PV drivers can detect using CPUID which hypervisor is present, and a common MSR shared by all hypervisors that provides the location of the hypercall page. Zach - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Anthony Liguori wrote: > The whole point of using the instruction is to allow hypercalls to be > used in many locations. This has the nice side effect of not > requiring a central hypercall initialization routine in the guest to > fetch the hypercall page. A PV driver can be completely independent > of any other code provided that it restricts itself to it's hypercall > namespace. I see. So you take the fault, disassemble the instruction, see that its another CPU's vmcall instruction, and then replace it with the current CPU's vmcall? > Xen is currently using 0/1/2. I had thought it was only using 0/1. > The intention was not to squash Xen's current CPUID usage so that it > would still be possible for Xen to make use of the guest code. Can we > agree that Xen won't squash leaves 3/4 or is it not worth trying to be > compatible at this point? No, the point is that you're supposed to work out which hypervisor it is from the signature in leaf 0, and then the hypervisor can put anything it wants in the other leaves. J - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Zachary Amsden wrote: > On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote: > >> Jeremy Fitzhardinge wrote: >> >>> Anthony Liguori wrote: >>> >>> This patch refactors the current hypercall infrastructure to better support live migration and SMP. It eliminates the hypercall page by trapping the UD exception that would occur if you used the wrong hypercall instruction for the underlying architecture and replacing it with the right one lazily. >>> I guess it would be pretty rude/unlikely for these opcodes to get reused >>> in other implementations... But couldn't you make the page trap >>> instead, rather than relying on an instruction fault? >>> >>> >> The whole point of using the instruction is to allow hypercalls to be >> used in many locations. This has the nice side effect of not requiring >> a central hypercall initialization routine in the guest to fetch the >> hypercall page. A PV driver can be completely independent of any other >> code provided that it restricts itself to it's hypercall namespace. >> > > But if the instruction is architecture dependent, and you run on the > wrong architecture, now you have to patch many locations at fault time, > introducing some nasty runtime code / data cache overlap performance > problems. Granted, they go away eventually. > We're addressing that by blowing away the shadow cache and holding the big kvm lock to ensure SMP safety. Not a great thing to do from a performance perspective but the whole point of patching is that the cost is amortized. > I prefer the idea of a hypercall page, but not a central initialization. > Rather, a decentralized approach where PV drivers can detect using CPUID > which hypervisor is present, and a common MSR shared by all hypervisors > that provides the location of the hypercall page. > So then each module creates a hypercall page using this magic MSR and the hypervisor has to keep track of it so that it can appropriately change the page on migration. The page can only contain a single instruction or else it cannot be easily changed (or you have to be able to prevent the guest from being migrated while in the hypercall page). We're really talking about identical models. Instead of an MSR, the #GP is what tells the hypervisor to update the instruction. The nice thing about this is that you don't have to keep track of all the current hypercall page locations in the hypervisor. Regards, Anthony Liguori > Zach > > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: > >> The whole point of using the instruction is to allow hypercalls to be >> used in many locations. This has the nice side effect of not >> requiring a central hypercall initialization routine in the guest to >> fetch the hypercall page. A PV driver can be completely independent >> of any other code provided that it restricts itself to it's hypercall >> namespace. >> > > I see. So you take the fault, disassemble the instruction, see that its > another CPU's vmcall instruction, and then replace it with the current > CPU's vmcall? > Yup. >> Xen is currently using 0/1/2. I had thought it was only using 0/1. >> The intention was not to squash Xen's current CPUID usage so that it >> would still be possible for Xen to make use of the guest code. Can we >> agree that Xen won't squash leaves 3/4 or is it not worth trying to be >> compatible at this point? >> > > No, the point is that you're supposed to work out which hypervisor it is > from the signature in leaf 0, and then the hypervisor can put anything > it wants in the other leaves. > Yeah, see, the initial goal was to make it possible to use the KVM paravirtualizations on other hypervisors. However, I don't think this is really going to be possible in general so maybe it's better to just use leaf 0. I'll let others chime in before sending a new patch. Regards, Anthony Liguori > J > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Anthony Liguori wrote: > Yeah, see, the initial goal was to make it possible to use the KVM > paravirtualizations on other hypervisors. However, I don't think this > is really going to be possible in general so maybe it's better to just > use leaf 0. I'll let others chime in before sending a new patch. Hm. Obviously you can just define a signature for "kvm-compatible hypercall interface" and make it common that way, but it gets tricky if the hypervisor supports multiple hypercall interfaces, including the kvm one. Start the kvm leaves at 0x40001000 or something? J - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: > >> Yeah, see, the initial goal was to make it possible to use the KVM >> paravirtualizations on other hypervisors. However, I don't think this >> is really going to be possible in general so maybe it's better to just >> use leaf 0. I'll let others chime in before sending a new patch. >> > > Hm. Obviously you can just define a signature for "kvm-compatible > hypercall interface" and make it common that way, but it gets tricky if > the hypervisor supports multiple hypercall interfaces, including the kvm > one. Start the kvm leaves at 0x40001000 or something? > Yeah, that works with me. Regards, Anthony Liguori > J > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio & hypercall interface?
Avi Kivity wrote: > Anthony Liguori wrote: > >> Dor Laor wrote: >> >> Hi all, I've finally started looking at Dor's git tree, and it struck me >>> that >>> >>> >>> it conflicts with Anthony's hypercall patches. FWIW I like Anthony's patching thing, and don't really care about arg order. It'd be nice if we could pull in the same direction tho 8) Thanks, Rusty. >>> Good news you're looking at my tree, since the forum I didn't do much >>> since I had to catch up some gazlion other tasks, never the less >>> starting on Sunday I'm back again. >>> >>> Actually, I wanted to rebase my hypercalls over Anhtony's too (except >>> for allowing userspace handling). >>> >>> >> I thought we discussed just providing a signaling message to userspace >> for virtio? It's not strictly necessary to expose hypercalls to >> userspace in order to implement a virtio backend in userspace. >> >> >> > > Yes, that's what I'd like to see too. Signal a channel. > > First, I though that this http://www.mail-archive.com/kvm-devel@lists.sourceforge.net/msg06230.html was your latest opinion. Second, regardless of the channel signal notification, there are still real necessities for userspace hypercall handling: 1. For virtio drivers there is also registration hypercall for passing the shared memory pfns. Sure there are other possibilities, but why limit ourselves? 2. For other purposes such as a balloon driver, a deflate/inflate hypercalls are needed. Although for x86 mmio/pio can be used but this is not compatible with other architectures. Regards & thanks for the patch resend, Dor - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Anthony Liguori wrote: > Jeremy Fitzhardinge wrote: > > Anthony Liguori wrote: > > > > > Yeah, see, the initial goal was to make it possible to use the KVM > > > paravirtualizations on other hypervisors. However, I don't think this > > > is really going to be possible in general so maybe it's better to just > > > use leaf 0. I'll let others chime in before sending a new patch. > > > > > > > Hm. Obviously you can just define a signature for "kvm-compatible > > hypercall interface" and make it common that way, but it gets tricky if > > the hypervisor supports multiple hypercall interfaces, including the kvm > > one. Start the kvm leaves at 0x40001000 or something? > > > > Yeah, that works with me. To me this is the beginning of fragmentation. Why do we need different and VMM-specific Linux paravirtualization for hardware-assisted virtualization? That would not be good for Linux. > > Regards, > > Anthony Liguori > > > J Jun --- Intel Open Source Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Nakajima, Jun wrote: >>> one. Start the kvm leaves at 0x40001000 or something? >>> >>> >> Yeah, that works with me. >> > > To me this is the beginning of fragmentation. Why do we need different > and VMM-specific Linux paravirtualization for hardware-assisted > virtualization? That would not be good for Linux. > On the contrary. Xen already has a hypercall interface, and we need to keep supporting it. If we were to also support a vmm-independent interface (aka "kvm interface"), then we need to be able to do that in parallel. If we have a cpuid leaf clash, then its impossible to do so; if we define the new interface to be disjoint from other current users of cpuid, then we can support them concurrently. J - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Jeremy Fitzhardinge wrote: > Nakajima, Jun wrote: > > > > one. Start the kvm leaves at 0x40001000 or something? > > > > > > > > > > > Yeah, that works with me. > > > > > > > To me this is the beginning of fragmentation. Why do we need different > > and VMM-specific Linux paravirtualization for hardware-assisted > > virtualization? That would not be good for Linux. > > > > On the contrary. Xen already has a hypercall interface, and we need to > keep supporting it. If we were to also support a vmm-independent > interface (aka "kvm interface"), then we need to be able to do that in > parallel. If we have a cpuid leaf clash, then its impossible to do so; > if we define the new interface to be disjoint from other current users > of cpuid, then we can support them concurrently. > > J Today, 3 CPUID leaves starting from 0x4000_ are defined in a generic fashion (hypervisor detection, version, and hypercall page), and those are the ones used by Xen today. We should extend those leaves (e.g. starting from 0x4000_0003) for the vmm-independent features as well. If Xen needs additional Xen-specific features, we need to allocate some leaves for those (e.g. 0x4000_1000) Jun --- Intel Open Source Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Disk migration
> >The push model may require parallelization of the disk and memory >convergence depending on how much disk activity the guest is doing. >That's a pretty interesting problem but it shouldn't be too >hard to solve. > Embed this kind of cache like disk ops (write and read hit always goes to local disk, while read miss goes to remote source before convergence) feature into IDE device model would be great which will benefit both KVM & Qemu and thus easier to push into Qemu tree. thx, eddie - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Nakajima, Jun wrote: > Today, 3 CPUID leaves starting from 0x4000_ are defined in a generic > fashion (hypervisor detection, version, and hypercall page), and those > are the ones used by Xen today. We should extend those leaves (e.g. > starting from 0x4000_0003) for the vmm-independent features as well. > > If Xen needs additional Xen-specific features, we need to allocate some > leaves for those (e.g. 0x4000_1000) But the signature is "XenVMMXenVMM", which isn't very generic. If we're presenting a generic interface, it needs to have a generic signature, otherwise guests will need to have a list of all hypervisor signatures supporting their interface. Since 0x4000 has already been established as the base leaf of the hypervisor-specific interfaces, the generic interface will have to be elsewhere. J - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Jeremy Fitzhardinge wrote: > Nakajima, Jun wrote: > > Today, 3 CPUID leaves starting from 0x4000_ are defined in a generic > > fashion (hypervisor detection, version, and hypercall page), and those > > are the ones used by Xen today. We should extend those leaves (e.g. > > starting from 0x4000_0003) for the vmm-independent features as well. > > > > If Xen needs additional Xen-specific features, we need to allocate some > > leaves for those (e.g. 0x4000_1000) > > But the signature is "XenVMMXenVMM", which isn't very generic. If we're > presenting a generic interface, it needs to have a generic signature, > otherwise guests will need to have a list of all hypervisor signatures > supporting their interface. Since 0x4000 has already been > established as the base leaf of the hypervisor-specific interfaces, the > generic interface will have to be elsewhere. The hypervisor detection machanism is generic, and the signature returned is implentation specific. Having a list of all hypervisor signatures sounds fine to me as we are detecting vendor-specific processor(s) in the native. And I don't expect the list is large. > > J Jun --- Intel Open Source Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
On Fri, 2007-09-14 at 13:53 -0700, Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: > > This patch refactors the current hypercall infrastructure to better support > > live > > migration and SMP. It eliminates the hypercall page by trapping the UD > > exception that would occur if you used the wrong hypercall instruction for > > the > > underlying architecture and replacing it with the right one lazily. > > > > I guess it would be pretty rude/unlikely for these opcodes to get reused > in other implementations... But couldn't you make the page trap > instead, rather than relying on an instruction fault? That's a pain for inline hypercalls tho. I was planning on moving lguest to this model (which is interesting, because AFAICT this insn will cause a #UD or #GP depending on whether VT is supported on this box so I have to look for both). Cheers, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio & hypercall interface?
On Sat, 2007-09-15 at 01:31 +0300, Dor Laor wrote:
> Second, regardless of the channel signal notification, there are still
> real necessities for userspace hypercall handling:
> 1. For virtio drivers there is also registration hypercall for passing
> the shared memory pfns.
> Sure there are other possibilities, but why limit ourselves?
I really prefer doing this the more "hardware-like" way and having the
device description say where the pages are. Surely this is simpler from
the qemu side, too?
I'm working from the lguest side to try to get uniform virtio, and
lguest does it this way.
> 2. For other purposes such as a balloon driver, a deflate/inflate
> hypercalls are needed.
> Although for x86 mmio/pio can be used but this is not compatible
> with other architectures.
We could encode the notification method in the config space ("execute
this!").
OK, maybe not. But it'd be generic!
Rusty.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote: > So then each module creates a hypercall page using this magic MSR and > the hypervisor has to keep track of it so that it can appropriately > change the page on migration. The page can only contain a single > instruction or else it cannot be easily changed (or you have to be able > to prevent the guest from being migrated while in the hypercall page). > > We're really talking about identical models. Instead of an MSR, the #GP > is what tells the hypervisor to update the instruction. The nice thing > about this is that you don't have to keep track of all the current > hypercall page locations in the hypervisor. I agree, multiple hypercall pages is insane. I was thinking more of a single hypercall page, fixed in place by the hypervisor, not the kernel. Then each module can read an MSR saying what VA the hypercall page is at, and the hypervisor can simply flip one page to switch architectures. Zach - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Nakajima, Jun wrote: > The hypervisor detection machanism is generic, and the signature > returned is implentation specific. Having a list of all hypervisor > signatures sounds fine to me as we are detecting vendor-specific > processor(s) in the native. And I don't expect the list is large. > > I'm confused about what you're proposing. I was thinking that a kernel looking for the generic hypervisor interface would check for a specific signature at some cpuid leaf, and then go about using it from there. If not, how does is it supposed to detect the generic hypervisor interface? J - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Jeremy Fitzhardinge wrote: > Nakajima, Jun wrote: > > The hypervisor detection machanism is generic, and the signature > > returned is implentation specific. Having a list of all hypervisor > > signatures sounds fine to me as we are detecting vendor-specific > > processor(s) in the native. And I don't expect the list is large. > > > > > > I'm confused about what you're proposing. I was thinking that a kernel > looking for the generic hypervisor interface would check for a specific > signature at some cpuid leaf, and then go about using it from there. If > not, how does is it supposed to detect the generic hypervisor interface? > > J I'm suggesting that we use CPUID.0x400Y (Y: TBD, e.g. 6) for Linux paravirtualization. The ebx, ecx and edx return the Linux paravirtualization features available on that hypervisor. Those features are defined architecturally (not VMM specific). Like CPUID.0, CPUID.0x4000 is used to detect the hypervisor with the vendor identification string returned in ebx, edx, and ecx (as we are doing in Xen). The eax returns the max leaf (which is 0x4002 on Xen today). And like CPUID.1, CPUID.0x4001 returns the version number in eax, and each VMM should be able to define a number of VMM-specific features available in ebx, ecx, and edx returned (which are reserved, i.e. not used in Xen today). Suppose we knew (i.e. tested) Xen and KVM supported Linux paravirtualization, the Linux code does: 1. detect Xen or KVM using CPUID.0x4000 2. Check the version if necessary using CPUID.0x4001 3. Check the Linux paravirtualization features available using CPUID.0x400Y. Jun --- Intel Open Source Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm daily snaphsots are now available
For those of you who would like to assist in testing without waiting for the next release, yet are uncomfortable with git, I've made available daily development snapshots of kvm in http://people.qumranet.com/avi/snapshots/ If you report a bug in a snaphot, please specify both the snapshot name (which includes the date) and the contents of the SOURCES file within the snapshot, which contains the git HEAD hashes for the kernel and userspace repositories. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
