On Fri, Dec 9, 2022 at 11:07 AM Oliver Upton wrote:
>
> On Thu, Dec 08, 2022 at 11:38:20AM -0800, David Matlack wrote:
>
> >Also do we want to keep "TDP" or switch
> >to something more familiar across architectures (e.g. ARM and RISC-V
> >both use "Stage-2")?
>
> As it relates to guest
On Fri, Dec 09, 2022 at 09:03:45PM +, Sean Christopherson wrote:
[...]
> > - GUEST_ASSERT(0);
> > +out:
> > + /*
> > +* If the guest cannot grab a ucall structure from the pool then the
> > +* only option to get out to userspace is a bare ucall. This is probably
> > +* a good
On Fri, Dec 09, 2022 at 08:45:01PM +, Sean Christopherson wrote:
> On Fri, Dec 09, 2022, Oliver Upton wrote:
> > An interesting feature of the Arm architecture is that the stage-1 MMU
> > supports two distinct VA regions, controlled by TTBR{0,1}_EL1. As KVM
> > selftests on arm64 only uses TTBR
On Fri, Dec 09, 2022, Oliver Upton wrote:
> Guest assertions depend on successfully allocating a ucall structure. As
> such, the use of guest assertions when ucall_alloc() fails simply leads
> to an infinite loop in guest code.
>
> Use GUEST_UCALL_NONE() to indicate failure instead. Though not
> t
On Fri, Dec 09, 2022, Oliver Upton wrote:
> An interesting feature of the Arm architecture is that the stage-1 MMU
> supports two distinct VA regions, controlled by TTBR{0,1}_EL1. As KVM
> selftests on arm64 only uses TTBR0_EL1, the VA space is constrained to
> [0, 2^(va_bits)). This is different f
On Thu, Dec 08, 2022 at 11:38:20AM -0800, David Matlack wrote:
> [ mm folks: You are being cc'd since this series includes a mm patch
> ("mm: Introduce architecture-neutral PG_LEVEL macros"), but general
> feedback is also welcome. I imagine there are a lot of lessons KVM can
> learn from mm
On Fri, Dec 09, 2022 at 09:57:15AM -0800, David Matlack wrote:
> On Fri, Dec 9, 2022 at 9:32 AM Oliver Upton wrote:
> >
> > Hey David,
> >
> > On Thu, Dec 08, 2022 at 11:38:43AM -0800, David Matlack wrote:
> > > Move VM-level TDP MMU state to struct kvm so it can be accessed by
> > > common code i
On Fri, Dec 09, 2022 at 04:44:46PM +, James Clark wrote:
> ARMV8_PMU_PMCR_N_MASK is an unshifted value which results in the wrong
> reset value for PMCR_EL0, so shift it to fix it.
That's just mean. *_MASK tends to be a shifted mask, although it would
appear that asm/perf_event.h does not foll
On Fri, Dec 9, 2022 at 9:32 AM Oliver Upton wrote:
>
> Hey David,
>
> On Thu, Dec 08, 2022 at 11:38:43AM -0800, David Matlack wrote:
> > Move VM-level TDP MMU state to struct kvm so it can be accessed by
> > common code in a future commit.
> >
> > No functional change intended.
>
> Could you inste
Hi,
On Fri, Dec 02, 2022 at 04:55:25AM +, Ricardo Koller wrote:
> PMUv3p5 uses 64-bit counters irrespective of whether the PMU is configured
> for overflowing at 32 or 64-bits. The consequence is that tests that check
> the counter values after overflowing should not assume that values will be
On Fri, Dec 9, 2022 at 9:25 AM Oliver Upton wrote:
>
> On Fri, Dec 09, 2022 at 10:37:47AM +0800, Yang, Weijiang wrote:
> >
> > On 12/9/2022 3:38 AM, David Matlack wrote:
> > > Rename kvm_mmu_page_role.smm with kvm_mmu_page_role.as_id and use it
> > > directly as the address space ID throughout the
Hey David,
On Thu, Dec 08, 2022 at 11:38:43AM -0800, David Matlack wrote:
> Move VM-level TDP MMU state to struct kvm so it can be accessed by
> common code in a future commit.
>
> No functional change intended.
Could you instead introduce a structure to hold all of the MMU state and
stick that
On Fri, Dec 09, 2022 at 10:37:47AM +0800, Yang, Weijiang wrote:
>
> On 12/9/2022 3:38 AM, David Matlack wrote:
> > Rename kvm_mmu_page_role.smm with kvm_mmu_page_role.as_id and use it
> > directly as the address space ID throughout the KVM MMU code. This
> > eliminates a needless level of indirect
On Fri, Dec 9, 2022 at 6:05 PM Oliver Upton wrote:
> Mind dumping what I had in v1 and applying this instead?
>
> https://lore.kernel.org/kvm/20221209015307.1781352-1-oliver.up...@linux.dev/
Ouch, five minutes too late... I can take care of the difference but
it'll have to wait for Monday.
Paolo
Hey Paolo,
On Fri, Dec 09, 2022 at 05:56:50PM +0100, Paolo Bonzini wrote:
> On 12/7/22 22:51, Oliver Upton wrote:
> > >
> > > I haven't pushed to kvm/next yet to give you time to check, so the
> > > merge is currently in kvm/queue only.
> > Have a look at this series, which gets things building a
On 12/7/22 22:51, Oliver Upton wrote:
I haven't pushed to kvm/next yet to give you time to check, so the
merge is currently in kvm/queue only.
Have a look at this series, which gets things building and actually
passing again:
https://lore.kernel.org/kvm/20221207214809.489070-1-oliver.up...@lin
ARMV8_PMU_PMCR_N_MASK is an unshifted value which results in the wrong
reset value for PMCR_EL0, so shift it to fix it.
This fixes the following error when running qemu:
$ qemu-system-aarch64 -cpu host -machine type=virt,accel=kvm -kernel ...
target/arm/helper.c:1813: pmevcntr_rawwrite: Asse
Hi,
We noticed qemu failing to run because of an assert on our CI. I don't see the
issue anymore with
this fix.
Applies to kvmarm/next (753d734f3f34)
Thanks
James Clark (1):
KVM: arm64: PMU: Fix PMCR_EL0 reset value
arch/arm64/kvm/sys_regs.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
On 12/9/2022 3:38 AM, David Matlack wrote:
Rename kvm_mmu_page_role.smm with kvm_mmu_page_role.as_id and use it
directly as the address space ID throughout the KVM MMU code. This
eliminates a needless level of indirection, kvm_mmu_role_as_id(), and
prepares for making kvm_mmu_page_role architec
On Fri, Dec 09, 2022 at 09:24:23AM +0100, Andrew Jones wrote:
> On Fri, Dec 09, 2022 at 01:52:59AM +, Oliver Upton wrote:
> > base-commit: 89b2395859651113375101bb07cd6340b1ba3637
>
> This commit doesn't seem to exist linux-next or kvm/queue, but the patch
> context seems to match up with linu
On Fri, Dec 09, 2022 at 01:52:59AM +, Oliver Upton wrote:
> The combination of the pool-based ucall implementation + page_fault_test
> resulted in some 'fun' bugs. As has always been the case, KVM selftests
> is a house of cards.
>
> Small series to fix up the issues on kvm/queue. Patches 1-2
On 12/7/22 08:49, Marc Zyngier wrote:
On Tue, 06 Dec 2022 21:43:43 +,
Paolo Bonzini wrote:
On 12/6/22 19:20, Mark Brown wrote:
I almost suggested doing that on multiple occasions this cycle, but ultimately
decided not to because it would effectively mean splitting series that touch KVM
an
22 matches
Mail list logo
