d two bits to distinguish
> availability of A/D bits from write protection. So, while at
> it give MMIO its own bit pattern, and move the two bits from
> bit 62 to bits 52..53 since Intel is allocating EPT page table
> bits from the top.
>
> Signed-off-by: Paolo Bonzini
> ---
Reviewed-by: Junaid Shahid
ct()
check to the if statement inside __rmap_clear_dirty() instead, since it already
checks for spte_ad_enabled() to decide between write-protection and
dirty-clearing.
Reviewed-by: Junaid Shahid
quent accesses that are wrong. Therefore, we can equip
> set_spte (where the first access happens) to record that the SPTE will
> have to be write protected, and then spte_clear_dirty will use this
> information to do the right thing.
>
> Signed-off-by: Paolo Bonzini
> ---
Reviewed-by: Junaid Shahid
vcpu ioctl
I suppose that this should be "vm ioctl".
> Parameters: struct kvm_enable_cap (in)
> Returns: 0 on success; -1 on error
...
Reviewed-by: Junaid Shahid
vm/arm/arm.c | 6 +++---
> virt/kvm/kvm_main.c | 6 +++---
> 5 files changed, 13 insertions(+), 13 deletions(-)
>
Reviewed-by: Junaid Shahid
On 11/26/2018 08:54 AM, Paolo Bonzini wrote:
> There are two problems with KVM_GET_DIRTY_LOG. First, and less important,
> it can take kvm->mmu_lock for an extended period of time. Second, its user
> can actually see many false positives in some cases. The latter is due
> to a benign race like t
; its physical address width")' removes the bit 63 checking
> unconditionally. This patch fixes it by checking bit 63 of CR3
> when PCIDE bit is not set in CR4.
>
> Fixes: d1cd3ce900441 (KVM: MMU: check guest CR3 reserved bits based on its
> physical address width)
> Cc
@@ -2934,7 +2935,7 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64
>> *sptep, unsigned pte_access,
>> ret = RET_PF_EMULATE;
>> kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
>> }
>> -if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)
>> +if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH || flush)
>> kvm_flush_remote_tlbs(vcpu->kvm);
>>
>> if (unlikely(is_mmio_spte(*sptep)))
>>
>
Reviewed-by: Junaid Shahid
KTHREAD_SHOULD_STOP and the
setting of KTHREAD_IS_PARKED atomic via a cmpxchg inside kthread_parkme.
Signed-off-by: Junaid Shahid
---
kernel/kthread.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 26db528c1d88..651f03baf62f
(Resending)
On Friday, April 28, 2017 07:32:36 PM Junaid Shahid wrote:
> In general, if kthread_unpark() and kthread_parkme() execute together,
> the kthread is supposed to be in an unparked state. This is because
> kthread_unpark() either wakes up the thread if it already got parked
(Adding back the correct linux-mm email address and also adding linux-kernel.)
On Thursday, May 18, 2017 01:41:33 PM David Rientjes wrote:
> On Thu, 18 May 2017, Michal Hocko wrote:
>
> > On Thu 18-05-17 11:50:40, Junaid Shahid wrote:
> > > d224e9381897 (drivers/md/dm-
[Resending after delivery failure]
Hi Dave,
On 02/13/2018 10:22 AM, Dave Watson wrote:
>
> Yes, these both sound reasonable. I will send a V2.
>
> Thanks!
Another minor suggestion for v2:
It might be a good idea to check if the first assoclen bytes are already
contiguous and only do the kmall
re call to kthread_park
complete prematurely.
Thanks,
Junaid
On Friday, September 29, 2017 10:28:38 AM Peter Zijlstra wrote:
> On Fri, Sep 29, 2017 at 09:59:55AM +0200, Thomas Gleixner wrote:
> > On Thu, 28 Sep 2017, Junaid Shahid wrote:
> >
> > > Hi Peter,
> > >
> >
Hi Dave,
On 02/12/2018 11:51 AM, Dave Watson wrote:
> +static int gcmaes_encrypt_sg(struct aead_request *req, unsigned int assoclen,
> + u8 *hash_subkey, u8 *iv, void *aes_ctx)
>
> +static int gcmaes_decrypt_sg(struct aead_request *req, unsigned int assoclen,
> +
Hi,
Has anyone been able to take a look at this?
Thanks,
Junaid
On Tuesday, May 30, 2017 03:40:02 PM Andrew Morton wrote:
> (cc tglx & tj)
>
> On Tue, 30 May 2017 15:37:23 -0700 Junaid Shahid wrote:
>
> > (Resending)
> >
> > On Friday, April 28, 20
On Monday, December 18, 2017 3:41:41 PM PST Huang, Ying wrote:
>
> A version implemented via stop_machine() could be gotten via a small
> patch as below. If you still prefer stop_machine(), I can resend a
> version implemented with stop_machine().
>
For the stop_machine() version, would it work
prandom_bytes_state
call with "rand = entropy;"
Signed-off-by: Junaid Shahid
---
arch/x86/mm/kaslr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 6e6b39710e5f..fe3eec30f736 100644
--- a/arch/x86/mm/kaslr.c
+++ b/a
On 6/30/20 3:07 AM, Vitaly Kuznetsov wrote:
Undesired triple fault gets injected to L1 guest on SVM when L2 is
launched with certain CR3 values. It seems the mmu_check_root()
check in fast_pgd_switch() is wrong: first of all we don't know
if 'new_pgd' is a GPA or a nested GPA and, in case it is a
18 matches
Mail list logo
