[RFC] kvm - possible out of bounds

[Geyslan Gregório Bem]

Hello,

I have found a possible out of bounds reading in
arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
function). pteg[] array could be accessed twice using the i variable
after the for iteration. What happens is that in the last iteration
the i index is incremented to 16, checked (i<16) then confirmed
exiting the loop.

277for (i=0; i<16; i+=2) { ...

Later there are reading attempts to the pteg last elements, but using
again the already incremented i (16).

303v = be64_to_cpu(pteg[i]);  /* pteg[16] */
304r = be64_to_cpu(pteg[i+1]); /* pteg[17] */

I really don't know if the for lace will somehow iterate until i is
16, anyway I think that the last readings must be using a defined max
len/index or another more clear method.

Eg.

v = be64_to_cpu(pteg[PTEG_LEN - 2]);
r = be64_to_cpu(pteg[PTEG_LEN - 1]);

Or just.

v = be64_to_cpu(pteg[14]);
r = be64_to_cpu(pteg[15]);



I found in the same file a variable that is not used.

380struct kvmppc_vcpu_book3s *vcpu_book3s;
...
387vcpu_book3s = to_book3s(vcpu);

-

A question, the kvmppc_mmu_book3s_64_init function is accessed by
unconventional way? Because I have not found any calling to it.

If something that I wrote is correct please tell me if I could send the patch.

-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] kvm - possible out of bounds

[Geyslan Gregório Bem]

Hello,

I have found a possible out of bounds reading in
arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
function). pteg[] array could be accessed twice using the i variable
after the for iteration. What happens is that in the last iteration
the i index is incremented to 16, checked (i<16) then confirmed
exiting the loop.

