>-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
age-
>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 expec
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,
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: Wedne
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
>-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
>-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
>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 lo
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 enter
>-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 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
>
>
>---
>>>
>>> -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
>> 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
>r
>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
>
>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
--
>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
>pa
>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();
>+
>
>cpuid was intentionally made per-vcpu, since that's the way real
>hardware works. Note that the ioctl() uses a vcpu fd, not a vm fd. Is
>there a reason why you can't initialize cpuid for all vcpus from qemu?
>
To my knowledge, for a SMP system, all the CPU should be the same, even
the steppin
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 of vCPU wide.
Signed-off-by: Xin Li <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index b08272b..eb9a594 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -355,9 +355,6 @@ struct kvm_vcpu {
} tr, es, ds, fs, gs;
>
>The long return value of rmode_tss_base is truncated by its declared
>return type of int.
>
>Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
>--
> drivers/kvm/vmx.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>Index: kvm/drivers/kvm/vmx.c
>===
>> 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 majo
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,
>>So you will check in the patch soon?
>>Really a good news since this will be the base for enabling SMP.
>>-Xin
>
>Our plan is to run regressions tests with it at by Monday to
>check it in
>if there are no surprises.
>I already booted Linux with it :)
>
>Btw: Have you started any smp related deve
So you will check in the patch soon?
Really a good news since this will be the base for enabling SMP.
-Xin
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Avi Kivity
>Sent: Thursday, May 24, 2007 4:55 PM
>To: Gregory Haskins
>Cc: kvm-devel@lists.sou
>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
>
> 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
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsa
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 & busi
28 matches
Mail list logo
