On 14/05/20 19:35, Jonathan Adams wrote:
>> In general for statsfs we took a more explicit approach where each
>> addend in a sum is a separate stats_fs_source. In this version of the
>> patches it's also a directory, but we'll take your feedback and add both
>> the ability to hide directories (fi
On 27/05/20 15:33, Andrew Lunn wrote:
>> I don't really know a lot about the networking subsystem, and as it was
>> pointed out in another email on patch 7 by Andrew, networking needs to
>> atomically gather and display statistics in order to make them consistent,
>> and currently this is not suppo
On 27/05/20 22:23, Jakub Kicinski wrote:
> On Wed, 27 May 2020 15:14:41 +0200 Emanuele Giuseppe Esposito wrote:
>> Regarding the config, as I said the idea is to gather multiple
>> subsystems' statistics, therefore there wouldn't be a single
>> configuration method like in netlink.
>> For example
On 27/05/20 23:27, Jakub Kicinski wrote:
> On Wed, 27 May 2020 23:07:53 +0200 Paolo Bonzini wrote:
>>> Again, I have little KVM knowledge, but BPF also uses a fd-based API,
>>> and carries stats over the same syscall interface.
>>
>> Can BPF stats (for BPF scrip
On 28/05/20 00:21, David Ahern wrote:
> On 5/27/20 3:07 PM, Paolo Bonzini wrote:
>> I see what you meant now. statsfs can also be used to enumerate objects
>> if one is so inclined (with the prototype in patch 7, for example, each
>> network interface becomes a directory).
&g
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 archite
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 the
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
On 22/06/21 07:25, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
include/uapi/linux/kvm.h
between commit:
9bb4a6f38fd4 ("KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE
capability")
from the powerpc tree and commits:
644f706719f0 (
On 22/06/21 16:51, Michael Ellerman wrote:
Please drop the patches at
https://www.spinics.net/lists/kvm-ppc/msg18666.html from the powerpc
tree, and merge them through either the kvm-powerpc or kvm trees.
The kvm-ppc tree is not taking patches at the moment.
If so, let's remove the "T" entry
On 24/06/21 05:57, David Stevens wrote:
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
follow_pte in gfn_to_pfn. However, the resolved pfns may not have
assoicated struct pages, so they should not be passed to pfn_to_page.
This series removes such calls from the x86 and a
On 24/06/21 05:57, David Stevens wrote:
static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
- int map_writable, int max_level, kvm_pfn_t pfn,
+ int map_writable, int max_level,
+ const struct kvm_pfn_page *p
On 24/06/21 10:52, Nicholas Piggin wrote:
For now, wrap all calls to gfn_to_pfn functions in the new helper
function. Callers which don't need the page struct will be updated in
follow-up patches.
Hmm. You mean callers that do need the page will be updated? Normally
if there will be leftover use
On 24/06/21 10:43, Nicholas Piggin wrote:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
From: David Stevens
Changelog? This looks like a bug, should it have a Fixes: tag?
Probably has been there forever... The best way to fix the bug would be
to nuke mmu_audit.c, which I'
On 24/06/21 11:57, Nicholas Piggin wrote:
Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so
it's a good idea to move the short name to the common case and the ugly
kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not
sure there should be any kvm_pfn_page_
On 24/06/21 12:06, Marc Zyngier wrote:
On Thu, 24 Jun 2021 09:58:00 +0100,
Nicholas Piggin wrote:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
From: David Stevens
out_unlock:
if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
read_unlock(&v
On 24/06/21 12:17, Nicholas Piggin wrote:
If all callers were updated that is one thing, but from the changelog
it sounds like that would not happen and there would be some gfn_to_pfn
users left over.
But yes in the end you would either need to make gfn_to_pfn never return
a page found via follo
On 24/06/21 13:42, Nicholas Piggin wrote:
+static int kvm_try_get_pfn(kvm_pfn_t pfn)
+{
+ if (kvm_is_reserved_pfn(pfn))
+ return 1;
So !pfn_valid would always return true. Yeah, this should work and is
certainly appealing!
Paolo
+ return get_page_unless_zero(pfn
On 24/06/21 13:42, Nicholas Piggin wrote:
Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
follow_pte in gfn_to_pfn. However, the resolved pfn
On 24/06/21 14:57, Nicholas Piggin wrote:
KVM: Fix page ref underflow for regions with valid but non-refcounted pages
It doesn't really fix the underflow, it disallows mapping them in the
first place. Since in principle things can break, I'd rather be
explicit, so let's go with "KVM: do not
On 25/06/21 09:58, Christian Borntraeger wrote:
On 25.06.21 09:36, David Stevens wrote:
From: Nicholas Piggin
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_t
On 12/08/21 11:04, David Hildenbrand wrote:
Reviewed-by: David Hildenbrand
But at the same time I wonder if we should just get rid of
CONFIG_KVM_S390_UCONTROL and consequently kvm_arch_vcpu_fault().
In practice CONFIG_KVM_S390_UCONTROL, is never enabled in any reasonable
kernel build and c
On 30/05/19 01:23, Mauro Carvalho Chehab wrote:
> Sphinx doesn't like orphan documents:
>
> Documentation/accelerators/ocxl.rst: WARNING: document isn't included in
> any toctree
> Documentation/arm/stm32/overview.rst: WARNING: document isn't included in
> any toctree
> Documentation
On 11/21/21 13:54, David Woodhouse wrote:
-kvm-objs := $(common-objs) kvm-s390.o intercept.o interrupt.o priv.o sigp.o
+kvm-objs := kvm-s390.o intercept.o interrupt.o priv.o sigp.o
kvm-objs += diag.o gaccess.o guestdbg.o vsie.o pv.o
"kvm-y +=" here (for both lines) would be nicer, it's con
On 11/21/21 13:54, David Woodhouse wrote:
From: David Woodhouse
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-obj
Sorry for the late review...
On 11/21/21 13:54, David Woodhouse wrote:
+EXPORT_SYMBOL_GPL(kvm_gfn_to_pfn_cache_check);
+
+static void __release_gpc(struct kvm *kvm, kvm_pfn_t pfn, void *khva,
+ gpa_t gpa, bool dirty)
+{
+ /* Unmap the old page if it was mapped befor
On 11/21/21 13:54, David Woodhouse wrote:
Introduce the basic concept of 2 level event channels for kernel delivery,
which is just a simple matter of a few test_and_set_bit calls on a mapped
shared info page.
This can be used for routing MSI of passthrough devices to PIRQ event
channels in a Xen
On 12/9/21 19:47, David Woodhouse wrote:
As in the previous two rounds, the last patch (this time patch 12) is
included as illustration of how we*might* use this for fixing the UAF
bugs in nesting, but isn't intended to be applied as-is. Patches 1-11 are.
Queued 1-7, will be on kvm/next tomorro
On 12/9/21 21:40, David Woodhouse wrote:
NP, very useful fixes. Thanks. Incremental patch looks like this. It
passes the xen_shinfo_test self-test; will test it with real Xen guests
tomorrow and repost based on your kvm/next tree once it shows up.
Compared to the review it's missing this hunk:
On 12/10/21 13:25, David Woodhouse wrote:
On Thu, 2021-12-09 at 23:34 +0100, Paolo Bonzini wrote:
Compared to the review it's missing this hunk:
@@ -265,7 +265,7 @@ void kvm_gfn_to_pfn_cache_unmap(struct kvm *kvm, struct
gfn_to_pfn_cache *gpc)
gpc->valid = false;
-
On 2/1/22 16:44, Anup Patel wrote:
+Paolo
On Tue, Feb 1, 2022 at 8:38 PM wrote:
From: Guo Ren
Current riscv doesn't support the 32bit KVM API. Let's make it
clear by not selecting KVM_COMPAT.
Signed-off-by: Guo Ren
Signed-off-by: Guo Ren
Cc: Arnd Bergmann
Cc: Anup Patel
This looks go
On 2/22/22 07:47, Nicholas Piggin wrote:
Patch 3 requires a KVM_CAP_PPC number allocated. QEMU maintainers are
happy with it (link in changelog) just waiting on KVM upstreaming. Do
you have objections to the series going to ppc/kvm tree first, or
another option is you could take patch 3 alone fir
On 20/04/2017 05:40, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
>
>> diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
>> index f2b3bd6c6bc2..0400e211aa44 100644
>> --- a/include/linux/srcutree.h
>> +++ b/include/linux/srcutree.h
>> @@ -24,25 +24,75 @@
> ...
>> +/*
>> +
; Thank you, Michael!
>
> Paolo, does this look good to you? My upstream maintainer will be much
> more likely to take this with your ack. ;-)
Sure,
Acked-by: Paolo Bonzini
since I don't expect conflicts between whoever applies this patch and
the KVM tree.
Paolo
On 18/05/2017 20:19, Naveen N. Rao wrote:
> Paolo Bonzini wrote:
>> The ARM and x86 architectures already use libdw, and it is useful to
>> have as much common code for the unwinder as possible. Porting PPC
>> to libdw only needs an architecture-specific hook to move the r
On 18/05/2017 20:48, Paolo Bonzini wrote:
>
>
> On 18/05/2017 20:19, Naveen N. Rao wrote:
>> Paolo Bonzini wrote:
>>> The ARM and x86 architectures already use libdw, and it is useful to
>>> have as much common code for the unwinder as possible. Porti
Bangoria
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paolo Bonzini
---
v1->v2: fix for 4.11->4.12 changes
tools/perf/Makefile.config | 2 +-
tools/perf/arch/powerpc/util/Build | 2 +
tools/perf/arch/powerpc/util/unwind-libdw.
On 01/06/2017 12:24, Paolo Bonzini wrote:
> Porting PPC to libdw only needs an architecture-specific hook to move
> the register state from perf to libdw.
>
> The ARM and x86 architectures already use libdw, and it is useful to
> have as much common code for the unwinder as
On 15/09/2017 07:26, Michael Neuling wrote:
> On POWER9 DD2.1 and below, sometimes on a Hypervisor Data Storage
> Interrupt (HDSI) the HDSISR is not be updated at all.
>
> To work around this we put a canary value into the HDSISR before
> returning to a guest and then check for this canary when we
On 22/09/2017 12:30, David Gibson wrote:
> On Fri, Sep 22, 2017 at 10:46:36AM +0200, Paolo Bonzini wrote:
>> On 15/09/2017 07:26, Michael Neuling wrote:
>>> On POWER9 DD2.1 and below, sometimes on a Hypervisor Data Storage
>>> Interrupt (HDSI) the HDSISR is not be upda
On 13/10/2017 01:16, Greg Kurz wrote:
> Ping ?
When is Paul back from vacation? :)
Paolo
> On Thu, 14 Sep 2017 23:56:25 +0200
> Greg Kurz wrote:
>
>> The following program causes a kernel oops:
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> main()
>> {
>> int fd
On 30/11/2017 10:33, Fabian Grünbichler wrote:
>
> It was reverted in 785373b4c38719f4af6775845df6be1dfaea120f after which
> the symptoms disappeared until this series was merged, which contains
>
> 369ea8242c0fb5239b4ddf0dc568f694bd244de4 mm/rmap: update to new mmu_notifier
> semantic v2
>
> W
On 08/12/2016 00:31, Tyrel Datwyler wrote:
> The first byte of each CRQ entry is used to indicate whether an entry is
> a valid response or free for the VIOS to use. After processing a
> response the driver sets the valid byte to zero to indicate the entry is
> now free to be reused. Add a memory
On 20/01/2017 19:19, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 19 Jan 2017 22:45:56 +0100
>
> * A local variable was set to an error code in five cases
> before a concrete error situation was detected.
> Thus move the corresponding assignments into
> if branches to indi
On 20/01/2017 19:21, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 20 Jan 2017 10:30:26 +0100
>
> A local variable was set to an error code in a few cases before a concrete
> error situation was detected. Thus move the corresponding assignments into
> if branches to indicate a so
On 10/02/2017 04:59, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvm tree got a conflict in:
>
> arch/powerpc/include/asm/head-64.h
>
> between commit:
>
> 852e5da99d15 ("powerpc/64s: Tidy up after exception handler rework")
>
> from the powerpc tree and commit:
On 14/02/2017 09:45, Michael Ellerman wrote:
>> If possible, please pull only up to "powerpc/64: Allow for relocation-on
>> interrupts from guest to host" and cherry-pick the top two patches
>> ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts" and
>> "powerpc/powernv: Remove separate e
On 15/02/2017 12:16, Michael Ellerman wrote:
>> However, the reason was that this is simply not how topic branches
>> should work: topic branches should be the base for other work, they
>> shouldn't contain _all_ the work.
>
> I think that's an overly specific definition of what a topic branch is.
On 28/02/2018 03:31, wei.guo.si...@gmail.com wrote:
> From: Simon Guo
>
> Although CONFIG_HAVE_KVM_VCPU_ASYNC_IOCTL is usually on, logically
> kvm_arch_vcpu_async_ioctl() definition should be wrapped with
> CONFIG_HAVE_KVM_VCPU_ASYNC_IOCTL #ifdef.
No, the symbol is defined by Kconfig. It is a b
est_enter_irqoff()
> instead.
>
> Fixes: 8b24e69fc47e
> ("KVM: PPC: Book3S HV: Close race with testing for signals on guest entry")
> Signed-off-by: Laurent Vivier
Reviewed-by: Paolo Bonzini
> ---
> arch/powerpc/kvm/book3s_hv.c | 5 ++---
> 1 file changed, 2 inse
On 18/04/2018 21:19, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> commit 1c8f422059a
> > > > Please consider s390 and (x86/arm) KVM. Once we have a few, more can
> > > > follow later, but I think its important to not only have PPC support for
> > > > this.
> > >
> > > Actually the s390 preemted check via sigp sense running is available for
> > > all hypervisors (z/VM, LPAR and KVM
On 30/09/2016 10:52, Pan Xinhui wrote:
>> x86 has no hypervisor support, and I'd like to understand the desired
>> semantics first, so I don't think it should block this series. In
>
> Once a guest do a hypercall or something similar, IOW, there is a
> kvm_guest_exit. we think this is a lock ho
On 19/10/2016 19:24, Radim Krčmář wrote:
>> > + if (vcpu->arch.st.msr_val & KVM_MSR_ENABLED)
>> > + if (kvm_read_guest_cached(vcpu->kvm, &vcpu->arch.st.stime,
>> > + &vcpu->arch.st.steal,
>> > + sizeof(struct kvm_steal_ti
On 21/10/2016 20:39, rkrc...@redhat.com wrote:
> 2016-10-21 11:27+, David Laight:
>> From: Pan Xinhui
>>> Sent: 20 October 2016 22:28
>>> Commit ("x86, kvm: support vcpu preempted check") add one field "__u8
>>> preempted" into struct kvm_steal_time. This field tells if one vcpu is
>>> runnin
On 24/10/2016 17:14, Radim Krčmář wrote:
> 2016-10-24 16:39+0200, Paolo Bonzini:
>> On 19/10/2016 19:24, Radim Krčmář wrote:
>>>>> + if (vcpu->arch.st.msr_val & KVM_MSR_ENABLED)
>>>>> + if (kvm_rea
On 28/10/2016 10:11, Pan Xinhui wrote:
> change from v5:
> spilt x86/kvm patch into guest/host part.
> introduce kvm_write_guest_offset_cached.
> fix some typos.
> rebase patch onto 4.9.2
Acked-by: Paolo Bonzini
Thanks,
Paolo
> change from v4:
>
On 04/11/2016 06:48, Michael Ellerman wrote:
> Currently the kconfig logic for VFIO_IOMMU_SPAPR_TCE and VFIO_SPAPR_EEH
> is broken when SPAPR_TCE_IOMMU=n. Leading to:
>
> warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct
> dependencies (VFIO && SPAPR_TCE_IOMMU)
> warni
On 07/11/2016 17:25, Alex Williamson wrote:
> On Mon, 07 Nov 2016 19:34:42 +1100
> Michael Ellerman wrote:
>
>> Paolo Bonzini writes:
>>> On 04/11/2016 06:48, Michael Ellerman wrote:
>>>> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
>>
On 09/05/2016 10:14, Thomas Huth wrote:
>> > Tested-by: Thomas Huth
> Ping!
>
> Alex, Paul, could you please pick up this patch? This patch is required
> to get the kvm-unit-tests working properly with kvm-pr, so I'd be glad
> if we could get this included finally...
I have a pull request for
On 20/06/2016 02:08, Paul Mackerras wrote:
> Paolo,
>
> Can I have an ack for Suraj's patch below? If it's OK with you,
> I'll take his series through my tree.
Yes, please do.
Paolo
> Thanks,
> Paul.
>
> On Wed, Jun 15, 2016 at 07:21:07PM +1000, Suraj Jitindar Singh wrote:
>> vcpus have sta
On 29/06/2016 06:44, Suraj Jitindar Singh wrote:
> Thanks for catching that, yeah I see.
>
> I don't think we can trivially move the struct kvmppc_vcore definition into
> kvm_book3s.h as other code in kvm_host.h (i.e. struct kvm_vcpu_arch) requires
> the definition. I was thinking that I could
On 06/07/2016 08:52, Peter Zijlstra wrote:
> On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote:
>> change fomr v1:
>> a simplier definition of default vcpu_is_preempted
>> skip mahcine type check on ppc, and add config. remove dedicated macro.
>> add one patch to drop over
On 06/07/2016 14:08, Wanpeng Li wrote:
> 2016-07-06 18:44 GMT+08:00 Paolo Bonzini :
>>
>>
>> On 06/07/2016 08:52, Peter Zijlstra wrote:
>>> On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote:
>>>> change fomr v1:
>>>> a simplier
On 06/07/2016 10:19, Peter Zijlstra wrote:
>>> Paolo, could you help out with an (x86) KVM interface for this?
>> >
>> > Xen support of this interface should be rather easy. Could you please
>> > Cc: xen-devel-requ...@lists.xenproject.org in the next version?
> So meta question; aren't all you v
On 11/07/2016 18:51, David Matlack wrote:
>> > vcpus have statistics associated with them which can be viewed within the
>> > debugfs. Currently it is assumed within the vcpu_stat_get() and
>> > vcpu_stat_get_per_vm() functions that all of these statistics are
>> > represented as 32-bit numbers.
On 11/07/2016 18:57, David Matlack wrote:
> On Mon, Jul 11, 2016 at 12:08 AM, Suraj Jitindar Singh
> wrote:
> > This patch introduces new halt polling functionality into the kvm_hv kernel
> > module. When a vcore is idle it will poll for some period of time before
> > scheduling itself out.
>
>
On 11/07/2016 19:30, David Matlack wrote:
> On Mon, Jul 11, 2016 at 10:05 AM, Paolo Bonzini wrote:
>>
>>
>> On 11/07/2016 18:51, David Matlack wrote:
>>>>> vcpus have statistics associated with them which can be viewed within the
>>>>> debugf
On 13/07/2016 20:00, Christian Borntraeger wrote:
>>> >> I thought u64 still existed on 32-bit architectures. unsigned long
>>> >> would be fine but with the caveat that certain stats would overflow on
>>> >> 32-bit architectures.
>> >
>> > Yes, but not all 32-bit architectures can do atomic rea
On 18/07/2016 09:17, Christian Borntraeger wrote:
> On 07/15/2016 09:52 AM, Suraj Jitindar Singh wrote:
>>
>>
>> On 14/07/16 19:42, Paolo Bonzini wrote:
>>>
>>> On 13/07/2016 20:00, Christian Borntraeger wrote:
>>>>>>>> I t
On 20/07/2016 07:46, Michael Ellerman wrote:
> Thanks.
>
> Acked-by: Michael Ellerman
>
> Or do you want me to merge this before Paul gets back?
No, this should be merged through the KVM tree. Please Cc the KVM
maintainers before offering to apply a patch that formally belongs to
another tre
On 20/07/2016 08:30, Paolo Bonzini wrote:
> In particular this patch would indeed have a conflict, because you have
>
> +#define KVM_CAP_PPC_HTM 129
>
> but cap numbers 129 and 130 are already taken. So whoever applies it
> should bump the number to 131.
Applied now
paca_struct only if KVM is supported by the kernel.
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Mahesh Salgaonkar
Cc: linuxppc-dev@lists.ozlabs.org
Cc: kvm-...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
It would be nice to have this in 4.8, to minimize any 4.9
paca_struct only if KVM is supported by the kernel.
Cc: Daniel Axtens
Cc: Michael Ellerman
Cc: Mahesh Salgaonkar
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: kvm-...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
v1->v2: use CONFIG_KVM_BOOK3S_HV_POSSI
On 11/08/2016 15:07, Paolo Bonzini wrote:
> hmi.c functions are unused unless sibling_subcore_state is nonzero, and
> that in turn happens only if KVM is in use. So move the code to
> arch/powerpc/kvm/, putting it under CONFIG_KVM_BOOK3S_HV_POSSIBLE
> rather than CONFIG_PPC_BOO
On 08/09/2016 12:08, Paul Mackerras wrote:
>> >
>> > arch/powerpc/include/asm/book3s/64/mmu-hash.h | 37
>> > arch/powerpc/include/asm/kvm_book3s_64.h | 87
>> > +++
>> > arch/powerpc/include/asm/mmu.h| 1 +
>> > arch/powerpc/mm/hash_n
On 12/09/2016 05:03, Michael Ellerman wrote:
>> > Can you place it in a pull request for both Michael and myself?
> Paul and I talked about this offline, he's going to create a topic
> branch with this in it.
>
> I'll hold off merging it until closer to the merge window, and I'll
> merge it then
+ kfree(ctx);
> kvm_put_kvm(kvm);
> return ret;
> }
>
Reviewed-by: Paolo Bonzini
On 18/09/2017 08:44, Michael Ellerman wrote:
> "Jan H. Schönherr" writes:
>
>> This reverts commit 36ae3c0a36b7456432fedce38ae2f7bd3e01a563.
>>
>> The commit broke compilation on !CONFIG_HAVE_KVM_IRQ_ROUTING. Also,
>> there may be cases with CONFIG_HAVE_KVM_IRQ_ROUTING, where larger
>> gsi values
On 7/27/24 01:51, Sean Christopherson wrote:
Move the marking of folios dirty from make_spte() out to its callers,
which have access to the _struct page_, not just the underlying pfn.
Once all architectures follow suit, this will allow removing KVM's ugly
hack where KVM elevates the refcount of V
On 7/27/24 01:51, Sean Christopherson wrote:
Move KVM x86's helper that "finishes" the faultin process to common KVM
so that the logic can be shared across all architectures. Note, not all
architectures implement a fast page fault path, but the gist of the
comment applies to all architectures.
On 7/27/24 01:51, Sean Christopherson wrote:
Use __kvm_faultin_page() get the APIC access page so that KVM can
precisely release the refcounted page, i.e. to remove yet another user
of kvm_pfn_to_refcounted_page(). While the path isn't handling a guest
page fault, the semantics are effectively t
On 7/27/24 01:51, Sean Christopherson wrote:
Provide the "struct page" associated with a guest_memfd pfn as an output
from __kvm_gmem_get_pfn() so that KVM guest page fault handlers can
Just "kvm_gmem_get_pfn()".
directly put the page instead of having to rely on
k
On 7/27/24 01:51, Sean Christopherson wrote:
Add a kvm_follow_pfn() wrapper, kvm_lookup_pfn(), to allow looking up a
gfn=>pfn mapping without the caller getting a reference to any underlying
page. The API will be used in flows that want to know if a gfn points at
a valid pfn, but don't actually
On 7/27/24 01:52, Sean Christopherson wrote:
Now that KVM no longer relies on an ugly heuristic to find its struct page
references, i.e. now that KVM can't get false positives on VM_MIXEDMAP
pfns, remove KVM's hack to elevate the refcount for pfns that happen to
have a valid struct page. In addi
On 7/27/24 01:51, Sean Christopherson wrote:
arm64 folks, the first two patches are bug fixes, but I have very low
confidence that they are correct and/or desirable. If they are more or
less correct, I can post them separately if that'd make life easier. I
included them here to avoid conflicts,
On 7/30/24 22:21, Sean Christopherson wrote:
On Tue, Jul 30, 2024, Paolo Bonzini wrote:
On 7/27/24 01:52, Sean Christopherson wrote:
Now that KVM no longer relies on an ugly heuristic to find its struct page
references, i.e. now that KVM can't get false positives on VM_MIXEDMAP
pfns, r
On 7/30/24 22:15, Sean Christopherson wrote:
On Tue, Jul 30, 2024, Paolo Bonzini wrote:
On 7/27/24 01:51, Sean Christopherson wrote:
Add a kvm_follow_pfn() wrapper, kvm_lookup_pfn(), to allow looking up a
gfn=>pfn mapping without the caller getting a reference to any underlying
page. The
On 7/30/24 22:00, Sean Christopherson wrote:
The probability of guest_memfd not having struct page for mapped pfns is likely
very low, but at the same time, providing a pfn+page pair doesn't cost us much.
And if it turns out that not having struct page is nonsensical, deferring the
kvm_gmem_get_p
On 7/30/24 21:15, Sean Christopherson wrote:
Does it make sense to move RET_PF_* to common code, and avoid a bool
argument here?
After this series, probably? Especially if/when we make "struct kvm_page_fault"
a common structure and converge all arch code. In this series, definitely not,
as it
On 10/10/24 20:09, Vishal Chourasia wrote:
Hi,
While building the kernel with CONFIG_PREEMPT_RT, I encountered several
compilation errors in the PowerPC KVM code. The issues appear in
book3s_hv_rm_mmu.c where it tries to access the 'rlock' member of struct
spinlock, which doesn't exist in the RT
On Fri, Oct 11, 2024 at 12:04 PM Vishal Chourasia wrote:
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 8094a01974cca..568dc856f0dfa 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -168,6 +168,7 @@ config PPC
> select ARCH_STACKWALK
> selec
On 10/23/24 14:01, Liu Jing wrote:
In the kvmppc_mmu_book3s_64_xlate function,
r = be64_to_cpu(pteg[i+1]); i used is 16 after the last loop and adding 1 will
cross the line.
Signed-off-by: Liu Jing
diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index 61290282
On Tue, Oct 22, 2024 at 2:25 AM Sean Christopherson wrote:
> > Looks good to me, thanks and congratulations!! Should we merge it in
> > kvm/next asap?
>
> That has my vote, though I'm obvious extremely biased :-)
Your wish is my command... Merged.
Paolo
On Thu, Oct 10, 2024 at 8:24 PM Sean Christopherson wrote:
> v13:
> - Rebased onto v6.12-rc2
> - Collect reviews. [Alex and others]
> - Fix a transient bug in arm64 and RISC-V where KVM would leak a page
>refcount. [Oliver]
> - Fix a dangling comment. [Alex]
> - Drop kvm_lookup_pfn(), as
Il mer 25 dic 2024, 13:48 Christian Zigotzky ha
scritto:
> > But do you see anything on the host dmesg (without and with the
> > patch), for example a WARN?
> Unfortunately no log during the start of KVM HV.
>
Ok.
> Also you might try edebc0a1b7ab5ff19b4f5cd011c93196fc34b3e4 + the
> > patch, to
On 12/24/24 12:05, Christian Zigotzky wrote:
Hello Paolo,
Thanks a lot for your patch.
I tested it with the RC4 of kernel 6.13 today but unfortunately it
doesn't solve the KVM HV issue. The guest system doesn't boot and I
can't see any error messages. (console=ttyS0)
But do you see anything
On Thu, Dec 26, 2024 at 3:26 PM Christian Zigotzky
wrote:
> This has solved the issue:
>
> cp linux-6.12.6/arch/powerpc/kvm/e500_mmu_host.c
> a/arch/powerpc/kvm/e500_mmu_host.c
> cp linux-6.12.6/include/linux/kvm_host.h a/include/linux/kvm_host.h
> cp linux-6.12.6/virt/kvm/kvm_main.c a/virt/kvm/kv
On 12/12/24 13:55, Arnd Bergmann wrote:
From: Arnd Bergmann
There are very few 32-bit machines that support KVM, the main exceptions
are the "Yonah" Generation Xeon-LV and Core Duo from 2006 and the Atom
Z5xx "Silverthorne" from 2008 that were all released just before their
64-bit counterparts.
On 12/13/24 09:03, Arnd Bergmann wrote:
On Fri, Dec 13, 2024, at 04:51, A. Wilcox wrote:
On Dec 12, 2024, at 6:55 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
I submitted a patch to remove KVM support for x86-32 hosts earlier
this month, but there were still concerns that this might be usefu
201 - 300 of 320 matches
Mail list logo
