On Wed, Sep 09, 2020 at 04:53:02PM +0100, Peter Maydell wrote:
> On Wed, 9 Sep 2020 at 16:48, Andrew Jones wrote:
> > We either need a KVM cap or a new CPU feature probing interface to avoid
> > making userspace try features one at a time. It's too bad that VCPU_INIT
> > doesn't clear all offendin
On Wed, Sep 09, 2020 at 06:45:33PM -0700, Richard Henderson wrote:
> On 9/9/20 8:25 AM, Andrew Jones wrote:
> >> * Provide a KVM-specific method to extract the tags from guest memory.
> >>This might also have benefits in terms of providing an easy way to
> >>read bulk tag data from guest m
On 9/10/20 2:06 PM, Gavin Shan wrote:
Hi Will and Marc,
On 9/8/20 1:23 AM, Will Deacon wrote:
Hi all,
Here's version four of the KVM page-table rework I previously posted here:
v1: https://lore.kernel.org/r/20200730153406.25136-1-w...@kernel.org
v2: https://lore.kernel.org/r/20200818132
Hi Will and Marc,
On 9/8/20 1:23 AM, Will Deacon wrote:
Hi all,
Here's version four of the KVM page-table rework I previously posted here:
v1: https://lore.kernel.org/r/20200730153406.25136-1-w...@kernel.org
v2: https://lore.kernel.org/r/20200818132818.16065-1-w...@kernel.org
v3: http
On 9/9/20 8:25 AM, Andrew Jones wrote:
>> * Provide a KVM-specific method to extract the tags from guest memory.
>>This might also have benefits in terms of providing an easy way to
>>read bulk tag data from guest memory (since the LDGM instruction
>>isn't available at EL0).
>
> Maybe
Add the MIDR part number info for the Arm Cortex-A77.
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Rob Herring
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 7219cddeba66
On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device load
and a store exclusive or PAR_EL1 read can cause a deadlock.
The workaround requires a DMB SY before and after a PAR_EL1 register
read. In addition, it's possible an interrupt (doing a device read) or
KVM guest exit could be
On Fri, Aug 21, 2020 at 11:51 AM Catalin Marinas
wrote:
>
> On Fri, Aug 21, 2020 at 06:02:39PM +0100, Marc Zyngier wrote:
> > On 2020-08-21 15:05, Catalin Marinas wrote:
> > > On Fri, Aug 21, 2020 at 01:45:40PM +0100, Marc Zyngier wrote:
> > > > On 2020-08-21 13:26, Catalin Marinas wrote:
> > > >
On 9/9/20 15:06, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is break;
>
> Found usi
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep-2.5.4 -rP --include=*.[ch] -n
"fallthrou
Hi Marc,
On 9/9/20 7:50 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On 2020-09-09 18:43, Auger Eric wrote:
>> Hi Marc,
>>
>> On 9/8/20 9:58 AM, Marc Zyngier wrote:
>>> As we can now hide events from the guest, let's also adjust its view of
>>> PCMEID{0,1}_EL1 so that it can figure out why some common
Hi Eric,
On 2020-09-09 18:43, Auger Eric wrote:
Hi Marc,
On 9/8/20 9:58 AM, Marc Zyngier wrote:
As we can now hide events from the guest, let's also adjust its view
of
PCMEID{0,1}_EL1 so that it can figure out why some common events are
not
counting as they should.
Referring to my previous c
Hi Marc,
On 9/8/20 9:58 AM, Marc Zyngier wrote:
> Add a small blurb describing how the event filtering API gets used.
>
> Signed-off-by: Marc Zyngier
> ---
> Documentation/virt/kvm/devices/vcpu.rst | 46 +
> 1 file changed, 46 insertions(+)
>
> diff --git a/Documentatio
Hi Marc,
On 9/8/20 9:58 AM, Marc Zyngier wrote:
> As we can now hide events from the guest, let's also adjust its view of
> PCMEID{0,1}_EL1 so that it can figure out why some common events are not
> counting as they should.
Referring to my previous comment should we filter the cycle counter out?
>
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 have a couple of MM fixes that have
>>> surfaced
Hi Marc,
On 9/8/20 9:58 AM, Marc Zyngier wrote:
> It can be desirable to expose a PMU to a guest, and yet not want the
> guest to be able to count some of the implemented events (because this
> would give information on shared resources, for example.
>
> For this, let's extend the PMUv3 device AP
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 have a couple of MM fixes that have
surfaced as people have started to use hugetlbfs in anger.
Hi Marc,
Hi Alex,
On 2020-09-09 15:20, Alexandru Elisei wrote:
Hi Will,
On 9/7/20 4:23 PM, Will Deacon wrote:
Convert user_mem_abort() to call kvm_pgtable_stage2_relax_perms() when
handling a stage-2 permission fault and kvm_pgtable_stage2_map() when
handling a stage-2 translation fault, rather than wa
On 09/09/2020 16:25, Andrew Jones wrote:
On Fri, Sep 04, 2020 at 05:00:16PM +0100, Steven Price wrote:
Arm's Memory Tagging Extension (MTE) adds 4 bits of tag data to every 16
bytes of memory in the system. This along with stashing a tag within the
high bit of virtual addresses allows runtime ch
On Wed, 9 Sep 2020 at 16:48, Andrew Jones wrote:
> We either need a KVM cap or a new CPU feature probing interface to avoid
> making userspace try features one at a time. It's too bad that VCPU_INIT
> doesn't clear all offending features from the feature set when returning
> EINVAL, because then u
On Fri, Sep 04, 2020 at 05:00:18PM +0100, Steven Price wrote:
> Add a new VCPU features 'KVM_ARM_VCPU_MTE' which enables memory tagging
> on a VCPU. When enabled on any VCPU in the virtual machine this causes
> all pages that are faulted into the VM to have the PG_mte_tagged flag
> set (and the tag
Hi Will,
On 9/7/20 4:23 PM, Will Deacon wrote:
> [..]
> +
> +int kvm_pgtable_walk(struct kvm_pgtable *pgt, u64 addr, u64 size,
> + struct kvm_pgtable_walker *walker)
> +{
> + struct kvm_pgtable_walk_data walk_data = {
> + .pgt= pgt,
> + .addr = AL
On Fri, Sep 04, 2020 at 05:00:16PM +0100, Steven Price wrote:
> Arm's Memory Tagging Extension (MTE) adds 4 bits of tag data to every 16
> bytes of memory in the system. This along with stashing a tag within the
> high bit of virtual addresses allows runtime checking of memory
> accesses.
>
> Thes
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.
Pao
Hi Will,
On 9/7/20 4:23 PM, Will Deacon wrote:
> Now that the guest stage-2 page-tables are managed independently from
> the host stage-1 page-tables, we can avoid constraining the IPA size
> based on the host and instead limit it only based on the PARange field
> of the ID_AA64MMFR0 register.
>
>
Hi Will,
On 9/7/20 4:23 PM, Will Deacon wrote:
> Convert user_mem_abort() to call kvm_pgtable_stage2_relax_perms() when
> handling a stage-2 permission fault and kvm_pgtable_stage2_map() when
> handling a stage-2 translation fault, rather than walking the page-table
> manually.
>
> Cc: Marc Zyngie
On Tue, Sep 08, 2020 at 12:02:22PM +0100, Andrew Scull wrote:
> On Mon, Sep 07, 2020 at 03:20:07PM +0100, Marc Zyngier wrote:
> > On Thu, 03 Sep 2020 14:53:05 +0100,
> > Andrew Scull wrote:
> > >
> > > Rather than passing arbitrary function pointers to run at hyp, define
> > > and equivalent set
Hi Will,
I'm answering my own question, again. See below.
On 9/8/20 2:07 PM, Alexandru Elisei wrote:
> Hi Will,
>
> On 9/3/20 6:57 PM, Will Deacon wrote:
>> On Wed, Sep 02, 2020 at 05:23:08PM +0100, Alexandru Elisei wrote:
>>> On 8/25/20 10:39 AM, Will Deacon wrote:
Convert unmap_stage2_rang
Hi Marc,
On 9/9/20 11:54 AM, Marc Zyngier wrote:
> Hi Eric,
>
> On 2020-09-09 10:38, Auger Eric wrote:
>> Hi Marc,
>>
>> On 9/8/20 9:58 AM, Marc Zyngier wrote:
>>> The PMU code suffers from a small defect where we assume that the event
>>> number provided by the guest is always 16 bit wide, even
On Wed, Sep 09, 2020 at 10:43:41AM +0200, Alexander Graf wrote:
> Hey Drew!
>
> On 09.09.20 08:25, Andrew Jones wrote:
> >
> > On Tue, Sep 08, 2020 at 10:57:30PM +0200, Alexander Graf wrote:
> > > We currently pass through the number of PMU counters that we have
> > > available
> > > in hardware
Hi Eric,
On 2020-09-09 10:38, Auger Eric wrote:
Hi Marc,
On 9/8/20 9:58 AM, Marc Zyngier wrote:
The PMU code suffers from a small defect where we assume that the
event
number provided by the guest is always 16 bit wide, even if the CPU
only
implements the ARMv8.0 architecture. This isn't rea
Hi Marc,
On 9/8/20 9:58 AM, Marc Zyngier wrote:
> The PMU code suffers from a small defect where we assume that the event
> number provided by the guest is always 16 bit wide, even if the CPU only
> implements the ARMv8.0 architecture. This isn't really problematic in
> the sense that the event nu
On 07/09/2020 16:28, Dr. David Alan Gilbert wrote:
(cc'ing in Eric Auger)
* Steven Price (steven.pr...@arm.com) wrote:
Arm's Memory Tagging Extension (MTE) adds 4 bits of tag data to every 16
bytes of memory in the system. This along with stashing a tag within the
high bit of virtual addresses
Hi Marc,
Noticed this patch while catching up with the lists.
Marc Zyngier writes:
> For the obscure cases where PMD and PUD are the same size
> (64kB pages with 42bit VA, for example, which results in only
> two levels of page tables), we can't map anything as a PUD,
> because there is... erm.
34 matches
Mail list logo
