Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Izik Eidus wrote: > hi, > why not making kvm_create_userspace_memory() recive a pointer to a > userspace allocated memory (that was allocated from file or from normal > malloc) > and make all the changes before kvm_create_userspace_memory() get called? I don't see how I can pass a pointer to kvm_create_userspace_memory() via kvm_create() without breaking the libkvm interface. There is no flags field or similar which could be used to signal "vm_mem is a valid pointer, please use that instead of mmap()'ing anonymous memory". Oh, and I also don't want special the treatment of the 0xa -> 0xf memory window. cheers, Gerd - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Split kvm_vcpu to support new archs.
Hi Avi,
According to your and community's suggestions, I changed the kvm_vcpu
structure to two parts. To avoid the much intrusive into current code,
one is common part which is defined as a macro, and the other one is
arch-specific part.
In addition, I have a suggestion to re-organize the head files, such as
kvm.h and x86.h. IMO, kvm.h is changed to kvm_comm.h, and only includes
common code for all archs.Then x86.h will be changed to kvm-x86.h, and
linked as kvm.h at compile time. So, other archs also defines its
kvm-xx.h to accommodate its arch-specific structures. What's your ideas
?(This idea doesn't include in this patch.)
>From 34cebd3a3fc0afba4df511219912bc3277e2a8c7 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Thu, 18 Oct 2007 12:51:02 +0800
Subject: [PATCH] First step to split kvm_vcpu. Currently, we just use an
macro to define the common fields in kvm_vcpu for all archs, and all
archs need to define its own kvm_vcpu struct.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
drivers/kvm/ioapic.c |2 +
drivers/kvm/irq.c |1 +
drivers/kvm/kvm.h | 166
+++-
drivers/kvm/kvm_main.c|4 +-
drivers/kvm/lapic.c |2 +
drivers/kvm/mmu.c |1 +
drivers/kvm/svm.c |2 +-
drivers/kvm/vmx.c |1 +
drivers/kvm/x86.h | 128 ++
drivers/kvm/x86_emulate.c |1 +
10 files changed, 166 insertions(+), 142 deletions(-)
diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
index 1a5e59a..cf1d50b 100644
--- a/drivers/kvm/ioapic.c
+++ b/drivers/kvm/ioapic.c
@@ -27,6 +27,8 @@
*/
#include "kvm.h"
+#include "x86.h"
+
#include
#include
#include
diff --git a/drivers/kvm/irq.c b/drivers/kvm/irq.c
index 851995d..22bfeee 100644
--- a/drivers/kvm/irq.c
+++ b/drivers/kvm/irq.c
@@ -22,6 +22,7 @@
#include
#include "kvm.h"
+#include "x86.h"
#include "irq.h"
/*
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index c38e4a3..28e664e 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -308,93 +308,37 @@ struct kvm_io_device *kvm_io_bus_find_dev(struct
kvm_io_bus *bus, gpa_t addr);
void kvm_io_bus_register_dev(struct kvm_io_bus *bus,
struct kvm_io_device *dev);
-struct kvm_vcpu {
- struct kvm *kvm;
- struct preempt_notifier preempt_notifier;
- int vcpu_id;
- struct mutex mutex;
- int cpu;
- u64 host_tsc;
- struct kvm_run *run;
- int interrupt_window_open;
- int guest_mode;
- unsigned long requests;
- unsigned long irq_summary; /* bit vector: 1 per word in
irq_pending */
- DECLARE_BITMAP(irq_pending, KVM_NR_INTERRUPTS);
- unsigned long regs[NR_VCPU_REGS]; /* for rsp:
vcpu_load_rsp_rip() */
- unsigned long rip; /* needs vcpu_load_rsp_rip() */
-
- unsigned long cr0;
- unsigned long cr2;
- unsigned long cr3;
- unsigned long cr4;
- unsigned long cr8;
- u64 pdptrs[4]; /* pae */
- u64 shadow_efer;
- u64 apic_base;
- struct kvm_lapic *apic;/* kernel irqchip context */
-#define VCPU_MP_STATE_RUNNABLE 0
-#define VCPU_MP_STATE_UNINITIALIZED 1
-#define VCPU_MP_STATE_INIT_RECEIVED 2
-#define VCPU_MP_STATE_SIPI_RECEIVED 3
-#define VCPU_MP_STATE_HALTED4
- int mp_state;
- int sipi_vector;
- u64 ia32_misc_enable_msr;
-
- struct kvm_mmu mmu;
-
- struct kvm_mmu_memory_cache mmu_pte_chain_cache;
- struct kvm_mmu_memory_cache mmu_rmap_desc_cache;
- struct kvm_mmu_memory_cache mmu_page_cache;
- struct kvm_mmu_memory_cache mmu_page_header_cache;
-
- gfn_t last_pt_write_gfn;
- int last_pt_write_count;
- u64 *last_pte_updated;
-
- struct kvm_guest_debug guest_debug;
-
- struct i387_fxsave_struct host_fx_image;
- struct i387_fxsave_struct guest_fx_image;
- int fpu_active;
- int guest_fpu_loaded;
-
- int mmio_needed;
- int mmio_read_completed;
- int mmio_is_write;
- int mmio_size;
- unsigned char mmio_data[8];
+#ifdef CONFIG_HAS_IOMEM
+#define KVM_VCPU_MMIO \
+ int mmio_needed;\
+ int mmio_read_completed;\
+ int mmio_is_write;\
+ int mmio_size;\
+ unsigned char mmio_data[8];\
gpa_t mmio_phys_addr;
- gva_t mmio_fault_cr2;
- struct kvm_pio_request pio;
- void *pio_data;
- wait_queue_head_t wq;
- int sigset_active;
- sigset_t sigset;
+#else
+#define KVM_VCPU_MMIO
- struct kvm_stat stat;
+#endif
- struct {
- int active;
- u8 save_iopl;
- struct kvm_save_segment {
- u16 selector;
- unsigned long base;
- u32 limit;
- u32 ar;
- } tr, es, ds, fs, gs;
- } rmode;
- int h
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Gerd Hoffmann wrote: > > Izik Eidus wrote: > > hi, > > why not making kvm_create_userspace_memory() recive a pointer to a > > userspace allocated memory (that was allocated from file or from normal > > malloc) > > and make all the changes before kvm_create_userspace_memory() get > called? > > I don't see how I can pass a pointer to kvm_create_userspace_memory() > via kvm_create() without breaking the libkvm interface. There is no > flags field or similar which could be used to signal "vm_mem is a valid > pointer, please use that instead of mmap()'ing anonymous memory". > There is no need to keep binary compat to libkvm as long as it is linked statically. We only need to keep binary compat with the kernel. > > Oh, and I also don't want special the treatment of the 0xa -> > 0xf memory window. > > cheers, > Gerd > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Fix Build on tip.
Zhang, Xiantao wrote:
> >From c5c9ec8d090d553b4d5d00e7ba7fc2daddfb3d00 Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Thu, 18 Oct 2007 10:31:07 +0800
> Subject: [PATCH] Fix compile error on latest commit
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/x86_emulate.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
> index ced0939..220c244 100644
> --- a/drivers/kvm/x86_emulate.c
> +++ b/drivers/kvm/x86_emulate.c
> @@ -229,6 +229,7 @@ static u16 twobyte_table[256] = {
> /* EFLAGS bit definitions. */
> #define EFLG_OF (1<<11)
> #define EFLG_DF (1<<10)
> +#define EFLG_IF (1<<9)
> #define EFLG_SF (1<<7)
> #define EFLG_ZF (1<<6)
> #define EFLG_AF (1<<4)
>
I committed a fix which changes the code to use X86_EFLAGS_IF instead.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Fix top level qemu config for cross compile
Jerone Young wrote: > Qemu is interpreting --cross-prefix & cpu as one argument. This of > course yeilds an error. This fixes the error. > > Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: Access registers for instructions with ModR/M byte and Mod = 3
Aurelien Jarno wrote: > Ok, next try. This time I have opened the IA32 manual (I should have > done that before), so I hope it is correct. > > > KVM: Access registers for instructions with ModR/M byte and Mod = 3 > > The patch belows changes the access type to register from memory for > instructions that are declared as SrcMem or DstMem, but have a > ModR/M byte with Mod = 3. > > It fixes (at least) the lmsw and smsw instructions on an AMD64 CPU, > which are needed for FreeBSD. > > Applied, thanks. We probably want to move modrm decoding to create a 'modrm_operand' of type 'struct operand' and then simply copy that into c->src or c->dst as needed. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section
Dong, Eddie wrote: previous irq injection, next injection will be refused with IRQ window enabled. This is because current implementation will inject exception earlier than irq injection and vmx_intr_assist doesn;t know if previous injected event is external irq (and thus overwrite) or exception. Guest will see lower priority irq get injected rather than higher priority IRQ which arrives later. >> Well, the same thing happens with the code before this commit, >> no? If a >> > > Why? > The philosiphy here is that the vCPU may receive new virtual irqs, > but it will not try to injected. From guest point of view, an old irq > (say irq_lo) arrives earlier and right before the virtual instruction > boundary, > and thus get responsed, while the new high priority irq (irq_hi) arrives > a little bit later than irq_lo, but right after the instruction boundary > and thus couldn't preempt irq_lo. > > When guest response to irq_lo, eflag.if=0, so irq_hi can't be responsed > at that time although it see irq_hi in IRR. > > That align with native where it uses micro-code. > > If we enable pirq before physical irq is delivered, current code has > obvious issue (see below comments too). > If we insist to move virq deliver out of irq disable. Then we need to > avoid 2nd injection of irq. But a big side effect is that frequently > higher priority irq such as NIC/IDE irq will arrive right after lower > priority irq which will obviously hurt various benchmark and even > correctness. > > I will argue the necessaity of this code movement. A VM > Exit/Resume itself probably will block system responsibility > (can't deliver irq) in the level of 1K cycles, interrupt injection is > clearly far less than this granularity. Probably less than 100cycles. > > The reason for the code movement is that interrupt injection in real mode on Intel must be emulated, which means writing into guest memory, which means sleeping operations once swap is enabled. A side benefit is removing the lapic calculations from the critical section. But I still don't understand your object. The interrupt has to be committed sometime. We move the commit point earlier by the time it takes to ->prepare_guest_switch() (normally zero, but sometimes some thousand cycles), and kvm_load_guest_fpu() (usually zero as well). The timing is sometimes worse, but there was always a window where a high priority interrupt is ignored over low priority interrupts. [we can try to improve it by using vm86 interrupt redirection which may allow event injection using VT instead of writing to the guest stack]. > >> high priority interrupt arrives after injection, it will have to wait. >> The difference is that before this commit, it woke up with the IPI and >> now it notices with KVM_REQ_INTR. >> > > When physical IRQ is disabled, the physical IPI will not interrupt > pCPU, it get delivered only after we resume to guest. > > But the effect is the same: the high priority interrupt is delayed. >> The window grew larger, but not by much typically. >> > > > Maybe not much typical, but will frequently happen. > With this commit, now the window becomes huge since > vcpu deschedule may happen :-( > > If the vcpu is descheduled, then both interrupts are delayed, by much more than it takes to process a single one. If we're descheduled then interrupt priority is a very small problem with respect to timing. > Another serious issue in current code is that due to previous > injection, the irq is already consumed, (IRR->ISR). So if there > are higher priority IRQs arrive later after the previous injection, > now guest will see 2 IRQs consumed, i.e. 2 ISR bits are set. > > I don't understand why. If an event is pending in VM_ENTRY_INTR_INFO_FIELD, then we don't call kvm_cpu_get_interrupt() at all. > I will guess this one is the major problem source if no-kvm-irqchip > & kvm_irqchip still has difference. And I bet it should cause many > issues. > Well, I can thing of a workaround by using vm86 interrupt redirection. But I'm not convinced it is necessary. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section
Avi Kivity wrote:
>> I will argue the necessaity of this code movement. A VM
>> Exit/Resume itself probably will block system responsibility
>> (can't deliver irq) in the level of 1K cycles, interrupt injection is
>> clearly far less than this granularity. Probably less than 100cycles.
>>
>>
>
> The reason for the code movement is that interrupt injection in real
> mode on Intel must be emulated, which means writing into guest memory,
> which means sleeping operations once swap is enabled. A side
OK, that is the difference between Xen & KVM.
An alternative is to lock the pages when in rmode before we disable
irq. But let us see if we can live with this movement.
> benefit is
> removing the lapic calculations from the critical section.
>
> But I still don't understand your object. The interrupt has to be
> committed sometime. We move the commit point earlier by the time it
> takes to ->prepare_guest_switch() (normally zero, but sometimes some
> thousand cycles), and kvm_load_guest_fpu() (usually zero as
> well). The
> timing is sometimes worse, but there was always a window where a high
> priority interrupt is ignored over low priority interrupts.
Yes even in rare native when 2 irqs arrives at almost same time.
But now we have frequent happenings. Guest frequently see
higher irq pending. Let us keep an eye to see if it will hurt something.
Then probably need this patch?
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index aab465d..46ad3b7 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2165,6 +2165,7 @@ again:
if (unlikely(r))
goto out;
+ vcpu->guest_mode = 1;
kvm_inject_pending_timer_irqs(vcpu);
clear_bit(KVM_REQ_INTR, &vcpu->requests);
if (irqchip_in_kernel(vcpu->kvm))
@@ -2183,6 +2184,7 @@ again:
local_irq_enable();
preempt_enable();
r = -EINTR;
+ vcpu->guest_mode = 0;
kvm_run->exit_reason = KVM_EXIT_INTR;
++vcpu->stat.signal_exits;
goto out;
@@ -2192,6 +2194,7 @@ again:
if (test_and_clear_bit(KVM_REQ_TLB_FLUSH,
&vcpu->requests))
kvm_x86_ops->tlb_flush(vcpu);
if (test_bit(KVM_REQ_INTR, &vcpu->requests)) {
+ vcpu->guest_mode = 0;
local_irq_enable();
preempt_enable();
r = 1;
@@ -2199,7 +2202,6 @@ again:
}
}
- vcpu->guest_mode = 1;
kvm_guest_enter();
kvm_x86_ops->run(vcpu, kvm_run);
>
> [we can try to improve it by using vm86 interrupt redirection
> which may
> allow event injection using VT instead of writing to the guest stack].
:) Love this much more personaly, or lock pages.
>
>>
>
> If the vcpu is descheduled, then both interrupts are delayed, by much
> more than it takes to process a single one. If we're descheduled then
> interrupt priority is a very small problem with respect to timing.
>
>> Another serious issue in current code is that due to previous
>> injection, the irq is already consumed, (IRR->ISR). So if there
>> are higher priority IRQs arrive later after the previous injection,
>> now guest will see 2 IRQs consumed, i.e. 2 ISR bits are set.
>>
>>
>
> I don't understand why. If an event is pending in
> VM_ENTRY_INTR_INFO_FIELD, then we don't call
> kvm_cpu_get_interrupt() at all.
>
This is for protect mode. real mode is not setting this one,
and thus double consumed.
But this is fixable with other additional logic. My point is that
we may see more potential issues now :-(
Eddie
ll
Description: ll
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Dor Laor wrote: > Gerd Hoffmann wrote: >> I don't see how I can pass a pointer to kvm_create_userspace_memory() >> via kvm_create() without breaking the libkvm interface. There is no >> flags field or similar which could be used to signal "vm_mem is a valid >> pointer, please use that instead of mmap()'ing anonymous memory". > There is no need to keep binary compat to libkvm as long as it is linked > statically. What about source compatibility? cheers, Gerd - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
On Thu, 2007-10-18 at 12:18 +0200, Gerd Hoffmann wrote: > Dor Laor wrote: > > Gerd Hoffmann wrote: > >> I don't see how I can pass a pointer to kvm_create_userspace_memory() > >> via kvm_create() without breaking the libkvm interface. There is no > >> flags field or similar which could be used to signal "vm_mem is a valid > >> pointer, please use that instead of mmap()'ing anonymous memory". > > > There is no need to keep binary compat to libkvm as long as it is linked > > statically. > > What about source compatibility? > > cheers, > Gerd > > anyone who use kvmctl, should not call kvm_create_userspace_memory directly, instead should call kvm_create()... - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm: disabled by bios
On Sat, Oct 13, 2007 at 09:30:54PM -0300, Emmanuel Nicolas Millan wrote: > >Hi, > > > >is there any option to reenable virtualisation support (AMD-CPU) if it > >is disabled by bios (and Bios does not show an option to enable > >virtualisation support)? > > >Elmar > > Hi, i'm having the same problem, my bios doesn't have an option to > enable virtualization support, and I already upgrade the bios to the > last version available. > > I saw the patch "[patches] [PATCH] [19/50] Experimental: detect if SVM > is disabled by BIOS" could this patch resolve the problem? is there > any way to enable SVM support with KVM? If SVM is disabled by BIOS there is nothing you can do with current hardware to reenable it. If the BIOS does not provide an option to reenable it please contact your BIOS vendor for a newer BIOS which support reenablement of SVM. Joerg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Izik Eidus wrote: > On Thu, 2007-10-18 at 12:18 +0200, Gerd Hoffmann wrote: > >> Dor Laor wrote: >> >>> Gerd Hoffmann wrote: >>> I don't see how I can pass a pointer to kvm_create_userspace_memory() via kvm_create() without breaking the libkvm interface. There is no flags field or similar which could be used to signal "vm_mem is a valid pointer, please use that instead of mmap()'ing anonymous memory". >>> There is no need to keep binary compat to libkvm as long as it is linked >>> statically. >>> >> What about source compatibility? >> >> cheers, >> Gerd >> >> >> > anyone who use kvmctl, should not call kvm_create_userspace_memory > directly, > > instead should call kvm_create()... > > Why not have an API for creating memory slots? It allows much more flexibility and is more in line with what qemu wants. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Avi Kivity wrote:
> Izik Eidus wrote:
>> On Thu, 2007-10-18 at 12:18 +0200, Gerd Hoffmann wrote:
>>
> I don't see how I can pass a pointer to
> kvm_create_userspace_memory() via kvm_create() without
> breaking the libkvm interface. There is no flags field or
> similar which could be used to signal "vm_mem is a valid
> pointer, please use that instead of mmap()'ing anonymous
> memory".
>
There is no need to keep binary compat to libkvm as long as it
is linked statically.
>> anyone who use kvmctl, should not call kvm_create_userspace_memory
>> directly, instead should call kvm_create()...
I'm talking about the kvm_create() interface, dammit. Sure I can modify
kvm_create_userspace_memory() without breaking anyone as this isn't part
of the public (kvmctl.h) interface. That doesn't buy us much though.
I'd have to pass the pointer to kvm_create() somehow so it can be passed
down to kvm_create_userspace_memory(). I can't without breaking the
public library interface though.
> Why not have an API for creating memory slots? It allows much more
> flexibility and is more in line with what qemu wants.
This *is* what the patch does. It adds a function to add a
userspace-memory-backed memory slot: kvm_register_userspace_phys_mem().
That alone doesn't cut it though as there are some more constrains:
* kvm_create() builds a standard memory layout, which I want be able
to skip.
* kvm_create() fails to create a vcpu in case no memory is available,
which makes simple approach to just ask kvm_create() for 0 bytes
physical memory for the guest unusable.
Thats why I went the route to additionally split the job kvm_create()
does into multiple, individually callable pieces. So I can first create
the vm, then create my custom memory slots (instead of the standard
setup built by kvm_create_userspace_memory()), then create the vcpu.
cheers,
Gerd
ps: patch attached again for reference.
* split kvm_create() into smaller pieces which can be individually
called if needed.
* add kvm_register_userspace_phys_mem() function.
---
user/kvmctl.c | 61 +-
user/kvmctl.h |8 +++
2 files changed, 64 insertions(+), 5 deletions(-)
Index: kvm-46/user/kvmctl.c
===
--- kvm-46.orig/user/kvmctl.c
+++ kvm-46/user/kvmctl.c
@@ -427,12 +427,9 @@ int kvm_alloc_userspace_memory(kvm_conte
return 0;
}
-int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+int kvm_create_vm(kvm_context_t kvm)
{
- unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
int fd = kvm->fd;
- int zfd;
- int r;
kvm->vcpu_fd[0] = -1;
@@ -442,6 +439,15 @@ int kvm_create(kvm_context_t kvm, unsign
return -1;
}
kvm->vm_fd = fd;
+ return 0;
+}
+
+int kvm_create_default_phys_mem(kvm_context_t kvm, unsigned long phys_mem_bytes,
+void **vm_mem)
+{
+ unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
+ int zfd;
+ int r;
r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
if (r > 0)
@@ -457,18 +463,37 @@ int kvm_create(kvm_context_t kvm, unsign
close(zfd);
kvm->physical_memory = *vm_mem;
+ return 0;
+}
+
+void kvm_create_irqchip(kvm_context_t kvm)
+{
+ int r;
kvm->irqchip_in_kernel = 0;
if (!kvm->no_irqchip_creation) {
r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_IRQCHIP);
if (r > 0) { /* kernel irqchip supported */
- r = ioctl(fd, KVM_CREATE_IRQCHIP);
+ r = ioctl(kvm->vm_fd, KVM_CREATE_IRQCHIP);
if (r >= 0)
kvm->irqchip_in_kernel = 1;
else
printf("Create kernel PIC irqchip failed\n");
}
}
+}
+
+int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+{
+ int r;
+
+ r = kvm_create_vm(kvm);
+ if (r < 0)
+ return r;
+ r = kvm_create_default_phys_mem(kvm, phys_mem_bytes, vm_mem);
+ if (r < 0)
+ return r;
+ kvm_create_irqchip(kvm);
r = kvm_create_vcpu(kvm, 0);
if (r < 0)
return r;
@@ -558,6 +583,32 @@ void *kvm_create_phys_mem(kvm_context_t
log, writable);
}
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+ unsigned long phys_start, void *userspace_addr,
+ unsigned long len, int slot, int log)
+{
+ struct kvm_userspace_memory_region memory = {
+ .slot = slot,
+ .memory_size = len,
+ .guest_phys_addr = phys_start,
+ .userspace_addr = (intptr_t)userspace_addr,
+ .flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+ };
+ int r;
+
+ if (!kvm->physical_memory)
+ kvm->physical_memory = userspace_addr - phys_start;
+
+ r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+ if (r == -1) {
+ fprintf(stderr, "create_userspace_phys_mem: %s", strerror(errno));
+ return -1;
+ }
+
+ kvm_userspace_memory_region_save_params(kvm, &memory);
+return 0;
+}
+
/* destroy/free a whole slot.
* phys_start, len and slot are the params passed to kvm_create_phys_mem()
*/
Index: kvm-46/user/kvmctl.h
=
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Gerd Hoffmann wrote: > >>> anyone who use kvmctl, should not call kvm_create_userspace_memory >>> directly, instead should call kvm_create()... >>> > > I'm talking about the kvm_create() interface, dammit. Sure I can modify > kvm_create_userspace_memory() without breaking anyone as this isn't part > of the public (kvmctl.h) interface. That doesn't buy us much though. > I'd have to pass the pointer to kvm_create() somehow so it can be passed > down to kvm_create_userspace_memory(). I can't without breaking the > public library interface though. > > Break it. It has just one user, our qemu, which is included in the same package. We will freeze the lib kvm ABI once we have merged our changes into upstream qemu. But that won't happen unless we get a sane interface for that library (the current interface is not acceptable). >> Why not have an API for creating memory slots? It allows much more >> flexibility and is more in line with what qemu wants. >> > > This *is* what the patch does. It adds a function to add a > userspace-memory-backed memory slot: kvm_register_userspace_phys_mem(). > > That alone doesn't cut it though as there are some more constrains: > > * kvm_create() builds a standard memory layout, which I want be able >to skip. > kvm_create() should not be creating memory. > * kvm_create() fails to create a vcpu in case no memory is available, >which makes simple approach to just ask kvm_create() for 0 bytes >physical memory for the guest unusable. > kvm_create() should not be creating vcpus. > Thats why I went the route to additionally split the job kvm_create() > does into multiple, individually callable pieces. So I can first create > the vm, then create my custom memory slots (instead of the standard > setup built by kvm_create_userspace_memory()), then create the vcpu. > That's exactly what's needed. The patch looks good, except that I wouldn't export kvm_create_default_phys_mem(). Let qemu do the hard work instead. Once qemu switches to the new interface, we can remove kvm_create(). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1815704 ] Restarting KVM, with boot from CDROM, KVM crashes
Bugs item #1815704, was opened at 2007-10-18 13:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1815704&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: Restarting KVM, with boot from CDROM, KVM crashes Initial Comment: Restarting KVM, with boot from CDROM, KVM either fails to boot (resulting in Qemu window, showing error) or crash (resulting in KVM userspace crash). Host: Fedora7, 64-bit, Intel CPU, KVM-46. Guests: Debian 4.0 32-bit, Windows XP 32-bit. The result is KVM userspace crash without hard disk (without -hda), while with Hard Disk (-hda attached) it results in Qemu window showing me "error 0003 - unable to boot from CD-ROM" This crash happens with -no-acpi, or with -no-kvm-irqchip or with default parameters. This works with -no-kvm. -Technologov. 18.10.2007. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1815704&group_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-47 release
Today's news includes partial support for swapping. You can now run guests with more memory than you have on the host, and Linux will page them out to the swap file. The support is partial in that the guest will still pin a substantial amount of memory. Changes from kvm-46: - Reset fixes (Eddie Dong, me) - Portability work (Carsten Otte) - Cleanups (Anthony Liguori, Laurent Vivier) - Simplify guest pagetable dirty bit management - Fix nx bit for huge pages - Fix write access to clean large pages (fixes rmap leak) - Support for Linux 2.6.16 guests (movnti instruction) (Sheng Yang) - Simplify apic timer backlog processing - Move interrupt injection out of critical section - x86 emulator work (Nitin A Kamble) - restore freebsd support on AMD (fix smsw and lmsw) (Aurelien Jarno) - Simplify guest page table walker - Partial guest swapping (Izik Eidus) - kvmctl improvements (Anthony Liguori) - libkvm, qemu compilation against older kernels - guest time accounting (Laurent Vivier) - configure improvements (Carlo Marcelo Arenas Belon) - fix 4GB+ configurations (Izik Eidus) - cross compilation support (Jerone Young) Notes: If you use the modules bundled with kvm-47, you can use any version of Linux from 2.6.9 upwards. If you use the modules bundled with Linux 2.6.20, you need to use kvm-12. If you use the modules bundled with Linux 2.6.21, you need to use kvm-17. Modules from Linux 2.6.22 and up will work with any kvm version from kvm-22. Some features may only be available in newer releases. For best performance, use Linux 2.6.23-rc2 or later as the host. http://kvm.qumranet.com - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Gerd Hoffmann wrote: > Hi, > > >> Break it. It has just one user, our qemu, which is included in the same >> package. >> > > No, I'm hacking up one more user ;) > > Nice. What will it do? > But maybe I'm better off shipping a private copy of kvmctl.c as long as > the library interface isn't finalized yet and subject to change. > > Yes. Patches to improve libkvm's interface so we can decouple it from qemu will be most welcome. >>> Thats why I went the route to additionally split the job kvm_create() >>> does into multiple, individually callable pieces. So I can first create >>> the vm, then create my custom memory slots (instead of the standard >>> setup built by kvm_create_userspace_memory()), then create the vcpu. >>> >>> >> That's exactly what's needed. >> >> The patch looks good, except that I wouldn't export >> kvm_create_default_phys_mem(). >> > > Fine with me. If you one uses the splitted versions, then for creating > a non-default memory layout, so there is no point in exporting that one. > > Should I send an updated patch or do you just drop these lines when merging? > Please send a rebased and retested patch. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Use virtual cpu accounting if available for guest times.
Avi,
ppc and s390 offer the possibility to track process times precisely
by looking at cpu timer on every context switch, irq, softirq etc.
We can use that infrastructure as well for guest time accounting.
We need to account the used time before we change the state.
This patch adds a call to account_system_vtime to kvm_guest_enter
and kvm_guest exit. If CONFIG_VIRT_CPU_ACCOUNTING is not set,
account_system_vtime is defined in hardirq.h as an empty function,
which means this patch does not change the behaviour on other
platforms.
I compile tested this patch on x86 and function tested the patch on
s390.
Avi, please apply.
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h |3 +++
1 file changed, 3 insertions(+)
Index: kvm/drivers/kvm/kvm.h
===
--- kvm.orig/drivers/kvm/kvm.h
+++ kvm/drivers/kvm/kvm.h
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -669,11 +670,13 @@ __init void kvm_arch_init(void);
static inline void kvm_guest_enter(void)
{
+ account_system_vtime(current);
current->flags |= PF_VCPU;
}
static inline void kvm_guest_exit(void)
{
+ account_system_vtime(current);
current->flags &= ~PF_VCPU;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Use virtual cpu accounting if available for guest times.
Christian Borntraeger wrote: > ppc and s390 offer the possibility to track process times precisely > by looking at cpu timer on every context switch, irq, softirq etc. > We can use that infrastructure as well for guest time accounting. > We need to account the used time before we change the state. > This patch adds a call to account_system_vtime to kvm_guest_enter > and kvm_guest exit. If CONFIG_VIRT_CPU_ACCOUNTING is not set, > account_system_vtime is defined in hardirq.h as an empty function, > which means this patch does not change the behaviour on other > platforms. > > I compile tested this patch on x86 and function tested the patch on > s390. > > Avi, please apply. > > Done. Thanks! -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Hi, > Break it. It has just one user, our qemu, which is included in the same > package. No, I'm hacking up one more user ;) But maybe I'm better off shipping a private copy of kvmctl.c as long as the library interface isn't finalized yet and subject to change. >> Thats why I went the route to additionally split the job kvm_create() >> does into multiple, individually callable pieces. So I can first create >> the vm, then create my custom memory slots (instead of the standard >> setup built by kvm_create_userspace_memory()), then create the vcpu. >> > > That's exactly what's needed. > > The patch looks good, except that I wouldn't export > kvm_create_default_phys_mem(). Fine with me. If you one uses the splitted versions, then for creating a non-default memory layout, so there is no point in exporting that one. Should I send an updated patch or do you just drop these lines when merging? cheers, Gerd - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] FW: [kvm-commits] KVM: Move interrupt injection out of interruptdisabled section
Dong, Eddie wrote:
>
>> benefit is
>> removing the lapic calculations from the critical section.
>>
>> But I still don't understand your object. The interrupt has to be
>> committed sometime. We move the commit point earlier by the time it
>> takes to ->prepare_guest_switch() (normally zero, but sometimes some
>> thousand cycles), and kvm_load_guest_fpu() (usually zero as
>> well). The
>> timing is sometimes worse, but there was always a window where a high
>> priority interrupt is ignored over low priority interrupts.
>>
>
> Yes even in rare native when 2 irqs arrives at almost same time.
> But now we have frequent happenings. Guest frequently see
> higher irq pending. Let us keep an eye to see if it will hurt something.
>
> Then probably need this patch?
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index aab465d..46ad3b7 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -2165,6 +2165,7 @@ again:
> if (unlikely(r))
> goto out;
>
> + vcpu->guest_mode = 1;
> kvm_inject_pending_timer_irqs(vcpu);
> clear_bit(KVM_REQ_INTR, &vcpu->requests);
> if (irqchip_in_kernel(vcpu->kvm))
> @@ -2183,6 +2184,7 @@ again:
> local_irq_enable();
> preempt_enable();
> r = -EINTR;
> + vcpu->guest_mode = 0;
> kvm_run->exit_reason = KVM_EXIT_INTR;
> ++vcpu->stat.signal_exits;
> goto out;
> @@ -2192,6 +2194,7 @@ again:
> if (test_and_clear_bit(KVM_REQ_TLB_FLUSH,
> &vcpu->requests))
> kvm_x86_ops->tlb_flush(vcpu);
> if (test_bit(KVM_REQ_INTR, &vcpu->requests)) {
> + vcpu->guest_mode = 0;
> local_irq_enable();
> preempt_enable();
> r = 1;
> @@ -2199,7 +2202,6 @@ again:
> }
> }
>
> - vcpu->guest_mode = 1;
> kvm_guest_enter();
>
> kvm_x86_ops->run(vcpu, kvm_run);
>
>
I don't see why this is needed. The interrupt code will
set_bit(KVM_REQ_INTR) even if the vcpu is not in guest mode.
>
>> [we can try to improve it by using vm86 interrupt redirection
>> which may
>> allow event injection using VT instead of writing to the guest stack].
>>
>
> :) Love this much more personaly, or lock pages.
>
>
We could lock the pages like this:
- do the interrupt injection
- if a real mode interrupt, abort, and set a flag requesting to lock
the guest pages
- exit the critical section
- notice the flag is set, lock guest stack
- retry
- otherwise, proceed with injection
but using vm86 interrupt redirection is better.
>>> Another serious issue in current code is that due to previous
>>> injection, the irq is already consumed, (IRR->ISR). So if there
>>> are higher priority IRQs arrive later after the previous injection,
>>> now guest will see 2 IRQs consumed, i.e. 2 ISR bits are set.
>>>
>>>
>>>
>> I don't understand why. If an event is pending in
>> VM_ENTRY_INTR_INFO_FIELD, then we don't call
>> kvm_cpu_get_interrupt() at all.
>>
>>
> This is for protect mode. real mode is not setting this one,
> and thus double consumed.
>
>
Good point. That is also fixed by using vm86 interrupt redirection.
I'll read some more about it.
> But this is fixable with other additional logic. My point is that
> we may see more potential issues now :-(
>
>
>
You're right. Well, that's the price of progress (swapping).
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] move kvm_guest_exit() after local_irq_enable()
According comments from Avi, we can clear PF_VCPU in kvm_guest_exit if we move
it after local_irq_enable().
http://lkml.org/lkml/2007/10/15/114
To simplify s390 port, we don't clear it in account_system_time().
http://lkml.org/lkml/2007/10/15/183
---
drivers/kvm/kvm_main.c |5 -
kernel/sched.c |1 -
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 87275be..b9cd1f0 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2194,12 +2194,15 @@ again:
kvm_x86_ops->run(vcpu, kvm_run);
- kvm_guest_exit();
vcpu->guest_mode = 0;
local_irq_enable();
++vcpu->stat.exits;
+ barrier();
+
+ kvm_guest_exit();
+
preempt_enable();
/*
diff --git a/kernel/sched.c b/kernel/sched.c
index b27ab3e..57fac22 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3315,7 +3315,6 @@ void account_system_time(struct task_struct *p, int
hardirq_offset,
#ifdef CONFIG_GUEST_ACCOUNTING
if (p->flags & PF_VCPU) {
account_guest_time(p, cputime);
- p->flags &= ~PF_VCPU;
return;
}
#endif
--
1.5.2.4
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] move kvm_guest_exit() after local_irq_enable()
Laurent Vivier wrote: > According comments from Avi, we can clear PF_VCPU in kvm_guest_exit if we move > it after local_irq_enable(). > > http://lkml.org/lkml/2007/10/15/114 > > To simplify s390 port, we don't clear it in account_system_time(). > > http://lkml.org/lkml/2007/10/15/183 > Applied (the kvm part), and added a fat comment on the barrier. Can you send a signed-off-by: line? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] move kvm_guest_exit() after local_irq_enable()
Avi Kivity a écrit : > Laurent Vivier wrote: >> According comments from Avi, we can clear PF_VCPU in kvm_guest_exit if we >> move >> it after local_irq_enable(). >> >> http://lkml.org/lkml/2007/10/15/114 >> >> To simplify s390 port, we don't clear it in account_system_time(). >> >> http://lkml.org/lkml/2007/10/15/183 >> > > Applied (the kvm part), and added a fat comment on the barrier. Can you > send a signed-off-by: line? > Sorry, I missed it... Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1815804 ] Windows XP setup stucks
Bugs item #1815804, was opened at 2007-10-18 15:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1815804&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: Windows XP setup stucks Initial Comment: Host: openSUSE 10.3, 32-bit, Intel CPU, KVM-47 ! Guest: Windows XP. Setup stucks at the very beginning. -Alexey -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1815804&group_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] newest kvm modules?
Hello, I'm using the newest linux kernel (2.6.23.1) but as I could read in some emials - I should use the newest kvm modules. (Because kvm crashes if I install OpenSolaris Express as guest on Linux - with -no-kvm installation works). Could you tell me where can I download the newst one? regards, Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] newest kvm modules?
On Thu, 2007-10-18 at 18:07 +0200, Oliver Kowalke wrote: > Hello, > I'm using the newest linux kernel (2.6.23.1) but as I could read in some > emials - I should use the newest kvm modules. > (Because kvm crashes if I install OpenSolaris Express as guest on Linux - > with -no-kvm installation works). > Could you tell me where can I download the newst one? > regards, Oliver checkout: http://sourceforge.net/project/showfiles.php?group_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Missing commits on kvm-commits?
Anthony Liguori wrote: > It appears that a good number of KVM commits never make their way to > kvm-commits. > > For instance, I don't see Izik's recent overcommit patches > (1253f76f37189f0bfda7e4a46bfe537f329dc0db) > > If I commit through git-am, it doesn't show up. If I start a rebase, lots of spam shows up, then I hastily turn it off and even regular commits won't show up until I remember to turn it on. If someone has a clever suggestion (maybe a hook on push?) I'll be happy to apply it. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs.
Zhang, Xiantao wrote:
> Hi Avi,
> According to your and community's suggestions, I changed the kvm_vcpu
> structure to two parts. To avoid the much intrusive into current code,
> one is common part which is defined as a macro, and the other one is
> arch-specific part.
> In addition, I have a suggestion to re-organize the head files, such as
> kvm.h and x86.h. IMO, kvm.h is changed to kvm_comm.h, and only includes
> common code for all archs.Then x86.h will be changed to kvm-x86.h, and
> linked as kvm.h at compile time. So, other archs also defines its
> kvm-xx.h to accommodate its arch-specific structures. What's your ideas
> ?(This idea doesn't include in this patch.)
>
Let's not hurry with file layout, but split off x86 first.
> >From 34cebd3a3fc0afba4df511219912bc3277e2a8c7 Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Thu, 18 Oct 2007 12:51:02 +0800
> Subject: [PATCH] First step to split kvm_vcpu. Currently, we just use an
> macro to define the common fields in kvm_vcpu for all archs, and all
> archs need to define its own kvm_vcpu struct.
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
>
Patch is good, but your mailer wordwrapped it. Use git-send-email, or
another mailer, or attach.
> +#define KVM_VCPU_COMM \
>
KVM_VCPU_COMMON.
> + struct kvm *kvm; \
> + struct preempt_notifier preempt_notifier;\
> + int vcpu_id;\
> + struct mutex mutex;\
> + int cpu;\
> + struct kvm_run *run;\
> + int guest_mode;\
> + unsigned long requests;\
> + struct kvm_guest_debug guest_debug;\
> + int fpu_active; \
> + int guest_fpu_loaded;\
> + wait_queue_head_t wq;\
> + int sigset_active;\
> + sigset_t sigset;\
> + struct kvm_stat stat;\
> + KVM_VCPU_MMIO
>
>
Put some spaces between ';' and '\'.
>
> -static inline int memslot_id(struct kvm *kvm, struct kvm_memory_slot
> *slot)
> -{
> - return slot - kvm->memslots;
> -}
> -
>
This baby is not x86 specific.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Missing commits on kvm-commits?
It appears that a good number of KVM commits never make their way to kvm-commits. For instance, I don't see Izik's recent overcommit patches (1253f76f37189f0bfda7e4a46bfe537f329dc0db) Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RESEND] Allocate userspace memory for older userspace (v2)
dAnthony Liguori wrote:
> Allocate a userspace buffer for older userspaces. Also eliminate phys_mem
> buffer. The memset() in kvmctl really kills initial memory usage but swapping
> does even with old userspaces.
>
> Since v1, fixed a bug in slot creation.
>
> I send the previous patch in response to a mail instead of top level so I'm
> resending properly.
>
>
This is really nice, especially the diffstat.
> Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
> @@ -745,29 +727,27 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm
> *kvm,
> r = -ENOMEM;
>
> /* Allocate if a slot is being created */
> - if (npages && !new.phys_mem) {
> - new.phys_mem = vmalloc(npages * sizeof(struct page *));
> -
> - if (!new.phys_mem)
> - goto out_unlock;
> -
> + if (npages && !new.rmap) {
> new.rmap = vmalloc(npages * sizeof(struct page *));
>
> if (!new.rmap)
> goto out_unlock;
>
> - memset(new.phys_mem, 0, npages * sizeof(struct page *));
> memset(new.rmap, 0, npages * sizeof(*new.rmap));
> - if (user_alloc) {
> - new.user_alloc = 1;
> +
> + if (user_alloc)
> new.userspace_addr = mem->userspace_addr;
> - } else {
> - for (i = 0; i < npages; ++i) {
> - new.phys_mem[i] = alloc_page(GFP_HIGHUSER
> - | __GFP_ZERO);
> - if (!new.phys_mem[i])
> - goto out_unlock;
> - }
> + else {
> + down_write(¤t->mm->mmap_sem);
> + new.userspace_addr = do_mmap(NULL, 0,
> + npages * PAGE_SIZE,
> + PROT_READ | PROT_WRITE,
> + MAP_SHARED | MAP_ANONYMOUS,
> + 0);
> + up_write(¤t->mm->mmap_sem);
> +
> + if (new.userspace_addr > -1024UL)
>
Surely there's some macro to test for this type of error return? Also
we may want to return the do_mmap() error code here (not sure).
> + goto out_unlock;
> }
> }
>
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH][RESEND] Allocate userspace memory for older userspace (v2)
Allocate a userspace buffer for older userspaces. Also eliminate phys_mem
buffer. The memset() in kvmctl really kills initial memory usage but swapping
does even with old userspaces.
Since v1, fixed a bug in slot creation.
I send the previous patch in response to a mail instead of top level so I'm
resending properly.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 53b2d58..eb086e9 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -407,10 +407,8 @@ struct kvm_memory_slot {
gfn_t base_gfn;
unsigned long npages;
unsigned long flags;
- struct page **phys_mem;
unsigned long *rmap;
unsigned long *dirty_bitmap;
- int user_alloc; /* user allocated memory */
unsigned long userspace_addr;
};
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index c84bbea..25c79c3 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -322,36 +323,21 @@ static struct kvm *kvm_create_vm(void)
return kvm;
}
-static void kvm_free_kernel_physmem(struct kvm_memory_slot *free)
-{
- int i;
-
- for (i = 0; i < free->npages; ++i)
- if (free->phys_mem[i])
- __free_page(free->phys_mem[i]);
-}
-
/*
* Free any memory in @free but not in @dont.
*/
static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
- if (!dont || free->phys_mem != dont->phys_mem)
- if (free->phys_mem) {
- if (!free->user_alloc)
- kvm_free_kernel_physmem(free);
- vfree(free->phys_mem);
- }
if (!dont || free->rmap != dont->rmap)
vfree(free->rmap);
if (!dont || free->dirty_bitmap != dont->dirty_bitmap)
vfree(free->dirty_bitmap);
- free->phys_mem = NULL;
free->npages = 0;
free->dirty_bitmap = NULL;
+ free->rmap = NULL;
}
static void kvm_free_physmem(struct kvm *kvm)
@@ -734,10 +720,6 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
goto out_unlock;
}
- /* Deallocate if slot is being removed */
- if (!npages)
- new.phys_mem = NULL;
-
/* Free page dirty bitmap if unneeded */
if (!(new.flags & KVM_MEM_LOG_DIRTY_PAGES))
new.dirty_bitmap = NULL;
@@ -745,29 +727,27 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
r = -ENOMEM;
/* Allocate if a slot is being created */
- if (npages && !new.phys_mem) {
- new.phys_mem = vmalloc(npages * sizeof(struct page *));
-
- if (!new.phys_mem)
- goto out_unlock;
-
+ if (npages && !new.rmap) {
new.rmap = vmalloc(npages * sizeof(struct page *));
if (!new.rmap)
goto out_unlock;
- memset(new.phys_mem, 0, npages * sizeof(struct page *));
memset(new.rmap, 0, npages * sizeof(*new.rmap));
- if (user_alloc) {
- new.user_alloc = 1;
+
+ if (user_alloc)
new.userspace_addr = mem->userspace_addr;
- } else {
- for (i = 0; i < npages; ++i) {
- new.phys_mem[i] = alloc_page(GFP_HIGHUSER
-| __GFP_ZERO);
- if (!new.phys_mem[i])
- goto out_unlock;
- }
+ else {
+ down_write(¤t->mm->mmap_sem);
+ new.userspace_addr = do_mmap(NULL, 0,
+npages * PAGE_SIZE,
+PROT_READ | PROT_WRITE,
+MAP_SHARED | MAP_ANONYMOUS,
+0);
+ up_write(¤t->mm->mmap_sem);
+
+ if (new.userspace_addr > -1024UL)
+ goto out_unlock;
}
}
@@ -1032,6 +1012,8 @@ struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm,
gfn_t gfn)
struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
{
struct kvm_memory_slot *slot;
+ struct page *page[1];
+ int npages;
gfn = unalias_gfn(kvm, gfn);
slot = __gfn_to_memslot(kvm, gfn);
@@ -1039,24 +1021,19 @@ struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
get_page(bad_page);
return bad_page;
}
- if (slot->user_alloc) {
- struct page *page[1];
- int npages;
-
- do
Re: [kvm-devel] [PATCH][RESEND] Allocate userspace memory for older userspace (v2)
On Thu, 2007-10-18 at 09:05 -0500, Anthony Liguori wrote: > Allocate a userspace buffer for older userspaces. Also eliminate phys_mem > buffer. The memset() in kvmctl really kills initial memory usage but swapping > does even with old userspaces. > > Since v1, fixed a bug in slot creation. > > I send the previous patch in response to a mail instead of top level so I'm > resending properly. Patch look good, and beside the fact that it allow swapping for older userspace, it make the code simpler. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RESEND] Allocate userspace memory for older userspace (v2)
Avi Kivity wrote:
> dAnthony Liguori wrote:
>
>> Allocate a userspace buffer for older userspaces. Also eliminate phys_mem
>> buffer. The memset() in kvmctl really kills initial memory usage but
>> swapping
>> does even with old userspaces.
>>
>> Since v1, fixed a bug in slot creation.
>>
>> I send the previous patch in response to a mail instead of top level so I'm
>> resending properly.
>>
>>
>>
>
>
> This is really nice, especially the diffstat.
>
Time to update patchbomb script...
>> Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
>> @@ -745,29 +727,27 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm
>> *kvm,
>> r = -ENOMEM;
>>
>> /* Allocate if a slot is being created */
>> -if (npages && !new.phys_mem) {
>> -new.phys_mem = vmalloc(npages * sizeof(struct page *));
>> -
>> -if (!new.phys_mem)
>> -goto out_unlock;
>> -
>> +if (npages && !new.rmap) {
>> new.rmap = vmalloc(npages * sizeof(struct page *));
>>
>> if (!new.rmap)
>> goto out_unlock;
>>
>> -memset(new.phys_mem, 0, npages * sizeof(struct page *));
>> memset(new.rmap, 0, npages * sizeof(*new.rmap));
>> -if (user_alloc) {
>> -new.user_alloc = 1;
>> +
>> +if (user_alloc)
>> new.userspace_addr = mem->userspace_addr;
>> -} else {
>> -for (i = 0; i < npages; ++i) {
>> -new.phys_mem[i] = alloc_page(GFP_HIGHUSER
>> - | __GFP_ZERO);
>> -if (!new.phys_mem[i])
>> -goto out_unlock;
>> -}
>> +else {
>> +down_write(¤t->mm->mmap_sem);
>> +new.userspace_addr = do_mmap(NULL, 0,
>> + npages * PAGE_SIZE,
>> + PROT_READ | PROT_WRITE,
>> + MAP_SHARED | MAP_ANONYMOUS,
>> + 0);
>> +up_write(¤t->mm->mmap_sem);
>> +
>> +if (new.userspace_addr > -1024UL)
>>
>>
>
> Surely there's some macro to test for this type of error return? Also
> we may want to return the do_mmap() error code here (not sure).
>
I guess I used the wrong code as an example, sent out a new version
using IS_ERR() although its a little ugly since we have to cast to a
pointer.
I looked at the error returns by do_mmap(), I don't think we'll get
anything more meaningful from do_mmap() than -ENOMEM so I don't think
there's much value to returning it's error code. I don't feel strongly
about it though.
Regards,
Anthony Liguori
>> +goto out_unlock;
>> }
>> }
>>
>>
>
>
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Allocate userspace memory for older userspace (v3)
Weird... guilt stripped the diffstat. It should be:
kvm.h |2 -
kvm_main.c | 83
++---
2 files changed, 30 insertions(+), 55 deletions(-)
Regards,
Anthony Liguori
Anthony Liguori wrote:
> Allocate a userspace buffer for older userspaces. Also eliminate phys_mem
> buffer. The memset() in kvmctl really kills initial memory usage but swapping
> does even with old userspaces.
>
> Since v1, fixed a bug in slot creation.
>
> Since v2, changed the error checking to use IS_ERR().
>
> Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
>
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 53b2d58..eb086e9 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -407,10 +407,8 @@ struct kvm_memory_slot {
> gfn_t base_gfn;
> unsigned long npages;
> unsigned long flags;
> - struct page **phys_mem;
> unsigned long *rmap;
> unsigned long *dirty_bitmap;
> - int user_alloc; /* user allocated memory */
> unsigned long userspace_addr;
> };
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index c84bbea..1db607c 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -322,36 +323,21 @@ static struct kvm *kvm_create_vm(void)
> return kvm;
> }
>
> -static void kvm_free_kernel_physmem(struct kvm_memory_slot *free)
> -{
> - int i;
> -
> - for (i = 0; i < free->npages; ++i)
> - if (free->phys_mem[i])
> - __free_page(free->phys_mem[i]);
> -}
> -
> /*
> * Free any memory in @free but not in @dont.
> */
> static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
> struct kvm_memory_slot *dont)
> {
> - if (!dont || free->phys_mem != dont->phys_mem)
> - if (free->phys_mem) {
> - if (!free->user_alloc)
> - kvm_free_kernel_physmem(free);
> - vfree(free->phys_mem);
> - }
> if (!dont || free->rmap != dont->rmap)
> vfree(free->rmap);
>
> if (!dont || free->dirty_bitmap != dont->dirty_bitmap)
> vfree(free->dirty_bitmap);
>
> - free->phys_mem = NULL;
> free->npages = 0;
> free->dirty_bitmap = NULL;
> + free->rmap = NULL;
> }
>
> static void kvm_free_physmem(struct kvm *kvm)
> @@ -734,10 +720,6 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm
> *kvm,
> goto out_unlock;
> }
>
> - /* Deallocate if slot is being removed */
> - if (!npages)
> - new.phys_mem = NULL;
> -
> /* Free page dirty bitmap if unneeded */
> if (!(new.flags & KVM_MEM_LOG_DIRTY_PAGES))
> new.dirty_bitmap = NULL;
> @@ -745,29 +727,27 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm
> *kvm,
> r = -ENOMEM;
>
> /* Allocate if a slot is being created */
> - if (npages && !new.phys_mem) {
> - new.phys_mem = vmalloc(npages * sizeof(struct page *));
> -
> - if (!new.phys_mem)
> - goto out_unlock;
> -
> + if (npages && !new.rmap) {
> new.rmap = vmalloc(npages * sizeof(struct page *));
>
> if (!new.rmap)
> goto out_unlock;
>
> - memset(new.phys_mem, 0, npages * sizeof(struct page *));
> memset(new.rmap, 0, npages * sizeof(*new.rmap));
> - if (user_alloc) {
> - new.user_alloc = 1;
> +
> + if (user_alloc)
> new.userspace_addr = mem->userspace_addr;
> - } else {
> - for (i = 0; i < npages; ++i) {
> - new.phys_mem[i] = alloc_page(GFP_HIGHUSER
> - | __GFP_ZERO);
> - if (!new.phys_mem[i])
> - goto out_unlock;
> - }
> + else {
> + down_write(¤t->mm->mmap_sem);
> + new.userspace_addr = do_mmap(NULL, 0,
> + npages * PAGE_SIZE,
> + PROT_READ | PROT_WRITE,
> + MAP_SHARED | MAP_ANONYMOUS,
> + 0);
> + up_write(¤t->mm->mmap_sem);
> +
> + if (IS_ERR((void *)new.userspace_addr))
> + goto out_unlock;
> }
> }
>
> @@ -1032,6 +1012,8 @@ struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm,
> gfn_t gfn)
> struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
> {
> struct kvm_memory_slot *slot;
> + struct page *page[1];
> + int npages;
>
[kvm-devel] [PATCH] Allocate userspace memory for older userspace (v3)
Allocate a userspace buffer for older userspaces. Also eliminate phys_mem
buffer. The memset() in kvmctl really kills initial memory usage but swapping
does even with old userspaces.
Since v1, fixed a bug in slot creation.
Since v2, changed the error checking to use IS_ERR().
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 53b2d58..eb086e9 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -407,10 +407,8 @@ struct kvm_memory_slot {
gfn_t base_gfn;
unsigned long npages;
unsigned long flags;
- struct page **phys_mem;
unsigned long *rmap;
unsigned long *dirty_bitmap;
- int user_alloc; /* user allocated memory */
unsigned long userspace_addr;
};
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index c84bbea..1db607c 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -322,36 +323,21 @@ static struct kvm *kvm_create_vm(void)
return kvm;
}
-static void kvm_free_kernel_physmem(struct kvm_memory_slot *free)
-{
- int i;
-
- for (i = 0; i < free->npages; ++i)
- if (free->phys_mem[i])
- __free_page(free->phys_mem[i]);
-}
-
/*
* Free any memory in @free but not in @dont.
*/
static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
- if (!dont || free->phys_mem != dont->phys_mem)
- if (free->phys_mem) {
- if (!free->user_alloc)
- kvm_free_kernel_physmem(free);
- vfree(free->phys_mem);
- }
if (!dont || free->rmap != dont->rmap)
vfree(free->rmap);
if (!dont || free->dirty_bitmap != dont->dirty_bitmap)
vfree(free->dirty_bitmap);
- free->phys_mem = NULL;
free->npages = 0;
free->dirty_bitmap = NULL;
+ free->rmap = NULL;
}
static void kvm_free_physmem(struct kvm *kvm)
@@ -734,10 +720,6 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
goto out_unlock;
}
- /* Deallocate if slot is being removed */
- if (!npages)
- new.phys_mem = NULL;
-
/* Free page dirty bitmap if unneeded */
if (!(new.flags & KVM_MEM_LOG_DIRTY_PAGES))
new.dirty_bitmap = NULL;
@@ -745,29 +727,27 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
r = -ENOMEM;
/* Allocate if a slot is being created */
- if (npages && !new.phys_mem) {
- new.phys_mem = vmalloc(npages * sizeof(struct page *));
-
- if (!new.phys_mem)
- goto out_unlock;
-
+ if (npages && !new.rmap) {
new.rmap = vmalloc(npages * sizeof(struct page *));
if (!new.rmap)
goto out_unlock;
- memset(new.phys_mem, 0, npages * sizeof(struct page *));
memset(new.rmap, 0, npages * sizeof(*new.rmap));
- if (user_alloc) {
- new.user_alloc = 1;
+
+ if (user_alloc)
new.userspace_addr = mem->userspace_addr;
- } else {
- for (i = 0; i < npages; ++i) {
- new.phys_mem[i] = alloc_page(GFP_HIGHUSER
-| __GFP_ZERO);
- if (!new.phys_mem[i])
- goto out_unlock;
- }
+ else {
+ down_write(¤t->mm->mmap_sem);
+ new.userspace_addr = do_mmap(NULL, 0,
+npages * PAGE_SIZE,
+PROT_READ | PROT_WRITE,
+MAP_SHARED | MAP_ANONYMOUS,
+0);
+ up_write(¤t->mm->mmap_sem);
+
+ if (IS_ERR((void *)new.userspace_addr))
+ goto out_unlock;
}
}
@@ -1032,6 +1012,8 @@ struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm,
gfn_t gfn)
struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
{
struct kvm_memory_slot *slot;
+ struct page *page[1];
+ int npages;
gfn = unalias_gfn(kvm, gfn);
slot = __gfn_to_memslot(kvm, gfn);
@@ -1039,24 +1021,19 @@ struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
get_page(bad_page);
return bad_page;
}
- if (slot->user_alloc) {
- struct page *page[1];
- int npages;
-
- down_read(¤t->mm->mmap_sem);
-
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> No, I'm hacking up one more user ;)
>
> Nice. What will it do?
Run xenified guest kernels without Xen.
>> Should I send an updated patch or do you just drop these lines when
>> merging?
>
> Please send a rebased and retested patch.
Oh, -47 is there. Updated patch attached.
cheers,
Gerd
diff -up ./kvmctl.h.upstream ./kvmctl.h
--- ./kvmctl.h.upstream 2007-10-18 17:09:06.0 +0200
+++ ./kvmctl.h 2007-10-18 17:09:11.0 +0200
@@ -146,6 +146,9 @@ int kvm_get_shadow_pages(kvm_context_t k
int kvm_create(kvm_context_t kvm,
unsigned long phys_mem_bytes,
void **phys_mem);
+int kvm_create_vm(kvm_context_t kvm);
+void kvm_create_irqchip(kvm_context_t kvm);
+
/*!
* \brief Create a new virtual cpu
*
@@ -413,6 +416,9 @@ void *kvm_create_phys_mem(kvm_context_t,
unsigned long len, int slot, int log, int writable);
void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start,
unsigned long len, int slot);
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+ unsigned long phys_start, void *userspace_addr,
+ unsigned long len, int slot, int log);
int kvm_get_dirty_pages(kvm_context_t, int slot, void *buf);
diff -up ./kvmctl.c.upstream ./kvmctl.c
--- ./kvmctl.c.upstream 2007-10-18 17:08:57.0 +0200
+++ ./kvmctl.c 2007-10-18 17:18:53.0 +0200
@@ -436,12 +436,9 @@ int kvm_alloc_userspace_memory(kvm_conte
#endif
-int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+int kvm_create_vm(kvm_context_t kvm)
{
- unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
int fd = kvm->fd;
- int zfd;
- int r;
kvm->vcpu_fd[0] = -1;
@@ -451,6 +448,15 @@ int kvm_create(kvm_context_t kvm, unsign
return -1;
}
kvm->vm_fd = fd;
+ return 0;
+}
+
+int kvm_create_default_phys_mem(kvm_context_t kvm, unsigned long phys_mem_bytes,
+void **vm_mem)
+{
+ unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1) & PAGE_MASK;
+ int zfd;
+ int r;
#ifdef KVM_CAP_USER_MEMORY
r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
@@ -468,13 +474,19 @@ int kvm_create(kvm_context_t kvm, unsign
close(zfd);
kvm->physical_memory = *vm_mem;
+ return 0;
+}
+
+void kvm_create_irqchip(kvm_context_t kvm)
+{
+ int r;
kvm->irqchip_in_kernel = 0;
#ifdef KVM_CAP_IRQCHIP
if (!kvm->no_irqchip_creation) {
r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_IRQCHIP);
if (r > 0) { /* kernel irqchip supported */
- r = ioctl(fd, KVM_CREATE_IRQCHIP);
+ r = ioctl(kvm->vm_fd, KVM_CREATE_IRQCHIP);
if (r >= 0)
kvm->irqchip_in_kernel = 1;
else
@@ -482,6 +494,19 @@ int kvm_create(kvm_context_t kvm, unsign
}
}
#endif
+}
+
+int kvm_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem)
+{
+ int r;
+
+ r = kvm_create_vm(kvm);
+ if (r < 0)
+ return r;
+ r = kvm_create_default_phys_mem(kvm, phys_mem_bytes, vm_mem);
+ if (r < 0)
+ return r;
+ kvm_create_irqchip(kvm);
r = kvm_create_vcpu(kvm, 0);
if (r < 0)
return r;
@@ -577,6 +602,32 @@ void *kvm_create_phys_mem(kvm_context_t
log, writable);
}
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+ unsigned long phys_start, void *userspace_addr,
+ unsigned long len, int slot, int log)
+{
+ struct kvm_userspace_memory_region memory = {
+ .slot = slot,
+ .memory_size = len,
+ .guest_phys_addr = phys_start,
+ .userspace_addr = (intptr_t)userspace_addr,
+ .flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+ };
+ int r;
+
+ if (!kvm->physical_memory)
+ kvm->physical_memory = userspace_addr - phys_start;
+
+ r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+ if (r == -1) {
+ fprintf(stderr, "create_userspace_phys_mem: %s\n", strerror(errno));
+ return -1;
+ }
+
+ kvm_userspace_memory_region_save_params(kvm, &memory);
+return 0;
+}
+
/* destroy/free a whole slot.
* phys_start, len and slot are the params passed to kvm_create_phys_mem()
*/
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RESEND] Allocate userspace memory for older userspace (v2)
Anthony Liguori wrote: >> >> >> This is really nice, especially the diffstat. >> > > Time to update patchbomb script... > I meant I like the number of lines deleted by the patch, not a subtle hint that I want diffstats. Diffstats are for people who don't read patches. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Allocate userspace memory for older userspace (v3)
Anthony Liguori wrote: > Allocate a userspace buffer for older userspaces. Also eliminate phys_mem > buffer. The memset() in kvmctl really kills initial memory usage but swapping > does even with old userspaces. > Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-47 release
Good day. First thanks for release 47. This is to report a problem with kvm-47 where my host locked up upon shutdown of windows 32 bit xp guest. Guest was running for about 15 min before shutdown. Host locked up when guest was at "you may now turn off your machine" screen. Host Details: = Linux localhost.localdomain 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping: 10 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 4391.55 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: = Thanks. Haydn On 10/18/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > > Today's news includes partial support for swapping. You can now run > guests with more memory than you have on the host, and Linux will page > them out to the swap file. The support is partial in that the guest > will still pin a substantial amount of memory. > > Changes from kvm-46: > - Reset fixes (Eddie Dong, me) > - Portability work (Carsten Otte) > - Cleanups (Anthony Liguori, Laurent Vivier) > - Simplify guest pagetable dirty bit management > - Fix nx bit for huge pages > - Fix write access to clean large pages (fixes rmap leak) > - Support for Linux 2.6.16 guests (movnti instruction) (Sheng Yang) > - Simplify apic timer backlog processing > - Move interrupt injection out of critical section > - x86 emulator work (Nitin A Kamble) > - restore freebsd support on AMD (fix smsw and lmsw) (Aurelien Jarno) > - Simplify guest page table walker > - Partial guest swapping (Izik Eidus) > - kvmctl improvements (Anthony Liguori) > - libkvm, qemu compilation against older kernels > - guest time accounting (Laurent Vivier) > - configure improvements (Carlo Marcelo Arenas Belon) > - fix 4GB+ configurations (Izik Eidus) > - cross compilation support (Jerone Young) > > > Notes: > If you use the modules bundled with kvm-47, you can use any version > of Linux from 2.6.9 upwards. > If you use the modules bundled with Linux 2.6.20, you need to use > kvm-12. > If you use the modules bundled with Linux 2.6.21, you need to use > kvm-17. > Modules from Linux 2.6.22 and up will work with any kvm version from > kvm-22. Some features may only be available in newer releases. > For best performance, use Linux 2.6.23-rc2 or later as the host. > > http://kvm.qumranet.com > > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] kvmctl.c: allow custom memory setup.
Gerd Hoffmann wrote: > >>> Should I send an updated patch or do you just drop these lines when >>> merging? >>> >> Please send a rebased and retested patch. >> > > Oh, -47 is there. Updated patch attached. > > Applied. But please: - always supply the changelog comment so I don't have to hunt for it - base diffs so they can be applied from the base directory with patch -p1 (this one was -p0 against the user/ directory). in general 'git diff' (or 'git format-patch' produces the best results with a minimum of fuss. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-48 release
kvm-47 had a host memory corruption bug when setting the guest pte dirty bit, so here's kvm-48 with a fix. Note that guest time accounting, below, will only work with Linux 2.6.24+. Changes from kvm-47: - use precise cpu accounting on ppc and s390 (Christian Borntraeger) - make guest time accounting actually work (Laurent Vivier) - fix host memory corruption when setting the guest dirty bit - allow swapping with older userspace (Anthony Liguori) - allow custom memory setup using libkvm (Gerd Hoffmann) Notes: If you use the modules bundled with kvm-48, you can use any version of Linux from 2.6.9 upwards. If you use the modules bundled with Linux 2.6.20, you need to use kvm-12. If you use the modules bundled with Linux 2.6.21, you need to use kvm-17. Modules from Linux 2.6.22 and up will work with any kvm version from kvm-22. Some features may only be available in newer releases. For best performance, use Linux 2.6.23-rc2 or later as the host. http://kvm.qumranet.com - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Fix guest time accounting going faster than user time accounting
Seems I overlooked this type while reviewing Laurents patch. cputime_add already adds, dont do it twice. Avi. This should go to Linus before 2.6.24. Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]> --- fs/proc/array.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23/fs/proc/array.c === --- linux-2.6.23.orig/fs/proc/array.c +++ linux-2.6.23/fs/proc/array.c @@ -446,7 +446,7 @@ static int do_task_stat(struct task_stru maj_flt += sig->maj_flt; utime = cputime_add(utime, sig->utime); stime = cputime_add(stime, sig->stime); - gtime += cputime_add(gtime, sig->gtime); + gtime = cputime_add(gtime, sig->gtime); } sid = signal_session(sig); - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/2] add flags for conditional compilation of qemu dependencies
On Wed, Oct 17, 2007 at 06:55:02PM +0200, Avi Kivity wrote: > Carlo Marcelo Arenas Belon wrote: > > This series adds options to kvm's configure that match the ones used by qemu > > to conditionally enable or disable options that alter its runtime > > dependencies > > and functionality, like for example, support for alsa or TLS encrypted vnc > > sessions. > > Applied both, thanks. But if someone is thinking of a patch flood to > add all qemu options, I'd prefer a passthrough instead. The only other option I was interested in implementing was the one to conditionally enable or disable support for sdl, but I can see why a passthrough is a better option in the long run. Carlo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-47 release
That was quick! Don't have this problem with kvm48 anymore. On 10/18/07, Haydn Solomon <[EMAIL PROTECTED]> wrote: > > Good day. First thanks for release 47. This is to report a problem with > kvm-47 where my host locked up upon shutdown of windows 32 bit xp guest. > Guest was running for about 15 min before shutdown. Host locked up when > guest was at "you may now turn off your machine" screen. > > Host Details: > = > Linux localhost.localdomain 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT > 2007 x86_64 x86_64 x86_64 GNU/Linux > > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 15 > model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz > stepping: 10 > cpu MHz : 800.000 > cache size : 4096 KB > physical id : 0 > siblings: 2 > core id : 0 > cpu cores : 2 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm > constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm > bogomips: 4391.55 > clflush size: 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > = > > Thanks. > > Haydn > > > > > On 10/18/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > > > > Today's news includes partial support for swapping. You can now run > > guests with more memory than you have on the host, and Linux will page > > them out to the swap file. The support is partial in that the guest > > will still pin a substantial amount of memory. > > > > Changes from kvm-46: > > - Reset fixes (Eddie Dong, me) > > - Portability work (Carsten Otte) > > - Cleanups (Anthony Liguori, Laurent Vivier) > > - Simplify guest pagetable dirty bit management > > - Fix nx bit for huge pages > > - Fix write access to clean large pages (fixes rmap leak) > > - Support for Linux 2.6.16 guests (movnti instruction) (Sheng Yang) > > - Simplify apic timer backlog processing > > - Move interrupt injection out of critical section > > - x86 emulator work (Nitin A Kamble) > > - restore freebsd support on AMD (fix smsw and lmsw) (Aurelien Jarno) > > - Simplify guest page table walker > > - Partial guest swapping (Izik Eidus) > > - kvmctl improvements (Anthony Liguori) > > - libkvm, qemu compilation against older kernels > > - guest time accounting (Laurent Vivier) > > - configure improvements (Carlo Marcelo Arenas Belon) > > - fix 4GB+ configurations (Izik Eidus) > > - cross compilation support (Jerone Young) > > > > > > Notes: > > If you use the modules bundled with kvm-47, you can use any version > > of Linux from 2.6.9 upwards. > > If you use the modules bundled with Linux 2.6.20, you need to use > > kvm-12. > > If you use the modules bundled with Linux 2.6.21, you need to use > > kvm-17. > > Modules from Linux 2.6.22 and up will work with any kvm version > > from > > kvm-22. Some features may only be available in newer releases. > > For best performance, use Linux 2.6.23-rc2 or later as the host. > > > > http://kvm.qumranet.com > > > > > > > > > > - > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > ___ > > kvm-devel mailing list > > kvm-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Fix guest time accounting going faster than user time accounting
Acked-by: Laurent Vivier <[EMAIL PROTECTED]> Christian Borntraeger a écrit : > Seems I overlooked this type while reviewing Laurents patch. > cputime_add already adds, dont do it twice. > > Avi. This should go to Linus before 2.6.24. > > Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]> > > --- > fs/proc/array.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6.23/fs/proc/array.c > === > --- linux-2.6.23.orig/fs/proc/array.c > +++ linux-2.6.23/fs/proc/array.c > @@ -446,7 +446,7 @@ static int do_task_stat(struct task_stru > maj_flt += sig->maj_flt; > utime = cputime_add(utime, sig->utime); > stime = cputime_add(stime, sig->stime); > - gtime += cputime_add(gtime, sig->gtime); > + gtime = cputime_add(gtime, sig->gtime); > } > > sid = signal_session(sig); > -- [EMAIL PROTECTED] - "Given enough eyeballs, all bugs are shallow" E. S. Raymond - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/3] Add powerpc tests
This patch contains a small set of simple tests for testing guest functionality for powerpc. Signed-off-by: Jerone Young <[EMAIL PROTECTED]> diff --git a/user/test/powerpc/io.S b/user/test/powerpc/io.S new file mode 100644 --- /dev/null +++ b/user/test/powerpc/io.S @@ -0,0 +1,32 @@ +#define SPRN_MMUCR 0x3b2 + +#define TLBWORD0 0xf210 +#define TLBWORD1 0xf000 +#define TLBWORD2 0x0003 + +.global _start +_start: + li r4, 0 + mtspr SPRN_MMUCR, r4 + + li r3, 2 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 0 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 1 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 2 + + lis r3, 0xf000 + lis r4, 0x1234 + ori r4, r4, 0x5678 + stb r4, 0(r3) + lbz r5, 0(r3) + + b . diff --git a/user/test/powerpc/spin.S b/user/test/powerpc/spin.S new file mode 100644 --- /dev/null +++ b/user/test/powerpc/spin.S @@ -0,0 +1,4 @@ + +.global _start +_start: + b . diff --git a/user/test/powerpc/sprg.S b/user/test/powerpc/sprg.S new file mode 100644 --- /dev/null +++ b/user/test/powerpc/sprg.S @@ -0,0 +1,7 @@ + +.global _start +_start: + li r3, 42 + mtsprg 0, r3 + mfsprg r4, 0 + b . diff --git a/user/test/powerpc/tlbsx.S b/user/test/powerpc/tlbsx.S new file mode 100644 --- /dev/null +++ b/user/test/powerpc/tlbsx.S @@ -0,0 +1,33 @@ +#define SPRN_MMUCR 0x3b2 + +#define TLBWORD0 0x1210 +#define TLBWORD1 0x1000 +#define TLBWORD2 0x0003 + +.global _start +_start: + li r4, 0 + mtspr SPRN_MMUCR, r4 + + li r3, 23 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 0 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 1 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 2 + + lis r4, 0x1000 + tlbsx r5, r4, r0 + cmpwi r5, 23 + beq good + trap + +good: + b . diff --git a/user/test/powerpc/tlbwe.S b/user/test/powerpc/tlbwe.S new file mode 100644 --- /dev/null +++ b/user/test/powerpc/tlbwe.S @@ -0,0 +1,27 @@ +#define SPRN_MMUCR 0x3b2 + +/* Create a mapping at 4MB */ +#define TLBWORD0 0x00400210 +#define TLBWORD1 0x0040 +#define TLBWORD2 0x0003 + +.global _start +_start: + li r4, 0 + mtspr SPRN_MMUCR, r4 + + li r3, 23 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 0 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 1 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 2 + + b . diff --git a/user/test/powerpc/tlbwe_16KB.S b/user/test/powerpc/tlbwe_16KB.S new file mode 100644 --- /dev/null +++ b/user/test/powerpc/tlbwe_16KB.S @@ -0,0 +1,35 @@ +#define SPRN_MMUCR 0x3b2 + +/* 16KB mapping at 4MB */ +#define TLBWORD0 0x00400220 +#define TLBWORD1 0x0040 +#define TLBWORD2 0x0003 + +.global _start +_start: + li r4, 0 + mtspr SPRN_MMUCR, r4 + + li r3, 5 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 0 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 1 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 2 + + /* load from 4MB */ + lis r3, 0x0040 + lwz r4, 0(r3) + + /* load from 4MB+8KB */ + ori r3, r3, 0x2000 + lwz r4, 0(r3) + + b . diff --git a/user/test/powerpc/tlbwe_hole.S b/user/test/powerpc/tlbwe_hole.S new file mode 100644 --- /dev/null +++ b/user/test/powerpc/tlbwe_hole.S @@ -0,0 +1,27 @@ +#define SPRN_MMUCR 0x3b2 + +/* Try to map real address 1GB. */ +#define TLBWORD0 0x4210 +#define TLBWORD1 0x4000 +#define TLBWORD2 0x0003 + +.global _start +_start: + li r4, 0 + mtspr SPRN_MMUCR, r4 + + li r3, 23 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 0 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 1 + + lis r4, [EMAIL PROTECTED] + ori r4, r4, [EMAIL PROTECTED] + tlbwe r4, r3, 2 + + b . - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE co
Re: [kvm-devel] [PATCH 2/3] Split kvmctl for architectures
Jerone Young wrote: > This patch splits kvmctl architecture specific declarations & > implementations into their own files & headers. Common interfaces are > kept in kvmctl.h, as well as the arch specific headers are included from > within kvmctl.h. This may or may not want to be changed. > > Also includes the having different main.c files for different > architectures (otherwise it's a lot of ifdefs). > > Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> > Signed-off-by: Jerone Young <[EMAIL PROTECTED]> > This patch is pretty hard to reasonably review since diff is so large. A quick glance suggests that there's a lot of code duplication between things like main-x86.c and main-ppc.c. Perhaps the common code could be unified? Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] Split kvmctl for architectures
On Thu, 2007-10-18 at 15:28 -0500, Anthony Liguori wrote: > Jerone Young wrote: > > This patch splits kvmctl architecture specific declarations & > > implementations into their own files & headers. Common interfaces are > > kept in kvmctl.h, as well as the arch specific headers are included from > > within kvmctl.h. This may or may not want to be changed. > > > > Also includes the having different main.c files for different > > architectures (otherwise it's a lot of ifdefs). > > > > Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> > > Signed-off-by: Jerone Young <[EMAIL PROTECTED]> > > > > This patch is pretty hard to reasonably review since diff is so large. Yeah.. I'm going to break it down to try and make it more reviewable. > > A quick glance suggests that there's a lot of code duplication between > things like main-x86.c and main-ppc.c. Perhaps the common code could be > unified? I do have a main.c with ifdefs. But the feeling here is that as things are added this gets hair really quick. Right now it's ok with only 2 main architectures. But if others come in, this file could turn into an ifdef mess. I really have no strong feelings on it. I can combine them. > > Regards, > > Anthony Liguori > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] Split kvmctl for architectures
Jerone Young wrote: > diff --git a/user/kvmctl-powerpc.c b/user/kvmctl-powerpc.c > new file mode 100644 > --- /dev/null > +++ b/user/kvmctl-powerpc.c > @@ -0,0 +1,351 @@ > +/* > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Copyright IBM Corp. 2007 > + * > + * Authors: Christian Ehrhardt <[EMAIL PROTECTED]> > +*/ > - shouldnt the userspace libary be lgpl? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 2/3] Split kvmctl for architectures
On Thu, 2007-10-18 at 15:37 -0500, Jerone Young wrote: > On Thu, 2007-10-18 at 15:28 -0500, Anthony Liguori wrote: > > > > A quick glance suggests that there's a lot of code duplication between > > things like main-x86.c and main-ppc.c. Perhaps the common code could be > > unified? > > I do have a main.c with ifdefs. But the feeling here is that as things > are added this gets hair really quick. Right now it's ok with only 2 > main architectures. But if others come in, this file could turn into an > ifdef mess. > > I really have no strong feelings on it. I can combine them. Contrary to popular belief, we can share code between multiple architectures without using ifdefs... -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs.
On Thu, 2007-10-18 at 15:34 +0800, Zhang, Xiantao wrote:
> Hi Avi,
> According to your and community's suggestions, I changed the kvm_vcpu
> structure to two parts. To avoid the much intrusive into current code,
> one is common part which is defined as a macro, and the other one is
> arch-specific part.
> In addition, I have a suggestion to re-organize the head files, such as
> kvm.h and x86.h. IMO, kvm.h is changed to kvm_comm.h, and only includes
> common code for all archs.Then x86.h will be changed to kvm-x86.h, and
> linked as kvm.h at compile time. So, other archs also defines its
> kvm-xx.h to accommodate its arch-specific structures. What's your ideas
> ?(This idea doesn't include in this patch.)
First of all let me say that I hate cpp macros. What is the problem with
embedding an architecture-specific sub-structure, i.e.
struct kvm_vcpu {
...
struct arch_kvm_vcpu arch_vcpu;
};
This has a nice software engineering property too: common code will have
to explicitly dereference "arch_vcpu", which in the best case wouldn't
even compile, but even in the worst case is at least a visual red flag.
The way you're using macros, there is nothing obviously wrong about
"vcpu->host_tsc" in shared code.
One more comment below.
> >From 34cebd3a3fc0afba4df511219912bc3277e2a8c7 Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Thu, 18 Oct 2007 12:51:02 +0800
> Subject: [PATCH] First step to split kvm_vcpu. Currently, we just use an
> macro to define the common fields in kvm_vcpu for all archs, and all
> archs need to define its own kvm_vcpu struct.
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/ioapic.c |2 +
> drivers/kvm/irq.c |1 +
> drivers/kvm/kvm.h | 166
> +++-
> drivers/kvm/kvm_main.c|4 +-
> drivers/kvm/lapic.c |2 +
> drivers/kvm/mmu.c |1 +
> drivers/kvm/svm.c |2 +-
> drivers/kvm/vmx.c |1 +
> drivers/kvm/x86.h | 128 ++
> drivers/kvm/x86_emulate.c |1 +
> 10 files changed, 166 insertions(+), 142 deletions(-)
...
> +#ifdef CONFIG_HAS_IOMEM
> +#define KVM_VCPU_MMIO \
> + int mmio_needed;\
> + int mmio_read_completed;\
> + int mmio_is_write;\
> + int mmio_size;\
> + unsigned char mmio_data[8];\
> gpa_t mmio_phys_addr;
> - gva_t mmio_fault_cr2;
> - struct kvm_pio_request pio;
> - void *pio_data;
> - wait_queue_head_t wq;
>
> - int sigset_active;
> - sigset_t sigset;
> +#else
> +#define KVM_VCPU_MMIO
>
> - struct kvm_stat stat;
> +#endif
...
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index aab465d..9ff049c 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -2272,7 +2272,7 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu
> *vcpu, struct kvm_run *kvm_run)
> if (r)
> goto out;
> }
> -
> +#if CONFIG_HAS_IOMEM
> if (vcpu->mmio_needed) {
> memcpy(vcpu->mmio_data, kvm_run->mmio.data, 8);
> vcpu->mmio_read_completed = 1;
> @@ -2287,7 +2287,7 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu
> *vcpu, struct kvm_run *kvm_run)
> goto out;
> }
> }
> -
> +#endif
It does not make sense to share kvm_vcpu_ioctl_run(). Just look at it.
FYI, "char mmio_data[8]" has alignment problems. PowerPC has
endian-reversed load/store instructions, and to use them target data
must be aligned.
Also, memcpy() doesn't work for big-endian systems with sub-word loads.
Imagine if I do a single-byte load: "memcpy(&gpr, mmio_data, 1)" would
set the MSB, but the byte should land in the LSB of the register.
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] Split kvmctl for architectures
On Thu, 2007-10-18 at 22:47 +0200, Izik Eidus wrote: > Jerone Young wrote: > > diff --git a/user/kvmctl-powerpc.c b/user/kvmctl-powerpc.c > > new file mode 100644 > > --- /dev/null > > +++ b/user/kvmctl-powerpc.c > > @@ -0,0 +1,351 @@ > > +/* > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License > > + * along with this program; if not, write to the Free Software > > + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, > > USA. > > + * > > + * Copyright IBM Corp. 2007 > > + * > > + * Authors: Christian Ehrhardt <[EMAIL PROTECTED]> > > +*/ > > - > shouldnt the userspace libary be lgpl? You would be correct. I need to totally rework this patch. But I will make sure that the preamble is lgpl. Thanks for pointing that out. > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/3] Modify user directory makefiles & configure script
This patch moves make rules around to accommodate for powerpc or any none x86 architecture. This patch also adds file user/config-powerpc.mak. Also added $CROSS_COMPILE variable is added to the config.mak generated to configure script. Signed-off-by: Jerone Young <[EMAIL PROTECTED]> diff --git a/user/Makefile b/user/Makefile --- a/user/Makefile +++ b/user/Makefile @@ -15,8 +15,7 @@ cc-option = $(shell if $(CC) $(1) -S -o cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null \ > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;) -CFLAGS += -I $(KERNELDIR)/include $(autodepend-flags) -g -fomit-frame-pointer \ - -Wall +CFLAGS += $(autodepend-flags) -g -fomit-frame-pointer -Wall CFLAGS += $(call cc-option, -fno-stack-protector, "") CFLAGS += $(call cc-option, -fno-stack-protector-all, "") @@ -26,16 +25,7 @@ CXXFLAGS = $(autodepend-flags) autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d -all: kvmctl libkvm.a flatfiles - -kvmctl: LDFLAGS += -pthread -lrt - -kvmctl: kvmctl.o main.o - balloon_ctl: balloon_ctl.o - -libkvm.a: kvmctl.o - $(AR) rcs $@ $^ flatfiles-common = test/bootstrap test/vmexit.flat test/smp.flat @@ -78,3 +68,4 @@ clean: clean: $(RM) kvmctl *.o *.a .*.d $(RM) test/bootstrap test/*.o test/*.flat test/.*.d + $(RM) test/powerpc/*.o test/powerpc/*.bin test/powerpc/*.elf diff --git a/user/config-i386.mak b/user/config-i386.mak --- a/user/config-i386.mak +++ b/user/config-i386.mak @@ -3,5 +3,14 @@ bits = 32 bits = 32 ldarch = elf32-i386 CFLAGS += -m32 +CFLAGS += -I $(KERNELDIR)/include +CFLAGS += -D__i386__ flatfiles= + +all: kvmctl libkvm.a flatfiles +kvmctl: LDFLAGS += -pthread -lrt +kvmctl: kvmctl-x86.o main-x86.o + $(CC) -o $@ $(LDFLAGS) $^ $(LDLIBS) +libkvm.a: kvmctl-x86.o + $(AR) rcs $@ $^ diff --git a/user/config-powerpc.mak b/user/config-powerpc.mak new file mode 100644 --- /dev/null +++ b/user/config-powerpc.mak @@ -0,0 +1,32 @@ +LIBDIR = /lib +cstart.o = test/cstart.o +bits = 32 +ldarch = elf32-powerpc +CFLAGS += -m32 +CFLAGS += -D__powerpc__ + +# for some reaons binutils hates tlbsx unless we say we're 405 +CFLAGS := -mregnames -Wa,-m405 + +TEST_DIR=test/powerpc + +all: kvmctl libkvm.a tests +kvmctl: LDFLAGS += -pthread -lrt +kvmctl: kvmctl-powerpc.o main-powerpc.o + $(CC) -o $@ $(LDFLAGS) $^ $(LDLIBS) +libkvm.a: kvmctl-powerpc.o + $(AR) rcs $@ $^ + +tests: $(TEST_DIR)/spin.bin \ + $(TEST_DIR)/sprg.bin \ + $(TEST_DIR)/io.bin \ + $(TEST_DIR)/tlbsx.bin \ + $(TEST_DIR)/tlbwe.bin \ + $(TEST_DIR)/tlbwe_16KB.bin \ + $(TEST_DIR)/tlbwe_hole.bin + +%.elf: %.o + $(CC) -nostdlib $^ -o $@ + +%.bin: %.elf + $(CROSS_COMPILE)objcopy -O binary $^ $@ diff --git a/user/config-x86_64.mak b/user/config-x86_64.mak --- a/user/config-x86_64.mak +++ b/user/config-x86_64.mak @@ -3,5 +3,14 @@ bits = 64 bits = 64 ldarch = elf64-x86-64 CFLAGS += -m64 +CFLAGS += -I $(KERNELDIR)/include +CFLAGS += -D__x86_64__ flatfiles = test/access.flat test/irq.flat test/sieve.flat test/simple.flat test/stringio.flat test/memtest1.flat + +all: kvmctl libkvm.a flatfiles +kvmctl: LDFLAGS += -pthread -lrt +kvmctl: kvmctl-x86.o main-x86.o + $(CC) -o $@ $(LDFLAGS) $^ $(LDLIBS) +libkvm.a: kvmctl-x86.o + $(AR) rcs $@ $^ diff --git a/user/configure b/user/configure --- a/user/configure +++ b/user/configure @@ -63,4 +63,5 @@ ARCH=$arch ARCH=$arch CC=$cross_prefix$cc LD=$cross_prefix$ld +CROSS_COMPILE=$cross_prefix EOF - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 2/3] Split kvmctl for architectures
Ok, so some useful feedback :-). I'm going to rework these patches completely. Have them share a LOT more then these now. Which is basically a total spilt. On Thu, 2007-10-18 at 15:40 -0500, Hollis Blanchard wrote: > On Thu, 2007-10-18 at 15:37 -0500, Jerone Young wrote: > > On Thu, 2007-10-18 at 15:28 -0500, Anthony Liguori wrote: > > > > > > A quick glance suggests that there's a lot of code duplication between > > > things like main-x86.c and main-ppc.c. Perhaps the common code could be > > > unified? > > > > I do have a main.c with ifdefs. But the feeling here is that as things > > are added this gets hair really quick. Right now it's ok with only 2 > > main architectures. But if others come in, this file could turn into an > > ifdef mess. > > > > I really have no strong feelings on it. I can combine them. > > Contrary to popular belief, we can share code between multiple > architectures without using ifdefs... > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] qemu-system-x86_64 locks hard when used with kvm
On Tuesday 16 October 2007, Avi Kivity wrote: > Jan Frey wrote: > >> Can you set up netconsole or serial console on that machine and grab > >> the kernel output? > > > > Currently I don't have really much time.. could you point me to some > > guide or manual about what to do exactly? I'll try to do so in a few > > days.. > > Netconsole is easiest (no need for a special cable). See > Documentation/networking/netconsole.txt. So... found the time for testing it. Unfortunately console stays silent.. machine crashes immediately (even reset button won't work, I've got to poweroff hard..) I checked network config, my second machine reports some other kernel messages, but there is nothing coming related to qemu befor crashing. Regards, Jan -- Jan Frey linux [at] janfrey.de - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs.
Hollis Blanchard wrote:
> On Thu, 2007-10-18 at 15:34 +0800, Zhang, Xiantao wrote:
>
>> Hi Avi,
>> According to your and community's suggestions, I changed the kvm_vcpu
>> structure to two parts. To avoid the much intrusive into current code,
>> one is common part which is defined as a macro, and the other one is
>> arch-specific part.
>> In addition, I have a suggestion to re-organize the head files, such as
>> kvm.h and x86.h. IMO, kvm.h is changed to kvm_comm.h, and only includes
>> common code for all archs.Then x86.h will be changed to kvm-x86.h, and
>> linked as kvm.h at compile time. So, other archs also defines its
>> kvm-xx.h to accommodate its arch-specific structures. What's your ideas
>> ?(This idea doesn't include in this patch.)
>>
>
> First of all let me say that I hate cpp macros. What is the problem with
> embedding an architecture-specific sub-structure, i.e.
> struct kvm_vcpu {
> ...
> struct arch_kvm_vcpu arch_vcpu;
> };
>
I think you want the opposite direction of nesting.
There already is such a thing for vt/svm. What's needed is just another
level for x86/ppc, etc. All the necessary hooks are already in place to
allocate at the very bottom of the stack.
So to summarize, today we have:
struct kvm_vcpu {
/* stuff common to vt/svm and possibly other archs*/
};
struct vcpu_svm {
struct kvm_vcpu vcpu;
/* svm specific stuff */
};
But we should move to:
struct kvm_vcpu {
/* stuff common to x86/ppc/ia64 */
};
struct vcpu_x86 {
struct kvm_vcpu vcpu;
/* stuff common to vt/svm */
}
struct vcpu_svm {
struct vcpu_x86 vcpu;
/* svm specific stuff */
};
Regards,
Anthony Liguori
> This has a nice software engineering property too: common code will have
> to explicitly dereference "arch_vcpu", which in the best case wouldn't
> even compile, but even in the worst case is at least a visual red flag.
> The way you're using macros, there is nothing obviously wrong about
> "vcpu->host_tsc" in shared code.
>
> One more comment below.
>
>
>> >From 34cebd3a3fc0afba4df511219912bc3277e2a8c7 Mon Sep 17 00:00:00 2001
>> From: Zhang Xiantao <[EMAIL PROTECTED]>
>> Date: Thu, 18 Oct 2007 12:51:02 +0800
>> Subject: [PATCH] First step to split kvm_vcpu. Currently, we just use an
>> macro to define the common fields in kvm_vcpu for all archs, and all
>> archs need to define its own kvm_vcpu struct.
>> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
>> ---
>> drivers/kvm/ioapic.c |2 +
>> drivers/kvm/irq.c |1 +
>> drivers/kvm/kvm.h | 166
>> +++-
>> drivers/kvm/kvm_main.c|4 +-
>> drivers/kvm/lapic.c |2 +
>> drivers/kvm/mmu.c |1 +
>> drivers/kvm/svm.c |2 +-
>> drivers/kvm/vmx.c |1 +
>> drivers/kvm/x86.h | 128 ++
>> drivers/kvm/x86_emulate.c |1 +
>> 10 files changed, 166 insertions(+), 142 deletions(-)
>>
> ...
>
>> +#ifdef CONFIG_HAS_IOMEM
>> +#define KVM_VCPU_MMIO \
>> +int mmio_needed;\
>> +int mmio_read_completed;\
>> +int mmio_is_write;\
>> +int mmio_size;\
>> +unsigned char mmio_data[8];\
>> gpa_t mmio_phys_addr;
>> -gva_t mmio_fault_cr2;
>> -struct kvm_pio_request pio;
>> -void *pio_data;
>> -wait_queue_head_t wq;
>>
>> -int sigset_active;
>> -sigset_t sigset;
>> +#else
>> +#define KVM_VCPU_MMIO
>>
>> -struct kvm_stat stat;
>> +#endif
>>
>
> ...
>
>
>> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
>> index aab465d..9ff049c 100644
>> --- a/drivers/kvm/kvm_main.c
>> +++ b/drivers/kvm/kvm_main.c
>> @@ -2272,7 +2272,7 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu
>> *vcpu, struct kvm_run *kvm_run)
>> if (r)
>> goto out;
>> }
>> -
>> +#if CONFIG_HAS_IOMEM
>> if (vcpu->mmio_needed) {
>> memcpy(vcpu->mmio_data, kvm_run->mmio.data, 8);
>> vcpu->mmio_read_completed = 1;
>> @@ -2287,7 +2287,7 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu
>> *vcpu, struct kvm_run *kvm_run)
>> goto out;
>> }
>> }
>> -
>> +#endif
>>
>
> It does not make sense to share kvm_vcpu_ioctl_run(). Just look at it.
>
> FYI, "char mmio_data[8]" has alignment problems. PowerPC has
> endian-reversed load/store instructions, and to use them target data
> must be aligned.
>
> Also, memcpy() doesn't work for big-endian systems with sub-word loads.
> Imagine if I do a single-byte load: "memcpy(&gpr, mmio_data, 1)" would
> set the MSB, but the byte should land in the LSB of the register.
>
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> ht
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs.
On Thu, 2007-10-18 at 16:04 -0500, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > What is the problem with
> > embedding an architecture-specific sub-structure, i.e.
> > struct kvm_vcpu {
> > ...
> > struct arch_kvm_vcpu arch_vcpu;
> > };
> >
>
> I think you want the opposite direction of nesting.
...
> We should move to:
>
> struct kvm_vcpu {
> /* stuff common to x86/ppc/ia64 */
> };
>
> struct vcpu_x86 {
> struct kvm_vcpu vcpu;
> /* stuff common to vt/svm */
> }
>
> struct vcpu_svm {
> struct vcpu_x86 vcpu;
> /* svm specific stuff */
> };
Why?
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Split kvm_vcpu to support new archs.
Hollis Blanchard wrote:
> On Thu, 2007-10-18 at 16:04 -0500, Anthony Liguori wrote:
>
>> Hollis Blanchard wrote:
>>
>>> What is the problem with
>>> embedding an architecture-specific sub-structure, i.e.
>>> struct kvm_vcpu {
>>> ...
>>> struct arch_kvm_vcpu arch_vcpu;
>>> };
>>>
>>>
>> I think you want the opposite direction of nesting.
>>
> ...
>
>> We should move to:
>>
>> struct kvm_vcpu {
>> /* stuff common to x86/ppc/ia64 */
>> };
>>
>> struct vcpu_x86 {
>> struct kvm_vcpu vcpu;
>> /* stuff common to vt/svm */
>> }
>>
>> struct vcpu_svm {
>> struct vcpu_x86 vcpu;
>> /* svm specific stuff */
>> };
>>
>
> Why?
>
It provides better encapsulation. If you have a kvm_vcpu, unless you do
container_of(), you can't access the arch_vcpu. It helps make sure that
architecture common code remains common.
It also leaves open the possibility of supporting multiple architectures
at the same time. I don't know why you would want to do that :-)
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 3/3] Add powerpc tests
On Oct 18, 2007, at 3:11 PM, Jerone Young wrote: > This patch contains a small set of simple tests for testing guest > functionality for powerpc. > > > Signed-off-by: Jerone Young <[EMAIL PROTECTED]> some of these tests should be marked a 44x specific (any tlb related ones) - k - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH] Split kvm_vcpu to support new archs.
On Thu, 2007-10-18 at 16:31 -0500, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > On Thu, 2007-10-18 at 16:04 -0500, Anthony Liguori wrote:
> >
> >> Hollis Blanchard wrote:
> >>
> >>> What is the problem with
> >>> embedding an architecture-specific sub-structure, i.e.
> >>> struct kvm_vcpu {
> >>> ...
> >>> struct arch_kvm_vcpu arch_vcpu;
> >>> };
> >>>
> >>>
> >> I think you want the opposite direction of nesting.
> >>
> > ...
> >
> >> We should move to:
> >>
> >> struct kvm_vcpu {
> >> /* stuff common to x86/ppc/ia64 */
> >> };
> >>
> >> struct vcpu_x86 {
> >> struct kvm_vcpu vcpu;
> >> /* stuff common to vt/svm */
> >> }
> >>
> >> struct vcpu_svm {
> >> struct vcpu_x86 vcpu;
> >> /* svm specific stuff */
> >> };
> >>
> >
> > Why?
> >
>
> It provides better encapsulation. If you have a kvm_vcpu, unless you do
> container_of(), you can't access the arch_vcpu. It helps make sure that
> architecture common code remains common.
I must be misunderstanding, because this seems completely backwards to
me. With your nesting, any time architecture code wants to access
architecture state (which is almost all the time), you'd *need*
container_of:
void arch_func(struct kvm_vcpu *vcpu) {
struct arch_vcpu *arch = container_of(vcpu, arch_vcpu,
arch);
arch->gpr[3] = 0;
}
In contrast, my nesting proposal would look like this:
void arch_func(struct kvm_vcpu *vcpu) {
vcpu->arch.gpr[3] = 0;
}
> It also leaves open the possibility of supporting multiple architectures
> at the same time. I don't know why you would want to do that :-)
That's true, though this could also be accomplished by keeping arch_vcpu
as the last member of kvm_vcpu.
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH] Split kvm_vcpu to support new archs.
Hollis Blanchard wrote:
> On Thu, 2007-10-18 at 16:31 -0500, Anthony Liguori wrote:
>
>> Hollis Blanchard wrote:
>>
>>> On Thu, 2007-10-18 at 16:04 -0500, Anthony Liguori wrote:
>>>
>>>
Hollis Blanchard wrote:
> What is the problem with
> embedding an architecture-specific sub-structure, i.e.
> struct kvm_vcpu {
> ...
> struct arch_kvm_vcpu arch_vcpu;
> };
>
>
>
I think you want the opposite direction of nesting.
>>> ...
>>>
>>>
We should move to:
struct kvm_vcpu {
/* stuff common to x86/ppc/ia64 */
};
struct vcpu_x86 {
struct kvm_vcpu vcpu;
/* stuff common to vt/svm */
}
struct vcpu_svm {
struct vcpu_x86 vcpu;
/* svm specific stuff */
};
>>> Why?
>>>
>>>
>> It provides better encapsulation. If you have a kvm_vcpu, unless you do
>> container_of(), you can't access the arch_vcpu. It helps make sure that
>> architecture common code remains common.
>>
>
> I must be misunderstanding, because this seems completely backwards to
> me. With your nesting, any time architecture code wants to access
> architecture state (which is almost all the time), you'd *need*
> container_of:
>
> void arch_func(struct kvm_vcpu *vcpu) {
> struct arch_vcpu *arch = container_of(vcpu, arch_vcpu,
> arch);
> arch->gpr[3] = 0;
> }
>
> In contrast, my nesting proposal would look like this:
>
> void arch_func(struct kvm_vcpu *vcpu) {
> vcpu->arch.gpr[3] = 0;
> }
>
Well, you'd probably define a to_ppc() and then do something like:
void arch_func(struct kvm_vcpu *vcpu) {
to_arch(vcpu)->gpr[3] = 0;
}
Which is exactly what's done in the vt/svm backend (see usage of
to_svm/to_vmx).
Regards,
Anthony Liguori
>> It also leaves open the possibility of supporting multiple architectures
>> at the same time. I don't know why you would want to do that :-)
>>
>
> That's true, though this could also be accomplished by keeping arch_vcpu
> as the last member of kvm_vcpu.
>
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
