On 09.12.2011, at 19:19, Scott Wood wrote:
> On 12/09/2011 09:26 AM, Alexander Graf wrote:
>> When entering the guest, we want to make sure we're not getting preempted
>> away, so let's disable preemption on entry, but enable it again while
>> handling
>> guest exits.
>>
>> Reported-by: Jörg So
On 09.12.2011, at 20:15, Scott Wood wrote:
> On 12/09/2011 01:10 PM, Alexander Graf wrote:
>>
>> On 09.12.2011, at 19:19, Scott Wood wrote:
>>
>>> On 12/09/2011 09:26 AM, Alexander Graf wrote:
Our vcpu kick implementation differs a bit from x86 which resulted in us
not
disablin
On 12/09/2011 01:10 PM, Alexander Graf wrote:
>
> On 09.12.2011, at 19:19, Scott Wood wrote:
>
>> On 12/09/2011 09:26 AM, Alexander Graf wrote:
>>> Our vcpu kick implementation differs a bit from x86 which resulted in us not
>>> disabling preemption during the kick. Get it a bit closer to what x
On 09.12.2011, at 19:19, Scott Wood wrote:
> On 12/09/2011 09:26 AM, Alexander Graf wrote:
>> Our vcpu kick implementation differs a bit from x86 which resulted in us not
>> disabling preemption during the kick. Get it a bit closer to what x86 does.
>
> Disabling preemption only matters due to
On 12/09/2011 09:26 AM, Alexander Graf wrote:
> When entering the guest, we want to make sure we're not getting preempted
> away, so let's disable preemption on entry, but enable it again while handling
> guest exits.
>
> Reported-by: Jörg Sommer
> Signed-off-by: Alexander Graf
> ---
> arch/pow
On 12/09/2011 09:26 AM, Alexander Graf wrote:
> Our vcpu kick implementation differs a bit from x86 which resulted in us not
> disabling preemption during the kick. Get it a bit closer to what x86 does.
Disabling preemption only matters due to the other bit of functionality
you brought over -- avo
Our vcpu kick implementation differs a bit from x86 which resulted in us not
disabling preemption during the kick. Get it a bit closer to what x86 does.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/powerpc.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arc
When entering the guest, we want to make sure we're not getting preempted
away, so let's disable preemption on entry, but enable it again while handling
guest exits.
Reported-by: Jörg Sommer
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_pr.c |7 +++
1 files changed, 7 insert
Somewhere during merges we ended up from
local_irq_enable()
foo();
local_irq_disable()
to always keeping irqs enabled during that part. However, we now
have the following code:
foo();
local_irq_disable()
which disables interrupts without the surrounding code enabling them
again! So le
So far we got away with not implementing preemption properly. However,
recently users emerged who wanted to run PREEMPT_xxx kernels, running
into issues with KVM on there.
This patch set fixes all preempt issues I've found so far with Book3S
PR KVM.
Alexander Graf (4):
KVM: PPC: Book3s: PR: Dis
When running the 64-bit Book3s PR code without CONFIG_PREEMPT_NONE, we were
doing a few things wrong, most notably access to PACA fields without making
sure that the pointers stay stable accross the access (preempt_disable()).
This patch moves to_svcpu towards a get/put model which allows us to di
On Fri, 2011-12-09 at 17:52 +1100, Matt Evans wrote:
> This patch series rearranges and tidies various parts of kvmtool to pave the
> way
> for the addition of support for another architecture -- SPAPR PPC64. A second
> patch series will follow to present the PPC64 support.
I applied most of the
On Fri, Dec 9, 2011 at 8:55 AM, Matt Evans wrote:
> Add a --hugetlbfs commandline option to give a path to hugetlbfs-map guest
> memory (down in kvm__arch_init()). For x86, guest memory is a normal
> ANON mmap() if this option is not provided, otherwise a hugetlbfs mmap.
>
> Signed-off-by: Matt E
On Fri, Dec 9, 2011 at 8:55 AM, Matt Evans wrote:
> Add a --hugetlbfs commandline option to give a path to hugetlbfs-map guest
> memory (down in kvm__arch_init()). For x86, guest memory is a normal
> ANON mmap() if this option is not provided, otherwise a hugetlbfs mmap.
>
> Signed-off-by: Matt E
On Fri, Dec 9, 2011 at 10:24 AM, Sasha Levin wrote:
> If you also got kernel patches that add __SANE_USERSPACE_TYPES__ to the
> headers, and KVM_CAP_NR_VCPUS to KVM PPC, we can carry them in the KVM
> tools tree as well.
Yup, all we need is ACKs from PPC maintainers.
If you also got kernel patches that add __SANE_USERSPACE_TYPES__ to the
headers, and KVM_CAP_NR_VCPUS to KVM PPC, we can carry them in the KVM
tools tree as well.
On Fri, 2011-12-09 at 17:53 +1100, Matt Evans wrote:
> kvmtool's types.h includes , which by default on PPC64 brings in
> int-l64.h; de
16 matches
Mail list logo
