I've updated this patch and switched to using a scale/shift
like Xen is
doing, but I must admit, I don't understand how it helps adjtime. I
poked around a bit and it wasn't obvious.
I think the reason is that Xen can't use FP to avoid FP save/restore
at VM Exit time, while PV guest can
Li, Xin B wrote:
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.
Yes. This was
Dong, Eddie wrote:
In Xen, we virtualize TSC too to make sure the guest TSC time is
synchronized with
guest PIT time, so guest can see an accurate virtual time. (refer my
presentation
doc on Xen September summit 06.) It is good but time to time
we see bugs due to the complicated time
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
Dong, Eddie wrote:
Yes. but I am wondering about the performance. Hypercall to get
host time should be expansive than hardware support TSC read which is
about 200 cycles. I may make mistake since I didn't go through the patch
in very detail.
gettimeofday is very important :-)
Maybe we
This patch applies to the lapic branch. Its a simple little cleanup that I
meant to get in earlier and never got around to.
---
KVM: Properly support LINT1 pin
LINT1 is not currently wired to anything, so there is no support for it in
the LAPIC code. We should fix the support for completeness
On Wed, 2007-06-20 at 15:43 +0800, Dong, Eddie wrote:
As we discussed, if we move APIC to kernel while leaving PIC in user
level, we have ABI level holes if the interrupt a user level qemu
injected is not immediately injected to guest for some reason. \
Hi Eddie,
I know you worked hard on
On Thu, 2007-06-21 at 20:41 +0800, Dong, Eddie wrote:
I'm not sure if this affects the TSC theory or not, but note that the
host and guest have 250Hz PIT configured in the config. E.g. both
kernels are programming the PIT to 250Hz, but guest is only
seeing 125Hz
ticks. If I fix the
Gregory Haskins wrote:
On Wed, 2007-06-20 at 15:43 +0800, Dong, Eddie wrote:
As we discussed, if we move APIC to kernel while leaving PIC in user
level, we have ABI level holes if the interrupt a user level qemu
injected is not immediately injected to guest for some reason. \
Hi Eddie,
I
Baruch Even wrote:
Avi Kivity wrote:
Baruch Even wrote:
I'm using KVM 28 and when I'm trying to reboot the guest vm kvm
fails with the following message:
Can you be more specific as to what you're doing? what host cpu,
bitness, guest OS, bitness, actions to reproduce?
The host CPU
Avi Kivity wrote:
Anthony Liguori wrote:
Hi,
This is an update to the paravirt_ops KVM backend series. I've made
a number of changes and attempted to incorporate all the feedback
from the last review. Some highlights:
1) Clean up the paravirt time source patch to use a more Xen-like
On Thu, 2007-06-21 at 13:31 +, Gregory Haskins wrote:
On Thu, 2007-06-21 at 21:02 +0800, Dong, Eddie wrote:
Achitectually not only that. A premature IRR-ISR will cause guest OS
confuse in many place. A guest (say BIOS) may turn from interrupt
enabled mode to polling mode which polls
If you really think supporting mixed irqchip mode is a must
I will leave it to Avi to decide since he implicitly suggested it.
But suffice to say, if we *dont* want to support it we will need to
get the other in-kernel stuff into the lapic branch in its entirety
before it can be merged so
Gregory Haskins wrote:
So assuming this newly enlightened position is true, I think this
means we have a choice:
1) Drop support for mixed level-1 mode and move the PIC to the
kernel now as Eddie is doing
2) Keep the level-1/2 distinction, and add support for making sure
that once a
On Thu, 2007-06-21 at 22:57 +0800, Dong, Eddie wrote:
Gregory Haskins wrote:
So assuming this newly enlightened position is true, I think this
means we have a choice:
1) Drop support for mixed level-1 mode and move the PIC to the
kernel now as Eddie is doing
2) Keep the
We are in same page now :-)
Gregory Haskins wrote:
On Thu, 2007-06-21 at 22:57 +0800, Dong, Eddie wrote:
Gregory Haskins wrote:
So assuming this newly enlightened position is true, I think this
means we have a choice:
1) Drop support for mixed level-1 mode and move the PIC to the
On Thu, 2007-06-21 at 22:28 +0800, Dong, Eddie wrote:
I suppose, but it somewhat defeats the purpose IMO. Every pin in the
8259 that gets tickled implicitly means an IOAPIC pin was tickled
also. Do we really want to go to userspace for that? Essentially
User space can handle this, go
From: Joerg Roedel [EMAIL PROTECTED]
This patch adds an implementation to the svm is_disabled function to
detect reliably if the BIOS disabled the SVM feature in the CPU. This
fixes the issues with kernel panics when loading the kvm-amd module on
machines where SVM is available but disabled.
Avi Kivity wrote:
Gregory Haskins wrote:
1) KVM_ISA_INTERRUPT: In level-1 mode, this API allows the userspace
pic to dispatch a vector to the kernel. In level-2 mode, this allows
any userspace app to tickle an isa based irq line (which feeds into
the inputs of the PIC and IOAPIC. In other
On Fri, 2007-06-22 at 10:09 +0800, Dong, Eddie wrote:
Avi Kivity wrote:
Eddie, is that what you were driving at in your simplification
attempt?
Yes, some minor thing:
KVM_ISA_INTERRUPT: Per VM I/F, and need an irq line and irq level.
KVM_IOAPIC_INTERRUPT: Per VM I/F, may also need
20 matches
Mail list logo