277for (i=0; i<16; i+=2) { ...

Later there are reading attempts to the pteg last elements, but using
again the already incremented i (16).

303v = be64_to_cpu(pteg[i]);  /* pteg[16] */
304r = be64_to_cpu(pteg[i+1]); /* pteg[17] */

I really don't know if the for lace will somehow iterate until i is
16, anyway I think that the last readings must be using a defined max
len/index or another more clear method.

Eg.

v = be64_to_cpu(pteg[PTEG_LEN - 2]);
r = be64_to_cpu(pteg[PTEG_LEN - 1]);

Or just.

v = be64_to_cpu(pteg[14]);
r = be64_to_cpu(pteg[15]);



I found in the same file a variable that is not used.

380struct kvmppc_vcpu_book3s *vcpu_book3s;
...
387vcpu_book3s = to_book3s(vcpu);

-

A question, the kvmppc_mmu_book3s_64_init function is accessed by
unconventional way? Because I have not found any calling to it.

If something that I wrote is correct please tell me if I could send the patch.

-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kvm - possible out of bounds

[Paul Mackerras]

On Sun, Nov 29, 2015 at 05:14:03PM -0300, Geyslan Gregório Bem wrote:
> Hello,
> 
> I have found a possible out of bounds reading in
> arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
> function). pteg[] array could be accessed twice using the i variable
> after the for iteration. What happens is that in the last iteration
> the i index is incremented to 16, checked (i<16) then confirmed
> exiting the loop.
> 
> 277for (i=0; i<16; i+=2) { ...
> 
> Later there are reading attempts to the pteg last elements, but using
> again the already incremented i (16).
> 
> 303v = be64_to_cpu(pteg[i]);  /* pteg[16] */
> 304r = be64_to_cpu(pteg[i+1]); /* pteg[17] */

Was it some automated tool that came up with this?

There is actually no problem because the accesses outside the loop are
only done if the 'found' variable is true; 'found' is initialized to
false and only ever set to true inside the loop just before a break
statement.  Thus there is a correlation between the value of 'i' and
the value of 'found' -- if 'found' is true then we know 'i' is less
than 16.

> I really don't know if the for lace will somehow iterate until i is
> 16, anyway I think that the last readings must be using a defined max
> len/index or another more clear method.

I think it's perfectly clear to a human programmer, though some tools
(such as gcc) struggle with this kind of correlation between
variables.  That's why I asked whether your report was based on the
output from some tool.

> Eg.
> 
> v = be64_to_cpu(pteg[PTEG_LEN - 2]);
> r = be64_to_cpu(pteg[PTEG_LEN - 1]);
> 
> Or just.
> 
> v = be64_to_cpu(pteg[14]);
> r = be64_to_cpu(pteg[15]);

Either of those options would cause the code to malfunction.

> I found in the same file a variable that is not used.
> 
> 380struct kvmppc_vcpu_book3s *vcpu_book3s;
> ...
> 387vcpu_book3s = to_book3s(vcpu);

True.  It could be removed.

> A question, the kvmppc_mmu_book3s_64_init function is accessed by
> unconventional way? Because I have not found any calling to it.

Try arch/powerpc/kvm/book3s_pr.c line 410:

kvmppc_mmu_book3s_64_init(vcpu);

Grep (or git grep) is your friend.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kvm - possible out of bounds

[Paul Mackerras]

On Sun, Nov 29, 2015 at 05:14:03PM -0300, Geyslan Gregório Bem wrote:
> Hello,
> 
> I have found a possible out of bounds reading in
> arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
> function). pteg[] array could be accessed twice using the i variable
> after the for iteration. What happens is that in the last iteration
> the i index is incremented to 16, checked (i<16) then confirmed
> exiting the loop.
> 
> 277for (i=0; i<16; i+=2) { ...
> 
> Later there are reading attempts to the pteg last elements, but using
> again the already incremented i (16).
> 
> 303v = be64_to_cpu(pteg[i]);  /* pteg[16] */
> 304r = be64_to_cpu(pteg[i+1]); /* pteg[17] */

Was it some automated tool that came up with this?

There is actually no problem because the accesses outside the loop are
only done if the 'found' variable is true; 'found' is initialized to
false and only ever set to true inside the loop just before a break
statement.  Thus there is a correlation between the value of 'i' and
the value of 'found' -- if 'found' is true then we know 'i' is less
than 16.

> I really don't know if the for lace will somehow iterate until i is
> 16, anyway I think that the last readings must be using a defined max
> len/index or another more clear method.

I think it's perfectly clear to a human programmer, though some tools
(such as gcc) struggle with this kind of correlation between
variables.  That's why I asked whether your report was based on the
output from some tool.

> Eg.
> 
> v = be64_to_cpu(pteg[PTEG_LEN - 2]);
> r = be64_to_cpu(pteg[PTEG_LEN - 1]);
> 
> Or just.
> 
> v = be64_to_cpu(pteg[14]);
> r = be64_to_cpu(pteg[15]);

Either of those options would cause the code to malfunction.

> I found in the same file a variable that is not used.
> 
> 380struct kvmppc_vcpu_book3s *vcpu_book3s;
> ...
> 387vcpu_book3s = to_book3s(vcpu);

True.  It could be removed.

> A question, the kvmppc_mmu_book3s_64_init function is accessed by
> unconventional way? Because I have not found any calling to it.

Try arch/powerpc/kvm/book3s_pr.c line 410:

kvmppc_mmu_book3s_64_init(vcpu);

Grep (or git grep) is your friend.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kvm - possible out of bounds

[Geyslan Gregório Bem]

2015-11-29 18:33 GMT-03:00 Paul Mackerras :
> On Sun, Nov 29, 2015 at 05:14:03PM -0300, Geyslan Gregório Bem wrote:
>> Hello,
>>
>> I have found a possible out of bounds reading in
>> arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
>> function). pteg[] array could be accessed twice using the i variable
>> after the for iteration. What happens is that in the last iteration
>> the i index is incremented to 16, checked (i<16) then confirmed
>> exiting the loop.
>>
>> 277for (i=0; i<16; i+=2) { ...
>>
>> Later there are reading attempts to the pteg last elements, but using
>> again the already incremented i (16).
>>
>> 303v = be64_to_cpu(pteg[i]);  /* pteg[16] */
>> 304r = be64_to_cpu(pteg[i+1]); /* pteg[17] */
>
> Was it some automated tool that came up with this?

Yep, cppcheck. As I'm still not engaged to a specific area in the
kernel, just trying to help with automated catches.

>
> There is actually no problem because the accesses outside the loop are
> only done if the 'found' variable is true; 'found' is initialized to
> false and only ever set to true inside the loop just before a break
> statement.  Thus there is a correlation between the value of 'i' and
> the value of 'found' -- if 'found' is true then we know 'i' is less
> than 16.

I figured it out after your explanation.

>
>> I really don't know if the for lace will somehow iterate until i is
>> 16, anyway I think that the last readings must be using a defined max
>> len/index or another more clear method.
>
> I think it's perfectly clear to a human programmer, though some tools
> (such as gcc) struggle with this kind of correlation between
> variables.  That's why I asked whether your report was based on the
> output from some tool.
>
>> Eg.
>>
>> v = be64_to_cpu(pteg[PTEG_LEN - 2]);
>> r = be64_to_cpu(pteg[PTEG_LEN - 1]);
>>
>> Or just.
>>
>> v = be64_to_cpu(pteg[14]);
>> r = be64_to_cpu(pteg[15]);
>
> Either of those options would cause the code to malfunction.

Yep, I understand now that v and r get the found ones. So i is needed.

>
>> I found in the same file a variable that is not used.
>>
>> 380struct kvmppc_vcpu_book3s *vcpu_book3s;
>> ...
>> 387vcpu_book3s = to_book3s(vcpu);
>
> True.  It could be removed.

I'll make a patch for that.

>
>> A question, the kvmppc_mmu_book3s_64_init function is accessed by
>> unconventional way? Because I have not found any calling to it.
>
> Try arch/powerpc/kvm/book3s_pr.c line 410:
>
> kvmppc_mmu_book3s_64_init(vcpu);
>
> Grep (or git grep) is your friend.

Hmm, indeed.

>
> Paul.

Thank you, Paul. If you have some other changes in progress let me know.

-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NEW ARRIVALS, CISCO, LAPTOP AND AVAYA

[INC]

Hello,

We have the below lists in stock and looking for offers. 

CPUs and QTYs in stock.

75  X   X5650
55  X   E5410
65  X   X5660
45  X   E5530
75  X   E5645
70  X   X5680
65  X   X5690

 IP phones and QTYs in stock.

15 x CP-7937G
57 x CP-7942G
45 x CP-7945G
55 x CP-7962G


Here is the qty in stock for laptops
 

150 x E6500 Dell Latitude E6500 Core 2 Duo 2.80GHz T9600 4GB 160GB DVD+/-RW Win 
7
 60 x E6510 Dell Ltitude E6510. 15.6" Intel Core i5- M520 @ 2.40GHz. 4GB. 320GB 
DVD+/-RW Win 7
30 X 8530P HP EliteBook 8530p 15.4" Laptop 2.53GHz Core 2 Duo T9400, 4GB RAM, 
160GB HDD, Win
100 x  8740W  HP EliteBook 8740w 17" 2.4Ghz Core i5 6GB 250GB Win 7 Pr
45 x 8760W HP EliteBook 8760W 17.3" 2nd Gen Intel Core i7 2.70GHz 8GB 320GB 
Windows 7 Pro
50 x DELL 6520Dell latitude e6520 15.6" i5-2520M 2.5Ghz, 8GB Ram, 500GB HD Win 
7 @ $115
120 x DELL 6420 Laptop Dell Latitude E6420 14" Intel Core i5 2.4Ghz 4GB RAM 
250GB HDD DVD Win 7
150 x T410 Lenovo ThinkPad Laptop T410s 14.1" 2.40GHz Core i5 4GB RAM 160GB Win 
7
180 x 8440P HP EliteBook 8440p 14" M520 Core i5 2.4GHz 4GB 250GB Win 7


Let me know if you're interested. We are very open to offers and willing to 
work with you to make sure that we have a deal.

Best regards,
Vivian Walsh (Sales)
SIGMA COMPUTECH INC
11455 Newkirk St,Bldg7
Dallas, TX 75229
Email: sa...@sigmacomputech.com
Web: www.sigmacomputech.com
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kvm - possible out of bounds

[Geyslan Gregório Bem]

2015-11-29 18:33 GMT-03:00 Paul Mackerras :
> On Sun, Nov 29, 2015 at 05:14:03PM -0300, Geyslan Gregório Bem wrote:
>> Hello,
>>
>> I have found a possible out of bounds reading in
>> arch/powerpc/kvm/book3s_64_mmu.c (kvmppc_mmu_book3s_64_xlate
>> function). pteg[] array could be accessed twice using the i variable
>> after the for iteration. What happens is that in the last iteration
>> the i index is incremented to 16, checked (i<16) then confirmed
>> exiting the loop.
>>
>> 277for (i=0; i<16; i+=2) { ...
>>
>> Later there are reading attempts to the pteg last elements, but using
>> again the already incremented i (16).
>>
>> 303v = be64_to_cpu(pteg[i]);  /* pteg[16] */
>> 304r = be64_to_cpu(pteg[i+1]); /* pteg[17] */
>
> Was it some automated tool that came up with this?

Yep, cppcheck. As I'm still not engaged to a specific area in the
kernel, just trying to help with automated catches.

>
> There is actually no problem because the accesses outside the loop are
> only done if the 'found' variable is true; 'found' is initialized to
> false and only ever set to true inside the loop just before a break
> statement.  Thus there is a correlation between the value of 'i' and
> the value of 'found' -- if 'found' is true then we know 'i' is less
> than 16.

I figured it out after your explanation.

>
>> I really don't know if the for lace will somehow iterate until i is
>> 16, anyway I think that the last readings must be using a defined max
>> len/index or another more clear method.
>
> I think it's perfectly clear to a human programmer, though some tools
> (such as gcc) struggle with this kind of correlation between
> variables.  That's why I asked whether your report was based on the
> output from some tool.
>
>> Eg.
>>
>> v = be64_to_cpu(pteg[PTEG_LEN - 2]);
>> r = be64_to_cpu(pteg[PTEG_LEN - 1]);
>>
>> Or just.
>>
>> v = be64_to_cpu(pteg[14]);
>> r = be64_to_cpu(pteg[15]);
>
> Either of those options would cause the code to malfunction.

Yep, I understand now that v and r get the found ones. So i is needed.

>
>> I found in the same file a variable that is not used.
>>
>> 380struct kvmppc_vcpu_book3s *vcpu_book3s;
>> ...
>> 387vcpu_book3s = to_book3s(vcpu);
>
> True.  It could be removed.

I'll make a patch for that.

>
>> A question, the kvmppc_mmu_book3s_64_init function is accessed by
>> unconventional way? Because I have not found any calling to it.
>
> Try arch/powerpc/kvm/book3s_pr.c line 410:
>
> kvmppc_mmu_book3s_64_init(vcpu);
>
> Grep (or git grep) is your friend.

Hmm, indeed.

>
> Paul.

Thank you, Paul. If you have some other changes in progress let me know.

-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH kernel 5/9] KVM: PPC: Account TCE-containing pages in locked_vm

[Paul Mackerras]

On Tue, Sep 15, 2015 at 08:49:35PM +1000, Alexey Kardashevskiy wrote:
> At the moment pages used for TCE tables (in addition to pages addressed
> by TCEs) are not counted in locked_vm counter so a malicious userspace
> tool can call ioctl(KVM_CREATE_SPAPR_TCE) as many times as RLIMIT_NOFILE and
> lock a lot of memory.
> 
> This adds counting for pages used for TCE tables.
> 
> This counts the number of pages required for a table plus pages for
> the kvmppc_spapr_tce_table struct (TCE table descriptor) itself.
> 
> This does not change the amount of (de)allocated memory.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
>  arch/powerpc/kvm/book3s_64_vio.c | 51 
> +++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c 
> b/arch/powerpc/kvm/book3s_64_vio.c
> index 9526c34..b70787d 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -45,13 +45,56 @@ static long kvmppc_stt_npages(unsigned long window_size)
>* sizeof(u64), PAGE_SIZE) / PAGE_SIZE;
>  }
>  
> +static long kvmppc_account_memlimit(long npages, bool inc)
> +{
> + long ret = 0;
> + const long bytes = sizeof(struct kvmppc_spapr_tce_table) +
> + (abs(npages) * sizeof(struct page *));

Why abs(npages)?  Can npages be negative?  If so, what does that mean?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH kernel 5/9] KVM: PPC: Account TCE-containing pages in locked_vm

