Adding localversion avoids confusion in kernel images :
like Linux version 2.6.30-rc7 does not tell whether it is linus or kvm kernel.
By adding localversion it tells :
Linux version 2.6.30-rc7-kvm , any doubt ;-)
Secondly, by installing modules it overwrites on linus modules.
By adding local
Am Freitag 29 Mai 2009 09:18:14 schrieb Jaswinder Singh Rajput:
> Adding localversion avoids confusion in kernel images :
>
> like Linux version 2.6.30-rc7 does not tell whether it is linus or kvm
> kernel.
>
> By adding localversion it tells :
>
> Linux version 2.6.30-rc7-kvm , any doubt ;-)
> I a
From: Christian Ehrhardt
*updates in v2*
merged a small piece of code from patch 1/1 that belongs here themtically
If signal pending is true we exit without updating kvm_run, userspace
currently just does nothing and jumps to kvm_run again.
Since we did not set an exit_reason we might end up wit
From: Christian Ehrhardt
*updates in v3*
- ensure allocations (might_sleep) are out of atomic context
*updates in v2*
instead of a "kick to level" behaviour the patch now implements a kick to the
lowest level. The check there bails out to upper levels if not all outstanding
vcpu->requests could
From: Christian Ehrhardt
kvm on s390 formerly ignored vcpu->cpu.
This patch adds set/unset vcpu->cpu in kvm_arch_vcpu_load/put to allow
further architecture unification e.g. let generic code not find -1 on
currently scheduled vcpus.
Signed-off-by: Christian Ehrhardt
---
[diffstat]
kvm-s390.c
From: Christian Ehrhardt
Changing s390 code in kvm_arch_vcpu_load/put come across this header
declarations. They are complete duplicates, not even useful forward
declarations as nothing using it is in between (maybe it was that in
the past).
This patch removes the two dispensable lines.
Signed-o
From: Christian Ehrhardt
*updates in v5*
- ensure dropping all vcpu requests while freeing a vcpu
*updates in v4*
- kickout only scheduled vcpus (its superfluous and wait might hang forever on
not running vcpus)
*updates in v3*
- handling the mmu reload vcpu request can now be handled inside
From: Christian Ehrhardt
*updates in v5*
- ensure dropping all vcpu requests while freeing a vcpu
*updates in v4*
- ensure kick allocations (might_sleep) are out of atomic context
- update vcpu->cpu in kvm-s390 arch handler for load/put
- remove a redundant declaration in kvm_host.h related to l
Hi Gleb,
with latest kernel modules, namely beginning with 6bc0a1a235 (Remove
irq_pending bitmap), I'm loosing interrupts with upstream's KVM support.
After some bisecting, hair-pulling and a bit meditation I added a
WARN_ON(kvm_cpu_has_interrupt(vcpu)) to kvm_vcpu_ioctl_interrupt, and it
actually
On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote:
> Hi Gleb,
>
> with latest kernel modules, namely beginning with 6bc0a1a235 (Remove
> irq_pending bitmap), I'm loosing interrupts with upstream's KVM support.
> After some bisecting, hair-pulling and a bit meditation I added a
> WARN_ON(k
Ryan Harper wrote:
This patch restores -mempath working for me on latest qemu-kvm.git.
Thanks for confirming.
btw, why'd we go from -mem-path (kvm-84/stable) to -mempath (kvm-85 and
newer)? Changing these breaks existing scripts. Not a big deal, but
wondering what was the motivation for t
On Fri, 2009-05-29 at 09:48 +0200, Christian Bornträger wrote:
> Am Freitag 29 Mai 2009 09:18:14 schrieb Jaswinder Singh Rajput:
> > Adding localversion avoids confusion in kernel images :
> >
> > like Linux version 2.6.30-rc7 does not tell whether it is linus or kvm
> > kernel.
> >
> > By adding l
Am Freitag 29 Mai 2009 10:43:46 schrieb Jaswinder Singh Rajput:
> > > Adding localversion avoids confusion in kernel images :
> > NAK from my side. If you need a distinction, there is always
> Here is NAK for your NAK from my side.
> This patch is only for KVM tree and not for linus tree.
I know t
On 05/28/09 10:53, Avi Kivity wrote:
Gerd Hoffmann wrote:
Trying to use in-kernel xen netback driver adds this problem:
* Host kernel does xen hypercalls. Ouch. We have to emulate them
in-kernel (otherwise using in-kernel netback would be a quite
pointless exercise).
Or do the standard functio
Hello again. I'm making more progress getting KVM going in M5, and
right now I'm trying to figure out why I'm getting an unhandled vm exit
with exit code 0x8021. According to Intel's manual, something about
the guest state isn't being set up correctly. I dumped the initial
register state
From: Christian Ehrhardt
kvm on s390 formerly ignored vcpu->cpu.
This patch adds set/unset vcpu->cpu in kvm_arch_vcpu_load/put to allow
further architecture unification e.g. let generic code not find -1 on
currently scheduled vcpus.
Signed-off-by: Christian Ehrhardt
---
[diffstat]
kvm-s390.c
From: Christian Ehrhardt
*updates in v6*
- ensure the wait_on_bit waiter is notified
- move the reset of requests to kvm_vcpu_release to drop them early
*updates in v5*
- ensure dropping vcpu all requests while freeing a vcpu
*updates in v4*
- kickout only scheduled vcpus (its superfluous and w
From: Christian Ehrhardt
*updates in v2*
merged a small piece of code from patch 1/1 that belongs here themtically
If signal pending is true we exit without updating kvm_run, userspace
currently just does nothing and jumps to kvm_run again.
Since we did not set an exit_reason we might end up wit
From: Christian Ehrhardt
Changing s390 code in kvm_arch_vcpu_load/put come across this header
declarations. They are complete duplicates, not even useful forward
declarations as nothing using it is in between (maybe it was that in
the past).
This patch removes the two dispensable lines.
Signed-o
From: Christian Ehrhardt
*updates in v3*
- ensure allocations (might_sleep) are out of atomic context
*updates in v2*
instead of a "kick to level" behaviour the patch now implements a kick to the
lowest level. The check there bails out to upper levels if not all outstanding
vcpu->requests could
From: Christian Ehrhardt
*updates in v6*
- drop the unrelated fix to kvm_host.h from the series to clear it thematically
- ensure the wait_on_bit waiter is notified
- move the reset of requests to kvm_vcpu_release to drop them early
Note: I beg a pardon for the change rate of these series in the
On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote:
> Hi Gleb,
>
> with latest kernel modules, namely beginning with 6bc0a1a235 (Remove
> irq_pending bitmap), I'm loosing interrupts with upstream's KVM support.
> After some bisecting, hair-pulling and a bit meditation I added a
> WARN_ON(k
Gleb Natapov wrote:
> On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote:
>> Hi Gleb,
>>
>> with latest kernel modules, namely beginning with 6bc0a1a235 (Remove
>> irq_pending bitmap), I'm loosing interrupts with upstream's KVM support.
>> After some bisecting, hair-pulling and a bit medita
On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote:
> >> Hi Gleb,
> >>
> >> with latest kernel modules, namely beginning with 6bc0a1a235 (Remove
> >> irq_pending bitmap), I'm loosing interrupts with upstre
Testing latest qemu-kvm.git and kvm-kmod.git, ept enabled and backing
guests with large pages trips a BUG in the mmu code. If I disable ept,
but still use large pages, migration succeeds. Reproduce with:
hugetlbfs setup:
% mkdir -p /hugetlbfs && mount -t hugetlbfs hugetlbfs /hugetlbfs
% echo 100
Gleb Natapov wrote:
> On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote:
Hi Gleb,
with latest kernel modules, namely beginning with 6bc0a1a235 (Remove
irq_pending bitmap), I'm loosing
On Fri, May 29, 2009 at 06:46:47PM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote:
> >> Gleb Natapov wrote:
> >>> On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote:
> Hi Gleb,
>
> with latest kernel modules, name
Gleb Natapov wrote:
> On Fri, May 29, 2009 at 06:46:47PM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
> On Fri, May 29, 2009 at 10:23:24AM +0200, Jan Kiszka wrote:
>> Hi Gleb,
>>
>> with late
On Fri, May 29, 2009 at 07:01:44PM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Fri, May 29, 2009 at 06:46:47PM +0200, Jan Kiszka wrote:
> >> Gleb Natapov wrote:
> >>> On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Fri, May 29, 2009 at 10:
Gleb Natapov wrote:
> On Fri, May 29, 2009 at 07:01:44PM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Fri, May 29, 2009 at 06:46:47PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
> On Fri, May 29, 2009 at 04:52:41PM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On F
On Fri, May 29, 2009 at 07:26:52PM +0200, Jan Kiszka wrote:
> with latest kernel modules, namely beginning with 6bc0a1a235 (Remove
> irq_pending bitmap), I'm loosing interrupts with upstream's KVM
> support.
> After some bisecting, hair-pulling and a bit meditat
Gleb Natapov wrote:
> On Fri, May 29, 2009 at 07:26:52PM +0200, Jan Kiszka wrote:
>> with latest kernel modules, namely beginning with 6bc0a1a235 (Remove
>> irq_pending bitmap), I'm loosing interrupts with upstream's KVM
>> support.
>> After some bisecting, hair-pul
Hi Amit,
Please correct me if I am wrong, but the fact that the PVDMA module is
located in the guest imposes a security problem. So, if someone in the guest
has root access, he could modify the PVDMA module and then corrupt the host
memory. Because of this the guest has to be trusted. I
On Thu, 28 May 2009, Masami Hiramatsu wrote:
> Add dynamic ftrace_event_call support to ftrace. Trace engines can adds new
> ftrace_event_call to ftrace on the fly. Each operator functions of the call
> takes a ftrace_event_call data structure as an argument, because these
> functions may be shar
On Thu, 28 May 2009, Masami Hiramatsu wrote:
> Add kprobes-based event tracer on ftrace.
>
> This tracer is similar to the events tracer which is based on Tracepoint
> infrastructure. Instead of Tracepoint, this tracer is based on kprobes(kprobe
> and kretprobe). It probes anywhere where kprobes
On Thu, 28 May 2009, Masami Hiramatsu wrote:
> +#undef SHOW_FIELD
> +#define SHOW_FIELD(type, item, name) \
> + do {\
> + ret = trace_seq_printf(s, "\tfield: " #type " %s;\t"\
> +
36 matches
Mail list logo
