Long, Kaiwen wrote:
Hi,
Is there any plan to port KVM on Itanium to utilize the VTI ?
I'd
like to have a try. Is there anyone doing the work? Or Any volunteer
to work together on it? -Original Message-
We are still in design phase now. There are outstanding issues for
Itanium.
Dor Laor wrote:
Do you know why Xen guy choose of implementing it in Xen? Why didn't
they rip Qemu implementation?
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ linux
kernel, KB gets 14% gain. We also did a shared PIC model which share
PIC state among Qemu VMM with less
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
any 'cut' of the interface to allow both qemu and KVM generate vectors
is unnecessary (and harmful) complexity. The interface cut should be
at
the 'pin' level, with Qemu raising a signal on a pin and lowering a
signal on a pin, but
Dor Laor wrote:
Dor Laor wrote:
Do you know why Xen guy choose of implementing it in Xen? Why
didn't they rip Qemu implementation?
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ linux
kernel, KB gets 14% gain. We also did a shared PIC model which share
PIC state among
Avi Kivity wrote:
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ linux
kernel, KB gets 14% gain. We also did a shared PIC model which share
PIC state among Qemu VMM with less LOC in VMM, it can get
similar performance gain (5.8% in my test).
BTW, at that time, PIT is in VMM
Dor Laor wrote:
So for the sake of the next arguments, what was the fuel running the
decision of moving all the X-PI[c|t] things into the Xen?
PIT is in Xen at very beginning when HVM support is designed due to
performance
reason. Moving PIC to VMM is also for performance reason at that time
Avi Kivity wrote:
Dong, Eddie wrote:
Avi Kivity wrote:
With PIC in Xen, CPU2K gets 6.5% performance gain in old 1000HZ
linux kernel, KB gets 14% gain. We also did a shared PIC model
which share PIC state among Qemu VMM with less LOC in VMM, it
can get
similar performance gain (5.8
A minor patch to avoid heavy is_empty_shadow_page for release version.
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index e85b4c7..58fdd7b 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -52,11 +52,15 @@ static void kvm_mmu_audit(struct kvm_vcpu *vcpu,
const char *msg) {}
This patch is to remove the redundant MSR save/restore at lightweight VM
EXIT time. With this patch VMX guest KB performance can increase 17-37%.
(I only tested it on KVM-18 since the git tree still has problem in my
side, but I'd like to post this earlier to collect more feedback)
Thanks, eddie
Sorry for that, attached now.
Eddie
-Original Message-
From: Avi Kivity [mailto:[EMAIL PROTECTED]
Sent: 2007年4月25日 16:03
To: Dong, Eddie
Cc: kvm-devel
Subject: Re: [kvm-devel] [PATCH] Remove heavy is_empty_shadow_page call.
Dong, Eddie wrote:
A minor patch to avoid heavy
O, yes typo at different tree porting time.
Michael Riepe wrote:
Dong, Eddie wrote:
A minor patch to avoid heavy is_empty_shadow_page for release
version.
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index e85b4c7..58fdd7b 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
A minor change to reduce vcpu_put/vcpu_load frequency (still base on
KVM-18). Not sure if you would like to see this?
Signed-off-by: Yaozu Dong [EMAIL PROTECTED]
--- vmx.old 2007-04-25 20:28:19.0 +0800
+++ vmx.new 2007-04-25 20:28:10.0 +0800
@@ -1945,7 +1945,8 @@
Avi Kivity wrote:
Dong, Eddie wrote:
A minor change to reduce vcpu_put/vcpu_load frequency (still base on
KVM-18). Not sure if you would like to see this?
Signed-off-by: Yaozu Dong [EMAIL PROTECTED]
--- vmx.old 2007-04-25 20:28:19.0 +0800
+++ vmx.new 2007-04-25 20:28
Anthony Liguori wrote:
This should get moved to kvm_resched() since both VT/SVM would benefit
from this.
I would suggest we just add similar code in SVM side. After we
optimize the MSR/VMCS register save/restore to skip for
those lightweight VM EXIT (handled by KVM). Giving up preemption
Anthony Liguori wrote:
Dong, Eddie wrote:
Anthony Liguori wrote:
This should get moved to kvm_resched() since both VT/SVM would
benefit from this.
I would suggest we just add similar code in SVM side. After we
optimize the MSR/VMCS register save/restore to skip for
those lightweight
I am looking into the efficiency of shadow code and get
interesting sight: Increasing KVM_NUM_MMU_PAGES doesn't help performance
which is quit stranger, and the #PF is realitively higher than other
virtualization solution.
If any of you have any sight, please let me know.
thanks,
Carsten Otte wrote:
Hollis Blanchard wrote:
So if I understand correctly, this work is totally separate from
KVM, but you're posting for comment and intend to merge with KVM in
the future.
Actually we started working on this quite long before kvm came up back
in 2005 as prototype work. Our
Looking at following code, PT_INDEX is defined as a host environment
dependant MACRO while the code is walking guest page table. Is this a
bug? Do we ever get a pure 32 bits (non PAE) guest run on top of 64 bits
(or PAE) host?
thanks,eddie
static int FNAME(walk_addr)(struct guest_walker
O, my fault! Sorry.
Dong, Eddie wrote:
Looking at following code, PT_INDEX is defined as a host environment
dependant MACRO while the code is walking guest page table. Is this a
bug? Do we ever get a pure 32 bits (non PAE) guest run on top of 64
bits (or PAE) host?
thanks,eddie
Avi Kivity wrote:
Dong, Eddie wrote:
This patch provides short cut handling for light weight VM Exit,
which can boost KB performance 11% under FC5 guest.
Any comments?
While the patch looks good, it kills FC6 x86_64 boot with a double
fault. Guest kernel is 2.6.18-1.2798. dmesg says
Avi Kivity wrote:
I measured 650 cycles saved from a total of 5300 before the patch.
The patch had a bug where it would exit to userspace if need_resched()
was true. This can reduce performance on a high context
Avi:
This is not a must though it is OK, OS will automatically do
Avi:
Following commit mentioned guest state leaking into host, Can u
explain a bit?
In my understanding, as if control goes to vmx_vcpu_run, CPU
preemption is disabled, i.e. no rescheduling will happen (Guest
resheduling will only happen at IOCTL return to Qemu time or vcpu_put
Avi Kivity wrote:
Some exit handlers (even the #PF handler) can sleep sometimes. They
call kvm_arch_ops-vcpu_put(), do some sleepy thing, then call
kvm_arch_ops-vcpu_load(). The changes in the commit make
sure that if
vcpu_put() is called, the lightweight exit is converted to a
Avi Kivity wrote:
Why not use hardware autoloading? Is it slower than software?
I believe HW is faster than SW, but the problem is that this kind of
save/restore is
only needed for heavy weight VM Exit in KVM. While HW doesn't provide an
easy
way to bypass these MSR save/restore for light
Avi Kivity wrote:
You missed my comments regarding coding style.
Oo, I read the original mail too quickly and goes to bottom directly.
Here is the update.
BTW, vcpu-active_msr_list is not in this patch. I am working on another
patch
for MSR_EFER acceleration now which give me another 5-10%
Alternative to swaping host/guest MSR entry array to avoid MSR bitmap.
More suggestions?
thx,eddie
Signed-off-by: Yaozu(Eddie) Dong [EMAIL PROTECTED]
against ca76d209b88c344fc6a8eac17057c0088a3d6940.
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 1bbafba..5f056d9 100644
---
Avi Kivity wrote:
This looks nicer, however I get an oops on fxrstor in
kvm_load_guest_fpu(), when running user/test/vmexit.flat compiled for
i386, on an x86_64 host.
Avi:
Per your guideline, I did following under kvm-userspace/user:
1: make test/bootstrap
2: make
Avi Kivity wrote:
Here it is.
It's broken; your binutils is probably too old.
Can u also send me your bootstrap and flat so that I can try here?
Thx,eddie
Avi:
Using yout vmexit.flat, it can work with my patch smoothly. Is
this the one you see problems?
From the
Seems a typo leaking our eyes :-(
Fixing a typo which mixes X86_64 and CONFIG_X86_64 and block 64
bits guest now.
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 5f4bdc0..9bf8c04 100644
---
Avi Kivity wrote:
Dong, Eddie wrote:
Avi:
This patch is to avoid saving and restoring of msr_efer on
lightweight vmexit.
With this patch, the Kernel build get 10% increasement for
64bits
on 64 bits, and 5-8% increasement for 32bits on 64 bits.
Vmexit.flat can see
Try again.
Eddie
kvm.h |2 ++
kvm_main.c | 23 +++
vmx.c | 59
+--
3 files changed, 66 insertions(+), 18 deletions(-)
commit 7de9b4bff794317ae05c0f3b2fec9b3d710fed2b
Author: root [EMAIL
[EMAIL PROTECTED] wrote:
Try again.
Wrong attachment. Please use this one.
commit 5ad9d2ec2cd1f324aa75f2bb0fd7a2de1cb769c3
Author: root [EMAIL PROTECTED](none)
Date: Mon May 21 10:37:34 2007 +0800
KVM: VMX: Avoid saving and restoring msr_efer on lightweight vmexit
Not sure if we should use PT_USER_MASK | PT_WRITABLE_MASK here.
diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
index 6dd0da9..183d4ca 100644
--- a/drivers/kvm/paging_tmpl.h
+++ b/drivers/kvm/paging_tmpl.h
@@ -213,7 +213,7 @@ static void FNAME(update_pte)(struct kvm_vcpu
Avi Kivity wrote:
Dong, Eddie wrote:
Avi:
I noticed the current MMU data structure is defined as per VCPU
such as:
struct kvm_vcpu {
.
struct list_head free_pages;
struct kvm_mmu_page page_header_buf[KVM_NUM_MMU_PAGES];
. }
This is a hot topics
Avi Kivity wrote:
On a pte update, npte will always be 1. On a pde update, we won't do
anything in mmu_pte_write_new_pte because it doesn't handle
pdes. If we
extend it to handle pdes, then we need either to modify the
new gpde or
to have the update take the quadrant into account.
Agree,
Avi Kivity wrote:
Dong, Eddie wrote:
Avi Kivity wrote:
On a pte update, npte will always be 1. On a pde update, we won't
do anything in mmu_pte_write_new_pte because it doesn't handle
pdes. If we extend it to handle pdes, then we need either to
modify the new gpde or to have the update
Move per VCPU mmu_memory_cache to be VM basis.
Your opnion?
Eddie
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0632d0b..77989b4 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -300,11 +300,6 @@ struct kvm_vcpu {
struct kvm_mmu mmu;
- struct
Avi Kivity wrote:
Dong, Eddie wrote:
Move per VCPU mmu_memory_cache to be VM basis.
Your opnion?
Eddie
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0632d0b..77989b4 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -300,11 +300,6 @@ struct kvm_vcpu
Greg:
Can you explain a bit why we need to distinguish
kvm_irqpin_extint from kvm_irqpin_localint? I am not in previous thread
for this. I saw latest V09 has hole here such as handle_exception due to
IRQ inject fail. I.e. IDT_VECTORING_INFO_FIELD only push localint back,
but no extint.
-Original Message-
From: Gregory Haskins [mailto:[EMAIL PROTECTED]
Sent: 2007年6月5日 1:23
To: Dong, Eddie; kvm-devel@lists.sourceforge.net
Subject: RE: [kvm-devel] [PATCH 3/9] KVM: Add irqdevice object
Dong, Eddie [EMAIL PROTECTED] 06/04/07 3:13 AM
Greg:
Can you explain a bit
When in kernel device model is introduced, the guest interrupt status
may get changed when after it injected an IRQ and thus guest see a
messed interrupt state. This patch tries to disable irq at that window
to avoid the confusion.
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Incorporates v8 plus the following changes:
1) Fix for hang on AMD
2) Fixes issue where irq-windows are inaccurately reported to
userspace 3) Fixed issue where irq-window-exiting requests can be
ignored in some cases
Note that we no longer need the backlog.patch
Gregory Haskins wrote:
Hi Eddie,
Back from vacation. Just catching up on email now
On Thu, 2007-06-07 at 16:20 +0800, Dong, Eddie wrote:
Greg:
Here are some detail comments towarding the LAPIC device model.
1:
irqabstraction layer vcpu-irq.pending holds the abstract
Gregory Haskins wrote:
On Fri, 2007-06-08 at 17:59 +0800, Dong, Eddie wrote:
1: I/F between user/kernel
a: Similar with the question in kernel side, current I/F only
support an IRQ set notification, we need clear notification too.
Especially when guest use IMR to mask the interrupt
We found that using an hrtimer enabled host with
CONFIG_HZ=1000 improves
things. However I don't think that it's as accurate as 7
seconds in 20
minutes (that's better than 1% accuracy), so probably more work is
needed in qemu to correct time drift.
Time virtualization for HVM is always a
This patch add in-kernel piohandlers on top of Greg's in-kernel
mmiohandlers as a preparation of in kernel PIC patch.
Eddie
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 31846b1..a7c5e6b 100644
--- a/drivers/kvm/kvm.h
+++
It is likely that guest stops to receive interrupt. I met this issue in
debuging
in kernel PIC patch. The normal reason is that a previous irq injection
fails (IDT_Vectoring valid). It seems currnet KVM handling to
IDT_Vectoring
doesn't cover all situation.
(The in Kernel PIC patch will try to
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. \
This patch fixes this by introducing new VM level IOCTL
KVM_SET_ISA_IRQ_LEVEL KVM_CREATE_PIC to
User level patch for in kernel PIC.
thx,eddie
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
kernel/Kbuild |2 +-
qemu/cpu-defs.h |1 +
qemu/hw/i8259.c |5 +
qemu/qemu-kvm.c |9 -
user/kvmctl.c | 44 +++-
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 every 8ms (probably maximum resolution
with this setup) so the timer-wheel
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
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
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
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
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
Gregory Haskins wrote:
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
Woo, we have gone through so many threads within single day and get
almost
everything in hand now :-) Should we make a short notes on the decision
to be referenced in future (Any place to KVM I/F)?
Basically we have solved the I/Fs issue and part IRQ delivery issue.
Several other minor points
+#include kvm.h
+#include virq.h
+
+/*
+ * check if there is pending interrupt without
+ * intack.
+ */
+int cpu_has_interrupt(struct kvm_vcpu *v)
+{
+struct pic_state2 *s = kernel_pic(v-kvm);
+
Isn't the PIC connected to just one cpu?
Yes, but will have APIC irq after
Avi Kivity wrote:
Dong, Eddie wrote:
Woo, we have gone through so many threads within single day and get
almost everything in hand now :-) Should we make a short notes on
the decision to be referenced in future (Any place to KVM I/F)?
Basically we have solved the I/Fs issue and part IRQ
Avi Kivity wrote:
GSI is ACPI notion of Global System Interrupt.
(Just parameter passing difference: GSI use GSI #,
our previous discussion use: PIC/IOAPIC # + line #)
Can you refer me to any documentation about it?
ACPI spec 3.0a, section 5.2.12.
http://www.acpi.info/spec.htm has
[EMAIL PROTECTED] wrote:
Hi,
I am wondering how KVM handles debug and breakpoint interrupt? Does it
process them like normal NMI interrupt, or is there any special
processing?
Do u mean int 1/3 handling? Or DR virtualization?
Eddie
Jun Koi wrote:
On 6/25/07, Dor Laor [EMAIL PROTECTED] wrote:
On 6/25/07, Dong, Eddie [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
On 6/25/07, Dor Laor [EMAIL PROTECTED] wrote:
I am wondering how KVM handles debug and breakpoint interrupt?
Does it process them like normal NMI interrupt
Greg/Dor:
When thinking to merge APIC device model with PIC, a curious
question: Where does the code base come from? Xen or Qemu? I found there
are many diff from Xen (even excluding name difference).
Eddie
-
This
There is a bug in the APIC V09 patch when porting Xen
find_highest_vector to find_highest_bit,
here is the prototype fix. (Not tested)
diff --git a/drivers/kvm/lapic.c b/drivers/kvm/lapic.c
index 602e94c..64264a0 100644
--- a/drivers/kvm/lapic.c
+++ b/drivers/kvm/lapic.c
@@ -62,12 +62,21 @@
This exit reason is either NMI, or software interrupt or exception.
Dong, could you explain a bit: in which case interrupt 1/3 cause NMI,
and in which case they cause exception?
If you set the bitmap for INT 1/3 in EXCEPTION_BITMAP (refer
update_exception_bitmap), you will see
VM Exit for
I saw compiler error at current head, does anybody else see too?
41ac4b23696b12fec15191969bc18da42359861d
make -C /lib/modules/2.6.21-rc3/build M=`pwd` $@
make[1]: Entering directory `/root/linux-2.6.21-rc3'
LD /root/work2/5th/kvm-userspace/kernel/built-in.o
CC [M]
With following fix, kernel PIC+APIC works on AMD box.
Eddie
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index f4099f2..53ec38b 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -460,6 +460,12 @@ static void init_sys_seg(struct vmcb_seg *seg,
uint32_t type)
static int
+/* for KVM_SET_IRQ_LEVEL */
+struct kvm_irq_level {
+__u32 irq;
+__u32 level;
+};
Please add an irqchip index, so this can be used for
configurations with
multiple irqchips (likely ioapics). You'll also need to add
padding so
the structure is 64-bit aligned.
Adding
Avi Kivity wrote:
Other than these minor issues, the patch looks fine.
Here is the rebased one.
If gsi/level is not enough, then following patch can fix this. But not
sure so far.
thx,eddie
against: cfc329b216bc3e54fe1107e8f714c7b3bc133224
drivers/kvm/Makefile |2
Avi Kivity wrote:
Merged both into the 'lapic2' branch. Got the following oops running
Windows (i386 on Intel):
Avi:
This one should fixed the bug.
Against lapic2 dc03e1b70198e0e4aadfc9063399590fa42cf55e.
thx,eddie
Destroy io bus earlier than all the registered bus node
This rebase the HLT emulation patch to lapic2 branch.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
diff --git a/drivers/kvm/i8259.c b/drivers/kvm/i8259.c
index f4ae5f7..e84e665 100644
--- a/drivers/kvm/i8259.c
+++ b/drivers/kvm/i8259.c
@@
Use host cpu model name, type, family, Model, stepping for guest.
Against head.
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index bacdb37..1b86a13 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -756,6 +755,10 @@ static void
Avi Kivity wrote:
Dong, Eddie wrote:
Use host cpu model name, type, family, Model, stepping for guest.
Against head.
This is turning into a mix of the qemu cpuid and the host cpuid. We
need to think of a way to make this controllable.
Actually I am wondering why we need a Qemu
Avi Kivity wrote:
One of the uses of virtualization is to abstract the underlying
hardware, so that a VM image can run on any platform (live
migration is
an example of this use case). For that we must not let any detail of
the hardware be visible.
I doutb about the live migration cross
Avi:
To make lapic code into mainline earlier, I am thinking what
should the user space code look like. If we wait till lapic branch has
all same functionality as mainline have today i.e. live migration, all
guests etc, we may have very long way to go given that only Greg (temply
off), me
Avi Kivity wrote:
Dong, Eddie wrote:
Avi:
To make lapic code into mainline earlier, I am thinking what
should the user space code look like. If we wait till lapic branch
has all same functionality as mainline have today i.e. live
migration, all guests etc, we may have very long way
[EMAIL PROTECTED] wrote:
Avi Kivity wrote:
Dong, Eddie wrote:
Avi:
To make lapic code into mainline earlier, I am thinking what
should the user space code look like. If we wait till lapic branch
has all same functionality as mainline have today i.e. live
migration, all guests etc, we
If we release a kernel with pic but not lapic, and userspace that
defaults to user-pic+lapic, then that kernel will not work
with a newer
userspace that defaults to in-kernel pic+lapic.
We need to switch in one go. I don't mind checking in patches to the
lapic2 branch, and continually
I don't think live migration is particularly difficult. You
need a APIs
to read and write the PIC+LAPIC states, and you write the
state into the
This is partily true party not. Like what did in Xen, a live migration
in kernel side need to consider not only device state, but also cpu
state.
I had already solved these types of issues neatly in the lapic branch,
so perhaps you can model a solution from that (at least in
spirit). For
instance, the irq.deferred source has the IDT_Vectoring state,
irq.pending has the vcpu interrupt state (NMI, EXTINT, etc),
kvm-isa_int has the PIC
Here is the update with adding HLT cap.
diff --git a/drivers/kvm/i8259.c b/drivers/kvm/i8259.c
index f4ae5f7..e84e665 100644
--- a/drivers/kvm/i8259.c
+++ b/drivers/kvm/i8259.c
@@ -411,8 +411,13 @@ static void picdev_read(struct kvm_io_device *this,
static void pic_irq_request(void *opaque, int
Avi Kivity wrote:
Dong, Eddie wrote:
Here is the update with adding HLT cap.
diff --git a/drivers/kvm/i8259.c b/drivers/kvm/i8259.c index
f4ae5f7..e84e665 100644 --- a/drivers/kvm/i8259.c
+++ b/drivers/kvm/i8259.c
@@ -411,8 +411,13 @@ static void picdev_read(struct kvm_io_device
Gregory Haskins wrote:
On Thu, 2007-07-12 at 22:20 +0800, Dong, Eddie wrote:
Apply to current kvm.git? Then we need to define false for
irqchip_in_kernel() which makes the patch quit stranger.
I think what Avi is saying is this can be generalized as a separate
feature independent
Avi Kivity wrote:
Dong, Eddie wrote:
Gregory Haskins wrote:
On Thu, 2007-07-12 at 22:20 +0800, Dong, Eddie wrote:
Apply to current kvm.git? Then we need to define false for
irqchip_in_kernel() which makes the patch quit stranger.
I think what Avi is saying is this can
Gregory Haskins wrote:
On Thu, 2007-07-12 at 23:39 +0800, Dong, Eddie wrote:
Greg:
I think you need to do the whole patch for this including kernel
side. Will u ?
Ya, I can do that. But I probably wont be able to look at it until
this RT stuff I am working on is done.
Then, Avi
[EMAIL PROTECTED] wrote:
Avi,
A couple of months back, we had a discussion about PMU virtualization
and the difficulty I encountered trying to catch the PMU interrupt
vector in kvm on VM-exit. KVM does not set ack_intr_on_intr. Would
you mind reminding me of the reason for this?
On the
Stephane Eranian wrote:
Eddie,
On Fri, Jul 13, 2007 at 08:46:06AM +0800, Dong, Eddie wrote:
[EMAIL PROTECTED] wrote:
Avi,
A couple of months back, we had a discussion about PMU
virtualization and the difficulty I encountered trying to catch the
PMU interrupt vector in kvm on VM-exit
Avi:
Per our discussion, we will only support all user level irqchip
or all kernel level irqchip.
Here is the patch against lapic2 that passed RHEL5U test. Please give
comments.
thx,eddie
diff --git a/drivers/kvm/Makefile b/drivers/kvm/Makefile
index 952dff3..b29651b 100644
---
Avi:
This is to add kernel string pio support which is used
by some of Windows version. The patch is developped on top
of lapic2 branch but should be fine to mainline head too.
thanks, eddie
commit ee682213bfd318d40bb6826e5273ce6724658b95
Author: root [EMAIL PROTECTED](none)
Date: Tue
Avi:
Most of the comments are fixed, but need to have a double check
on several point of them. Can u have a look?
Eddie
+
+switch (delivery_mode) {
+case dest_LowestPrio:
Wierd constant. How about IOAPIC_DEST_LOWEST_PRIO?
dest_LowestPrio is defined in native Linux
If guest is in hlt time, vcpu-guest_mode=0. (VM Exit always
clear this
one).
BTW, even we give a redunadant IPI, it is just a minor performance
issue
only.
I think that Avi was looking for the call to
wake_up_interruptible(vcpu-wq);
Maybe it's hard to realize the apic code path where you call
+unsigned long get_cr8(struct kvm_vcpu *vcpu)
+{
+ if (irqchip_in_kernel(vcpu-kvm))
+ return kvm_lapic_get_cr8(vcpu);
+ else
+ return vcpu-cr8;
+}
+EXPORT_SYMBOL_GPL(get_cr8);
How about keep vcpu-cr8 even with kernel lapic? then we don't
need this.
We
This is the ioapic patch. With this on rebased lapic2 branch, Both
Win2003/Xp and Rhel5 works well.
Appreciate if this can be in the branch so that I can fully move to live
migration support.
thx,eddie
kernel apic/ioapic support
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
Missed attachment. Here it is.
ioapic-30-4.user.patch
Description: ioapic-30-4.user.patch
ioapic-30-4.patch
Description: ioapic-30-4.patch
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE
Avi Kivity wrote:
Dong, Eddie wrote:
Avi:
This is the cleaned and branch check-in ready candidate patch
for lapic based on previous cr8 patch.
It needs the later ioapic patch to fully function.
Most of userspace part is missing.
??? I don't need the user side change
Well, the ioapic userspace patch removes some nonexistent code that I
assume the lapic userspace patch should have added.
O, this is a temp hack added by in kernel PIC. Maybe the branch
mismatch.
Here is the resent one. The sequence is:
lapic
ioapic
hlt
thx,eddie
Rename KVM_CREATE_PIC to KVM_CREATE_IRQCHIP
KVM_CAP_PIC to KVM_PIC_IRQCHIP since now it is not only PIC.
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
against lapic2 branch.
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index d7e16ba..3ce3e48
When thinking about live migration support for in kernel irqchip, one
question comes out which need to be solved first:
Do we need to support live migration among user level irqchip and kernel
level? If the answer is yes, kernel level irqchip must keep same state
with user level, i.e. if Qemu
Avi Kivity wrote:
Dong, Eddie wrote:
When thinking about live migration support for in kernel irqchip, one
question comes out which need to be solved first:
Do we need to support live migration among user level irqchip and
kernel level?
Yes.
If the answer is yes, kernel level irqchip
1 - 100 of 258 matches
Mail list logo