[Paul Mackerras]

On Tue, Sep 15, 2015 at 08:49:35PM +1000, Alexey Kardashevskiy wrote:
> At the moment pages used for TCE tables (in addition to pages addressed
> by TCEs) are not counted in locked_vm counter so a malicious userspace
> tool can call ioctl(KVM_CREATE_SPAPR_TCE) as many times as RLIMIT_NOFILE and
> lock a lot of memory.
> 
> This adds counting for pages used for TCE tables.
> 
> This counts the number of pages required for a table plus pages for
> the kvmppc_spapr_tce_table struct (TCE table descriptor) itself.
> 
> This does not change the amount of (de)allocated memory.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
>  arch/powerpc/kvm/book3s_64_vio.c | 51 
> +++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c 
> b/arch/powerpc/kvm/book3s_64_vio.c
> index 9526c34..b70787d 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -45,13 +45,56 @@ static long kvmppc_stt_npages(unsigned long window_size)
>* sizeof(u64), PAGE_SIZE) / PAGE_SIZE;
>  }
>  
> +static long kvmppc_account_memlimit(long npages, bool inc)
> +{
> + long ret = 0;
> + const long bytes = sizeof(struct kvmppc_spapr_tce_table) +
> + (abs(npages) * sizeof(struct page *));

Why abs(npages)?  Can npages be negative?  If so, what does that mean?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] vgaarb: fix signal handling in vga_get()

