: 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
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
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 insert
> -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 ;
> alex.willia
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:
在 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
to be 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
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
age-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/virtio/virtio_crypto_algs.c
b/drivers/crypto/virtio/virtio_cry
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
.
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-off-by
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)
olve after look at the
code.
I hope experts in the thread could review the code when you free, thanks :)
---
Regards,
Longpeng(Mike)
, 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)
idate it here is
needed ?
'''
/* Source data */
- for (i = 0; i < src_nents; i++)
- sgs[num_out++] = >src[i];
+ for (sg = req->src; src_nents; sg = sg_next(sg), src_nents--)
+ sgs[num_out++] = sg;
'''
> Regards,
> Markus
>
--
---
Regards,
Longpeng(Mike)
ger.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/virtio_crypto_algs.c
b/drivers/crypto/virtio/virtio_crypto
.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
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)
cipher_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)
lidation?
> 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
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 | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
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
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/virtio
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:
fndef 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)
fndef 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) <longpe...@huawei.com>
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/x86.c | 1 -
2 files changed, 2 deletion
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
->spec_ctrl != 0)
> + 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)
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 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: Peng Ha
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:
-devel/2016-01/msg00664.html
[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg02891.html
--
Regards,
Longpeng(Mike)
-devel/2016-01/msg00664.html
[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg02891.html
--
Regards,
Longpeng(Mike)
] https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg02891.html
--
Regards,
Longpeng(Mike)
] 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)" <longpe...@huawei.com>
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's too shor
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's too shor
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:
>>
>> signed integer o
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:
>>
>> signed integer o
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 sh
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 sh
-off-by: Longpeng(Mike) <longpe...@huawei.com>
---
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/inclu
-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/include/asm/kvm_host.h b/arch/x86
ch/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 kvm_vcpu *me)
>
ch/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 kvm_vcpu *me)
>
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: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)" <longpe...@huawei.com> wrote:
>
>> This is a simple optimization for kvm_vcpu_on_spin, the
>> main idea is described in patch-1's commit msg.
>
> I thin
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 goo
This implements the kvm_arch_vcpu_in_kernel() for s390.
Signed-off-by: Longpeng(Mike) <longpe...@huawei.com>
---
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
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) <longpe...@huaw
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) <longpe...@huawei.com>
---
arch/arm/kvm/handle_exit.c | 2 +-
arch/arm64/kvm/handle_exit.c | 2 +-
arch/mips/kvm/mips.c | 6 ++
arch/power
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 | 6
This implements the kvm_arch_vcpu_in_kernel() for ARM.
Signed-off-by: Longpeng(Mike) <longpe...@huawei.com>
---
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
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
mpls 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 optimization framework
KVM
mpls 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 optimization framework
KVM
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 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 ker
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 ker
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) <longpe...@huawei.com>
>&g
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/s390/k
architecture(e.g. arm/s390), spin/preempt_in_kernel()
are the same, but they are different for X86.
Signed-off-by: Longpeng(Mike) <longpe...@huawei.com>
---
arch/mips/kvm/mips.c | 10 ++
arch/powerpc/kvm/powerpc.c | 10 ++
arch/s390/kvm/kvm-s390.c | 10 ++
arch/x86/kvm
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) <longpe...@huawei.com>
---
arch/s390/kvm/kvm-s390.c | 4 ++--
virt/kvm/arm/arm.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
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) <longpe...@huawei.com>
---
arch/x86/include/asm/kvm_host.h | 5 +
ar
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-s390.c b
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
ce 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/s390
arch/mips/kvm/
ce 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/s390
arch/mips/kvm/
+0x7a2/0x1fa0 [kvm_intel]
...
Signed-off-by: Longpeng(Mike) <longpe...@huawei.com>
---
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/arch/x86/kvm/x86.c
@@ -6215,6 +
+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/arch/x86/kvm/x86.c
@@ -6215,6 +6215,7 @@ static void
ed_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)
ed_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 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)" <longpe...@huawei.com> wrote:
>
>> Hi David,
>>
>> On 2017/7/31 19:31, David Hildenbrand wrote:
>
>>>> diff --git a/include/linux/kvm_hos
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
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)
1 - 100 of 133 matches
Mail list logo
