From: James Morse
As per ARM ARM DDI 0487G.a, when FEAT_LPA2 is implemented, ID_AA64MMFR0_EL1
might contain a range of values to describe supported translation granules
(4K and 16K pages sizes in particular) instead of just enabled or disabled
values. This changes __enable_mmu() function to
This patchset extends IOCTL interface to retrieve KVM statistics data
in aggregated binary format.
It is meant to provide a lightweight, flexible, scalable and efficient
lock-free solution for userspace telemetry applications to pull the
statistics data periodically for large scale systems.
The
Prepare the statistics name strings for supporting binary format
aggregated statistics data retrieval.
No functional change intended.
Signed-off-by: Jing Zhang
---
arch/arm64/kvm/guest.c| 47 --
arch/mips/kvm/mips.c | 114 ++
arch/powerpc/kvm/book3s.c | 107
Three ioctl commands are added to support binary form statistics data
retrieval. KVM_STATS_GET_INFO, KVM_STATS_GET_NAMES, KVM_STATS_GET_DATA.
KVM_CAP_STATS_BINARY_FORM indicates the capability.
Signed-off-by: Jing Zhang
---
virt/kvm/kvm_main.c | 115
Check if the KVM binary form statistics works correctly and whether the
statistics name strings are synced correctly with KVM internal stats
data.
Signed-off-by: Jing Zhang
---
tools/testing/selftests/kvm/.gitignore| 1 +
tools/testing/selftests/kvm/Makefile | 3 +
Define ioctl commands for VM/vCPU aggregated statistics data retrieval
in binary format and update corresponding API documentation.
The capability and ioctl are not enabled for now.
No functional change intended.
Signed-off-by: Jing Zhang
---
Documentation/virt/kvm/api.rst | 79
On Wed, 3 Mar 2021 16:45:05 +, Marc Zyngier wrote:
> It recently became apparent that the ARMv8 architecture has interesting
> rules regarding attributes being used when fetching instructions
> if the MMU is off at Stage-1.
>
> In this situation, the CPU is allowed to fetch from the PoC and
>
On Mon, 01 Mar 2021 14:23:14 +,
Steven Price wrote:
>
> The VMM may not wish to have it's own mapping of guest memory mapped
> with PROT_MTE because this causes problems if the VMM has tag checking
> enabled (the guest controls the tags in physical RAM and it's unlikely
> the tags are
On Mon, 01 Mar 2021 14:23:12 +,
Steven Price wrote:
>
> Define the new system registers that MTE introduces and context switch
> them. The MTE feature is still hidden from the ID register as it isn't
> supported in a VM yet.
>
> Signed-off-by: Steven Price
> ---
>
Hi Marc,
On 3/8/21 8:03 PM, Marc Zyngier wrote:
> Hi Alex,
>
> On Mon, 08 Mar 2021 16:53:09 +,
> Alexandru Elisei wrote:
>> Hello,
>>
>> It's not clear to me why this patch is needed. If one VCPU in the VM is
>> generating
>> code, is it not the software running in the VM responsible for
On Mon, 01 Mar 2021 14:23:11 +,
Steven Price wrote:
>
> Add a new VM feature 'KVM_ARM_CAP_MTE' which enables memory tagging
> for a VM. This will expose the feature to the guest and automatically
> tag memory pages touched by the VM as PG_mte_tagged (and clear the tag
> storage) to ensure
Hi Andre,
On 2/25/21 12:59 AM, Andre Przywara wrote:
> Using the RTC device at its legacy I/O address as set by IBM in 1981
> was a kludge we used for simplicity on ARM platforms as well.
> However this imposes problems due to their missing alignment and overlap
> with the PCI I/O address space.
Hi Andre,
I think you forgot to change the way the address is generated in
serial8250_generate_fdt_node, it's still KVM_IOPORT_AREA + dev->iobase. It's
technically correct, as KVM_IOPORT_AREA == ARM_IOPORT_AREA == 0x0, but very
confusing (and prone to breakage is something changes in the memory
Hi Andre,
This is a really good idea, thank you for implementing it!
Some comments below.
On 2/25/21 12:59 AM, Andre Przywara wrote:
> The hardcoded memory map we expose to a guest is currently described
> using a series of partially interconnected preprocessor constants,
> which is hard to
Hi Andre,
On 2/25/21 12:59 AM, Andre Przywara wrote:
> Now that all users of the dedicated ioport trap handler interface are
> gone, we can retire the code associated with it.
>
> This removes ioport.c and ioport.h, along with removing prototypes from
> other header files.
>
> This also transfers
On 3/9/21 7:35 PM, Will Deacon wrote:
> On Mon, Mar 08, 2021 at 02:42:00PM +, Marc Zyngier wrote:
>> On Fri, 05 Mar 2021 14:36:09 +,
>> Anshuman Khandual wrote:
>>> - switch (cpuid_feature_extract_unsigned_field(mmfr0, tgran_2)) {
>>> - default:
>>> - case 1:
>>> + tgran_2 =
On Tue, 09 Mar 2021 14:29:10 +,
Andrew Jones wrote:
>
> On Tue, Mar 09, 2021 at 01:43:40PM +, Marc Zyngier wrote:
> > Hi Andrew,
> >
> > On Tue, 09 Mar 2021 13:20:21 +,
> > Andrew Jones wrote:
> > >
> > > Hi Marc,
> > >
> > > On Mon, Mar 08, 2021 at 05:46:43PM +, Marc Zyngier
Hi Andre,
On 2/25/21 12:59 AM, Andre Przywara wrote:
> With the planned retirement of the special ioport emulation code, we
> need to provide an emulation function compatible with the MMIO prototype.
>
> Adjust the existing MMIO callback routine to automatically determine
> the region this trap
On Tue, Mar 09, 2021 at 01:26:46PM +, Will Deacon wrote:
> On Wed, Mar 03, 2021 at 04:45:05PM +, Marc Zyngier wrote:
> > It recently became apparent that the ARMv8 architecture has interesting
> > rules regarding attributes being used when fetching instructions
> > if the MMU is off at
On Tue, Mar 09, 2021 at 01:43:40PM +, Marc Zyngier wrote:
> Hi Andrew,
>
> On Tue, 09 Mar 2021 13:20:21 +,
> Andrew Jones wrote:
> >
> > Hi Marc,
> >
> > On Mon, Mar 08, 2021 at 05:46:43PM +, Marc Zyngier wrote:
> > > KVM/arm64 has forever used a 40bit default IPA space, partially
Hi Suzuki,
On Tue, 09 Mar 2021 11:09:48 +,
Suzuki Poulose wrote:
>
>
>
> > On 8 Mar 2021, at 17:46, Marc Zyngier wrote:
> >
> > KVM/arm64 has forever used a 40bit default IPA space, partially
> > due to its 32bit heritage (where the only choice is 40bit).
> >
> > However, there are
Hi Andre,
On 2/25/21 12:59 AM, Andre Przywara wrote:
> With the planned retirement of the special ioport emulation code, we
> need to provide an emulation function compatible with the MMIO prototype.
>
> Adjust the I/O port trap handler to use that new function, and provide
> shims to implement
On Mon, Mar 08, 2021 at 02:42:00PM +, Marc Zyngier wrote:
> On Fri, 05 Mar 2021 14:36:09 +,
> Anshuman Khandual wrote:
> > - switch (cpuid_feature_extract_unsigned_field(mmfr0, tgran_2)) {
> > - default:
> > - case 1:
> > + tgran_2 = cpuid_feature_extract_unsigned_field(mmfr0,
Hi Andrew,
On Tue, 09 Mar 2021 13:20:21 +,
Andrew Jones wrote:
>
> Hi Marc,
>
> On Mon, Mar 08, 2021 at 05:46:43PM +, Marc Zyngier wrote:
> > KVM/arm64 has forever used a 40bit default IPA space, partially
> > due to its 32bit heritage (where the only choice is 40bit).
> >
> >
On Wed, Mar 03, 2021 at 04:45:05PM +, Marc Zyngier wrote:
> It recently became apparent that the ARMv8 architecture has interesting
> rules regarding attributes being used when fetching instructions
> if the MMU is off at Stage-1.
>
> In this situation, the CPU is allowed to fetch from the
Hi Marc,
On Mon, Mar 08, 2021 at 05:46:43PM +, Marc Zyngier wrote:
> KVM/arm64 has forever used a 40bit default IPA space, partially
> due to its 32bit heritage (where the only choice is 40bit).
>
> However, there are implementations in the wild that have a *cough*
> much smaller *cough* IPA
Hi Andre,
On 2/25/21 12:59 AM, Andre Przywara wrote:
> Now that the x86 I/O ports have trap handlers adhering to the MMIO fault
> handler prototype, let's switch over to the joint registration routine.
>
> This allows us to get rid of the ioport shim routines.
>
> Since the debug output was done
Hi Andre,
Regarding the naming of the functions, these are real ioport emulation
functions,
which are executed because a KVM_EXIT_IO exit reason from KVM_RUN. Wouldn't
naming
the functions something like *_pio or *_io be more appropriate?
Thanks,
Alex
On 2/25/21 12:59 AM, Andre Przywara
On Tue, Mar 09, 2021 at 11:35:54AM +, Marc Zyngier wrote:
> On Tue, 09 Mar 2021 11:26:59 +,
> Will Deacon wrote:
> >
> > On Mon, Mar 08, 2021 at 05:46:43PM +, Marc Zyngier wrote:
> > > KVM/arm64 has forever used a 40bit default IPA space, partially
> > > due to its 32bit heritage
On Tue, 09 Mar 2021 11:26:59 +,
Will Deacon wrote:
>
> On Mon, Mar 08, 2021 at 05:46:43PM +, Marc Zyngier wrote:
> > KVM/arm64 has forever used a 40bit default IPA space, partially
> > due to its 32bit heritage (where the only choice is 40bit).
> >
> > However, there are implementations
On Mon, Mar 08, 2021 at 05:46:43PM +, Marc Zyngier wrote:
> KVM/arm64 has forever used a 40bit default IPA space, partially
> due to its 32bit heritage (where the only choice is 40bit).
>
> However, there are implementations in the wild that have a *cough*
> much smaller *cough* IPA space,
Hi Marc,
> -Original Message-
> From: Marc Zyngier [mailto:m...@kernel.org]
> Sent: 09 March 2021 10:33
> To: Shameerali Kolothum Thodi
> Cc: linux-arm-ker...@lists.infradead.org; io...@lists.linux-foundation.org;
> kvmarm@lists.cs.columbia.edu; alex.william...@redhat.com;
>
> On 8 Mar 2021, at 17:46, Marc Zyngier wrote:
>
> KVM/arm64 has forever used a 40bit default IPA space, partially
> due to its 32bit heritage (where the only choice is 40bit).
>
> However, there are implementations in the wild that have a *cough*
> much smaller *cough* IPA space, which
On Mon, 1 Mar 2021 at 14:23, Steven Price wrote:
>
> A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> granting a guest access to the tags, and provides a mechanism for the
> VMM to enable it.
>
> A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
>
Hi Shameer,
[+Will]
On Mon, 22 Feb 2021 15:53:36 +,
Shameer Kolothum wrote:
>
> On an ARM64 system with a SMMUv3 implementation that fully supports
> Broadcast TLB Maintenance(BTM) feature, the CPU TLB invalidate
> instructions are received by SMMU. This is very useful when the
> SMMU
Hi Daniel,.
On Tue, 02 Mar 2021 16:48:50 +,
Daniel Kiss wrote:
>
> CPUs that support SVE are architecturally required to support the
> Virtualization Host Extensions (VHE), so far the kernel supported
> SVE alongside KVM with VHE enabled. In same cases it is desired to
> run nVHE config
On 2021/3/9 16:43, Marc Zyngier wrote:
On Tue, 09 Mar 2021 08:34:43 +,
"wangyanan (Y)" wrote:
On 2021/3/9 0:34, Will Deacon wrote:
On Mon, Jan 25, 2021 at 10:10:44PM +0800, Yanan Wang wrote:
After dirty-logging is stopped for a VM configured with huge mappings,
KVM will recover the
On Fri, 5 Mar 2021 12:21:24 -0800, Sami Tolvanen wrote:
> allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following
> linker errors:
>
> ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21CC):
> relocation R_AARCH64_CONDBR19 out of range: 2031220 is not in
>
On Tue, 09 Mar 2021 08:34:43 +,
"wangyanan (Y)" wrote:
>
>
> On 2021/3/9 0:34, Will Deacon wrote:
> > On Mon, Jan 25, 2021 at 10:10:44PM +0800, Yanan Wang wrote:
> >> After dirty-logging is stopped for a VM configured with huge mappings,
> >> KVM will recover the table mappings back to
On 2021/3/9 0:34, Will Deacon wrote:
On Mon, Jan 25, 2021 at 10:10:44PM +0800, Yanan Wang wrote:
After dirty-logging is stopped for a VM configured with huge mappings,
KVM will recover the table mappings back to block mappings. As we only
replace the existing page tables with a block entry and
40 matches
Mail list logo