[Kirill A. Shutemov]

There are few defects in vga_get() related to signal hadning:

  - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
case;

  - if we found pending signal we must remove ourself from wait queue
and change task state back to running;

  - -ERESTARTSYS is more appropriate, I guess.

Signed-off-by: Kirill A. Shutemov 
---

Alex, I try to get KVM with VGA passthrough working properly. I have i915
(HD 4600) on the host and GTX 580 for the guest. The guest GPU is not
capabale of EFI, so I have to use x-vga=on. It's kinda work with your
patch for i915.enable_hd_vgaarb=1. But guest refuse to initialize the GPU
after KVM was not shut down correctly, resulting in host crash like this:

BUG: unable to handle kernel paging request at 880870187ed8
IP: [] 0x880870187ed8
PGD 2129067 PUD 800841e3
Oops: 0011 [#1] PREEMPT SMP
Modules linked in: iwlmvm iwlwifi
CPU: 6 PID: 3983 Comm: qemu-system-x86 Not tainted 4.3.0-gentoo #6
Hardware name: Gigabyte Technology Co., Ltd. Z87X-UD7 TH/Z87X-UD7 TH-CF, BIOS 
F5a 06/12/2014
task: 88087a91 ti: 8808632c task.ti: 8808632c
RIP: 0010:[]  [] 0x880870187ed8
RSP: 0018:8808632c3d08  EFLAGS: 00010006
RAX: 880870187db0 RBX: 70187f58 RCX: 
RDX:  RSI: 0003 RDI: 880870187db0
RBP: 8808632c3d48 R08:  R09: 
R10: 000103c0 R11: 0293 R12: 81ea03c8
R13: 8104c7cb R14:  R15: 0003
FS:  7f984f9b2700() GS:88089f38() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 880870187ed8 CR3: 0008645f8000 CR4: 001426e0
Stack:
 810cc83d 632c3d28  81ea03c0
 0046 0003  
 8808632c3d80 810cca44 88087af63800 0286
Call Trace:
 [] ? __wake_up_common+0x4d/0x80
 [] __wake_up+0x34/0x50
 [] __vga_put+0x73/0xd0
 [] vga_put+0x54/0x80
 [] vfio_pci_vga_rw+0x1d2/0x220
 [] vfio_pci_rw+0x33/0x60
 [] vfio_pci_write+0x17/0x20
 [] vfio_device_fops_write+0x26/0x30
 [] __vfs_write+0x23/0xe0
 [] ? __vfs_read+0x23/0xd0
 [] ? do_vfs_ioctl+0x2b5/0x490
 [] vfs_write+0xa4/0x190
 [] SyS_pwrite64+0x66/0xa0
 [] entry_SYSCALL_64_fastpath+0x12/0x6a
Code: 88 ff ff e0 7e 18 70 08 88 ff ff 00 8c 57 76 08 88 ff ff 20 7f 18 70 08 
88 ff ff 08 7f 18 70 08 88 ff ff 94 51 1a 81 ff ff ff ff <09> 00 00 00 00 00 00 
00 01 8c 57 76 08 88 ff ff 00 8c 57 76 08
RIP  [] 0x880870187ed8
 RSP 
CR2: 880870187ed8

The patch fixes the crash, but doesn't help with getting GPU in guest
working again.

Any ideas?

---
 drivers/gpu/vga/vgaarb.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 3166e4bc4eb6..9abcaa53bd25 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -395,8 +395,10 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int 
interruptible)
set_current_state(interruptible ?
  TASK_INTERRUPTIBLE :
  TASK_UNINTERRUPTIBLE);
