cpu *vcpu)
> break;
> case PSCI_1_0_FN_PSCI_FEATURES:
> feature = smccc_get_arg1(vcpu);
> + val = kvm_psci_check_allowed_function(vcpu, feature);
> + if (val)
> + break;
> +
> switch(feature) {
>
On Wed, Apr 01, 2020 at 05:58:15PM +0100, Marc Zyngier wrote:
> When a guest delibarately uses an SSMC32 function number (which is allowed),
> we should make sure we drop the top 32bits from the input arguments, as they
> could legitimately be junk.
>
> Reported-by: Christoffer Dal
enerated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
Acked-by: Christoffer Dall
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
gfn, write_fault, &writable);
> if (pfn == KVM_PFN_ERR_HWPOISON) {
> - kvm_send_hwpoison_signal(hva, vma);
> + kvm_send_hwpoison_signal(hva, vma_shift);
> return 0;
> }
> if (is_error_noslot_pfn(pfn))
> --
> 2.24.0
>
>
Reviewed-by: Christoffer Dall
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Mon, Dec 16, 2019 at 10:31:19AM +, Marc Zyngier wrote:
> On 2019-12-13 11:14, Christoffer Dall wrote:
> > On Fri, Dec 13, 2019 at 09:28:59AM +, Marc Zyngier wrote:
> > > Hi Christoffer,
> > >
> > > On 2019-12-13 08:29, Christoffer Dall wrote:
>
:0] = MEM[7:0]
>
>Any surprises?
No, this looks as I expected it to.
Thanks for the test.
Christoffer
> __
>
>From: Christoffer Dall
>Sent: 13 December 2019 10:56
>To: Marc Zyngier
On Fri, Dec 13, 2019 at 09:28:59AM +, Marc Zyngier wrote:
> Hi Christoffer,
>
> On 2019-12-13 08:29, Christoffer Dall wrote:
> > Hi Marc,
> >
> > On Wed, Dec 11, 2019 at 04:56:48PM +, Marc Zyngier wrote:
> > > A device mapping is normally always map
On Fri, Dec 13, 2019 at 10:12:19AM +, Marc Zyngier wrote:
> On 2019-12-12 19:50, Christoffer Dall wrote:
> > On AArch64 you can do a sign-extended load to either a 32-bit or 64-bit
> > register, and we should only sign extend the register up to the width of
> > the registe
On Wed, Dec 11, 2019 at 04:56:50PM +, Marc Zyngier wrote:
> Should userspace unmap memory whilst the guest is running, we exit
> with a -EFAULT, but also having spat a useless message on the console.
>
> Get rid of it.
Acked-by: Christoffer Dall
>
> Signed-of
Hi James,
On Thu, Dec 12, 2019 at 03:34:31PM +, James Morse wrote:
> Hi Marc,
>
> On 12/12/2019 11:33, Marc Zyngier wrote:
> > On 2019-12-11 16:56, Marc Zyngier wrote:
[...]
>
> (allocating from a kmemcache while holding current's mmap_sem. I don't want
> to think about
> it!)
>
> Can we
On Wed, Dec 11, 2019 at 04:56:49PM +, Marc Zyngier wrote:
> When we check for a poisoned page, we use the VMA to tell userspace
> about the looming disaster. But we pass a pointer to this VMA
> after having released the mmap_sem, which isn't a good idea.
>
> Instead, re-check that we have stil
Hi Marc,
On Wed, Dec 11, 2019 at 04:56:48PM +, Marc Zyngier wrote:
> A device mapping is normally always mapped at Stage-2, since there
> is very little gain in having it faulted in.
It is actually becoming less clear to me what the real benefits of
pre-populating the stage 2 page table are,
decoding information in
the SF ("Sixty-Four" -- how cute...) bit.
Let's take advantage of this with the usual 32-bit/64-bit header file
dance and do the right thing on AArch64 hosts.
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_emulate.h | 5 +
arch/arm/include
this point in time defines how the VMA is used
> during its lifetime. There may be other cases where a VMA is created
> with VM_READ vm_flags that are changed to VM_READ|VM_WRITE later, and
> we are currently rejecting this use case as well."
>
> [1]
> https://gitlab.com/virtio
On Thu, Nov 21, 2019 at 04:20:20AM +0100, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski
>
FWIW, the config file should read
On Wed, Nov 20, 2019 at 07:28:07AM -0800, Sean Christopherson wrote:
> On Wed, Nov 20, 2019 at 12:52:16PM +0100, Christoffer Dall wrote:
> > On Tue, Nov 19, 2019 at 07:44:48PM -0800, Sean Christopherson wrote:
> > > On Fri, Nov 08, 2019 at 12:19:20PM +0100, Christoffer Dall wr
On Tue, Nov 19, 2019 at 07:44:48PM -0800, Sean Christopherson wrote:
> On Fri, Nov 08, 2019 at 12:19:20PM +0100, Christoffer Dall wrote:
> > Hi,
> >
> > I had a look at our relatively complicated logic in
> > kvm_arch_prepare_memory_region(), and was wondering if there
Hi,
I had a look at our relatively complicated logic in
kvm_arch_prepare_memory_region(), and was wondering if there was room to
unify some of this handling between architectures.
(If you haven't seen our implementation, you can find it in
virt/kvm/arm/mmu.c, and it has lovely ASCII art!)
I then
ted test cases (I get almost no doorbell at all in the non
> oversubscribed case, and the usual hailstorm as soon as there is
> oversubscription). I'd welcome some testing on more current HW.
>
Reviewed-by: Christoffer Dall
___
kvmarm mailing list
kvm
Hi Alexandru,
On Wed, Nov 06, 2019 at 01:02:21PM +, Alexandru Elisei wrote:
>
> On 10/28/19 1:05 PM, Christoffer Dall wrote:
> > On CPUs that support S2FWB (Armv8.4+), KVM configures the stage 2 page
> > tables to override the memory attributes of memory accesses, regardles
harm in the
former, and while the latter might result in slight overhead for zeroing
the page, it seems this is what a hypervisor should do on page table
allocations.
Signed-off-by: Christoffer Dall
---
arch/mips/include/asm/kvm_host.h | 15 ++---
arch/mips/include/asm/kvm_types.h | 4
he to memcache to avoid overly long lines.
This is a bit tedious on the callsites but ends up looking more
palatable.
Signed-off-by: Christoffer Dall
---
arch/x86/include/asm/kvm_host.h | 6 ++---
arch/x86/include/asm/kvm_types.h | 4 ++--
arch/x86/kvm/mmu.c
FP_PGTABLE_USER here as well.
This will make it easier to unify the memchace implementation between
architectures.
Signed-off-by: Christoffer Dall
---
arch/x86/kvm/mmu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
ind
-specific kvm_types.h to
know the size of object in kvm_host.h.
We only define the functions and data types if
KVM_ARCH_WANT_MMU_MEMORY_CACHE is defined, because not all architectures
require the mmu memory cache.
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_types.h | 5 +++
arch
tionality.
- Rename KVM_NR_MEM_OBJS to KVM_MMU_NR_MEMCACHE_OBJS
Christoffer Dall (5):
KVM: x86: Move memcache allocation to GFP_PGTABLE_USER
KVM: x86: Move mmu_memory_cache functions to common code
KVM: x86: Rename mmu_memory_cache to kvm_mmu_memcache
KVM: arm/arm64: Move to com
avior.
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_host.h| 13 +-
arch/arm/include/asm/kvm_mmu.h | 2 +-
arch/arm/include/asm/kvm_types.h | 4 ++
arch/arm64/include/asm/kvm_host.h | 13 +-
arch/arm64/include/asm/kvm_mmu.h | 2 +-
arch/arm64/include/asm/kvm_ty
dance, and simply not set TVM when
creating a VM on a system that has S2FWB.
Signed-off-by: Christoffer Dall
Reviewed-by: Mark Rutland
---
I was only able to test this on the model with cache modeling enabled,
but even removing TVM from HCR_EL2 without having FWB also worked with
that setup, so
dance, and simply not set TVM when
creating a VM on a systme that has S2FWB.
Signed-off-by: Christoffer Dall
Cc: Mark Rutland
Cc: Alexandru Elisei
---
I was only able to test this on the model with cache modeling enabled,
but even removing TVM from HCR_EL2 without having FWB also worked with
On Thu, Oct 24, 2019 at 04:07:29PM -0700, Sean Christopherson wrote:
> The end goal of this series is to dynamically size the memslot array so
> that KVM allocates memory based on the number of memslots in use, as
> opposed to unconditionally allocating memory for the maximum number of
> memslots.
On Fri, Oct 25, 2019 at 10:48:46AM +0800, Shannon Zhao wrote:
>
>
> On 2019/10/24 21:41, Marc Zyngier wrote:
> > On 2019-10-24 11:58, James Morse wrote:
> > > Hi Shannon,
> > >
> > > On 24/10/2019 11:27, Shannon Zhao wrote:
> > > > Curently KVM ARM64 doesn't support to compile as a kernel module
s fine. I've also run the selftest framework's tests for the dirty
logging and the migration loop test for arm64, and they pass fine.
You can add my (for arm64):
Tested-by: Christoffer Dall
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
mslots(kvm, as_id, slots);
>
> kvm_arch_commit_memory_region(kvm, mem, &old, &new, change);
>
> kvm_free_memslot(kvm, &old, &new);
> - kvfree(old_memslots);
> + kvfree(slots);
> return 0;
>
> out_slots:
> + if (cha
vm,
> new.userspace_addr = mem->userspace_addr;
>
> if (kvm_arch_create_memslot(kvm, &new, npages))
> - goto out_free;
> + goto out;
> }
>
> /* Allocate page dirty bitmap if needed */
> --
> 2.22.0
>
Acked-by: Christoffer Dall
dling/handling/
> needed in the future.
>
> Signed-off-by: Sean Christopherson
Otherwise looks good to me.
Acked-by: Christoffer Dall
r = kvm_arch_vcpu_create(vcpu);
> if (r)
> goto vcpu_free_run_page;
>
What a fantastically welcome piece of work! Thanks for doing this,
many's the time I waded through all those calls to ensure a patch was
doing the right thing.
Mod
On Mon, Oct 21, 2019 at 06:59:22PM -0700, Sean Christopherson wrote:
> Add an arm specific hook to free the arm64-only sve_state. Doing so
> eliminates the last functional code from kvm_arch_vcpu_uninit() across
> all architectures and paves the way for removing kvm_arch_vcpu_init()
> and kvm_arch
On Sun, Oct 20, 2019 at 11:25:24AM +0100, Marc Zyngier wrote:
> Hi Christoffer,
>
> On Fri, 11 Oct 2019 12:07:04 +0100,
> Christoffer Dall wrote:
> >
> > When a guest accesses memory outside the memory slots, KVM usually
> > bounces the access back to userspace wi
In preparation for improving our handling of guest aborts with missing
decode info or outside any mapped resource, sync updated Linux header
files.
NOTE: This is a development update and these headers are not yet in an
upstream tree. DO NOT MERGE.
Signed-off-by: Christoffer Dall
---
arm
MMIO
regions which cannot be found, and allow them to return if the invalid
access was handled or not.
Signed-off-by: Christoffer Dall
---
arm/include/arm-common/kvm-cpu-arch.h | 16
arm/kvm-cpu.c | 2 +-
mips/include/kvm/kvm-cpu-arch.h
istent use of has_ in patch 2 and allow injecting
SError and external abort simultaenously with a single call to set
VCPU events.
Changes since v1:
- Rebased on v5.4-rc2
- Fixed some documentation and coding nit in review of v1
Christoffer Dall (2):
KVM: arm/arm64: Allow reporting no
a new exit reason to report the
event to userspace. User space can then emulate an exception to the
guest, restart the guest, suspend the guest, or take any other
appropriate action as per the policy of the running system.
Reported-by: Heinrich Schuchardt
Signed-off-by: Christoffer Dall
Reviewe
. The kernel already has functionality to inject an
external abort, but we need to wire up a signal from user space that
lets user space tell the kernel to do this.
It turns out, we already have the set event functionality which we can
perfectly reuse for this.
Signed-off-by: Christoffer Dall
7;s memory map, or if this
appeared to be an attempt at doing MMIO.
Signed-off-by: Christoffer Dall
---
arm/kvm-cpu.c | 20 +++-
arm/kvm.c | 8
include/kvm/kvm.h | 1 +
kvm.c | 1 +
mmio.c| 11 +++
5 files changed, 40 insert
On Tue, Oct 08, 2019 at 02:03:07PM +0200, Alexander Graf wrote:
>
>
> On 08.10.19 11:36, Christoffer Dall wrote:
> > In some scenarios, such as buggy guest or incorrect configuration of the
> > VMM and firmware description data, userspace will detect a memory access
> &
In preparation for improving our handling of guest aborts with missing
decode info or outside any mapped resource, sync updated Linux header
files.
NOTE: This is a development update and these headers are not yet in an
upstream tree. DO NOT MERGE.
Signed-off-by: Christoffer Dall
---
arm
MMIO
regions which cannot be found, and allow them to return if the invalid
access was handled or not.
Signed-off-by: Christoffer Dall
---
arm/include/arm-common/kvm-cpu-arch.h | 16
arm/kvm-cpu.c | 2 +-
mips/include/kvm/kvm-cpu-arch.h
n v5.4-rc2
- Fixed some documentation and coding nit in review of v1
Christoffer Dall (2):
KVM: arm/arm64: Allow reporting non-ISV data aborts to userspace
KVM: arm/arm64: Allow user injection of external data aborts
Documentation/virt/kvm/api.txt | 51 +++-
arch/a
a new exit reason to report the
event to userspace. User space can then emulate an exception to the
guest, restart the guest, suspend the guest, or take any other
appropriate action as per the policy of the running system.
Reported-by: Heinrich Schuchardt
Signed-off-by: Christoffer Dall
---
Do
. The kernel already has functionality to inject an
external abort, but we need to wire up a signal from user space that
lets user space tell the kernel to do this.
It turns out, we already have the set event functionality which we can
perfectly reuse for this.
Signed-off-by: Christoffer Dall
7;s memory map, or if this
appeared to be an attempt at doing MMIO.
Signed-off-by: Christoffer Dall
---
arm/kvm-cpu.c | 20 +++-
arm/kvm.c | 8
include/kvm/kvm.h | 1 +
kvm.c | 1 +
mmio.c| 11 +++
5 files changed, 40 insert
On Thu, Sep 26, 2019 at 03:09:11PM +0100, Marc Zyngier wrote:
> On 09/09/2019 13:13, Christoffer Dall wrote:
> > In some scenarios, such as buggy guest or incorrect configuration of the
> > VMM and firmware description data, userspace will detect a memory access
> > to a port
On Tue, Oct 01, 2019 at 06:21:43PM +0100, James Morse wrote:
> Hi Christoffer,
>
> On 09/09/2019 13:13, Christoffer Dall wrote:
> > For a long time, if a guest accessed memory outside of a memslot using
> > any of the load/store instructions in the architecture which doesn&
On Thu, Sep 26, 2019 at 02:47:55PM +0100, Marc Zyngier wrote:
> On 09/09/2019 13:13, Christoffer Dall wrote:
> > For a long time, if a guest accessed memory outside of a memslot using
> > any of the load/store instructions in the architecture which doesn't
> > supply d
On Mon, Sep 09, 2019 at 04:56:23PM +0100, Peter Maydell wrote:
> On Mon, 9 Sep 2019 at 16:16, Christoffer Dall
> wrote:
> >
> > On Mon, Sep 09, 2019 at 01:32:46PM +0100, Peter Maydell wrote:
> > > This API seems to be missing support for userspace to specify
> &
On Mon, Sep 09, 2019 at 01:32:46PM +0100, Peter Maydell wrote:
> On Mon, 9 Sep 2019 at 13:13, Christoffer Dall
> wrote:
> >
> > In some scenarios, such as buggy guest or incorrect configuration of the
> > VMM and firmware description data, userspace will detect a memory
In preparation for improving our handling of guest aborts with missing
decode info or outside any mapped resource, sync updated Linux header
files.
NOTE: This is a development update and these headers are not yet in an
upstream tree. DO NOT MERGE.
Signed-off-by: Christoffer Dall
---
arm
MMIO
regions which cannot be found, and allow them to return if the invalid
access was handled or not.
Signed-off-by: Christoffer Dall
---
arm/include/arm-common/kvm-cpu-arch.h | 16
arm/kvm-cpu.c | 2 +-
mips/include/kvm/kvm-cpu-arch.h
info. With these
patches, this will return to userspace for it to handle, but there's no
way for userspace to return the decoding information to KVM and have KVM
complete the access to the in-kernel emulated device. I have no plans
to address this limitation.
Christoffer Dall (2):
KVM: arm/ar
a new exit reason to report the
event to userspace. User space can then emulate an exception to the
guest, restart the guest, suspend the guest, or take any other
appropriate action as per the policy of the running system.
Reported-by: Heinrich Schuchardt
Signed-off-by: Christoffer Dall
---
Do
7;s memory map, or if this
appeared to be an attempt at doing MMIO.
Signed-off-by: Christoffer Dall
---
arm/kvm-cpu.c | 20 +++-
arm/kvm.c | 8
include/kvm/kvm.h | 1 +
kvm.c | 1 +
mmio.c| 11 +++
5 files changed, 40 insert
. The kernel already has functionality to inject an
external abort, but we need to wire up a signal from user space that
lets user space tell the kernel to do this.
It turns out, we already have the set event functionality which we can
perfectly reuse for this.
Signed-off-by: Christoffer Dall
On Fri, Sep 06, 2019 at 02:31:42PM +0100, Peter Maydell wrote:
> On Fri, 6 Sep 2019 at 14:13, Christoffer Dall
> wrote:
> > I'd prefer leaving it to userspace to worry about, but I thought Peter
> > said that had been problematic historically, which I took at face valu
On Fri, Sep 06, 2019 at 02:08:15PM +0200, Alexander Graf wrote:
>
>
> On 06.09.19 10:00, Christoffer Dall wrote:
> > On Thu, Sep 05, 2019 at 02:09:18PM +0100, Marc Zyngier wrote:
> > > On 05/09/2019 10:22, Christoffer Dall wrote:
> > > > On Thu, Sep 05, 201
On Thu, Sep 05, 2019 at 02:09:18PM +0100, Marc Zyngier wrote:
> On 05/09/2019 10:22, Christoffer Dall wrote:
> > On Thu, Sep 05, 2019 at 09:56:44AM +0100, Peter Maydell wrote:
> >> On Thu, 5 Sep 2019 at 09:52, Marc Zyngier wrote:
> >>>
> >>> On Thu, 05 Se
On Thu, Sep 05, 2019 at 03:25:47PM +0200, Heinrich Schuchardt wrote:
> On 9/5/19 11:22 AM, Christoffer Dall wrote:
> > On Thu, Sep 05, 2019 at 09:56:44AM +0100, Peter Maydell wrote:
> > > On Thu, 5 Sep 2019 at 09:52, Marc Zyngier wrote:
> > > >
> > &g
Hi Heinrich,
On Thu, Sep 05, 2019 at 02:01:36PM +0200, Heinrich Schuchardt wrote:
> On 9/5/19 11:20 AM, Stefan Hajnoczi wrote:
> > On Wed, Sep 04, 2019 at 08:07:36PM +0200, Heinrich Schuchardt wrote:
> > > If an application tries to access memory that is not mapped, an error
> > > ENOSYS, "load/st
On Thu, Sep 05, 2019 at 09:56:44AM +0100, Peter Maydell wrote:
> On Thu, 5 Sep 2019 at 09:52, Marc Zyngier wrote:
> >
> > On Thu, 05 Sep 2019 09:16:54 +0100,
> > Peter Maydell wrote:
> > > This is true, but the problem is that barfing out to userspace
> > > makes it harder to debug the guest beca
On Thu, Sep 05, 2019 at 09:16:54AM +0100, Peter Maydell wrote:
> On Thu, 5 Sep 2019 at 09:04, Marc Zyngier wrote:
> > How can you tell that the access would fault? You have no idea at that
> > stage (the kernel doesn't know about the MMIO ranges that userspace
> > handles). All you know is that yo
y existing static keys. One of the instances becomes
> cpus_have_const_cap(), and the rest is a light sprinkling of
> has_vhe().
>
> So off it goes.
I'm not sure I want to kiss hyp_alternate_select() at all, but away it
must go!
Reviewed-by: Christoffer Dall
On Fri, Aug 30, 2019 at 09:42:50AM +0100, Steven Price wrote:
> Implement the service call for configuring a shared structure between a
> VCPU and the hypervisor in which the hypervisor can write the time
> stolen from the VCPU's execution time by other tasks on the host.
>
> The hypervisor alloca
On Wed, Aug 28, 2019 at 01:09:15PM +0100, Steven Price wrote:
> On 27/08/2019 09:57, Christoffer Dall wrote:
> > On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
> >> Introduce a paravirtualization interface for KVM/arm64 based on the
> >> "Arm P
On Tue, Aug 27, 2019 at 10:57:06AM +0200, Christoffer Dall wrote:
> On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
> > Introduce a paravirtualization interface for KVM/arm64 based on the
> > "Arm Paravirtualized Time for Arm-Base Systems" specification DEN
On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
> Introduce a paravirtualization interface for KVM/arm64 based on the
> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>
> This only adds the details about "Stolen Time" as the details of "Live
> Physical Time"
On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
> Introduce a paravirtualization interface for KVM/arm64 based on the
> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>
> This only adds the details about "Stolen Time" as the details of "Live
> Physical Time"
On Wed, Jul 31, 2019 at 10:17:53AM +0200, Jan Kiszka wrote:
> On 30.06.19 17:19, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > The only difference between the currently supported A15 and A7 target
> > cores is the reset state of bit 11 in SCTLR. This bit is RES1 or RAO/WI
> > in other ARM cores,
Hi Jan,
On Sun, Jun 30, 2019 at 12:18:59PM +0200, Jan Kiszka wrote:
> On 30.06.19 11:34, Jan Kiszka wrote:
> >On 30.06.19 00:42, Marc Zyngier wrote:
> >>On Sat, 29 Jun 2019 19:09:37 +0200
> >>Jan Kiszka wrote:
> >>>However, as the Raspberry kernel is not yet ready for 64-bit (and
> >>>upstream is
On Sat, Jun 22, 2019 at 03:11:36PM -0400, Andrea Arcangeli wrote:
> Hello Christoffer,
>
> On Tue, Jun 11, 2019 at 01:51:32PM +0200, Christoffer Dall wrote:
> > Sorry, what does this mean? Do you mean that we can either do:
> >
> > on_vm_s2_fau
On Thu, Jun 13, 2019 at 11:01:41AM +0100, Marc Zyngier wrote:
> On Mon, 03 Jun 2019 13:14:40 +0100,
> Andrew Jones wrote:
> >
> > On Wed, May 29, 2019 at 12:03:11PM +0200, Christoffer Dall wrote:
> > > On Wed, May 29, 2019 at 10:13:21AM +0100, Marc Zyngier wrote:
On Sun, Jun 09, 2019 at 01:40:24PM -0400, Andrea Arcangeli wrote:
> Hello,
>
> On Sun, Jun 09, 2019 at 11:37:19AM +0200, Paolo Bonzini wrote:
> > On 09/06/19 10:18, Christoffer Dall wrote:
> > > In some sense, we are thus maintaining a 'hidden', or internal,
>
On Sun, Jun 09, 2019 at 11:37:19AM +0200, Paolo Bonzini wrote:
> On 09/06/19 10:18, Christoffer Dall wrote:
> > In some sense, we are thus maintaining a 'hidden', or internal,
> > reference to the page, which is not counted anywhere.
> >
> > I am wondering i
Hi,
I have been looking at how we deal with page_count(page) on pages held
in stage 2 page tables on KVM/arm64.
What we do currently is to drop the reference on the page we get from
get_user_pages() once the page is inserted into our stage 2 page table,
typically leaving page_count(page) == page_
Introduce KVM_ARCH_WANT_MMU_MEMCACHE to avoid compile breakage on
architectures that don't use this functionality.
- Rename KVM_NR_MEM_OBJS to KVM_MMU_NR_MEMCACHE_OBJS
Christoffer Dall (4):
KVM: x86: Move mmu_memory_cache functions to common code
KVM: x86: Rename mmu_memory_cache to kvm_mmu
he to memcache to avoid overly long lines.
This is a bit tedious on the callsites but ends up looking more
palatable.
Signed-off-by: Christoffer Dall
---
arch/x86/include/asm/kvm_host.h | 6 ++---
arch/x86/include/asm/kvm_types.h | 4 ++--
arch/x86/kvm/mmu.c
Now that we have a common infrastructure for doing MMU cache
allocations, use this for mips as well.
Signed-off-by: Christoffer Dall
---
arch/mips/include/asm/kvm_host.h | 15 ++---
arch/mips/include/asm/kvm_types.h | 6
arch/mips/kvm/mips.c | 2 +-
arch/mips/kvm/mmu.c
architectures
require the mmu memory cache.
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_types.h | 5 +++
arch/arm64/include/asm/kvm_types.h | 6 +++
arch/mips/include/asm/kvm_types.h| 5 +++
arch/powerpc/include/asm/kvm_types.h | 5 +++
arch/s390/include/asm
avior.
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_host.h| 13 +-
arch/arm/include/asm/kvm_mmu.h | 2 +-
arch/arm/include/asm/kvm_types.h | 6 +++
arch/arm64/include/asm/kvm_host.h | 13 +-
arch/arm64/include/asm/kvm_mmu.h | 2 +-
arch/arm64/include/asm/kvm_ty
On Wed, May 29, 2019 at 10:13:21AM +0100, Marc Zyngier wrote:
> On 29/05/2019 10:08, Christoffer Dall wrote:
> > On Tue, May 28, 2019 at 05:08:53PM +0100, Marc Zyngier wrote:
> >> On 28/05/2019 14:40, Andrew Jones wrote:
> >>> On Tue, May 28, 2019 at 03:12:15PM
On Tue, May 28, 2019 at 05:08:53PM +0100, Marc Zyngier wrote:
> On 28/05/2019 14:40, Andrew Jones wrote:
> > On Tue, May 28, 2019 at 03:12:15PM +0200, Christoffer Dall wrote:
> >> On Tue, May 28, 2019 at 01:25:52PM +0100, Marc Zyngier wrote:
> >>> On 28/05/2019
On Tue, May 28, 2019 at 01:25:52PM +0100, Marc Zyngier wrote:
> On 28/05/2019 12:01, Christoffer Dall wrote:
> > On Mon, May 27, 2019 at 01:46:19PM +0200, Andrew Jones wrote:
> >> The emulated ptimer needs to track the level changes, otherwise the
> >> the interrup
On Mon, May 27, 2019 at 01:46:19PM +0200, Andrew Jones wrote:
> The emulated ptimer needs to track the level changes, otherwise the
> the interrupt will never get deasserted, resulting in the guest getting
> stuck in an interrupt storm if it enables ptimer interrupts. This was
> found with kvm-unit
umbia
web page, as that information is no longer up to date and I don't know
who manages that anymore.
Signed-off-by: Christoffer Dall
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5cfbea4ce575..4ba271a8e0ef 100644
--- a/MAINTAINERS
+++ b/M
Hi Steve,
On Wed, Mar 13, 2019 at 10:11:30AM +, Steven Price wrote:
>
> Personally I think what we need is:
>
> * Either a patch like the one from Heyi Guo (save/restore CNTVCT_EL0) or
> alternatively hooking up KVM_KVMCLOCK_CTRL to prevent the watchdog
> firing when user space explicitly st
Hi Jan,
On Thu, Mar 14, 2019 at 12:19:02PM +, Jan Bolke wrote:
> Hi all,
>
> Currently I am working on a SystemC integration of kvm on arm.
> Therefore, I use the kvm api and of course SystemC (library to simulate
> hardware platforms with C++).
>
> As I need the virtual cpu to interrupt it
[Adding Steven Price, who has recently looked at this, in cc]
On Tue, Mar 12, 2019 at 10:08:47AM +, Peter Maydell wrote:
> On Tue, 12 Mar 2019 at 06:10, Heyi Guo wrote:
> >
> > When we stop a VM for more than 30 seconds and then resume it, by qemu
> > monitor command "stop" and "cont", Linux
On Tue, Mar 05, 2019 at 11:45:52AM +, Andrew Murray wrote:
> On Mon, Mar 04, 2019 at 11:14:24AM +, Andrew Murray wrote:
> > On Tue, Feb 26, 2019 at 01:44:59PM +0100, Christoffer Dall wrote:
> > > On Wed, Feb 20, 2019 at 04:15:40PM +, Andrew Murray wrote:
> > >
On Wed, Feb 20, 2019 at 04:15:40PM +, Andrew Murray wrote:
> On Mon, Feb 18, 2019 at 10:53:07PM +0100, Christoffer Dall wrote:
> > On Mon, Jan 14, 2019 at 04:11:47PM +, Andrew Murray wrote:
> > > Add support for the :G and :H attributes in perf by handling the
On Wed, Feb 20, 2019 at 07:14:53PM +, Dave Martin wrote:
> On Fri, Jan 25, 2019 at 10:46:52AM +0100, Christoffer Dall wrote:
> > Resetting the VCPU state modifies the system register state in memory,
> > but this may interact with vcpu_load/vcpu_put if running with preempti
On Tue, Feb 19, 2019 at 11:39:50AM +, Alexandru Elisei wrote:
>
> On 1/24/19 2:00 PM, Christoffer Dall wrote:
> > VHE systems don't have to emulate the physical timer, we can simply
> > assigne the EL1 physical timer directly to the VM as the host always
> > us
On Mon, Feb 18, 2019 at 03:10:49PM +, André Przywara wrote:
> On Thu, 24 Jan 2019 15:00:30 +0100
> Christoffer Dall wrote:
>
> Hi,
>
> > VHE systems don't have to emulate the physical timer, we can simply
> > assigne the EL1 physical timer directly to the VM
On Mon, Feb 18, 2019 at 03:10:16PM +, André Przywara wrote:
> On Thu, 24 Jan 2019 15:00:29 +0100
> Christoffer Dall wrote:
>
> Hi,
>
> I already looked at most of these patches earlier, without finding
> serious issues, but figured I would give those without any Revie
1 - 100 of 3909 matches
Mail list logo
