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 20:32, Ben Gardon wrote:
Patches 1-7 are x86 specific prep patches to play nice with moving
the hva->gfn memslot lookups into common code. There ended up being waaay
more of these than I expected/wanted, but I had a hell of a time getting
the flushing logic right when shuffling the
On 25/03/21 12:44, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-fixes-5.12-3
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 15/03/21 23:31, Jing Zhang wrote:
We are considering about how to create the file descriptor. It might be risky
to create an extra fd for every vCPU. It will easily hit the fd limit for the
process or the system for machines running a ton of small VMs.
You already have a file descriptor for
On 12/03/21 23:27, Jing Zhang wrote:
4 bytes flags (always zero)
Could you give some potential use for this flag?
No idea, honestly. It probably would signal the presence of more fields
after "offset of the first stat value". In general it's better to leave
some room for extension.
4
On 12/03/21 17:00, Marc Zyngier wrote:
Hi Paolo,
Here's the second batch of KVM/arm64 fixes for 5.12. The most notable
item is the tidying up of the way we deal with the guest physical
space, which had a couple of warts. The other patches address i-cache
isolation between vcpus (they are
On 10/03/21 22:41, Jing Zhang wrote:
I would prefer a completely different interface, where you have a file
descriptor that can be created and associated to a vCPU or VM (or even
to /dev/kvm). Having a file descriptor is important because the fd can
be passed to a less-privileged process that
On 10/03/21 18:31, Marc Zyngier wrote:
Maintaining VM-global counters would require an atomic instruction and
would suffer lots of cacheline bouncing even on architectures that
have relaxed atomic memory operations.
Which is why we have per-cpu counters already. Making use of them
doesn't seem
On 10/03/21 18:05, Marc Zyngier wrote:
On Wed, 10 Mar 2021 16:03:42 +,
Paolo Bonzini wrote:
On 10/03/21 16:51, Marc Zyngier wrote:
+ kvm_for_each_vcpu(j, vcpu, kvm) {
+ pdata = data + VM_STAT_COUNT;
+ for (i = 0; i < VCPU_STAT_COUNT; i++, pd
On 10/03/21 16:51, Marc Zyngier wrote:
+ kvm_for_each_vcpu(j, vcpu, kvm) {
+ pdata = data + VM_STAT_COUNT;
+ for (i = 0; i < VCPU_STAT_COUNT; i++, pdata++)
+ *pdata += *((u64 *)>stat + i);
Do you really need the in-kernel copy? Why not
On 10/03/21 01:30, Jing Zhang wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 383df23514b9..87dd62516c8b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3464,6 +3464,51 @@ static long kvm_vcpu_ioctl(struct file *filp,
r =
On 05/03/21 19:52, Marc Zyngier wrote:
Hi Paolo,
Here's the first batch of fixes for 5.12. We have a handful of low
level world-switch regressions, a page table walker fix, more PMU
tidying up, and a workaround for systems with creative firmware.
This will need to go on top of the current
On 05/03/21 17:49, Marc Zyngier wrote:
Hi Paolo,
Here's the first batch of fixes for 5.12. We have a handful of low
level world-switch regressions, a page table walker fix, more PMU
tidying up, and a workaround for systems with creative firmware.
Note that this is based on -rc1 despite the
On 22/02/21 03:45, David Stevens wrote:
These patches reduce how often mmu_notifier updates block guest page
faults. The primary benefit of this is the reduction in the likelihood
of extreme latency when handling a page fault due to another thread
having been preempted while modifying host
On 12/02/21 15:36, Marc Zyngier wrote:
Hi Paolo,
Here's the initial set of KVM/arm64 updates for 5.11.
The most notable change this time is David's work to finally build the
nVHE EL2 object as a relocatable object. This makes the code a lot
cleaner, more reliable (we don't have to assume
On 28/01/21 18:58, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-fixes-5.11-3
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 28/01/21 07:05, David Stevens wrote:
These patches reduce how often mmu_notifier updates block guest page
faults. The primary benefit of this is the reduction in the likelihood
of extreme latency when handling a page fault due to another thread
having been preempted while modifying host
On 08/01/21 09:22, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-fixes-5.11-1
Looks like there are issues with the upstream changes brought in by
this pull request. Unless my bisection is quick tomorrow it may not
make it into 5.11-rc3.
On 07/01/21 12:20, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-fixes-5.11-1
Looks like there are issues with the upstream changes brought in by this
pull request. Unless my bisection is quick tomorrow it may not make it
into 5.11-rc3.
On 07/01/21 12:20, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-fixes-5.11-1
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 14/12/20 18:48, Marc Zyngier wrote:
Hi Paolo,
Here's the initial set of KVM/arm64 updates for 5.11. The most notable
change is the "PSCI relay" at EL2, which is the first "user visible"
feature required by the Protected KVM effort. The rest is a mixed bag
of architecture compliance (PMU
On 04/12/20 19:19, Marc Zyngier wrote:
Hi Paolo,
A week ago, I was hoping being done with the 5.10 fixes. I should
obviously know better.
Thanks to Yanan's excellent work, we have another set of page table
fixes, all plugging issues introduced with our new page table code.
The problems range
On 16/11/20 14:22, Zenghui Yu wrote:
It makes no sense to track dirty pages for those un-migratable memory
regions (e.g., Memory BAR region of the VFIO PCI device) and doing so
will potentially lead to some unpleasant issues during migration [1].
Skip dirty tracking for those regions by
On 15/11/20 15:31, Zenghui Yu wrote:
diff --git a/softmmu/memory.c b/softmmu/memory.c
index 71951fe4dc..0958db1a08 100644
--- a/softmmu/memory.c
+++ b/softmmu/memory.c
@@ -1806,7 +1806,10 @@ bool memory_region_is_ram_device(MemoryRegion *mr)
uint8_t
On 12/11/20 23:21, Marc Zyngier wrote:
We now expose ID_AA64PFR0_EL1.CSV2=1 to guests running on hosts
that are immune to Spectre-v2, but that don't have this field set,
most likely because they predate the specification.
However, this prevents the migration of guests that have started on
a
On 06/11/20 17:44, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-fixes-5.10-2
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 30/10/20 17:40, Marc Zyngier wrote:
> Hi Paolo,
>
> It was good to see you (and everyone else) at KVM Forum this week!
>
> And to celebrate, here's a first batch of fixes for KVM/arm64. A bunch
> of them are addressing issues introduced by the invasive changes that
> took place in the 5.10
On 23/10/20 18:54, James Morse wrote:
> SDEI gives you an NMI ... which you use to set a TIF flag. This can only work
> reliably for
> user-space. So much so that you have code in the hypervisor to only deliver
> the NMI ...
> when in user-space.
> The only reason you would need an NMI is to
On 18/09/20 19:16, Marc Zyngier wrote:
> Hi Paolo,
>
> Here's the latest set of fixes for 5.9. The first patch is pretty
> nasty, as a guest hitting this bug will have its vcpu stuck on a
> fault, without any hope of it being resolved. Embarrassing, and
> definitely a stable candidate. The second
On 09/09/20 19:15, Marc Zyngier wrote:
> On 2020-09-09 16:20, Paolo Bonzini wrote:
>> On 04/09/20 12:45, Marc Zyngier wrote:
>>> Hi Paolo,
>>>
>>> Here's a bunch of fixes for 5.9. The gist of it is the stolen time
>>> rework from Andrew, but we also hav
On 04/09/20 12:45, Marc Zyngier wrote:
> Hi Paolo,
>
> Here's a bunch of fixes for 5.9. The gist of it is the stolen time
> rework from Andrew, but we also have a couple of MM fixes that have
> surfaced as people have started to use hugetlbfs in anger.
Hi Marc,
I'll get to this next Friday.
On 18/08/20 12:16, Will Deacon wrote:
> Please note that I'm planning on rewriting most of the arm64 KVM page-table
> code for 5.10, so if you can get this series in early (e.g. for -rc2), then
> it would _really_ help with managing the kvm/arm64 queue for the next merge
> window.
Yes, I plan to
rmitted.
>
> Cheers,
>
> Will
>
> [1] https://android-kvm.googlesource.com/linux/+/refs/heads/topic/pgtable
>
> Cc: Marc Zyngier
> Cc: Suzuki K Poulose
> Cc: James Morse
> Cc: Thomas Bogendoerfer
> Cc: Paul Mackerras
> Cc: Paolo Bonzini
> Cc: Sean
On 05/08/20 19:56, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
> tags/kvmarm-5.9
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 05/08/20 19:56, Marc Zyngier wrote:
> Hi Paolo,
>
> This is the bulk of the 5.9 patches for KVM/arm64. It is a pretty busy
> merge window for us this time, thanks to the ongoing Protected KVM
> work. We have changes all over the map, but the most important piece
> probably is the way we now
On 28/07/20 10:22, Marc Zyngier wrote:
> Hi Paolo,
>
> This is the last batch of fixes for 5.8. One fixes a long standing MMU
> issue, while the other addresses a more recent brekage with out-of-line
> helpers in the nVHE code.
>
> Please pull,
>
> M.
>
> The following changes since
On 31/07/20 08:39, Zhenyu Ye wrote:
> On 2020/7/31 2:03, Paolo Bonzini wrote:
>> Yes, I think it's not needed. Probably the deassign check can be turned into
>> an assertion?
>>
>> Paolo
>>
>
> I think we can do this in the same function, and turnt
Yes, I think it's not needed. Probably the deassign check can be turned
into an assertion?
Paolo
Il gio 30 lug 2020, 16:36 Zhenyu Ye ha scritto:
> Hi all,
>
> There are checks of ioeventfd collision in both kvm_assign_ioeventfd_idx()
> and kvm_deassign_ioeventfd_idx(), however, with different
On 28/07/20 14:17, Andrew Jones wrote:
> GCC 10.1.0 introduced the -moutline-atomics option which, when
> enabled, use LSE instructions when the processor provides them.
> The option is enabled by default and unfortunately causes the
> following error at compile time:
>
> aarch64-linux-gnu-ld:
On 27/07/20 14:30, Andrew Jones wrote:
>>> Looks much better than my version. Do you want me to spin a v2 or do you
>>> want to
>>> send it as a separate patch? If that's the case, I tested the same way I
>>> did my
>>> patch (gcc 10.1.0 and 5.4.0 for cross-compiling, 9.3.0 native):
>>>
>>>
On 10/07/20 09:32, Tianjia Zhang wrote:
> Hi Paolo,
>
> Any opinion on this series patches? Can I help with this patchset ?
I was hoping to have some Tested-by, for now I'm queuing patches 1 and
2. Thanks,
Paolo
> Thanks and best,
> Tianjia
>
> On 2020/6/23 21:14, Tianjia Zhang wrote:
>> In
On 23/06/20 15:14, Tianjia Zhang wrote:
>
> /* Load non-volatile guest state from the vcpu */
> - VCPU_LOAD_NVGPRS(r4)
> + VCPU_LOAD_NVGPRS(r3)
>
> kvm_start_lightweight:
> /* Copy registers into shadow vcpu so we can access them in real mode */
> - mr r3, r4
>
On 23/06/20 17:31, Christian Borntraeger wrote:
>
> I have trouble seeing value in this particular patch. We add LOCs
> without providing any noticable benefit. All other patches in this series at
> least reduce the amount of code. So I would defer this to Paolo if he prefers
> to have this way
On 03/07/20 04:35, Sean Christopherson wrote:
> The only interesting delta from v2 is that patch 18 is updated to handle
> a conflict with arm64's p4d rework. Resolution was straightforward
> (famous last words).
>
>
> This series resurrects Christoffer Dall's series[1] to provide a common
>
On 06/07/20 13:05, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
> tags/kvmarm-fixes-5.8-3
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 29/06/20 18:25, Marc Zyngier wrote:
> Hi Paolo,
>
> Here's another pull request for a handful of KVM/arm64 fixes. Nothing
> absolutely critical (see the tag for the gory details), but I'd rather
> get these merged as soon as possible.
>
> Please pull,
>
> M.
>
> The following changes
On 23/06/20 12:00, Tianjia Zhang wrote:
>
>
> On 2020/6/23 17:42, Paolo Bonzini wrote:
>> On 27/04/20 06:35, Tianjia Zhang wrote:
>>> In the current kvm version, 'kvm_run' has been included in the
>>> 'kvm_vcpu'
>>> structure. For historical rea
On 27/04/20 06:35, Tianjia Zhang wrote:
> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> structure. For historical reasons, many kvm-related function parameters
> retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This
> patch does a unified cleanup of
On 11/06/20 11:09, Marc Zyngier wrote:
> Hi Paolo,
>
> Here's a bunch of fixes that cropped up during the merge window,
> mostly falling into two categories: 32bit system register accesses,
> and 64bit pointer authentication handling.
>
> Please pull,
>
> M.
>
> The following changes
On 31/05/20 14:44, Marc Zyngier wrote:
>>
>> Is there an ARM-approved way to reuse the S2 fault syndromes to detect
>> async page faults?
>
> It would mean being able to set an ESR_EL2 register value into ESR_EL1,
> and there is nothing in the architecture that would allow that,
I understand
On 29/05/20 18:00, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
> tags/kvmarm-5.8
Pulled, thanks (to kvm/queue only for now).
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 29/05/20 11:41, Marc Zyngier wrote:
>>>
>>>
>>> For x86 the advantage is that the processor can take care of raising the
>>> stage2 page fault in the guest, so it's faster.
>>>
>> I think there might be too much overhead if the page can be populated
>> quickly by host. For example, it's fast to
On 27/05/20 08:24, Tianjia Zhang wrote:
>>>
>>>
>
> Hi Huacai,
>
> These two patches(6/7 and 7/7) should be merged into the tree of the
> mips architecture separately. At present, there seems to be no good way
> to merge the whole architecture patchs.
>
> For this series of patches, some
On 28/05/20 09:03, Marc Zyngier wrote:
> The current state of the architecture doesn't seem to leave much leeway in
> terms of SW creativity here. You just can't allocate your own ISS encoding
> without risking a clash with future revisions of the architecture.
> It isn't even clear whether the
On 28/05/20 08:14, Gavin Shan wrote:
>> - for x86 we're also thinking of initiating the page fault from the
>> exception handler, rather than doing so from the hypervisor before
>> injecting the exception. If ARM leads the way here, we would do our
>> best to share code when x86 does the same.
>
On 27/05/20 09:48, Marc Zyngier wrote:
>
> My own question is whether this even makes any sense 10 years later.
> The HW has massively changed, and this adds a whole lot of complexity
> to both the hypervisor and the guest.
It still makes sense, but indeed it's for different reasons. One
Hi Gavin,
I definitely appreciate the work, but this is repeating most of the
mistakes done in the x86 implementation. In particular:
- the page ready signal can be done as an interrupt, rather than an
exception. This is because "page ready" can be handled asynchronously,
in contrast to "page
On 18/05/20 13:34, Maxim Levitsky wrote:
>> In high-performance configurations, most of the time virtio devices are
>> processed in another thread that polls on the virtio rings. In this
>> setup, the rings are configured to not cause a vmexit at all; this has
>> much smaller latency than even a
On 18/05/20 10:45, Anastassios Nanos wrote:
> Being in the kernel saves us from doing unneccessary mode switches.
> Of course there are optimizations for handling I/O on QEMU/KVM VMs
> (virtio/vhost), but essentially what happens is removing mode-switches (and
> exits) for I/O operations -- is
On 04/05/20 18:51, Will Deacon wrote:
>> 10 days is one week during which I could hardly work and the two
>> adjacent weekends. So this is basically really bad timing in Marc's
>> first pull request, that he couldn't have anticipated.
>
> Understood, and thanks for the quick reply. If possible,
On 04/05/20 13:30, Will Deacon wrote:
> I don't see this queued up in the kvm tree, which appears to have been
> sitting dormant for 10 days. Consequently, there are fixes sitting in
> limbo and we /still/ don't have a sensible base for arm64/kvm patches
> targetting 5.8.
>
> Paolo -- how can I
I'm squashing this in to keep the changes compared to the current code minimal,
and queuing the series.
Thanks,
Paolo
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index bbefa2a7f950..feca3118b17f 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++
On 24/04/20 14:16, Dr. David Alan Gilbert wrote:
>>> I was trying to work out whether we need to migrate this state,
>>> and I'm not sure. Andrew, do you know? I think this comes down
>>> to "at what points in QEMU's kvm run loop can migration kick in",
>>> and specifically if we get a
On 23/04/20 11:19, Peter Zijlstra wrote:
>>
>> 1) Davidlohr, please post only patches 1-3 to "equalize" the swait and
>> rcuwait APIs.
>>
>> 2) Peter, please prepare a topic branch for those, or provide Acked-by
> I don't think I have anything that conflicts with this, so sure, take
> the whole
On 23/04/20 10:41, Marc Zyngier wrote:
>>
>> -if (swait_active(kvm_arch_vcpu_wq(vcpu)))
>> +if (rcu_dereference(kvm_arch_vpu_get_wait(vcpu)) != NULL)
> This doesn't compile (wrong function name, and rcu_dereference takes a
> variable). But whatever it would do if we fixed it looks dodgy.
vcore wait for powerpc kvm-hv.
>
> The x86 tscdeadline_latency test mentioned in 8577370fb0cb
> ("KVM: Use simple waitqueue for vcpu->wq") shows that, on avg,
> latency is reduced by around 15-20% with this change.
>
> Cc: Paul Mackerras
> Cc: kvmarm@lists.cs.co
On 21/04/20 20:07, Davidlohr Bueso wrote:
>>
>
> I should have looked closer here - I was thinking about the return
> value of rcuwait_wait_event. Yes, that signal_pending check you
> mention makes the sleep semantics change bogus as interruptible is no
> longer just to avoid contributing to the
On 20/04/20 23:50, Davidlohr Bueso wrote:
> On Mon, 20 Apr 2020, Paolo Bonzini wrote:
>
>> On 20/04/20 22:56, Davidlohr Bueso wrote:
>>> On Mon, 20 Apr 2020, Marc Zyngier wrote:
>>>
>>>> This looks like a change in the semantics of the tracepoint. Before
On 20/04/20 22:56, Davidlohr Bueso wrote:
> On Mon, 20 Apr 2020, Marc Zyngier wrote:
>
>> This looks like a change in the semantics of the tracepoint. Before this
>> change, 'waited' would have been true if the vcpu waited at all. Here,
>> you'd
>> have false if it has been interrupted by a
On 20/04/20 19:12, Marc Zyngier wrote:
>>
>>
>> - trace_kvm_vcpu_wakeup(block_ns, waited, vcpu_valid_wakeup(vcpu));
>> + trace_kvm_vcpu_wakeup(block_ns, !block_check,
>> vcpu_valid_wakeup(vcpu));
>
> This looks like a change in the semantics of the tracepoint. Before
> this change, 'waited'
On 16/04/20 17:09, Marc Zyngier wrote:
> On Wed, 15 Apr 2020 18:13:56 +0200
> Paolo Bonzini wrote:
>
>> On 13/04/20 14:20, Keqian Zhu wrote:
>>> There is already support of enabling dirty log graually in small chunks
>>> for x86 in commit 3c9bd4006bfc (&quo
On 16/04/20 07:10, Tianjia Zhang wrote:
> In earlier versions of kvm, 'kvm_run' is an independent structure
> and is not included in the vcpu structure. At present, 'kvm_run'
> is already included in the vcpu structure, so the parameter
> 'kvm_run' is redundant.
>
> This patch simplify the
On 13/04/20 14:20, Keqian Zhu wrote:
> There is already support of enabling dirty log graually in small chunks
> for x86 in commit 3c9bd4006bfc ("KVM: x86: enable dirty log gradually in
> small chunks"). This adds support for arm64.
>
> x86 still writes protect all huge pages when
On 15/04/20 11:07, Vitaly Kuznetsov wrote:
> In case this is no longer needed I'd suggest we drop 'kvm_run' parameter
> and extract it from 'struct kvm_vcpu' when needed. This looks like a
> natural add-on to your cleanup patch.
I agree, though I think it should be _instead_ of Tianjia's patch
On 14/04/20 23:12, Davidlohr Bueso wrote:
> On Wed, 25 Mar 2020, Paolo Bonzini wrote:
>
>> On 24/03/20 05:44, Davidlohr Bueso wrote:
>>> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
>>> index 71244bf87c3a..e049fcb3dffb 100644
>>> --- a/arch/
On 13/04/20 23:34, Philippe Mathieu-Daudé wrote:
>> +#define VM_STAT(x, ...) offsetof(struct kvm, stat.x), KVM_STAT_VM, ##
>> __VA_ARGS__
>> +#define VCPU_STAT(x, ...) offsetof(struct kvm_vcpu, stat.x), KVM_STAT_VCPU,
>> ## __VA_ARGS__
> I find this macro expanding into multiple fields odd...
On 04/04/20 16:36, Andrew Jones wrote:
> Hi Paolo,
>
> This pull request is a repost of an older request, plus it
> contains Eric's new PMU and ITS tests.
>
> Thanks,
> drew
>
>
> The following changes since commit ce27fa2c7cd4d07859a9a2e81c7ff641897818d1:
>
> x86: vmx: skip
On 31/03/20 14:16, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git kvmarm-5.7
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On 24/03/20 05:44, Davidlohr Bueso wrote:
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index 71244bf87c3a..e049fcb3dffb 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -290,8 +290,7 @@ static enum hrtimer_restart
> kvm_mips_comparecount_wakeup(struct hrtimer
On 23/03/20 13:27, Vitaly Kuznetsov wrote:
>> -kvm_x86_ops->check_nested_events = vmx_check_nested_events;
>> -kvm_x86_ops->get_nested_state = vmx_get_nested_state;
>> -kvm_x86_ops->set_nested_state = vmx_set_nested_state;
>> -kvm_x86_ops->get_vmcs12_pages =
On 23/03/20 17:24, Vitaly Kuznetsov wrote:
> Sounds cool! (not sure that with only two implementations people won't
> call it 'over-engineered' but cool).
Yes, something like
#define KVM_X86_OP(name) .name = vmx_##name
(svm_##name for svm.c) and then
KVM_X86_OP(check_nested_events)
On 26/02/20 00:52, Marc Zyngier wrote:
> Paolo,
>
> This is a small update containing a number of fixes, the most important ones
> making sure we force the inlining of any helper that gets used by the EL2 code
> (James identified that some bad things happen with CLang and the Shadow Call
> Stack
On 18/02/20 22:07, Sean Christopherson wrote:
> tmp = id_to_memslot(__kvm_memslots(kvm, as_id), id);
> - old = *tmp;
> - tmp = NULL;
> + if (tmp) {
> + old = *tmp;
> + tmp = NULL;
> + } else {
> + memset(, 0, sizeof(old));
> +
On 18/02/20 22:07, Sean Christopherson wrote:
> -sorted by update_memslots(), and the old
>* memslot needs to be referenced after calling update_memslots(), e.g.
> - * to free its resources and for arch specific behavior.
> + * to free its resources and for arch specific
On 20/02/20 14:15, Marc Zyngier wrote:
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it
the whole thing works.
>
> Fixes: 7495e22bb165 ("KVM: Move running VCPU from ARM to common code").
> Cc: Peter Xu
> Cc: Paolo Bonzini
> Reported-by: Zenghui Yu
> Signed-off-by: Marc Zyngier
> Link:
> https://lore.kernel.org/r/318984f6-bc36-33a3-abc6-bf2295974...@h
On 30/01/20 14:25, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
> tags/kvmarm-5.6
Pulled, thanks!
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 30/01/20 01:10, Sean Christopherson wrote:
> Set kvm_x86_ops with the vendor's ops only after ->hardware_setup()
> completes to "prevent" using kvm_x86_ops before they are ready, i.e. to
> generate a null pointer fault instead of silently consuming unconfigured
> state.
What about even copying
On 21/01/20 14:17, Andrew Jones wrote:
> https://github.com/rhdrjones/kvm-unit-tests arm/queue
Pulled, thanks. It may take until tomorrow before I push because I'm
testing 100-odd x86 patches. :)
Paolo
___
kvmarm mailing list
On 08/01/20 21:24, Sean Christopherson wrote:
> - level = host_pfn_mapping_level(vcpu, gfn, pfn);
> + slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
> + if (!memslot_valid_for_gpte(slot, true))
> + return PT_PAGE_TABLE_LEVEL;
Following up on my remark to patch 7, this can also
On 09/01/20 20:47, Barret Rhoden wrote:
> Hi -
>
> On 1/8/20 3:24 PM, Sean Christopherson wrote:
>> This series is a mix of bug fixes, cleanup and new support in KVM's
>> handling of huge pages. The series initially stemmed from a syzkaller
>> bug report[1], which is fixed by patch 02, "mm: thp:
On 08/01/20 21:24, Sean Christopherson wrote:
> +
> + /*
> + * Manually do the equivalent of kvm_vcpu_gfn_to_hva() to avoid the
> + * "writable" check in __gfn_to_hva_many(), which will always fail on
> + * read-only memslots due to gfn_to_hva() assuming writes. Earlier
> +
On 09/01/20 22:04, Thomas Gleixner wrote:
> Sean Christopherson writes:
>
>> diff --git a/arch/x86/include/asm/pgtable_types.h
>> b/arch/x86/include/asm/pgtable_types.h
>> index b5e49e6bac63..400ac8da75e8 100644
>> --- a/arch/x86/include/asm/pgtable_types.h
>> +++
On 08/01/20 21:24, Sean Christopherson wrote:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 5f7f06824c2b..d9aced677ddd 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1418,15 +1418,23 @@ EXPORT_SYMBOL_GPL(kvm_is_visible_gfn);
>
> unsigned long
On 13/01/20 14:00, Andrew Jones wrote:
> Patch 3/3 is a rework of Alexandru's pabt test on top of a couple of
> framework changes allowing it to be more simply and robustly implemented.
>
> Andrew Jones (3):
> arm/arm64: Improve memory region management
> arm/arm64: selftest: Allow
On 20/01/20 04:46, Paul Mackerras wrote:
> On Wed, Dec 18, 2019 at 01:55:26PM -0800, Sean Christopherson wrote:
>> Fold init() into create() now that the two are called back-to-back by
>> common KVM code (kvm_vcpu_init() calls kvm_arch_vcpu_init() as its last
>> action, and
On 20/01/20 04:34, Paul Mackerras wrote:
> On Wed, Dec 18, 2019 at 01:55:00PM -0800, Sean Christopherson wrote:
>> Move the kvm_cpu_{un}init() calls to common PPC code as an intermediate
>> step towards removing kvm_cpu_{un}init() altogether.
>>
>> No functional change intended.
>>
>>
On 20/01/20 05:04, Paul Mackerras wrote:
> On Wed, Dec 18, 2019 at 01:54:57PM -0800, Sean Christopherson wrote:
>> Move allocation of all flavors of PPC vCPUs to common PPC code. All
>> variants either allocate 'struct kvm_vcpu' directly, or require that
>> the embedded 'struct kvm_vcpu' member
Queued. Paul, David, please test kvm/next in a couple days.
Paolo
On 18/12/19 22:54, Sean Christopherson wrote:
> The end goal of this series is to strip down the interface between common
> KVM code and arch specific code so that there is precisely one arch hook
> for creating a vCPU and one
301 - 400 of 627 matches
Mail list logo
