On 31/03/21 23:22, Sean Christopherson wrote:
On a related topic, any preference on whether to have an explicit "must_lock"
flag (what I posted), or derive the logic based on other params?
The helper I posted does:
if (range->must_lock &&
kvm_mmu_lock_and_check_handler(kvm,
On 31/03/21 23:05, Sean Christopherson wrote:
Wouldn't it be incorrect to lock a mutex (e.g. inside*another* MMU
notifier's invalidate callback) while holding an rwlock_t? That makes sense
because anybody that's busy waiting in write_lock potentially cannot be
preempted until the other task
On 31/03/21 22:52, Sean Christopherson wrote:
100% agree with introducing on_lock separately from the conditional locking.
Not so sure about introducing conditional locking and then converting non-x86
archs. I'd prefer to keep the conditional locking after arch conversion.
If something does go
On 31/03/21 21:47, Sean Christopherson wrote:
Rereading things, a small chunk of the rwsem nastiness can go away. I don't see
any reason to use rw_semaphore instead of rwlock_t.
Wouldn't it be incorrect to lock a mutex (e.g. inside *another* MMU
notifier's invalidate callback) while holding
On 31/03/21 22:15, Sean Christopherson wrote:
On Wed, Mar 31, 2021, Paolo Bonzini wrote:
On 26/03/21 03:19, Sean Christopherson wrote:
+ /*
+* Reset the lock used to prevent memslot updates between MMU notifier
+* range_start and range_end. At this point no more MMU
On Wed, Mar 31, 2021 at 11:41:20AM +0100, Steven Price wrote:
> On 31/03/2021 10:32, David Hildenbrand wrote:
> > On 31.03.21 11:21, Catalin Marinas wrote:
> > > On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
> > > > On 30.03.21 12:30, Catalin Marinas wrote:
> > > > > On Mon,
gen-hyprel tool parses object files of the EL2 portion of KVM
and generates runtime relocation data. While only filtering for
R_AARCH64_ABS64 relocations in the input object files, it has an
allow-list of relocation types that are used for relative
addressing. Other, unexpected, relocation types
On 31/03/21 18:41, Sean Christopherson wrote:
That said, the easiest way to avoid this would be to always update
mmu_notifier_count.
Updating mmu_notifier_count requires taking mmu_lock, which would defeat the
purpose of these shenanigans.
Okay; I wasn't sure if the problem was contention
On 31/03/21 18:20, Sean Christopherson wrote:
Every call
to .change_pte() is bookended by .invalidate_range_{start,end}(), i.e. the above
missing kvm->mmu_notifier_seq++ is benign because kvm->mmu_notifier_count is
guaranteed to be non-zero.
In fact ARM even relies on invalidate wrapping the
On Wed, 31 Mar 2021 16:25:46 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 3/30/21 9:07 PM, Marc Zyngier wrote:
[...]
> > I think it would be absolutely fine to make the slow path of
> > kvm_vcpu_first_run_init() run with preempt disabled. This happens so
> > rarely that that it isn't
Hi Marc,
On 3/30/21 9:07 PM, Marc Zyngier wrote:
> On Tue, 30 Mar 2021 18:13:07 +0100,
> Alexandru Elisei wrote:
>> Hi Marc,
>>
>> Thanks for having a look!
>>
>> On 3/30/21 10:55 AM, Marc Zyngier wrote:
>>> Hi Alex,
>>>
>>> On Tue, 23 Mar 2021 18:00:57 +,
>>> Alexandru Elisei wrote:
Hi Drew,
On 3/22/21 7:32 PM, Andrew Jones wrote:
> On Fri, Mar 12, 2021 at 06:32:02PM +0100, Eric Auger wrote:
>> The tests exercise the VGIC_V3 device creation including the
>> associated KVM_DEV_ARM_VGIC_GRP_ADDR group attributes:
>>
>> - KVM_VGIC_V3_ADDR_TYPE_DIST/REDIST
>> -
On 31.03.21 12:41, Steven Price wrote:
On 31/03/2021 10:32, David Hildenbrand wrote:
On 31.03.21 11:21, Catalin Marinas wrote:
On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
On 30.03.21 12:30, Catalin Marinas wrote:
On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price
On Wed, 31 Mar 2021 13:30:48 +, David Brazdil wrote:
> gen-hyprel tool parses object files of the EL2 portion of KVM
> and generates runtime relocation data. While only filtering for
> R_AARCH64_ABS64 relocations in the input object files, it has an
> allow-list of relocation types that are
Hi Marc,
On 3/31/21 2:16 PM, Marc Zyngier wrote:
> Julien's bandwidth for KVM reviewing has been pretty low lately,
> and Alexandru has accepted to step in and help with the reviewing.
>
> Many thanks to both!
Happy to help!
Acked-by: Alexandru Elisei
Thanks,
Alex
>
> Cc: Julien Thierry
>
Julien's bandwidth for KVM reviewing has been pretty low lately,
and Alexandru has accepted to step in and help with the reviewing.
Many thanks to both!
Cc: Julien Thierry
Cc: Alexandru Elisei
Signed-off-by: Marc Zyngier
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi Marc,
On 3/30/21 8:57 PM, Marc Zyngier wrote:
> On Tue, 30 Mar 2021 18:49:54 +0100,
> Alexandru Elisei wrote:
>> Hi Marc,
>>
>> On 3/30/21 6:13 PM, Alexandru Elisei wrote:
>>> [..]
> +}
> +
> /**
> * kvm_arm_reset_debug_ptr - reset the debug ptr to point to the vcpu
>
On 31/03/2021 10:32, David Hildenbrand wrote:
On 31.03.21 11:21, Catalin Marinas wrote:
On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
On 30.03.21 12:30, Catalin Marinas wrote:
On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
On 28/03/2021 13:21, Catalin
On 30/03/2021 11:13, Catalin Marinas wrote:
On Mon, Mar 29, 2021 at 04:55:29PM +0100, Steven Price wrote:
On 26/03/2021 18:56, Catalin Marinas wrote:
On Fri, Mar 12, 2021 at 03:18:57PM +, Steven Price wrote:
A KVM guest could store tags in a page even if the VMM hasn't mapped
the page
On Wed, 31 Mar 2021 at 09:59, Zenghui Yu wrote:
>
> [+kvmarm, Marc]
>
> On 2021/3/12 0:59, Peter Maydell wrote:
> > Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
> > means that we don't provide the 6 counters that are required by the
> > Arm BSA (Base System Architecture)
On 31/03/21 11:34, Marc Zyngier wrote:
Queued and 1-9 and 18, thanks. There's a small issue in patch 10 that
prevented me from committing 10-15, but they mostly look good.
Can you please push the resulting merge somewhere?
I'm concerned that it will conflict in interesting way with other
The sparse tool complains as follows:
arch/arm64/kvm/arm.c:1900:6: warning:
symbol '_kvm_host_prot_finalize' was not declared. Should it be static?
This symbol is not used outside of arm.c, so this
commit marks it static.
Reported-by: Hulk Robot
Signed-off-by: Xu Jia
---
On 2021-03-31 08:57, Paolo Bonzini wrote:
Queued and 1-9 and 18, thanks. There's a small issue in patch 10 that
prevented me from committing 10-15, but they mostly look good.
Can you please push the resulting merge somewhere?
I'm concerned that it will conflict in interesting way with other
On 31.03.21 11:21, Catalin Marinas wrote:
On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
On 30.03.21 12:30, Catalin Marinas wrote:
On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
On 28/03/2021 13:21, Catalin Marinas wrote:
On Sat, Mar 27, 2021 at 03:23:24PM
On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
> On 30.03.21 12:30, Catalin Marinas wrote:
> > On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
> > > On 28/03/2021 13:21, Catalin Marinas wrote:
> > > > On Sat, Mar 27, 2021 at 03:23:24PM +, Catalin Marinas
Kind ping...
On 2021/3/16 21:43, Keqian Zhu wrote:
> Hi all,
>
> We have two pathes to build stage2 mapping for MMIO regions.
>
> Create time's path and stage2 fault path.
>
> Patch#1 removes the creation time's mapping of MMIO regions
> Patch#2 tries stage2 block mapping for host device MMIO
[+kvmarm, Marc]
On 2021/3/12 0:59, Peter Maydell wrote:
Currently we give all the v7-and-up CPUs a PMU with 4 counters. This
means that we don't provide the 6 counters that are required by the
Arm BSA (Base System Architecture) specification if the CPU supports
the Virtualization extensions.
On 26/03/21 03:19, Sean Christopherson wrote:
+ /*
+* Reset the lock used to prevent memslot updates between MMU notifier
+* range_start and range_end. At this point no more MMU notifiers will
+* run, but the lock could still be held if KVM's notifier was removed
+
On Wed, 31 Mar 2021 15:36:19 +0800, Xu Jia wrote:
> The sparse tool complains as follows:
>
> arch/arm64/kvm/arm.c:1900:6: warning:
> symbol '_kvm_host_prot_finalize' was not declared. Should it be static?
>
> This symbol is not used outside of arm.c, so this
> commit marks it static.
Applied
On 26/03/21 03:19, Sean Christopherson wrote:
The end goal of this series is to optimize the MMU notifiers to take
mmu_lock if and only if the notification is relevant to KVM, i.e. the hva
range overlaps a memslot. Large VMs (hundreds of vCPUs) are very
sensitive to mmu_lock being taken for
On 26/03/21 03:19, Sean Christopherson wrote:
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+ kvm_handle_hva_range(mn, address, address + 1, pte, kvm_set_spte_gfn);
+#else
struct kvm *kvm = mmu_notifier_to_kvm(mn);
int idx;
trace_kvm_set_spte_hva(address);
idx =
On 26/03/21 03:19, Sean Christopherson wrote:
Avoid taking mmu_lock for unrelated .invalidate_range_{start,end}()
notifications. Because mmu_notifier_count must be modified while holding
mmu_lock for write, and must always be paired across start->end to stay
balanced, lock elision must happen
On 26/03/21 03:19, Sean Christopherson wrote:
Move MIPS to the gfn-based MMU notifier APIs, which do the hva->gfn
lookup in common code, and whose code is nearly identical to MIPS'
lookup.
No meaningful functional change intended, though the exact order of
operations is slightly different since
On 30.03.21 12:30, Catalin Marinas wrote:
On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
On 28/03/2021 13:21, Catalin Marinas wrote:
On Sat, Mar 27, 2021 at 03:23:24PM +, Catalin Marinas wrote:
On Fri, Mar 12, 2021 at 03:18:58PM +, Steven Price wrote:
diff --git
34 matches
Mail list logo
