Hi Marc,
In RFC patch, I still write protect huge pages when DIRTY_LOG_INITIALLY_ALL_SET
is enabled by userspace. I find that both huge pages and normal pages can be
write protected during log clear. So this formal patch is pretty simple now.
Thanks,
Keqian
On 2020/4/13 20:20, Keqian Zhu wrote:
On 2020/4/14 11:03, Zenghui Yu wrote:
If we're going to fail out the vgic_add_lpi(), let's make sure the
allocated vgic_irq memory is also freed. Though it seems that both
cases are unlikely to fail.
Cc: Zengruan Ye
Signed-off-by: Zenghui Yu
---
virt/kvm/arm/vgic/vgic-its.c | 8 ++--
1
On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote:
>
> On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei
> wrote:
> >
> > Hi,
> >
> > I've tested this patch by running badblocks and fio on a flash device
> > inside a
> > guest, everything worked as expected.
> >
> > I've also looked at the
On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei wrote:
>
> Hi,
>
> I've tested this patch by running badblocks and fio on a flash device inside a
> guest, everything worked as expected.
>
> I've also looked at the flowcharts for device operation from Intel Application
> Note 646, pages 12-21, and
On Wed, 15 Apr 2020 at 18:11, André Przywara wrote:
>
> On 15/04/2020 16:55, Ard Biesheuvel wrote:
> > On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote:
> >>
> >> On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I've tested this patch by running badblocks
On Wed, 15 Apr 2020 at 18:36, André Przywara wrote:
>
> On 15/04/2020 17:20, Ard Biesheuvel wrote:
> > On Wed, 15 Apr 2020 at 18:11, André Przywara wrote:
> >>
> >> On 15/04/2020 16:55, Ard Biesheuvel wrote:
> >>> On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote:
>
> On Tue, 7 Apr
Hi Marc,
On Wed, Apr 15, 2020 at 09:55:57AM +0100, Marc Zyngier wrote:
> On 2020-04-14 22:31, Will Deacon wrote:
> > Although we emit a "SANITY CHECK" warning and taint the kernel if we
> > detect a CPU mismatch for AArch32 support at EL1, we still online the
> > CPU with disastrous consequences
On 15/04/2020 17:20, Ard Biesheuvel wrote:
> On Wed, 15 Apr 2020 at 18:11, André Przywara wrote:
>>
>> On 15/04/2020 16:55, Ard Biesheuvel wrote:
>>> On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote:
On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei
wrote:
>
> Hi,
>
On Tue, 14 Apr 2020 17:56:25 +0200
Emanuele Giuseppe Esposito wrote:
> The macros VM_STAT and VCPU_STAT are redundantly implemented in multiple
> files, each used by a different architecure to initialize the debugfs
> entries for statistics. Since they all have the same purpose, they can be
>
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/2020 16:55, Ard Biesheuvel wrote:
> On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote:
>>
>> On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei
>> wrote:
>>>
>>> Hi,
>>>
>>> I've tested this patch by running badblocks and fio on a flash device
>>> inside a
>>> guest, everything worked as
On 15/04/2020 16:43, Ard Biesheuvel wrote:
Hi Ard,
> On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei
> wrote:
>>
>> Hi,
>>
>> I've tested this patch by running badblocks and fio on a flash device inside
>> a
>> guest, everything worked as expected.
>>
>> I've also looked at the flowcharts for
Hi Jacob,
On 4/15/20 5:59 PM, Jacob Pan wrote:
> On Wed, 15 Apr 2020 16:52:10 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>> On 4/15/20 12:15 AM, Jacob Pan wrote:
>>> Hi Eric,
>>>
>>> There are some discussions about how to size the uAPI data.
>>> https://lkml.org/lkml/2020/4/14/939
>>>
>>> I
On Wed, 15 Apr 2020 16:52:10 +0200
Auger Eric wrote:
> Hi Jacob,
> On 4/15/20 12:15 AM, Jacob Pan wrote:
> > Hi Eric,
> >
> > There are some discussions about how to size the uAPI data.
> > https://lkml.org/lkml/2020/4/14/939
> >
> > I think the problem with the current scheme is that 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
Hi Jacob,
On 4/15/20 12:15 AM, Jacob Pan wrote:
> Hi Eric,
>
> There are some discussions about how to size the uAPI data.
> https://lkml.org/lkml/2020/4/14/939
>
> I think the problem with the current scheme is that when uAPI data gets
> extended, if VFIO continue to use:
>
> minsz =
Hi Zenghui,
On 2020-04-15 14:15, Zenghui Yu wrote:
Hi Marc,
On 2020/4/14 18:35, Marc Zyngier wrote:
When a guest tries to read the active state of its interrupts,
we currently just return whatever state we have in memory. This
means that if such an interrupt lives in a List Register on
On Wed, 15 Apr 2020 14:15:51 +0100
Suzuki K Poulose wrote:
> On 04/15/2020 11:14 AM, Will Deacon wrote:
> > On Wed, Apr 15, 2020 at 11:13:54AM +0100, Suzuki K Poulose wrote:
> >> On 04/14/2020 10:31 PM, Will Deacon wrote:
> >>> Although we emit a "SANITY CHECK" warning and taint the kernel
Hi Marc,
On 2020/4/14 18:35, Marc Zyngier wrote:
When a guest tries to read the active state of its interrupts,
we currently just return whatever state we have in memory. This
means that if such an interrupt lives in a List Register on another
CPU, we fail to obsertve the latest active state
On 04/15/2020 11:14 AM, Will Deacon wrote:
On Wed, Apr 15, 2020 at 11:13:54AM +0100, Suzuki K Poulose wrote:
On 04/14/2020 10:31 PM, Will Deacon wrote:
Although we emit a "SANITY CHECK" warning and taint the kernel if we
detect a CPU mismatch for AArch32 support at EL1, we still online the
CPU
On Wed, 15 Apr 2020 10:30:06 +0200
Emanuele Giuseppe Esposito wrote:
> On 4/15/20 8:36 AM, Philippe Mathieu-Daudé wrote:
> > On 4/14/20 5:56 PM, Emanuele Giuseppe Esposito wrote:
> >> The macros VM_STAT and VCPU_STAT are redundantly implemented in
> >> multiple files, each used by a different
On Wed, Apr 15, 2020 at 12:37:31PM +0100, Suzuki K Poulose wrote:
> On 04/15/2020 11:58 AM, Will Deacon wrote:
> > On Wed, Apr 15, 2020 at 11:50:58AM +0100, Suzuki K Poulose wrote:
> > > On 04/14/2020 10:31 PM, Will Deacon wrote:
> > > > We don't need to be quite as strict about mismatched AArch32
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/mips/kvm/mips.c
>>> +++
On 04/15/2020 11:58 AM, Will Deacon wrote:
On Wed, Apr 15, 2020 at 11:50:58AM +0100, Suzuki K Poulose wrote:
On 04/14/2020 10:31 PM, Will Deacon wrote:
We don't need to be quite as strict about mismatched AArch32 support,
which is good because the friendly hardware folks have been busy
On Wed, Apr 15, 2020 at 11:50:58AM +0100, Suzuki K Poulose wrote:
> On 04/14/2020 10:31 PM, Will Deacon wrote:
> > We don't need to be quite as strict about mismatched AArch32 support,
> > which is good because the friendly hardware folks have been busy
> > mismatching this to their hearts'
The only user of PTE_S2_MEMATTR_MASK macro had been removed since
commit a501e32430d4 ("arm64: Clean up the default pgprot setting").
It has been about six years and no one has used it again.
Let's drop it.
Signed-off-by: Zenghui Yu
---
arch/arm64/include/asm/pgtable-hwdef.h | 1 -
1 file
On 04/14/2020 10:31 PM, Will Deacon wrote:
We don't need to be quite as strict about mismatched AArch32 support,
which is good because the friendly hardware folks have been busy
mismatching this to their hearts' content.
* We don't care about EL2 or EL3 (there are silly comments concerning
On 04/14/2020 10:31 PM, Will Deacon wrote:
If AArch32 is not supported at EL1, the AArch32 feature register fields
no longer advertise support for some system features:
* ISAR4.SMC
* PFR1.{Virt_frac, Sec_frac, Virtualization, Security, ProgMod}
In which case, we don't need to emit
On 04/14/2020 10:31 PM, Will Deacon wrote:
update_cpu_features() is pretty large, so split out the checking of the
AArch32 features into a separate function and call it after checking the
AArch64 features.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/cpufeature.c | 108
On 04/14/2020 10:31 PM, Will Deacon wrote:
There's no need to call id_aa64pfr0_32bit_el0() twice because the
sanitised value of ID_AA64PFR0_EL1 has already been updated for the CPU
being onlined.
Remove the redundant function call.
Signed-off-by: Will Deacon
Reviewed-by: Suzuki K Poulose
On Wed, Apr 15, 2020 at 11:13:54AM +0100, Suzuki K Poulose wrote:
> On 04/14/2020 10:31 PM, Will Deacon wrote:
> > Although we emit a "SANITY CHECK" warning and taint the kernel if we
> > detect a CPU mismatch for AArch32 support at EL1, we still online the
> > CPU with disastrous consequences for
On 04/14/2020 10:31 PM, Will Deacon wrote:
Although we emit a "SANITY CHECK" warning and taint the kernel if we
detect a CPU mismatch for AArch32 support at EL1, we still online the
CPU with disastrous consequences for any running 32-bit VMs.
Introduce a capability for AArch32 support at EL1 so
On 04/14/2020 10:31 PM, Will Deacon wrote:
In preparation for runtime updates to the strictness of some AArch32
features, spell out the register fields for ID_ISAR4 and ID_PFR1 to make
things clearer to read. Note that this isn't functionally necessary, as
the feature arrays themselves are not
Hi Will
On 04/14/2020 10:31 PM, Will Deacon wrote:
From: Sai Prakash Ranjan
We don't care if IESB is supported or not as we always set
SCTLR_ELx.IESB and, if it works, that's really great.
Relax the ID_AA64MMFR2.IESB cpufeature check so that we don't warn and
taint if it's mismatched.
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/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -290,8 +290,7 @@ static enum hrtimer_restart
On 4/14/20 5:56 PM, Emanuele Giuseppe Esposito wrote:
> The macros VM_STAT and VCPU_STAT are redundantly implemented in multiple
> files, each used by a different architecure to initialize the debugfs
> entries for statistics. Since they all have the same purpose, they can be
> unified in a single
On 4/15/20 8:36 AM, Philippe Mathieu-Daudé wrote:
On 4/14/20 5:56 PM, Emanuele Giuseppe Esposito wrote:
The macros VM_STAT and VCPU_STAT are redundantly implemented in multiple
files, each used by a different architecure to initialize the debugfs
entries for statistics. Since they all have
On 2020/4/14 22:26, Vitaly Kuznetsov wrote:
Tianjia Zhang writes:
kvm_arch_vcpu_ioctl_run() is only called in the file kvm_main.c,
where vcpu->run is the kvm_run parameter, so it has been replaced.
Signed-off-by: Tianjia Zhang
---
arch/x86/kvm/x86.c | 8
virt/kvm/arm/arm.c |
Hi Will,
On 2020-04-14 22:31, Will Deacon wrote:
Although we emit a "SANITY CHECK" warning and taint the kernel if we
detect a CPU mismatch for AArch32 support at EL1, we still online the
CPU with disastrous consequences for any running 32-bit VMs.
Introduce a capability for AArch32 support at
stage2_unmap_vm() was introduced to unmap user RAM region in the stage2
page table to make the caches coherent. E.g., a guest reboot with stage1
MMU disabled will access memory using non-cacheable attributes. If the
RAM and caches are not coherent at this stage, some evicted dirty cache
line may
40 matches
Mail list logo
