On booke, "struct tlbe_ref" contains host tlb mapping information
(pfn: for guest-pfn to pfn, flags: attribute associated with this mapping)
for a guest tlb entry. So when a guest creates a TLB entry then
"struct tlbe_ref" is set to point to valid "pfn" and set attributes in
"flags" field of the ab
From: Bharat Bhushan
kvm: powerpc: use cache attributes from linux pte
- 1st Patch fixes a bug in booke (detail in patch)
- 2nd patch is renaming the linux_pte_lookup_function() just for clarity.
There is not functional change.
- 3nd Patch adds a Linux pte lookup function.
- 4th Patch uses
We need to search linux "pte" to get "pte" attributes for
setting TLB in KVM.
This patch defines a linux_pte_lookup() function for same.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/include/asm/pgtable.h | 35 +++
1 files changed, 35 insertions(+), 0 deletions
lookup_linux_pte() is doing more than lookup, updating the pte,
so for clarity it is renamed to lookup_linux_pte_and_update()
Signed-off-by: Bharat Bhushan
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/boo
KVM uses same WIM tlb attributes as the corresponding qemu pte.
For this we now search the linux pte for the requested page and
get these cache caching/coherency attributes from pte.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/include/asm/kvm_host.h |2 +-
arch/powerpc/kvm/booke.c
On Mon, Oct 7, 2013 at 6:29 PM, Kashyap Chamarthy wrote:
> Gleb, so I just did a trace of KVM MMU to try to understand why L2 is
> stuck with shadow on EPT
Paolo, were you able to reproduce this again? Yesterday, on #qemu you
mentioned you'll test it again :-)
I was using kvm.git queue on both
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan
---
v2->v3
- CONFIG_KVM_GUEST implies CONFIG_EPAPR_PARAVIRT, so using only
CONFIG_EPAPR_PARAVIRT
v1->v2
- epapr_hypercall() i
kvm_hypercall0() and friends have nothing KVM specific so moved to
epapr_hypercall0() and friends. Also they are moved from
arch/powerpc/include/asm/kvm_para.h to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan
---
v1->v2-v3
- no Change
arch/powerpc/include/asm/epapr_hcal
From: Bharat Bhushan
This patchset does some code cleanup around kvm-hypercall.
v2->v3:
- Individual patch changelog have information
v1->v2:
- Review comment of previous patch. More information available in individual
patch.
Bharat Bhushan (2):
kvm/powerpc: rename kvm_hypercall() to epap
Hi Marcelo,
On Oct 8, 2013, at 9:23 AM, Marcelo Tosatti wrote:
>>
>> +if (kvm->arch.rcu_free_shadow_page) {
>> +kvm_mmu_isolate_pages(invalid_list);
>> +sp = list_first_entry(invalid_list, struct kvm_mmu_page, link);
>> +list_del_init(invalid_list);
>> +
On Thu, Sep 05, 2013 at 06:29:15PM +0800, Xiao Guangrong wrote:
> It is easy if the handler is in the vcpu context, in that case we can use
> walk_shadow_page_lockless_begin() and walk_shadow_page_lockless_end() that
> disable interrupt to stop shadow page being freed. But we are on the ioctl
> con
Implement reset of kernel watchdogs at pvclock read time. This avoids
adding special code to every watchdog.
This is possible for watchdogs which measure time based on sched_clock() or
ktime_get() variants.
Suggested by Don Zickus.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kernel/kvm
See individual patches for details.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please ignore patch 3/3 - there is none.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
In certain occasions it is possible for a hung task detector
positive to be false: continuation from a paused VM, for example.
Add a method to reset detection, similar as is done
with other kernel watchdogs.
Signed-off-by: Marcelo Tosatti
Index: kvm/kernel/hung_task.c
==
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2013-10-07 at 22:23 +0530, Bharat Bhushan wrote:
> kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
> Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
>
> Signed-off-by: Bharat Bhushan
> ---
> v1->v2
> - epapr_hypercall() is always defined and retu
>I wonder if the output of "udevadm monitor" during the mfks and mount
>steps shows devices appearing/disappearing? That might explain a race
>condition.
So sorry for the long delay in response, but the results of the "udevadm
monitor" gave me a new lead that led to solving the problem (which I w
Stimate utilizator
E-mailul a depasit 2 GB, care este creat de Webmaster acum la 2.30GB, nu
pute?i trimite sau primi mesaje noi pâna când va verifica?i contul.
Completa?i formularul pentru a verifica contul tau.
Va rugam sa completati detaliile de mai jos pentru a confirma contul dvs.
(1
On 05/10/13 01:54, Alexander Graf wrote:
>
> On 06.09.2013, at 15:30, Christian Borntraeger wrote:
>
>> On 06/09/13 14:19, Jens Freimann wrote:> This series adds a kvm_device that
>> acts as a irq controller for floating
>>> interrupts. As a first step it implements functionality to retrieve an
From: "Aneesh Kumar K.V"
With this patch if HV is included, interrupts come in to the HV version
of the kvmppc_interrupt code, which then jumps to the PR handler,
renamed to kvmppc_interrupt_pr, if the guest is a PR guest. This helps
in enabling both HV and PR, which we do in later patch
Signed-
On Mon, Sep 30, 2013 at 02:26:16PM +0100, Christoffer Dall wrote:
> On 30 September 2013 05:38, Will Deacon wrote:
> > On Fri, Sep 27, 2013 at 06:38:52PM +0100, Jonathan Austin wrote:
> >> The Cortex-A7 is very similar to the Cortex-A15 and as such there is very
> >> little extra infrastructure re
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan
---
v1->v2
- epapr_hypercall() is always defined and returns EV_UNIMPLEMENTED
when CONFIG_KVM_GUEST or CONFIG_EPAPR_PARAVIRT
kvm_hypercall0() and friends have nothing KVM specific so moved to
epapr_hypercall0() and friends. Also they are moved from
arch/powerpc/include/asm/kvm_para.h to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan
---
v1->v2
- No change
arch/powerpc/include/asm/epapr_hcalls
From: Bharat Bhushan
This patchset does some code cleanup around kvm-hypercall.
v1->v2:
- Review comment of previous patch. More information available in individual
patch.
Bharat Bhushan (2):
kvm/powerpc: rename kvm_hypercall() to epapr_hypercall()
kvm/powerpc: move kvm_hypercall0() and f
From: "Aneesh Kumar K.V"
drop is_hv_enabled, because that should not be a callback property
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_ppc.h | 6 +-
arch/powerpc/kvm/book3s.c | 6 +++---
arch/powerpc/kvm/book3s_hv.c | 1 -
arch/powerpc/kvm/book3s_pr.c
On 07/10/13 17:30, Alexander Graf wrote:
>
> On 07.10.2013, at 18:16, Marc Zyngier wrote:
>
>> On 07/10/13 17:04, Alexander Graf wrote:
>>>
>>> On 07.10.2013, at 17:40, Marc Zyngier
>>> wrote:
>>>
On an (even slightly) oversubscribed system, spinlocks are
quickly becoming a bottlene
From: Paul Mackerras
Since the code in book3s_64_vio_hv.c is called from real mode with HV
KVM, and therefore has to be built into the main kernel binary, this
makes it always built-in rather than part of the KVM module. It gets
called from the KVM module by PR KVM, so this adds an EXPORT_SYMBOL
From: "Aneesh Kumar K.V"
This help us to identify whether we are running with hypervisor mode KVM
enabled. The change is needed so that we can have both HV and PR kvm
enabled in the same kernel.
If both HV and PR KVM are included, interrupts come in to the HV version
of the kvmppc_interrupt code
From: "Aneesh Kumar K.V"
This moves the kvmppc_ops callbacks to be a per VM entity. This
enables us to select HV and PR mode when creating a VM. We also
allow both kvm-hv and kvm-pr kernel module to be loaded. To
achieve this we move /dev/kvm ownership to kvm.ko module. Depending on
which KVM mod
From: "Aneesh Kumar K.V"
We will use that in the later patch to find the kvm ops handler
Signed-off-by: Aneesh Kumar K.V
---
arch/arm/kvm/arm.c | 5 +++--
arch/ia64/kvm/kvm-ia64.c | 5 +++--
arch/mips/kvm/kvm_mips.c | 5 +++--
arch/powerpc/include/asm/kvm
From: "Aneesh Kumar K.V"
This patch add a new callback kvmppc_ops. This will help us in enabling
both HV and PR KVM together in the same kernel. The actual change to
enable them together is done in the later patch in the series.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_
From: "Aneesh Kumar K.V"
Make required changes to get BOOKE configs to build with
the introduction of kvmppc_ops callback
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_ppc.h | 4 +--
arch/powerpc/kvm/44x.c | 55 +++---
arch/powerp
From: "Aneesh Kumar K.V"
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/Kconfig | 6 +++---
arch/powerpc/kvm/Makefile | 11 ---
arch/powerpc/kvm/book3s.c | 12 +++-
arch/powerpc/kvm/book3s_emulate.c | 2 +-
arch/powerpc/kvm/book3s_hv.c | 2
From: "Aneesh Kumar K.V"
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/booke.c | 4 +-
arch/powerpc/kvm/e500_mmu.c | 2 +-
arch/powerpc/kvm/e500_mmu_host.c | 3 +-
arch/powerpc/kvm/trace.h | 204 ---
arch/powerpc/kvm/trace_bo
From: "Aneesh Kumar K.V"
This patch moves PR related tracepoints to a separate header. This
enables in converting PR to a kernel module which will be done in
later patches
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/book3s_64_mmu_host.c | 2 +-
arch/powerpc/kvm/book3s_mmu_hpte.c
From: "Aneesh Kumar K.V"
This help ups to select the relevant code in the kernel code
when we later move HV and PR bits as seperate modules. The patch
also makes the config options for PR KVM selectable
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s.h | 2 --
arch
From: "Aneesh Kumar K.V"
With later patches supporting PR kvm as a kernel module, the changes
that has to be built into the main kernel binary to enable PR KVM module
is now selected via KVM_BOOK3S_PR_POSSIBLE
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
From: Paul Mackerras
This label is not used now.
Signed-off-by: Paul Mackerras
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/book3s_hv_interrupts.S | 3 ---
arch/powerpc/kvm/book3s_interrupts.S| 3 ---
2 files changed, 6 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_interru
Hi All,
This patch series support enabling HV and PR KVM together in the same kernel. We
extend machine property with new property "kvm_type". A value of "HV" will
force HV
KVM and "PR" PR KVM. If we don't specify kvm_type we will select the fastest
KVM mode.
ie, HV if that is supported otherwis
On 07.10.2013, at 18:16, Marc Zyngier wrote:
> On 07/10/13 17:04, Alexander Graf wrote:
>>
>> On 07.10.2013, at 17:40, Marc Zyngier wrote:
>>
>>> On an (even slightly) oversubscribed system, spinlocks are quickly
>>> becoming a bottleneck, as some vcpus are spinning, waiting for a
>>> lock
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, October 07, 2013 9:43 PM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
> epapr_hypercall
On 07/10/13 17:04, Alexander Graf wrote:
>
> On 07.10.2013, at 17:40, Marc Zyngier wrote:
>
>> On an (even slightly) oversubscribed system, spinlocks are quickly
>> becoming a bottleneck, as some vcpus are spinning, waiting for a
>> lock to be released, while the vcpu holding the lock may not
On 07.10.2013, at 18:04, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
>> Behalf Of Alexander Graf
>> Sent: Monday, October 07, 2013 9:16 PM
>> To: Bhushan Bharat-R65777
>> Cc: Wood Scott-B07421;
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Alexander Graf
> Sent: Monday, October 07, 2013 9:16 PM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH
On 07.10.2013, at 17:40, Marc Zyngier wrote:
> On an (even slightly) oversubscribed system, spinlocks are quickly
> becoming a bottleneck, as some vcpus are spinning, waiting for a
> lock to be released, while the vcpu holding the lock may not be
> running at all.
>
> This creates contention, a
On 07/10/13 16:52, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
>> Sent: Monday, October 07, 2013 9:11 PM
>> To: linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
>> kvm@vger.kernel.org
>> Subject: [PATCH 2/2]
> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Monday, October 07, 2013 9:11 PM
> To: linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
> kvm@vger.kernel.org
> Subject: [PATCH 2/2] arm64: KVM: Yield CPU when vcpu executes a WFE
>
> On an
On 07.10.2013, at 17:43, Bhushan Bharat-R65777 wrote:
> at least when I can avoid it. With the current code the compiler
> would be
>> smart enough to just optimize out the complete branch.
Sure. My point is, where would you be calling that where the
>
> >>> at least when I can avoid it. With the current code the compiler
> >>> would be
> smart enough to just optimize out the complete branch.
> >>
> >> Sure. My point is, where would you be calling that where the
> >> entire file isn't predicated on (or selecting) CONFIG_
On an (even slightly) oversubscribed system, spinlocks are quickly
becoming a bottleneck, as some vcpus are spinning, waiting for a
lock to be released, while the vcpu holding the lock may not be
running at all.
This creates contention, and the observed slowdown is 40x for
hackbench. No, this isn'
This is a respin of a patch I posted a long while ago, this time with
numbers that I hope to be convincing enough.
The basic idea is that spinning on WFE in a guest is a waste of
resource, and that we're better of running another vcpu instead. This
specially shows when the system is oversubscribed
On an (even slightly) oversubscribed system, spinlocks are quickly
becoming a bottleneck, as some vcpus are spinning, waiting for a
lock to be released, while the vcpu holding the lock may not be
running at all.
The solution is to trap blocking WFEs and tell KVM that we're
now spinning. This ensur
On 07.10.2013, at 17:15, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Friday, October 04, 2013 4:46 PM
>> To: Bhushan Bharat-R65777
>> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; kvm@vger.kernel.org
>> Subject: Re: [
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Friday, October 04, 2013 4:46 PM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
> epapr_hypercall
On 07.10.2013, at 16:23, Cedric Le Goater wrote:
> Hi Alex,
>
> On 10/04/2013 02:50 PM, Alexander Graf wrote:
>>
>> On 03.10.2013, at 13:03, Cédric Le Goater wrote:
>>
>>> MMIO emulation reads the last instruction executed by the guest
>>> and then emulates. If the guest is running in Little
They will be used to decide whether to byte-swap or not. When Little
Endian host kernels come, these routines will need to be changed
accordingly.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/kvm_book3s.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powe
This patch adds an helper routine kvmppc_ld_inst() to load an
instruction form the guest. This routine will be modified in
the next patches to take into account the endian order of the
guest.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/kvm_book3s.h | 16 ++--
arch/
MMIO emulation reads the last instruction executed by the guest
and then emulates. If the guest is running in Little Endian mode,
the instruction needs to be byte-swapped before being emulated.
This patch stores the last instruction in the endian order of the
host, primarily doing a byte-swap if n
MMIO emulation reads the last instruction executed by the guest
and then emulates. If the guest is running in Little Endian mode,
the instruction needs to be byte-swapped before being emulated.
The first patches add simple helper routines to load instructions from
the guest. It prepares ground fo
On 10/04/2013 03:48 PM, Aneesh Kumar K.V wrote:
> Cédric Le Goater writes:
>
>> MMIO emulation reads the last instruction executed by the guest
>> and then emulates. If the guest is running in Little Endian mode,
>> the instruction needs to be byte-swapped before being emulated.
>>
>> This patch
Hi Alex,
On 10/04/2013 02:50 PM, Alexander Graf wrote:
>
> On 03.10.2013, at 13:03, Cédric Le Goater wrote:
>
>> MMIO emulation reads the last instruction executed by the guest
>> and then emulates. If the guest is running in Little Endian mode,
>> the instruction needs to be byte-swapped before
Gleb, so I just did a trace of KVM MMU to try to understand why L2 is
stuck with shadow on EPT
Ensure, EPT is enabled on L0 & disabled on L1
On L0:
-
$ cat /sys/module/kvm_intel/parameters/ept
Y
On L1
-
$ cat /sys/module/kvm_intel/parameters/ept
N
Build and install trace
Il 04/10/2013 15:10, Alexander Graf ha scritto:
>
> On 21.09.2013, at 01:53, Paul Mackerras wrote:
>
>> This fixes a typo in the code that saves the guest DSCR (Data Stream
>> Control Register) into the kvm_vcpu_arch struct on guest exit. The
>> effect of the typo was that the DSCR value was sav
Il 04/10/2013 15:38, Alexander Graf ha scritto:
>
> On 07.08.2013, at 12:03, Bharat Bhushan wrote:
>
>> When the MM code is invalidating a range of pages, it calls the KVM
>> kvm_mmu_notifier_invalidate_range_start() notifier function, which calls
>> kvm_unmap_hva_range(), which arranges to flush
Il 07/10/2013 11:49, Peter Lieven ha scritto:
>> It's in general not easy to do this if you take non-x86 targets into
>> account.
> What about the dirty way to zero out all non zero pages at the beginning of
> ram_load?
I'm not sure I follow?
Paolo
--
To unsubscribe from this list: send the line
On Fri, Oct 04, 2013 at 05:13:20PM +0100, Christoffer Dall wrote:
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -85,6 +85,8 @@
> #define PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[2:1] */
> #define PTE_S2_RDWR(_AT(pteva
On 07.10.2013 11:37, Paolo Bonzini wrote:
Il 07/10/2013 08:38, Peter Lieven ha scritto:
On 06.10.2013 15:57, Zhang Haoyu wrote:
>From my testing this has been fixed in the saucy version (1.5.0) of
qemu. It is fixed by this patch:
f1c72795af573b24a7da5eb52375c9aba8a37972
However later in the
Il 07/10/2013 08:38, Peter Lieven ha scritto:
> On 06.10.2013 15:57, Zhang Haoyu wrote:
>>> >From my testing this has been fixed in the saucy version (1.5.0) of
>> qemu. It is fixed by this patch:
>>> f1c72795af573b24a7da5eb52375c9aba8a37972
>>>
>>> However later in the history this commit was reve
69 matches
Mail list logo
