Avi Kivity wrote:
> > The key part of the implementation is the use of xchg() operation for
> > clearing dirty bits atomically. Since this allows us to update only
> > BITS_PER_LONG pages at once, we need to iterate over the dirty bitmap
> > until every dirty bit is cleared again for the next ca
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot contains 8 functions, maximum of supported PCI devices:
1 * 32 * 8 = 256. The maximum of coalesced mmio zone is 100,
each zone has an iobus devices.
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot contains 8 functions, maximum of supported PCI devices:
1 * 32 * 8 = 256. The maximum of coalesced mmio zone is 100,
each zone has an iobus devices.
On 2/28/2012 8:40 PM, John Fastabend wrote:
> On 2/18/2012 4:41 AM, jamal wrote:
>> On Fri, 2012-02-17 at 09:10 -0800, John Fastabend wrote:
>>
>>> Yes I agree that is the goal.
>>>
One last comment:
With synchronization there are other challenges when the entry in the
hardware confl
On 2/18/2012 4:41 AM, jamal wrote:
> On Fri, 2012-02-17 at 09:10 -0800, John Fastabend wrote:
>
>> Yes I agree that is the goal.
>>
>>> One last comment:
>>> With synchronization there are other challenges when the entry in the
>>> hardware conflicts with the entry in software when you intend the
Avi Kivity wrote:
> There will be an inversion for sure, if __put_user() faults and triggers
> an mmu notifier (perhaps directly, perhaps through an allocation that
> triggers a swap).
Ah, I did not notice that possibility.
Thanks,
Takuya
--
To unsubscribe from this list: send the line
For IvyBridge Mobile platform, a system hang may occur if a FLR(Function Level
Reset) is asserted to internal graphics.
This quirk patch is workaround for the IVB FLR errata issue.
We are disabling the FLR reset handshake between the PCH and CPU display,
then manually powering down the panel pow
When we know that we're running inside of a KVM guest, we don't have to
worry about synchronizing timebases between different CPUs, since the
host already took care of that.
This fixes CPU overcommit scenarios where vCPUs could hang forever trying
to sync each other while not being scheduled.
Rep
At 02/28/2012 07:23 PM, Avi Kivity Wrote:
> On 02/27/2012 05:01 AM, Wen Congyang wrote:
>> We can know the guest is paniced when the guest runs on xen.
>> But we do not have such feature on kvm. This patch implemnts
>> this feature, and the implementation is the same as xen:
>> register panic notif
At 02/28/2012 06:45 PM, Gleb Natapov Wrote:
> On Tue, Feb 28, 2012 at 11:19:47AM +0100, Jan Kiszka wrote:
>> On 2012-02-28 10:42, Wen Congyang wrote:
>>> At 02/28/2012 05:34 PM, Jan Kiszka Wrote:
On 2012-02-28 09:23, Wen Congyang wrote:
> At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
>> On
From: Scott Wood
Keeping two separate headers for e500-specific things was a
pain, and wasn't even organized along any logical boundary.
There was TLB stuff in despite the existence of
arch/powerpc/kvm/e500_tlb.h, and nothing in needed
to be referenced from outside arch/powerpc/kvm.
Signed-of
This is Scott's e500mc RFC patch set rebased, berobbed of its pt_regs
parts and fixed for bisectability. On top of them, I addressed all the
comments that I had on the code and that came up in his code as FIXMEs.
I verified that this patch set works just fine on e500mc and doesn't
break e500v2, so
From: Scott Wood
This gives us a place to put load/put actions that correspond to
code that is booke-specific but not specific to a particular core.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/44x.c |3 +++
arch/powerpc/kvm/booke.c |8
arch/
From: Scott Wood
Currently 32-bit only cares about this for choice of exception
vector, which is done in core-specific code. However, KVM will
want to distinguish as well.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/cputable.h |5 +++--
1 files ch
From: Scott Wood
The PID handling is e500v1/v2-specific, and is moved to e500.c.
The MMU sregs code and kvmppc_core_vcpu_translate will be shared with
e500mc, and is moved from e500.c to e500_tlb.c.
Partially based on patches from Liu Yu .
Signed-off-by: Scott Wood
[agraf: fix bisectability]
From: Scott Wood
This is in preparation for merging in the contents of
arch/powerpc/include/asm/kvm_e500.h.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/e500.c |2 +-
arch/powerpc/kvm/{e500_tlb.h => e500.h} |6 +++---
arch/powerpc/kvm/e5
From: Scott Wood
Move vcpu to the beginning of vcpu_e500 to give it appropriate
prominence, especially if more fields end up getting added to the
end of vcpu_e500 (and vcpu ends up in the middle).
Remove gratuitous "extern" and add parameter names to prototypes.
Signed-off-by: Scott Wood
[agra
From: Scott Wood
e500mc will want to do lpid allocation/deallocation here.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/44x.c |9 +
arch/powerpc/kvm/booke.c |9 -
arch/powerpc/kvm/e500.c |9 +
3 files changed, 18 insertion
From: Scott Wood
tlbilx is the new, preferred invalidation instruction. It is not
found on e500 prior to e500mc, but there should be no harm in
supporting it on all e500.
Based on code from Ashish Kalra .
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/e500.h
When setting MSR for an e500mc guest, we implicitly always set MSR_GS
to make sure the guest is in guest state. Since we have this implicit
rule there, we don't need to explicitly pass MSR_GS to set_msr().
Remove all explicit setters of MSR_GS.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm
From: Scott Wood
DO_KVM will need to identify the particular exception type.
There is an existing set of arbitrary numbers that Linux passes,
but it's an undocumented mess that sort of corresponds to server/classic
exception vectors but not really.
Signed-off-by: Scott Wood
Signed-off-by: Alex
When one vcpu wants to kick another, it can issue a special IPI instruction
called msgsnd. This patch emulates this instruction, its clearing counterpart
and the infrastructure required to actually trigger that interrupt inside
a guest vcpu.
With this patch, SMP guests on e500mc work.
Signed-off-
Instead of checking whether we should reschedule only when we exited
due to an interrupt, let's always check before entering the guest back
again. This gets the target more in line with the other archs.
Also while at it, generalize the whole thing so that eventually we could
have a single kvmppc_p
The semantics of BOOKE_IRQPRIO_MAX changed to denote the highest available
irqprio + 1, so let's reflect that in the code too.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powe
When using exit timing stats, we clobber r9 in the NEED_EMU case,
so better move that part down a few lines and fix it that way.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/bookehv_interrupts.S |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kv
The CONFIG_KVM_E500 option really indicates that we're running on a V2 machine,
not on a machine of the generic E500 class. So indicate that properly and
change the config name accordingly.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/Kconfig|8
arch/powerpc/kvm/Makefile
The SET_VCPU macro is a leftover from times when the vcpu struct wasn't
stored in the thread on vcpu_load/put. It's not needed anymore. Remove it.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/bookehv_interrupts.S |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git
Instead if doing
#ifndef CONFIG_64BIT
...
#else
...
#endif
we should rather do
#ifdef CONFIG_64BIT
...
#else
...
#endif
which is a lot easier to read. Change the bookehv implementation to
stick with this rule.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/bookehv_int
From: Scott Wood
Add processor support for e500mc, using hardware virtualization support
(GS-mode).
Current issues include:
- No support for external proxy (coreint) interrupt mode in the guest.
Includes work by Ashish Kalra ,
Varun Sethi , and
Liu Yu .
Signed-off-by: Scott Wood
Signed-off-b
From: Scott Wood
Chips such as e500mc that implement category E.HV in Power ISA 2.06
provide hardware virtualization features, including a new MSR mode for
guest state. The guest OS can perform many operations without trapping
into the hypervisor, including transitions to and from guest userspac
We need to make sure that no MAS updates happen automatically while we
have the guest MAS registers loaded. So move the disabling code a bit
higher up so that it covers the full time we have guest values in MAS
registers.
The race this patch fixes should never occur, but it makes the code a
bit mo
The comment for program interrupts triggered when using bookehv was
misleading. Update it to mention why MSR_GS indicates that we have
to inject an interrupt into the guest again, not emulate it.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c | 10 --
1 files changed, 8 ins
From: Scott Wood
Split e500 (v1/v2) and e500mc/e5500 to allow optimization of feature
checks that differ between the two.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/cputable.h | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff
When during guest execution we get a machine check interrupt, we don't
know how to handle it yet. So let's add the error printing code back
again that we dropped accidently earlier and tell user space that something
went really wrong.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |
There was some unused code in the exit code path that must have been
a leftover from earlier iterations. While it did no harm, it's superfluous
and thus should be removed.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- fix commit message
- also remove "lwzr9, VCPU_KVM(r4)" which was as
For BookE HV the guest visible MSR is shared->msr and is identical to
the MSR that is in use while the guest is running, because we can't trap
reads from/to MSR.
So shadow_msr is unused there. Indicate that with a comment.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_host.h |
When reinjecting an interrupt into the host interrupt handler after we're
back in host kernel land, we need to tell the kernel where the interrupt
happened. We can't tell it that we were in guest state, because that might
lead to random code walking host addresses. So instead, we tell it that
we ca
The tlbncfg registers should be populated with their respective TLB's
values. Fix the obvious typo.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/e500_tlb.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
When during guest context we get a performance monitor interrupt, we
currently bail out and oops. Let's route it to its correct handler
instead.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm
When we get a performance monitor interrupt, we need to make sure that
the host receives it. So reinject it like we reinject the other host
destined interrupts.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- call regs sync directly
---
arch/powerpc/include/asm/hw_irq.h |1 +
arch/powerpc
So far, we've always called prepare_to_enter even when all we did was return
to the host. This patch changes that semantic to only call prepare_to_enter
when we actually want to get back into the guest.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c | 18 ++
1 files
From: Scott Wood
e500mc has a normal PPC FPU, rather than SPE which is found
on e500v1/v2.
Based on code from Liu Yu .
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/system.h |1 +
arch/powerpc/kvm/booke.c | 44
The e500mc patches left some debug code in that we don't need. Remove it.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/booke.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 9fcc760..17d5318 100644
---
There's always a chance we're unable to read a guest instruction. The guest
could have its TLB mapped execute-, but not readable, something odd happens
and our TLB gets flushed. So it's a good idea to be prepared for that case
and have a fallback that allows us to fix things up in that case.
Add f
When we fail to emulate an instruction for the guest, we better go in and
tell it that we failed to emulate it, by throwing an illegal instruction
exception.
Please beware that we basically never get around to telling the guest that
we failed thanks to the debugging code right above it. If user sp
We can't run e500v2 kvm on e500mc kernels, so indicate that by
making the 2 options mutually exclusive in kconfig.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kcon
If we hit any exception whatsoever in the restore path and r1/r2 aren't the
host registers, we don't get a working oops. So it's always a good idea to
restore them as early as possible.
This time, it actually has practical reasons to do so too, since we need to
have the host page fault handler fix
From: Scott Wood
Rather than invalidate everything when a TLB1 entry needs to be
taken down, keep track of which host TLB1 entries are used for
a given guest TLB1 entry, and invalidate just those entries.
Based on code from Ashish Kalra
and Liu Yu .
Signed-off-by: Scott Wood
Signed-off-by: Al
From: Scott Wood
We'll use it on e500mc as well.
Signed-off-by: Scott Wood
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_book3s.h |3 ++
arch/powerpc/include/asm/kvm_booke.h |3 ++
arch/powerpc/include/asm/kvm_ppc.h|5
arch/powerpc/kvm/book3s_64_mmu_hv.c
On 2012-02-28 20:50, Avi Kivity wrote:
> On 02/28/2012 04:42 PM, Avi Kivity wrote:
>
>
>
> I'm getting a crash now:
>
> #0 0x74ea0285 in raise() from /lib64/libc.so.6
> #1 0x74ea1b9b in abort() from /lib64/libc.so.6
> #2 0x74e98e9e in __assert_fail_base ()
On 02/28/2012 04:42 PM, Avi Kivity wrote:
I'm getting a crash now:
#0 0x74ea0285 in raise() from /lib64/libc.so.6
#1 0x74ea1b9b in abort() from /lib64/libc.so.6
#2 0x74e98e9e in __assert_fail_base ()from /lib64/libc.so.6
#3 0x74e98f42 in __assert_
On 02/28/2012 09:26 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 11:06 AM, Avi Kivity wrote:
> >
> > No, the scheduler saves the state into task_struct. I need it saved
> > into the vcpu structure. We have two fpu states, the user state, and
> > the guest state. APIs that take a task_str
On Tue, Feb 28, 2012 at 11:06 AM, Avi Kivity wrote:
>
> No, the scheduler saves the state into task_struct. I need it saved
> into the vcpu structure. We have two fpu states, the user state, and
> the guest state. APIs that take a task_struct as a parameter, or
> reference current implicitly, a
On 02/27/2012 03:42 PM, Lukas Doktor wrote:
Hi,
This is a complete rework of cgroup test from subtests to singe-test-execution.
It improves stability of testing and allows better test customisation. The
speed is similar/faster in single variant execution and a bit slower in
all-variants execu
On 02/28/2012 08:34 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 10:09 AM, Avi Kivity wrote:
> >
> > This is done by preempt notifiers. Whenever a task switch happens we
> > push the guest fpu state into memory (if loaded) and let the normal
> > stuff happen. So the if we had a task switc
On Tue, Feb 28, 2012 at 10:09 AM, Avi Kivity wrote:
>
> This is done by preempt notifiers. Whenever a task switch happens we
> push the guest fpu state into memory (if loaded) and let the normal
> stuff happen. So the if we had a task switch during instruction
> emulation, for example, then we'd
On 02/28/2012 08:08 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 9:37 AM, Linus Torvalds
> wrote:
> >
> > So where's the comment about why you actually own and control CR0.TS,
> > and nobody else does?
>
> So what I think KVM should strive for (but I really don't know the
> code, so maybe t
On 02/28/2012 07:37 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 9:21 AM, Avi Kivity wrote:
> >
> > What you described is the slow path.
>
> Indeed. I'd even call it the "glacial and stupid" path.
Right. It won't be offended, since it's almost never called.
> >The fast path is
> >
> > v
On Tue, Feb 28, 2012 at 9:37 AM, Linus Torvalds
wrote:
>
> So where's the comment about why you actually own and control CR0.TS,
> and nobody else does?
So what I think KVM should strive for (but I really don't know the
code, so maybe there are good reasons why it is impossible) is to just
never
On 02/28/2012 07:36 PM, David Ahern wrote:
> On 2/28/12 10:24 AM, Avi Kivity wrote:
>> On 02/28/2012 05:55 PM, Joerg Roedel wrote:
>>>
>>> __init int amd_pmu_init(void)
>>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>>> index 5fa553b..773fee2 100644
>>> --- a/arch/x86/kvm/svm.c
>>> +++
On Tue, Feb 28, 2012 at 9:21 AM, Avi Kivity wrote:
>
> What you described is the slow path.
Indeed. I'd even call it the "glacial and stupid" path.
>The fast path is
>
> void kvm_load_guest_fpu(struct kvm_vcpu *vcpu)
> {
> if (vcpu->guest_fpu_loaded)
> return;
>
> If we're emulat
On 2/28/12 10:24 AM, Avi Kivity wrote:
On 02/28/2012 05:55 PM, Joerg Roedel wrote:
__init int amd_pmu_init(void)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5fa553b..773fee2 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -29,6 +29,7 @@
#include
#include
+#incl
On Tue Feb 28, 2012, you wrote:
> On 2012-02-19 21:13, Thomas Fjellstrom wrote:
> > I'm pretty much stumped on this. So I decided to try re-creating the vm
> > through virt-manager. Its up and running now. The only to major
> > differences I can see in the old and new config is the machine (-M
> >
https://bugzilla.kernel.org/show_bug.cgi?id=42812
Jan Kiszka changed:
What|Removed |Added
CC||jan.kis...@web.de
--- Comment #1 from Ja
On 02/28/2012 05:55 PM, Joerg Roedel wrote:
>
> __init int amd_pmu_init(void)
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 5fa553b..773fee2 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -29,6 +29,7 @@
> #include
> #include
>
> +#include
> #include
>
On 02/28/2012 06:05 PM, Linus Torvalds wrote:
> On Tue, Feb 28, 2012 at 3:21 AM, Avi Kivity wrote:
> >
> > Can you elaborate on what you don't like in the kvm code (apart from "it
> > does virtualiztion")?
>
> It doesn't fit any of the patterns of the x87 save/restore code, and I
> don't know what
On 02/28/2012 05:03 AM, Alexander Graf wrote:
>
> On 27.02.2012, at 20:28, Scott Wood wrote:
>
>> If there is a signal pending and MSR[WE] is set, we'll loop forever
>> without reaching this check.
>
> Good point. How about something like this on top (will fold in later)?
>
> diff --git a/arch/
Hi Stefan,
I was bisecting qemu-kvm.git.
git remote show origin
* remote origin
Fetch URL: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
Push URL: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
The bisect log is:
git bisect start
# good: [b8095f24f24e50a7d4be33d8a79474aff3324295]
On Tue, Feb 28, 2012 at 4:39 PM, Martin Mailand wrote:
> I could reproduce it and I bisected it down to this commit.
>
> 12d4536f7d911b6d87a766ad7300482ea663cea2 is the first bad commit
> commit 12d4536f7d911b6d87a766ad7300482ea663cea2
> Author: Anthony Liguori
> Date: Mon Aug 22 08:24:58 2011
Hi,
I could reproduce it and I bisected it down to this commit.
12d4536f7d911b6d87a766ad7300482ea663cea2 is the first bad commit
commit 12d4536f7d911b6d87a766ad7300482ea663cea2
Author: Anthony Liguori
Date: Mon Aug 22 08:24:58 2011 -0500
-martin
On 22.02.2012 20:53, Stefan Hajnoczi wrote:
Il 28/02/2012 17:07, Eric Blake ha scritto:
> { 'enum': 'BlockdevOp',
> 'data': [ 'snapshot', 'snapshot-mirror', 'reopen' ] }
> { 'type': 'BlockdevAction',
> 'data': {'device': 'str', 'op': 'BlockdevOp',
>'file': 'str', '*format': 'str', '*reuse': 'bool',
>'*mirror': 'st
On 02/28/2012 07:58 AM, Stefan Hajnoczi wrote:
> On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini wrote:
>> Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
>>> I'm not a fan of transactions or freeze/thaw (if used to atomically
>>> perform other commands).
>>>
>>> We should not export low-level blo
On Tue, Feb 28, 2012 at 3:21 AM, Avi Kivity wrote:
>
> Can you elaborate on what you don't like in the kvm code (apart from "it
> does virtualiztion")?
It doesn't fit any of the patterns of the x87 save/restore code, and I
don't know what it does.
It does clts on its own, in random places withou
It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is disabled in EFER.
This patch works around this issue by masking out the HO bit
in the performance counter control register when SVM is not
enabled.
The GO bit is n
On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini wrote:
> Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
>> I'm not a fan of transactions or freeze/thaw (if used to atomically
>> perform other commands).
>>
>> We should not export low-level block device operations so that
>> external software can
Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
> I'm not a fan of transactions or freeze/thaw (if used to atomically
> perform other commands).
>
> We should not export low-level block device operations so that
> external software can micromanage via QMP. I don't think this is a
> good idea bec
On 02/28/2012 04:40 PM, Jan Kiszka wrote:
> On 2012-02-28 15:32, Avi Kivity wrote:
> >
> > VMStateDescription vmstate_pit = {
> > .name = "i8254",
> > .version_id = 3,
> > .minimum_version_id = 2,
> > .minimum_version_id_old = 1,
> > .load_state_old = pit_load_old,
> > .fie
On 2012-02-28 15:32, Avi Kivity wrote:
>
> VMStateDescription vmstate_pit = {
> .name = "i8254",
> .version_id = 3,
> .minimum_version_id = 2,
> .minimum_version_id_old = 1,
> .load_state_old = pit_load_old,
> .fields = (VMStateField []) {
> <<< HEAD
> VMST
On Mon, Feb 27, 2012 at 10:06 PM, Anthony Liguori wrote:
> On 02/27/2012 03:58 PM, Paolo Bonzini wrote:
>>
>> Il 27/02/2012 18:21, Eric Blake ha scritto:
>
> Please send in any agenda items you are interested in covering.
>>>
>>> Given all the threads on snapshot/mirror/migrate/reopen in t
VMStateDescription vmstate_pit = {
.name = "i8254",
.version_id = 3,
.minimum_version_id = 2,
.minimum_version_id_old = 1,
.load_state_old = pit_load_old,
.fields = (VMStateField []) {
<<< HEAD
VMSTATE_UINT32(flags, PITState),
||| merged common ancestor
On 02/28/2012 04:00 PM, Nadav Har'El wrote:
> On Tue, Feb 28, 2012, Avi Kivity wrote about "Re: [PATCH] vhost: don't forget
> to schedule()":
> > > + if (need_resched())
> > > + schedule();
> >
> > This is cond_resched(), no?
>
> It indeed looks similar, bu
On Tue, Feb 28, 2012, Avi Kivity wrote about "Re: [PATCH] vhost: don't forget
to schedule()":
> > + if (need_resched())
> > + schedule();
>
> This is cond_resched(), no?
It indeed looks similar, but it appears there are some slightly
different things h
On 02/28/2012 03:20 PM, Peter Lieven wrote:
> On 28.02.2012 14:16, Avi Kivity wrote:
>> On 02/24/2012 08:41 AM, Stefan Hajnoczi wrote:
I dont think that it is cpu intense. All user pages are zeroed
anyway, but at allocation time it shouldnt be a big difference in
terms of cpu power.
https://bugzilla.kernel.org/show_bug.cgi?id=42829
--- Comment #1 from Steve 2012-02-28 13:49:24 ---
Also this sites described similar problems:
https://bugzilla.redhat.com/show_bug.cgi?id=520119
http://www.mail-archive.com/scientific-linux-users@
listserv.fnal.gov/msg10661.html
Let me kno
You are using old kernels on our Proxmox VE 1.9 - upgrade to latest stable, see
http://forum.proxmox.com/threads/8399-New-2-6-32-Kernel-for-Proxmox-VE-1-9-stable
If you still got issues, post in our Proxmox forum.
Martin
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-
On 28.02.2012 14:16, Avi Kivity wrote:
On 02/24/2012 08:41 AM, Stefan Hajnoczi wrote:
I dont think that it is cpu intense. All user pages are zeroed anyway, but at
allocation time it shouldnt be a big difference in terms of cpu power.
It's easy to find a scenario where eagerly zeroing pages is
PCI 2.3 allows to generically disable IRQ sources at device level. This
enables us to share legacy IRQs of such devices with other host devices
when passing them to a guest.
The new IRQ sharing feature introduced here is optional, user space has
to request it explicitly. Moreover, user space can i
On 02/24/2012 08:41 AM, Stefan Hajnoczi wrote:
> >
> > I dont think that it is cpu intense. All user pages are zeroed anyway, but
> > at allocation time it shouldnt be a big difference in terms of cpu power.
>
> It's easy to find a scenario where eagerly zeroing pages is wasteful.
> Imagine a proc
On 02/23/2012 06:42 PM, Stefan Hajnoczi wrote:
> On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
> > However, in a virtual machine I have not observed the above slow down to
> > that extend
> > while the benefit of zero after free in a virtualisation environment is
> > obvious:
> >
> > 1) zer
https://bugzilla.kernel.org/show_bug.cgi?id=42829
Steve changed:
What|Removed |Added
CC||ru...@rustcorp.com.au
Kernel Version|3.3.0-r
On 02/27/2012 03:07 PM, Nadav Har'El wrote:
> This is a tiny, but important, patch to vhost.
>
> Vhost's worker thread only called schedule() when it had no work to do, and
> it wanted to go to sleep. But if there's always work to do, e.g., the guest
> is running a network-intensive program like ne
On Tue, 28 Feb 2012, Ian Campbell wrote:
> On Tue, 2012-02-28 at 10:20 +, Dave Martin wrote:
> > On Mon, Feb 27, 2012 at 07:33:39PM +, Ian Campbell wrote:
> > > On Mon, 2012-02-27 at 18:03 +, Dave Martin wrote:
> > > > > Since we support only ARMv7+ there are "T2" and "T3" encodings
>
On 28.02.2012 13:05, Stefan Hajnoczi wrote:
On Tue, Feb 28, 2012 at 11:46 AM, Peter Lieven wrote:
On 24.02.2012 08:23, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi
wrote:
On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi
wrote:
On Thu, Feb 23, 2012 at 7:08 PM, p
On Tue, 28 Feb 2012, Dave Martin wrote:
> > Given that Stefano is proposing to make the ISS a (per-hypervisor)
> > constant we could consider just defining the Thumb and non-Thumb
> > constants instead of doing all the construction with the __HVC_IMM stuff
> > -- that would remove a big bit of the
On Tue, Feb 28, 2012 at 11:50 AM, Germain Maurice
wrote:
> I don't know if someone has already seen my request…
If you're not getting responses it could be because you are using
Proxmox VE, so the kernel and qemu-kvm might have patches. Have you
asked the Proxmox community/company for support?
On Tue, Feb 28, 2012 at 11:46 AM, Peter Lieven wrote:
> On 24.02.2012 08:23, Stefan Hajnoczi wrote:
>>
>> On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi
>> wrote:
>>>
>>> On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi
>>> wrote:
On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.c
Hello everybody,
I don't know if someone has already seen my request…
I got crashes on my KVM hosts. They are in a 6 nodes cluster of Proxmox VE
(1.9), the VM disks are LV through AoE and i use Coraid SAN storage (all the
device inside guests are Virtio - /dev/vdX, network).
For one of them (N
On 28.02.2012 09:37, Corentin Chary wrote:
On Mon, Feb 13, 2012 at 10:24 AM, Peter Lieven wrote:
Am 11.02.2012 um 09:55 schrieb Corentin Chary:
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lieven wrote:
Hi,
is anyone aware if there are still problems when enabling the threaded vnc
server?
I saw s
On 02/23/2012 01:35 PM, Takuya Yoshikawa wrote:
> We have seen some problems of the current implementation of
> get_dirty_log() which uses synchronize_srcu_expedited() for updating
> dirty bitmaps; e.g. it is noticeable that this sometimes gives us ms
> order of latency when we use VGA displays.
>
On 24.02.2012 08:23, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi wrote:
On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.com wrote:
Stefan Hajnoczi schrieb:
On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieve
1 - 100 of 120 matches
Mail list logo
