-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Li, Xin B
Sent: Wednesday, August 22, 2007 10:08 PM
To: kvm-devel@lists.sourceforge.net
Subject: [kvm-devel] [PATCH] Fix BIOS CPU enumeration
KVM BIOS uses the following code to delay an expected milliseconds
void delay_ms(int n
-Original Message-
From: Avi Kivity [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 23, 2007 4:29 PM
To: Li, Xin B
Cc: kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] [PATCH] Fix BIOS CPU enumeration
Li, Xin B wrote:
Current BIOS delays 10ms for AP to boot up, but we found
KVM BIOS uses the following code to delay an expected milliseconds
void delay_ms(int n)
{
int i, j;
for(i = 0; i n; i++) {
/* approximative ! */
for(j = 0; j 100; j++);
}
}
It's OK when we run APIC in user level, but when APIC is in kernel, the
delayed time is
Now on lapic5 branch, we can run Windows guests, both 32bit and 64bit
are OK, but Linux still has problems.
And we will send out the SMP patches for review soon.
-Xin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Li, Xin B
Sent: Wednesday, August 22
Just rebased to the latest lapic5 branch, found SMP patch is there, so
kernel APIC SMP is working on your side?
But I don't think you can even pass BIOS CPU enumeration.
-Xin
-Original Message-
From: Li, Xin B
Sent: Wednesday, August 22, 2007 10:17 PM
To: Li, Xin B; kvm-devel
Did you see any performance improvements out of this?
Acturally we don't expect any obviously performance because MSR accesses
are not frequent.
-Xin
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through
-Original Message-
From: Avi Kivity [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 02, 2007 10:50 PM
To: Li, Xin B
Cc: He, Qing; Rusty Russell; kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] [PATCH 2/2] Add MSR Bitmap support in VMX
Li, Xin B wrote:
Did you see any
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ulrich Drepper
Sent: Friday, August 03, 2007 2:24 AM
To: Nakajima, Jun
Cc: kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] [PATCH 2/2] Add MSR Bitmap support in VMX
-BEGIN PGP SIGNED
Remove a duplicated ia32e mode VM Entry control definition and use the
proper one.
Signed-off-by: Xin Li [EMAIL PROTECTED]
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 49635c4..10abb57 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -1107,7 +1107,7 @@ static void
btw, what about cpu hotplug? we need to deal with that too. Do we
error out and refuse to enable the cpu if it isn't compatible enough?
I think we shouldn't enable it, or the code becomes to complex.
-xin
--
error compiling committee.c: too many arguments to function
-Original Message-
From: Avi Kivity [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 31, 2007 4:10 PM
To: Li, Xin B
Cc: Yang, Sheng; kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] [PATCH] Add cpu consistence check in vmx.
Li, Xin B wrote:
btw, what about cpu hotplug? we need
This patch replaces vmcs_write32_fixedbits() with
adjust_vmx_controls(),
It still doesn't say why, but I can now see it: this is code
from Xen. I have no objection to copying Xen code, but it needs to be
documented in
the changelog, and there needs to be a good reason as to why you're
-static struct vmcs_descriptor {
+static struct vmcs_config {
Why the name change? Just for Xen compatibility? If that's the only
reason, it's insufficent.
If you agree the above, this becomes reasonable.
-Xin
I'm not a English native speaker, maybe descriptor is a good name too.
-xin
As for performance, I've got a few interesting results. kbuild with a
guest using 2G of memory goes from 19 minutes to 12 minutes with the
full series applied. Using 512mb, the build time goes from 10.75
minutes to 9 minutes. For 512mb, native is around 7 minutes so that's
pretty close to
BTW,
The current VMX code does not make sense to me:
static void vmx_flush_tlb(struct kvm_vcpu *vcpu)
{
vmcs_writel(GUEST_CR3, vmcs_readl(GUEST_CR3));
}
The point is, vmexits will invalidate all TLB entries on Intel VT
processor today.
-Xin
Hi Xin,
Nice work! I am bummed that you are getting to do all the fun
parts :)
I have one comment:
+ while (1) {
+ if (vcpu-init_sipi_sipi_state ==
+ KVM_VCPU_INIT_SIPI_SIPI_STATE_NORM)
+ break;
+ yield();
+ }
Li, Xin B wrote:
I've just got x86_64 Linux 2.6.20.3 SMP guest boots on KVM
with 2 vCPUs
(I'm using a x86_64 RHEL5 image but the RHEL5 kernel can't boot.),
I found that an issue with x86-64 is that the mmu picks up an nx shadow
page for a non-nx guest pte. This is unrelated to smp
Really strange, I sent out this email last night, but it didn't appear
on the list.
-Xin
-Original Message-
From: Li, Xin B
Sent: Tuesday, June 12, 2007 12:47 AM
To: kvm-devel@lists.sourceforge.net
Subject: cpuid should be VM wide instead of vCPU wide.
cpuid should be VM wide instead
I don't think this patch is complete to add NMIP support to KVM, and can
you pls exclude it from current APIC patchsets? We can revisit it later
with more thoughts.
-Xin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Gregory Haskins
Sent: Friday,
I don't think this patch is complete to add NMIP support to KVM
Could you be more specific on whats left to be done? From
what I could read in the doc, this seemed complete.
This is a good start, and we also need to add a vmexit handler to handle
exit reason 8, NMI pending.
And the major
Li, Xin B wrote:
If the git: and svn: protocols are blocked for you, I can
try to make them available through http.
That would be helpful, thanks!
-Xin
http://www.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git, branch
avi/master
Subversion is not yet available.
We also need synch
I can't get the source code through http or https, can anyone help?
-Xin
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT
22 matches
Mail list logo