-   if (signal_pending(current)) {
-   rc = -EINTR;
+   if (interruptible && signal_pending(current)) {
+   __set_current_state(TASK_RUNNING);
+   remove_wait_queue(_wait_queue, );
+   rc = -ERESTARTSYS;
break;
}
schedule();
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 0/3] basic busy polling support for vhost_net

[David Miller]

From: Jason Wang 
Date: Wed, 25 Nov 2015 15:11:26 +0800

> This series tries to add basic busy polling for vhost net. The idea is
> simple: at the end of tx/rx processing, busy polling for new tx added
> descriptor and rx receive socket for a while. The maximum number of
> time (in us) could be spent on busy polling was specified ioctl.
> 
> Test A were done through:
> 
> - 50 us as busy loop timeout
> - Netperf 2.6
> - Two machines with back to back connected ixgbe
> - Guest with 1 vcpu and 1 queue
> 
> Results:
> - For stream workload, ioexits were reduced dramatically in medium
>   size (1024-2048) of tx (at most -43%) and almost all rx (at most
>   -84%) as a result of polling. This compensate for the possible
>   wasted cpu cycles more or less. That porbably why we can still see
>   some increasing in the normalized throughput in some cases.
> - Throughput of tx were increased (at most 50%) expect for the huge
>   write (16384). And we can send more packets in the case (+tpkts were
>   increased).
> - Very minor rx regression in some cases.
> - Improvemnt on TCP_RR (at most 17%).

