>
>
>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
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.
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 v
>-Original Message-
>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>Sent: 2007年6月21日 17:01
>To: Dong, Eddie
>Cc: Gregory Haskins; kvm-devel@lists.sourceforge.net
>Subject: Re: [kvm-devel] A testing for KVM
>
>Dong, Eddie wrote:
>> In Xen, we virtualize TSC too to make sure the guest TSC ti
Stephane Eranian wrote:
> Avi,
>
> On Fri, Jun 15, 2007 at 01:49:06PM +0300, Avi Kivity wrote:
>
>> Magicboiz wrote:
>>
>>> a little bit better. It Opps'ed again, but this time, my laptop is still
>>> usable:
>>>
>>> sudo /usr/local/kvm/bin/qemu -hda /tmp/disco-qemu -m 128 -boot d
>>> -cdr
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 model
> 2) Chan
>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
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 :-)
>
Ma
On Thu, 2007-06-21 at 11:23 +0800, Dong, Eddie wrote:
> >
> >One of the things that I noticed during the development of the APIC
> >patchset that was quite odd:
> >
> >1) Linux guest was programming the PIT for 4ms.
> >2) QEMU was programming the sigalarm for 1ms
> >3) SIGALARM was only delivered e
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 completenes
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 t
> 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 lost interrupt to bring the ticks to a true
> 250Hz, wa
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 "f
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 Edd
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 is
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 mo
On Thu, 2007-06-21 at 21:02 +0800, Dong, Eddie wrote:
> 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
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 whi
>> 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 merg
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
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
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 th
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 th
On Thu, 2007-06-21 at 15:17 +, Gregory Haskins wrote:
> 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
On Thu, 2007-06-21 at 23:13 +0800, Dong, Eddie wrote:
> We are in same page now :-)
Good :) I still need to add that "int level" field to KVM_IRQ_INTERRUPT
as we discussed a few weeks ago to be considered complete, though.
-Greg
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 words, a level-2
On Thu, 2007-06-21 at 19:31 +0300, Avi Kivity wrote:
> Wait. Looks like APIs are changing meaning according to some mode.
> Confusion.
>
> How about:
>
> KVM_INTERRUPT == inject this vector now
> KVM_EXTINT == drives the processor's interrupt pin (this is handled by
> the lapic code). input is
Hiho,
--On Tuesday, June 19, 2007 13:41:07 +0100 Richard Hughes
<[EMAIL PROTECTED]> wrote:
On Tue, 2007-06-19 at 08:33 -0400, Jeremy Katz wrote:
[...]
I actually extracted the patch set yesterday for the Fedora kernel and
it's in today's rawhide kernel. Should be a good way to get some ext
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.
S
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. I
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
31 matches
Mail list logo
