Fixes: 6491d4d02893 ("intel-iommu: Free old page tables before creating
superpage")
Cc: # v3.0+
Link:
https://lore.kernel.org/linux-iommu/670baaf8-4ff8-4e84-4be3-030b95ab5...@huawei.com/
Suggested-by: Lu Baolu
Signed-off-by: Longpeng(Mike)
---
v1 -> v2:
- add Joerg
- reconstruct the so
Hi Baolu,
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, April 8, 2021 12:32 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; io...@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org
> Cc: bao
Hi Baolu,
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Friday, April 2, 2021 12:44 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; io...@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org
> Cc: bao
Hi Baolu,
在 2021/4/2 11:06, Lu Baolu 写道:
> Hi Longpeng,
>
> On 4/1/21 3:18 PM, Longpeng(Mike) wrote:
>> The translation caches may preserve obsolete data when the
>> mapping size is changed, suppose the following sequence which
>> can reveal the problem with high pr
ntel-iommu: Free old page tables before creating
superpage")
Cc: # v3.0+
Link:
https://lore.kernel.org/linux-iommu/670baaf8-4ff8-4e84-4be3-030b95ab5...@huawei.com/
Suggested-by: Lu Baolu
Signed-off-by: Longpeng(Mike)
---
drivers/iommu/intel/iommu.c | 15 +--
1 file changed, 13 i
> -Original Message-
> From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> Sent: Monday, March 22, 2021 7:51 AM
> To: 'Nadav Amit'
> Cc: Tian, Kevin ; chenjiashang
> ; David Woodhouse ;
> io...@lists.linux-foundation.org; LKML ;
> a
Hi Nadav,
> -Original Message-
> From: Nadav Amit [mailto:nadav.a...@gmail.com]
> Sent: Friday, March 19, 2021 12:46 AM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
> Cc: Tian, Kevin ; chenjiashang
> ; David Woodhouse ;
> io...@lists.li
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Thursday, March 18, 2021 4:56 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; Nadav Amit
> Cc: chenjiashang ; David Woodhouse
> ; io...@lists.linux
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Thursday, March 18, 2021 4:43 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; Nadav Amit
> Cc: chenjiashang ; David Woodhouse
> ; io...@lists.linux
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Thursday, March 18, 2021 4:27 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; Nadav Amit
> Cc: chenjiashang ; David Woodhouse
> ; io...@lists.linux
Hi Nadav,
> -Original Message-
> From: Nadav Amit [mailto:nadav.a...@gmail.com]
> Sent: Thursday, March 18, 2021 2:13 AM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
> Cc: David Woodhouse ; Lu Baolu
> ; Joerg Roedel ; w...@kernel.org;
> al
Hi guys,
I provide more information, please see below
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, March 18, 2021 10:59 AM
> To: Alex Williamson
> Cc: baolu...@linux.intel.com; Longpeng (Mike, Cloud Infrastructure Service
&
Hi Baolu,
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Wednesday, March 17, 2021 1:17 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; dw...@infradead.org; j...@8bytes.org;
> w...@kernel.org; alex.william...@redh
Hi Nadav,
> -Original Message-
> From: Nadav Amit [mailto:nadav.a...@gmail.com]
> Sent: Wednesday, March 17, 2021 1:46 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
> Cc: David Woodhouse ; Lu Baolu
> ; Joerg Roedel ; w...@kernel.org;
> al
Hi guys,
We find the Intel iommu cache (i.e. iotlb) maybe works wrong in a special
situation, it would cause DMA fails or get wrong data.
The reproducer (based on Alex's vfio testsuite[1]) is in attachment, it can
reproduce the problem with high probability (~50%).
The machine we used is:
proces
在 2021/1/20 18:27, Paraschiv, Andra-Irina 写道:
>
>
> On 19/01/2021 05:30, Longpeng(Mike) wrote:
>> According the PCI spec:
>> Bus Master Enable – Controls the ability of a PCI Express
>> Endpoint to issue Memory and I/O Read/Write Requests, and
>> the
PCI conformant.
Signed-off-by: Longpeng(Mike)
---
drivers/virt/nitro_enclaves/ne_pci_dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/virt/nitro_enclaves/ne_pci_dev.c
b/drivers/virt/nitro_enclaves/ne_pci_dev.c
index b9c1de4..143207e 100644
--- a/drivers/virt/nitro_enclaves
atch to these stable tree, but it seems there're some
other bugs. so I think the best way to resolve these conflicts is to apply the
dependent patches detected.
If we apply these dependent patches, then the conflicts of other two patches:
crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req
crypto: virtio: Fix dest length calculation in __virtio_crypto_skcipher_do_req
will also be gone.
---
Regards,
Longpeng(Mike)
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Message-Id: <20200123101000.GB24255@Red>
Signed-off-by: Gonglei
Signed-off-by: Longpeng(Mike)
---
drivers/crypto/virtio/virtio_crypto_algs.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/virtio
linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Message-Id: <20200123101000.GB24255@Red>
Acked-by: Gonglei
Signed-off-by: Longpeng(Mike)
---
drivers/crypto/virtio/virtio_crypto_algs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/vir
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: "David S. Miller"
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Longpeng(Mike) (3):
crypto: virtio: Fix src/dst scatterlist calculation in
__virtio_crypto_skcipher_d
uffer.
Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver")
Cc: Gonglei
Cc: Herbert Xu
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: "David S. Miller"
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Signed-o
ipher API")
>>
>>
>> NOTE: The patch will not be queued to stable trees until it is upstream.
>>
>> How should we proceed with this patch?
>
> Mike could you comment on backporting?
>
Hi Michael,
I will send V3, so I will resolve these conflicts later. :)
>> --
>> Thanks
>> Sasha
>
> .
>
---
Regards,
Longpeng(Mike)
after look at the
code.
I hope experts in the thread could review the code when you free, thanks :)
---
Regards,
Longpeng(Mike)
'
How about:
'''
When the virtio_crypto driver finish the skcipher request, it will call the
function "crypto_finalize_skcipher_request()" and then free the resources whose
pointers are stored in the 'skcipher parts', but the pointers of these resources
may be changed in that function. Thus fix it by releasing these resources
befored calling the function "crypto_finalize_skcipher_request()".
'''
> Regards,
> Markus
>
---
Regards,
Longpeng(Mike)
on, so validate it here is
needed ?
'''
/* Source data */
- for (i = 0; i < src_nents; i++)
- sgs[num_out++] = &req->src[i];
+ for (sg = req->src; src_nents; sg = sg_next(sg), src_nents--)
+ sgs[num_out++] = sg;
'''
> Regards,
> Markus
>
--
---
Regards,
Longpeng(Mike)
foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Message-Id: <20200123101000.GB24255@Red>
Signed-off-by: Longpeng(Mike)
---
drivers/crypto/virtio/virtio_crypto_algs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/virtio
.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Message-Id: <20200123101000.GB24255@Red>
Signed-off-by: Gonglei
Signed-off-by: Longpeng(Mike)
---
drivers/crypto/virtio/virtio_crypto_algs.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a
lizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Longpeng(Mike) (2):
crypto: virtio: Fix src/dst scatterlist calculation in
__virtio_crypto_skcipher_do_req()
crypto: virtio: Fix use-after-free in
virtio_crypto_skcipher_finalize_req()
d
rces may be changed in the
> function “crypto_finalize_skcipher_request”.
> Thus release specific resources before calling this function.
>
Oh great! Thanks.
> Regards,
> Markus
>
--
---
Regards,
Longpeng(Mike)
skcipher_request", so free these resources before call the
function is suitable.
> * Would you like to add the tag “Fixes” to the commit message?
>
OK.
> Regards,
> Markus
>
--
---
Regards,
Longpeng(Mike)
er validation?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=9cb1fd0efd195590b828b9b865421ad345a4a145#n138
>
> Would you like to add the tag “Fixes” to the commit message?
>
Will take all of your suggestions in v2, thanks.
> Regards,
> Markus
>
--
---
Regards,
Longpeng(Mike)
Hi Jason,
On 2020/5/25 11:12, Jason Wang wrote:
>
> On 2020/5/25 上午8:56, Longpeng(Mike) wrote:
>> The system will crash when we insmod crypto/tcrypt.ko whit mode=38.
>>
>> Usually the next entry of one sg will be @sg@ + 1, but if this sg element
>> is part of a chai
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: "David S. Miller"
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Reported-by: LABBE Corentin
Signed-off-by: Longpeng(Mike)
---
drivers/crypto/virtio/virtio_crypto_algs.c
Link: https://lkml.org/lkml/2020/1/23/205
Cc: Gonglei
Cc: Herbert Xu
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: "David S. Miller"
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Longpeng(Mike) (2):
crypto: virtio: fix src/dst sca
l.org
Reported-by: LABBE Corentin
Signed-off-by: Gonglei
Signed-off-by: Longpeng(Mike)
---
drivers/crypto/virtio/virtio_crypto_algs.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
b/drivers/crypto/virtio/v
From: Longpeng
If the msix_affinity_masks is alloced failed, then we'll
try to free some resources in vp_free_vectors() that may
access it directly.
We met the following stack in our production:
[ 29.296767] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 29.311151] IP: []
_rq)
return;
- if (throttled_hierarchy(gcfs_rq))
- return;
-
#ifndef CONFIG_SMP
runnable = shares = READ_ONCE(gcfs_rq->tg->shares);
So do guys you have any suggestion on this problem ? Is there a better way fix
this problem ?
--
Regards,
Longpeng(Mike)
The efer_reload is never used since
commit 26bb0981b3ff ("KVM: VMX: Use shared msr infrastructure"),
so remove it.
Signed-off-by: Longpeng(Mike)
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/x86.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/x86/i
wrmsrl(MSR_IA32_SPEC_CTRL, 0);
> + }
> + /*
> + * Speculative execution past the above wrmsrl might encounter
> + * an indirect branch and use guest-controlled contents of the
> + * indirect branch predictor; block it.
> + */
> + asm("lfence");
> +
> /* MSR_IA32_DEBUGCTLMSR is zeroed on vmexit. Restore it if needed */
> if (vmx->host_debugctlmsr)
> update_debugctlmsr(vmx->host_debugctlmsr);
--
Regards,
Longpeng(Mike)
Hi Paolo,
We have backported the first three patches and have tested for about 20 days, it
works fine.
So could you consider to merge this series ?
--
Regards,
Longpeng(Mike)
On 2017/7/11 17:16, Gonglei (Arei) wrote:
>
>
>> -Original Message-
>> From: kvm-ow.
Hi Peng,
There are two bugs in current code and Paolo already fixed them, please see:
https://www.spinics.net/lists/kvm/msg150896.html
--
Regards,
Longpeng(Mike)
On 2017/9/21 23:14, Peng Hao wrote:
> use kvm_vcpu_pi_need_handle encapsulation simply coede
>
> Signed-off-by:
/qemu-devel/2016-01/msg00664.html
[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg02891.html
--
Regards,
Longpeng(Mike)
ml
[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg02891.html
--
Regards,
Longpeng(Mike)
On 2017/8/10 21:18, Eric Farman wrote:
>
>
> On 08/08/2017 04:14 AM, Longpeng (Mike) wrote:
>>
>>
>> On 2017/8/8 15:41, Cornelia Huck wrote:
>>
>>> On Tue, 8 Aug 2017 12:05:31 +0800
>>> "Longpeng(Mike)" wrote:
>>>
>>
On 2017/8/8 21:57, Paolo Bonzini wrote:
> On 08/08/2017 15:50, Longpeng (Mike) wrote:
>>
>>
>> On 2017/8/8 21:08, Paolo Bonzini wrote:
>>
>>> On 08/08/2017 13:37, Longpeng(Mike) wrote:
>>>> Currently 'apic_arb_prio' is int32_t, it'
On 2017/8/8 21:08, Paolo Bonzini wrote:
> On 08/08/2017 13:37, Longpeng(Mike) wrote:
>> Currently 'apic_arb_prio' is int32_t, it's too short for long
>> time running. In our environment, it overflowed and then the
>> UBSAN was angry:
>>
>> sign
On 2017/8/8 19:25, David Hildenbrand wrote:
> On 08.08.2017 06:05, Longpeng(Mike) wrote:
>> This is a simple optimization for kvm_vcpu_on_spin, the
>> main idea is described in patch-1's commit msg.
>>
>> I did some tests base on the RFC version, the result s
0/24/365 = 584942417 )
Signed-off-by: Longpeng(Mike)
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/ioapic.h | 3 ++-
arch/x86/kvm/irq_comm.c | 2 +-
arch/x86/kvm/lapic.c| 6 +++---
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/inc
; [arch/x86/kvm/kvm-intel.ko] undefined!
ERROR: "kvm_arch_vcpu_in_kernel" [arch/x86/kvm/kvm-amd.ko] undefined!
But Paolo's approach is significantly better, it's a work of art, thanks a lot.
--
Regards,
Longpeng(Mike)
>>> -void kvm_vcpu_on_spin(struct kv
On 2017/8/8 15:30, Paolo Bonzini wrote:
> On 08/08/2017 06:05, Longpeng(Mike) wrote:
>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>> index cd0e6e6..dec5e8a 100644
>> --- a/arch/x86/kvm/hyperv.c
>> +++ b/arch/x86/kvm/hyperv.c
>> @@ -1268,7 +1268
On 2017/8/8 15:41, Cornelia Huck wrote:
> On Tue, 8 Aug 2017 12:05:31 +0800
> "Longpeng(Mike)" wrote:
>
>> This is a simple optimization for kvm_vcpu_on_spin, the
>> main idea is described in patch-1's commit msg.
>
> I think this generally looks g
This implements the kvm_arch_vcpu_in_kernel() for s390.
Signed-off-by: Longpeng(Mike)
---
arch/s390/kvm/kvm-s390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 0b0c689..e46177b 100644
--- a/arch/s390/kvm/kvm-s390.c
1. Implements the kvm_arch_vcpu_in_kernel(), because get_cpl requires
vcpu_load, so we must cache the result(whether the vcpu was preempted
when its cpl=0) in kvm_vcpu_arch.
2. Add ->spin_in_kernel hook, because we can get benefit from VMX.
Signed-off-by: Longpeng(Mike)
---
arch/x86/incl
kvm_arch_vcpu_in_kernel() to decide whether the
vcpu is in kernel-mode when it's preempted or spinlock exit.
Signed-off-by: Longpeng(Mike)
---
arch/arm/kvm/handle_exit.c | 2 +-
arch/arm64/kvm/handle_exit.c | 2 +-
arch/mips/kvm/mips.c | 6 ++
arch/powerpc/kvm/powerpc.c
This implements the kvm_arch_vcpu_in_kernel() for ARM.
Signed-off-by: Longpeng(Mike)
---
virt/kvm/arm/arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 862f820..b9f68e4 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
efactor the impls according to the suggestion. [Paolo]
Changes since RFC:
- only cache result for X86. [David & Cornlia & Paolo]
- add performance numbers. [David]
- impls arm/s390. [Christoffer & David]
- refactor the impls. [me]
---
Longpeng(Mike) (4):
KVM: add spinlock optimiza
On 08/07/2017 06:45 PM, Paolo Bonzini wrote:
On 07/08/2017 10:44, Longpeng(Mike) wrote:
+
+ /*
+* Intel sdm vol3 ch-25.1.3 says: The “PAUSE-loop exiting”
+* VM-execution control is ignored if CPL > 0. So the vcpu
+* is always exiting with CPL=0 if it uses
On 2017/8/7 16:55, David Hildenbrand wrote:
> On 07.08.2017 10:44, Longpeng(Mike) wrote:
>> If the vcpu(me) exit due to request a usermode spinlock, then
>> the spinlock-holder may be preempted in usermode or kernmode.
>>
>> But if the vcpu(me) is in kernmo
On 2017/8/7 16:52, David Hildenbrand wrote:
> On 07.08.2017 10:44, Longpeng(Mike) wrote:
>> Implements the kvm_arch_vcpu_spin/preempt_in_kernel() for arm/s390,
>> they needn't cache the result.
>>
>> Signed-off-by: Longpeng(Mike)
>> ---
>> arch/s
architecture(e.g. arm/s390), spin/preempt_in_kernel()
are the same, but they are different for X86.
Signed-off-by: Longpeng(Mike)
---
arch/mips/kvm/mips.c | 10 ++
arch/powerpc/kvm/powerpc.c | 10 ++
arch/s390/kvm/kvm-s390.c | 10 ++
arch/x86/kvm/x86.c | 10
Implements the kvm_arch_vcpu_spin/preempt_in_kernel() for arm/s390,
they needn't cache the result.
Signed-off-by: Longpeng(Mike)
---
arch/s390/kvm/kvm-s390.c | 4 ++--
virt/kvm/arm/arm.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/kvm-s39
Implements the kvm_arch_vcpu_spin/preempt_in_kernel(), because get_cpl
requires vcpu_load, so we must cache the result(whether the vcpu was
preempted when its cpl=0) in kvm_arch_vcpu.
Signed-off-by: Longpeng(Mike)
---
arch/x86/include/asm/kvm_host.h | 5 +
arch/x86/kvm/svm.c
lo]
- add performance numbers. [David]
- impls arm/s390. [Christoffer & David]
- refactor the impls. [me]
---
Longpeng(Mike) (3):
KVM: add spinlock-exiting optimize framework
KVM: X86: implement the logic for spinlock optimization
KVM: implement spinlock optimization logic for arm/s
e_vmcall+0x1a/0x30 [kvm_intel]
[] vmx_handle_exit+0x7a2/0x1fa0 [kvm_intel]
...
Signed-off-by: Longpeng(Mike)
---
arch/x86/kvm/x86.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6c97c82..b411f92 100644
--- a/arch/x86/kvm/x86.c
+++ b/ar
d_out).
In this approach, vmx_sched_out would only call vmx_get_cpl, isn't too
redundant, because we can just call kvm_x86_ops->get_cpl instead at the right
place?
> This will cache the result until the next sched_in, so that
'until the next sched_in' --> Do we need to clear the result in sched in ?
> kvm_vcpu_on_spin can use it.
>
> Paolo
>
> .
>
--
Regards,
Longpeng(Mike)
On 2017/7/31 21:22, Christoffer Dall wrote:
> On Sat, Jul 29, 2017 at 02:22:57PM +0800, Longpeng(Mike) wrote:
>> We had disscuss the idea here:
>> https://www.spinics.net/lists/kvm/msg140593.html
>
> This is not a very nice way to start a commit description.
>
> P
On 2017/7/31 20:31, Cornelia Huck wrote:
> On Mon, 31 Jul 2017 20:08:14 +0800
> "Longpeng (Mike)" wrote:
>
>> Hi David,
>>
>> On 2017/7/31 19:31, David Hildenbrand wrote:
>
>>>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_
continue;
>>
>> @@ -4009,8 +4013,11 @@ static void kvm_sched_out(struct preempt_notifier *pn,
>> {
>> struct kvm_vcpu *vcpu = preempt_notifier_to_vcpu(pn);
>>
>> -if (current->state == TASK_RUNNING)
>> +if (current->state == TASK_RUNNING) {
>> vcpu->preempted = true;
>> +vcpu->in_kernmode = kvm_arch_vcpu_spin_kernmode(vcpu);
>> +}
>> +
>
> so you don't have to do this change, too.
>
>> kvm_arch_vcpu_put(vcpu);
>> }
>>
>>
>
>
--
Regards,
Longpeng(Mike)
then the holder must be
preempted in kernmode, so we should choose a vcpu in kernmode
as the most eligible candidate.
PS: I only implement X86 arch currently for I'm not familiar
with other architecture.
Signed-off-by: Longpeng(Mike)
---
arch/mips/kvm/mips.c | 5 +
arch/p
On 2017/7/28 12:22, Longpeng (Mike) wrote:
>
>
> On 2017/6/6 18:57, Paolo Bonzini wrote:
>
>> The simplify part: do not touch pi_desc.nv, we can set it when the
>> VCPU is first created. Likewise, pi_desc.sn is only handled by
>> vmx_vcpu_pi_load, do n
assigned_device, instead
> check the SN bit to figure out whether vmx_vcpu_pi_put ran before.
> This matches what the previous patch did in pi_post_block.
>
> Cc: Longpeng (Mike)
> Cc: Huangweidong
> Cc: Gonglei
> Cc: wangxin
> Cc: Radim Krčmář
> Signed-off-by: Paolo
uration of
> pi_pre_block/pi_post_block. This is not strictly necessary, but
> easier to follow. For the same reason, PI.ON is checked only
> after the cmpxchg, and to handle it we just call the post-block
> code. This removes duplication of the list removal code.
>
> Cc: Longpeng
On 2017/6/6 20:35, Paolo Bonzini wrote:
>
>
> On 06/06/2017 14:30, Longpeng (Mike) wrote:
>>
>>
>> On 2017/6/6 18:57, Paolo Bonzini wrote:
>>
>>> In some cases, for example involving hot-unplug of assigned
>>> devices, pi_post_block can forge
; pi_pre_block/pi_post_block. This is not strictly necessary, but
> easier to follow. For the same reason, PI.ON is checked only
> after the cmpxchg, and to handle it we just call the post-block
> code. This removes duplication of the list removal code.
>
> Cc: Longpeng (Mike
Hi Jussi,
On 2016/12/7 21:15, Jussi Kivilinna wrote:
> Hello,
>
> 07.12.2016, 14:43, Longpeng (Mike) kirjoitti:
>> Hi Jussi and Herbert,
>>
>> I saw serveral des3-ede testcases(in crypto/testmgr.h) has 16-bytes IV, and
>> the
>> libgcrypt/nettle/RFC1851
On 2016/12/8 17:04, Herbert Xu wrote:
> On Wed, Dec 07, 2016 at 08:43:16PM +0800, Longpeng (Mike) wrote:
>> Hi Jussi and Herbert,
>>
>> I saw serveral des3-ede testcases(in crypto/testmgr.h) has 16-bytes IV, and
>> the
>> libgcrypt/nettle/RFC1851 said the I
Hi Jussi and Herbert,
I saw serveral des3-ede testcases(in crypto/testmgr.h) has 16-bytes IV, and the
libgcrypt/nettle/RFC1851 said the IV-len is 8-bytes.
Would you please tell me why these testcases has 16-bytes IV ?
Thank you. :)
--
Regards,
Longpeng(Mike)
This function declared twice, so remove one.
Signed-off-by: Longpeng(Mike)
---
include/linux/acpi.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 689a8b9..017849e 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -220,10
1) Since commit:41a54482 changed timer enabled variable to per-vcpu,
the correlative comment in kvm_timer_enable is useless now.
2) After the kvm module init successfully, the timecounter is always
non-null, so we can remove the checking of timercounter.
Signed-off-by: Longpeng(Mike
Commit-ID: c836eeda3e1e652d424b908f07eb7380448c
Gitweb: http://git.kernel.org/tip/c836eeda3e1e652d424b908f07eb7380448c
Author: Longpeng(Mike)
AuthorDate: Fri, 14 Oct 2016 08:42:20 +0800
Committer: Thomas Gleixner
CommitDate: Fri, 14 Oct 2016 14:14:20 +0200
x86: Remove
The MSR_IA32_RTIT_STATUS has defined twice, so remove one.
Signed-off-by: Longpeng(Mike)
---
arch/x86/include/asm/msr-index.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 56f4c66..78f3760 100644
--- a/arch/x86
Since Paolo has removed irq-enable-operation in vmx_handle_external_intr
(KVM: x86: use guest_exit_irqoff), the original comment about the IF bit
in rflags is incorrect and stale now, so remove it.
Signed-off-by: Longpeng(Mike)
---
Hi Radim,
Changes since v1:
- remove this stale comment
Interrupt is enabled by handle_external_intr() */
kvm_x86_ops->handle_external_intr(vcpu);
--
Regards,
Longpeng(Mike)
Since Paolo has removed irq-enable-operation in vmx_handle_external_intr
(KVM: x86: use guest_exit_irqoff), the original comment about the IF bit
in rflags is incorrect now.
Signed-off-by: Longpeng(Mike)
---
arch/x86/kvm/vmx.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
85 matches
Mail list logo