Michael are you going to take this?  It's touching vhost core as
much as it is the vhost_net driver.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

[Lan, Tianyu]

On 11/26/2015 11:56 AM, Alexander Duyck wrote:

> I am not saying you cannot modify the drivers, however what you are
doing is far too invasive.  Do you seriously plan on modifying all of
the PCI device drivers out there in order to allow any device that
might be direct assigned to a port to support migration?  I certainly
hope not.  That is why I have said that this solution will not scale.


Current drivers are not migration friendly. If the driver wants to
support migration, it's necessary to be changed.

RFC PATCH V1 presented our ideas about how to deal with MMIO, ring and
DMA tracking during migration. These are common for most drivers and
they maybe problematic in the previous version but can be corrected later.

Doing suspend and resume() may help to do migration easily but some
devices requires low service down time. Especially network and I got
that some cloud company promised less than 500ms network service downtime.

So I think performance effect also should be taken into account when we 
design the framework.





What I am counter proposing seems like a very simple proposition.  It
can be implemented in two steps.

1.  Look at modifying dma_mark_clean().  It is a function called in
the sync and unmap paths of the lib/swiotlb.c.  If you could somehow
modify it to take care of marking the pages you unmap for Rx as being
dirty it will get you a good way towards your goal as it will allow
you to continue to do DMA while you are migrating the VM.

2.  Look at making use of the existing PCI suspend/resume calls that
are there to support PCI power management.  They have everything
needed to allow you to pause and resume DMA for the device before and
after the migration while retaining the driver state.  If you can
implement something that allows you to trigger these calls from the
PCI subsystem such as hot-plug then you would have a generic solution
that can be easily reproduced for multiple drivers beyond those
supported by ixgbevf.


Glanced at PCI hotplug code. The hotplug events are triggered by PCI 
hotplug controller and these event are defined in the controller spec.
It's hard to extend more events. Otherwise, we also need to add some 
specific codes in the PCI hotplug core since it's only add and remove
PCI device when it gets events. It's also a challenge to modify Windows 
hotplug codes. So we may need to find another way.






Thanks.

- Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH kernel 5/9] KVM: PPC: Account TCE-containing pages in locked_vm

[Alexey Kardashevskiy]

On 11/30/2015 01:06 PM, Paul Mackerras wrote:

On Tue, Sep 15, 2015 at 08:49:35PM +1000, Alexey Kardashevskiy wrote:

At the moment pages used for TCE tables (in addition to pages addressed
by TCEs) are not counted in locked_vm counter so a malicious userspace
tool can call ioctl(KVM_CREATE_SPAPR_TCE) as many times as RLIMIT_NOFILE and
lock a lot of memory.

This adds counting for pages used for TCE tables.

This counts the number of pages required for a table plus pages for
the kvmppc_spapr_tce_table struct (TCE table descriptor) itself.

This does not change the amount of (de)allocated memory.

Signed-off-by: Alexey Kardashevskiy 
---
  arch/powerpc/kvm/book3s_64_vio.c | 51 +++-
  1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 9526c34..b70787d 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -45,13 +45,56 @@ static long kvmppc_stt_npages(unsigned long window_size)
 * sizeof(u64), PAGE_SIZE) / PAGE_SIZE;
  }

+static long kvmppc_account_memlimit(long npages, bool inc)
+{
+   long ret = 0;
+   const long bytes = sizeof(struct kvmppc_spapr_tce_table) +
+   (abs(npages) * sizeof(struct page *));


Why abs(npages)?  Can npages be negative?  If so, what does that mean?



Leftover from older versions when there was one shared 
account_memlimit(long npages). It does not make sense here, I need to 
remove it.



--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH kernel 5/9] KVM: PPC: Account TCE-containing pages in locked_vm

[Alexey Kardashevskiy]

On 11/30/2015 01:06 PM, Paul Mackerras wrote:

On Tue, Sep 15, 2015 at 08:49:35PM +1000, Alexey Kardashevskiy wrote:

At the moment pages used for TCE tables (in addition to pages addressed
by TCEs) are not counted in locked_vm counter so a malicious userspace
tool can call ioctl(KVM_CREATE_SPAPR_TCE) as many times as RLIMIT_NOFILE and
lock a lot of memory.

This adds counting for pages used for TCE tables.

This counts the number of pages required for a table plus pages for
the kvmppc_spapr_tce_table struct (TCE table descriptor) itself.

This does not change the amount of (de)allocated memory.

Signed-off-by: Alexey Kardashevskiy 
---
  arch/powerpc/kvm/book3s_64_vio.c | 51 +++-
  1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 9526c34..b70787d 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -45,13 +45,56 @@ static long kvmppc_stt_npages(unsigned long window_size)
 * sizeof(u64), PAGE_SIZE) / PAGE_SIZE;
  }

+static long kvmppc_account_memlimit(long npages, bool inc)
+{
+   long ret = 0;
+   const long bytes = sizeof(struct kvmppc_spapr_tce_table) +
+   (abs(npages) * sizeof(struct page *));


Why abs(npages)?  Can npages be negative?  If so, what does that mean?



Leftover from older versions when there was one shared 
account_memlimit(long npages). It does not make sense here, I need to 
remove it.



--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

best way to create a snapshot of a running vm ?

[Lentes, Bernd]

Hi,

what is the best way to create a snapshot of a running vm ? qemu-img or virsh ?
I#d like to create a snapshot which is copied afterwards by other means, e.g. 
by a network based backup software.

Bernd


-- 
Bernd Lentes 

Systemadministration 
institute of developmental genetics 
Gebäude 35.34 - Raum 208 
HelmholtzZentrum München 
bernd.len...@helmholtz-muenchen.de 
phone: +49 (0)89 3187 1241 
fax: +49 (0)89 3187 2294 

Wer Visionen hat soll zum Hausarzt gehen 
Helmut Schmidt
   

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html