[Xen-devel] [qemu-mainline test] 112506: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 112506 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112506/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112456

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 112456

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112456
 build-arm64-xsm   2 hosts-allocate  broken like 112456
 build-arm64   2 hosts-allocate  broken like 112456
 build-arm64   3 capture-logsbroken like 112456
 build-arm64-pvops 3 capture-logsbroken like 112456
 build-arm64-xsm   3 capture-logsbroken like 112456
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112456
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112456
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112456
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112456
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuue59b1c5f677ca7e97709f606ad46947e9fdbb7bb
baseline version:
 qemuuac44ed2afb7c60255e989b163301479f5b4ecd04

Last test of basis   112456  2017-08-05 00:17:41 Z3 days
Testing same since   112506  2017-08-07 09:39:19 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Richard Henderson 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64

[Xen-devel] [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

[Andy Lutomirski]

Xen's raw SYSCALL entries are much less weird than native.  Rather
than fudging them to look like native entries, use the Xen-provided
stack frame directly.

This lets us eliminate entry_SYSCALL_64_after_swapgs and two uses of
the SWAPGS_UNSAFE_STACK paravirt hook.  The SYSENTER code would
benefit from similar treatment.

This makes one change to the native code path: the compat
instruction that clears the high 32 bits of %rax is moved slightly
later.  I'd be surprised if this affects performance at all.

Signed-off-by: Andy Lutomirski 
---

Changes from v1 (which I never actually emailed):
 - Fix zero-extension in the compat case.

 arch/x86/entry/entry_64.S|  9 ++---
 arch/x86/entry/entry_64_compat.S |  7 +++
 arch/x86/xen/xen-asm_64.S| 23 +--
 3 files changed, 14 insertions(+), 25 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index aa58155187c5..7cee92cf807f 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -142,14 +142,8 @@ ENTRY(entry_SYSCALL_64)
 * We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON,
 * it is too small to ever cause noticeable irq latency.
 */
-   SWAPGS_UNSAFE_STACK
-   /*
-* A hypervisor implementation might want to use a label
-* after the swapgs, so that it can do the swapgs
-* for the guest and jump here on syscall.
-*/
-GLOBAL(entry_SYSCALL_64_after_swapgs)
 
+   swapgs
movq%rsp, PER_CPU_VAR(rsp_scratch)
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
 
@@ -161,6 +155,7 @@ GLOBAL(entry_SYSCALL_64_after_swapgs)
pushq   %r11/* pt_regs->flags */
pushq   $__USER_CS  /* pt_regs->cs */
pushq   %rcx/* pt_regs->ip */
+GLOBAL(entry_SYSCALL_64_after_hwframe)
pushq   %rax/* pt_regs->orig_ax */
pushq   %rdi/* pt_regs->di */
pushq   %rsi/* pt_regs->si */
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index e1721dafbcb1..5314d7b8e5ad 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -183,21 +183,20 @@ ENDPROC(entry_SYSENTER_compat)
  */
 ENTRY(entry_SYSCALL_compat)
/* Interrupts are off on entry. */
-   SWAPGS_UNSAFE_STACK
+   swapgs
 
/* Stash user ESP and switch to the kernel stack. */
movl%esp, %r8d
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
 
-   /* Zero-extending 32-bit regs, do not remove */
-   movl%eax, %eax
-
/* Construct struct pt_regs on stack */
pushq   $__USER32_DS/* pt_regs->ss */
pushq   %r8 /* pt_regs->sp */
pushq   %r11/* pt_regs->flags */
pushq   $__USER32_CS/* pt_regs->cs */
pushq   %rcx/* pt_regs->ip */
+GLOBAL(entry_SYSCALL_compat_after_hwframe)
+   movl%eax, %eax  /* discard orig_ax high bits */
pushq   %rax/* pt_regs->orig_ax */
pushq   %rdi/* pt_regs->di */
pushq   %rsi/* pt_regs->si */
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index c3df43141e70..a8a4f4c460a6 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -82,34 +82,29 @@ RELOC(xen_sysret64, 1b+1)
  * rip
  * r11
  * rsp->rcx
- *
- * In all the entrypoints, we undo all that to make it look like a
- * CPU-generated syscall/sysenter and jump to the normal entrypoint.
  */
 
-.macro undo_xen_syscall
-   mov 0*8(%rsp), %rcx
-   mov 1*8(%rsp), %r11
-   mov 5*8(%rsp), %rsp
-.endm
-
 /* Normal 64-bit system call target */
 ENTRY(xen_syscall_target)
-   undo_xen_syscall
-   jmp entry_SYSCALL_64_after_swapgs
+   popq %rcx
+   popq %r11
+   jmp entry_SYSCALL_64_after_hwframe
 ENDPROC(xen_syscall_target)
 
 #ifdef CONFIG_IA32_EMULATION
 
 /* 32-bit compat syscall target */
 ENTRY(xen_syscall32_target)
-   undo_xen_syscall
-   jmp entry_SYSCALL_compat
+   popq %rcx
+   popq %r11
+   jmp entry_SYSCALL_compat_after_hwframe
 ENDPROC(xen_syscall32_target)
 
 /* 32-bit compat sysenter target */
 ENTRY(xen_sysenter_target)
-   undo_xen_syscall
+   mov 0*8(%rsp), %rcx
+   mov 1*8(%rsp), %r11
+   mov 5*8(%rsp), %rsp
jmp entry_SYSENTER_compat
 ENDPROC(xen_sysenter_target)
 
-- 
2.13.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-4.1 baseline-only test] 71948: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71948 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71948/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   6 xen-build fail REGR. vs. 71621
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
71621
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
71621

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 71621

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-armhf-armhf-libvirt14 saverestore-support-check fail blocked in 71621
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail blocked in 71621
 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail blocked in 71621
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 71621
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-examine 10 examine-serial/bootloaderfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass

version targeted for testing:
 linux1af952704416d76ad86963f04feb10a3da143901
baseline version:
 linux2ac51e21d8c50ca37fc9b5b9a9b4937c810b0d0a

Last test of basis71621  2017-06-30 20:50:20 Z   38 days
Testing same since71948  2017-08-07 21:48:50 Z0 days1 attempts

Re: [Xen-devel] [PATCH v3] xen: get rid of paravirt op adjust_exception_frame

[Andy Lutomirski]

On Mon, Aug 7, 2017 at 1:56 PM, Boris Ostrovsky
 wrote:
>
>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>> index 811e4ddb3f37..a3dcd83187ce 100644
>> --- a/arch/x86/xen/enlighten_pv.c
>> +++ b/arch/x86/xen/enlighten_pv.c
>> @@ -579,6 +579,71 @@ static void xen_write_ldt_entry(struct desc_struct *dt, 
>> int entrynum,
>>   preempt_enable();
>>  }
>>
>> +#ifdef CONFIG_X86_64
>> +static struct {
>> + void (*orig)(void);
>> + void (*xen)(void);
>> + bool ist_okay;
>> + bool handle;
>> +} trap_array[] = {
>> + { debug, xen_xendebug, true, true },
>> + { int3, xen_xenint3, true, true },
>> + { double_fault, xen_double_fault, true, false },
>
> Is it really worth adding 'handle' member to the structure because of a
> single special case? We don't expect to ever have another such vector.
>
> (TBH, I think current implementation of cvt_gate_to_trap() is clearer,
> even if it is not as general as what is in this patch. I know that Andy
> disagrees).

I have no real opinion either way.  I just think it's nicer to put it
in cvt_gate_to_trap() instead of the the traps.c setup code.

--Andy

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-linus test] 112504: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 112504 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112504/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64-pvops 3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale 

[Xen-devel] [PATCH v3 2/2] xl: Register the AER event handler to handle AER errors

[Venu Busireddy]

When a guest is created, register the AER event handler to handle the
AER errors. When an AER error occurs, the handler will forcibly remove
the erring PCIe device from the guest.

Signed-off-by: Venu Busireddy 
---
 tools/xl/xl_vmcontrol.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 89c2b25..9855cdb 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -656,6 +656,7 @@ int create_domain(struct domain_create *dom_info)
 const char *restore_source = NULL;
 int migrate_fd = dom_info->migrate_fd;
 bool config_in_json;
+libxl_aer_watch *aer_ws = NULL;
 
 int i;
 int need_daemon = daemonize;
@@ -966,6 +967,12 @@ start:
 LOG("Waiting for domain %s (domid %u) to die [pid %ld]",
 d_config.c_info.name, domid, (long)getpid());
 
+ret = libxl_reg_aer_events_handler(ctx, domid, _ws);
+if (ret) {
+/* Log the error, and move on... */
+LOG("libxl_reg_aer_events_handler() failed, ret = 0x%08x", ret);
+}
+
 ret = libxl_evenable_domain_death(ctx, domid, 0, );
 if (ret) goto out;
 
@@ -993,6 +1000,7 @@ start:
 LOG("Domain %u has shut down, reason code %d 0x%x", domid,
 event->u.domain_shutdown.shutdown_reason,
 event->u.domain_shutdown.shutdown_reason);
+libxl_unreg_aer_events_handler(ctx, domid, aer_ws);
 switch (handle_domain_death(, event, _config)) {
 case DOMAIN_RESTART_SOFT_RESET:
 domid_soft_reset = domid;
@@ -1059,6 +1067,7 @@ start:
 
 case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
 LOG("Domain %u has been destroyed.", domid);
+libxl_unreg_aer_events_handler(ctx, domid, aer_ws);
 libxl_event_free(ctx, event);
 ret = 0;
 goto out;

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors

[Venu Busireddy]

Implement the callback function to handle unrecoverable AER errors, and
also the public APIs that can be used to register/unregister the handler.
When an AER error occurs, the handler will forcibly remove the erring
PCIe device from the guest.

Signed-off-by: Venu Busireddy 
---
 tools/libxl/libxl.h  | 14 +++
 tools/libxl/libxl_event.h| 13 +++
 tools/libxl/libxl_internal.h |  7 
 tools/libxl/libxl_pci.c  | 90 
 4 files changed, 124 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7cf0f31..c5af0aa 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1044,6 +1044,20 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
const libxl_mac *src);
  */
 #define LIBXL_HAVE_QED 1
 
+/* LIBXL_HAVE_REG_AER_EVENTS_HANDLER
+ *
+ * If it is defined, libxl has a library function called
+ * libxl_reg_aer_events_handler.
+ */
+#define LIBXL_HAVE_REG_AER_EVENTS_HANDLER 1
+
+/* LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER
+ *
+ * If it is defined, libxl has a library function called
+ * libxl_unreg_aer_events_handler.
+ */
+#define LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER 1
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 1ea789e..1aea906 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -184,6 +184,19 @@ void libxl_evdisable_domain_death(libxl_ctx *ctx, 
libxl_evgen_domain_death*);
* may generate only a DEATH event.
*/
 
+typedef struct libxl__aer_watch libxl_aer_watch;
+int libxl_reg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch **)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+  /*
+   * Registers a handler to handle the occurrence of unrecoverable AER errors.
+   * This function depends on the calling application running the libxl's
+   * internal event loop. Toolstacks that do not use libxl's internal
+   * event loop must arrange to have their own event loop created and enter
+   * libxl (say, call libxl_event_wait()), to enable the event to be processed.
+   */
+void libxl_unreg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch *)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+
 typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
 int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
 libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index afe6652..2b74286 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -352,6 +352,13 @@ struct libxl__ev_child {
 LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
 };
 
+/*
+ * Structure used for AER event handling.
+ */
+struct libxl__aer_watch {
+uint32_t domid;
+libxl__ev_xswatch watch;
+};
 
 /*
  * evgen structures, which are the state we use for generating
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 65ad5e5..feedf27 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1678,6 +1678,96 @@ static int libxl_device_pci_compare(libxl_device_pci *d1,
 return COMPARE_PCI(d1, d2);
 }
 
+static void aer_backend_watch_callback(libxl__egc *egc,
+   libxl__ev_xswatch *watch,
+   const char *watch_path,
+   const char *event_path)
+{
+EGC_GC;
+libxl_aer_watch *aer_ws = CONTAINER_OF(watch, *aer_ws, watch);
+int rc;
+uint32_t dom, bus, dev, fn;
+uint32_t domid = aer_ws->domid;
+char *p, *path;
+const char *aerFailedSBDF;
+libxl_device_pci pcidev;
+
+/* Extract the backend directory. */
+path = libxl__strdup(gc, event_path);
+p = strrchr(path, '/');
+if ((p == NULL) || (strcmp(p, "/aerFailedSBDF") != 0))
+return;
+/* Truncate the string so it points to the backend directory. */
+*p = '\0';
+
+/* Fetch the value of the failed PCI device. */
+rc = libxl__xs_read_checked(gc, XBT_NULL,
+GCSPRINTF("%s/aerFailedSBDF", path), );
+if (rc || !aerFailedSBDF)
+return;
+sscanf(aerFailedSBDF, "%x:%x:%x.%x", , , , );
+
+libxl_device_pci_init();
+pcidev_struct_fill(, dom, bus, dev, fn, 0);
+/* Forcibly remove the device from the guest */
+rc = libxl__device_pci_remove_common(gc, domid, , 1);
+if (rc)
+LOGD(ERROR, domid, " libxl__device_pci_remove_common() failed, rc=x%x",
+(unsigned int)rc);
+
+return;
+}
+
+int libxl_reg_aer_events_handler(libxl_ctx *ctx,
+ uint32_t domid,
+ libxl_aer_watch **aer_ws_out)
+{
+int rc = 0;
+int dom0_domid;
+char *be_path;
+libxl_aer_watch *aer_ws = NULL;
+

[Xen-devel] [PATCH v3 0/2] Containing AER unrecoverable errors

[Venu Busireddy]

This patch set is part of a set of patches that together allow containment
of unrecoverable AER errors from PCIe devices assigned to guests in
passthrough mode. The containment is achieved by forcibly removing the
erring PCIe device from the guest.

The original xen-pciback patch corresponding to this patch set is:
https://lists.xen.org/archives/html/xen-devel/2017-06/msg03274.html.
It will be reposted after this patch set is accepted.

Changes in v3:
  * Made the following changes suggested by Wei Liu.
- Added LIBXL_HAVE macros to libxl.h.
- Don't hard-code dom0's domid to 0. Instead, use libxl__get_domid().
- Corrected comments.
  * Made the following changes based on comments from Ian Jackson.
- Got rid of the global variable aer_watch.
- Added documentation (comments in code) for the new API calls.
- Removed the unnecessary writes to xenstore.

Changes in v2:
  - Instead of killing the guest and hiding the device, forcibly remove
the device from the guest.

Venu Busireddy (2):
  libxl: Implement the handler to handle unrecoverable AER errors.
  xl: Register the AER event handler to handle AER errors.

 tools/libxl/libxl.h  | 14 +++
 tools/libxl/libxl_event.h| 13 +++
 tools/libxl/libxl_internal.h |  7 
 tools/libxl/libxl_pci.c  | 90 
 tools/xl/xl_vmcontrol.c  |  9 +
 5 files changed, 133 insertions(+)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 2/2] xl: Register the AER event handler to handle AER errors

[Venu Busireddy]

When a guest is created, register the AER event handler to handle the
AER errors. When an AER error occurs, the handler will forcibly remove
the erring PCIe device from the guest.

Signed-off-by: Venu Busireddy 
---
 tools/xl/xl_vmcontrol.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 89c2b25..9855cdb 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -656,6 +656,7 @@ int create_domain(struct domain_create *dom_info)
 const char *restore_source = NULL;
 int migrate_fd = dom_info->migrate_fd;
 bool config_in_json;
+libxl_aer_watch *aer_ws = NULL;
 
 int i;
 int need_daemon = daemonize;
@@ -966,6 +967,12 @@ start:
 LOG("Waiting for domain %s (domid %u) to die [pid %ld]",
 d_config.c_info.name, domid, (long)getpid());
 
+ret = libxl_reg_aer_events_handler(ctx, domid, _ws);
+if (ret) {
+/* Log the error, and move on... */
+LOG("libxl_reg_aer_events_handler() failed, ret = 0x%08x", ret);
+}
+
 ret = libxl_evenable_domain_death(ctx, domid, 0, );
 if (ret) goto out;
 
@@ -993,6 +1000,7 @@ start:
 LOG("Domain %u has shut down, reason code %d 0x%x", domid,
 event->u.domain_shutdown.shutdown_reason,
 event->u.domain_shutdown.shutdown_reason);
+libxl_unreg_aer_events_handler(ctx, domid, aer_ws);
 switch (handle_domain_death(, event, _config)) {
 case DOMAIN_RESTART_SOFT_RESET:
 domid_soft_reset = domid;
@@ -1059,6 +1067,7 @@ start:
 
 case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
 LOG("Domain %u has been destroyed.", domid);
+libxl_unreg_aer_events_handler(ctx, domid, aer_ws);
 libxl_event_free(ctx, event);
 ret = 0;
 goto out;

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors

[Venu Busireddy]

Implement the callback function to handle unrecoverable AER errors, and
also the public APIs that can be used to register/unregister the handler.
When an AER error occurs, the handler will forcibly remove the erring
PCIe device from the guest.

Signed-off-by: Venu Busireddy 
---
 tools/libxl/libxl.h  | 14 +++
 tools/libxl/libxl_event.h| 13 +++
 tools/libxl/libxl_internal.h |  7 
 tools/libxl/libxl_pci.c  | 90 
 4 files changed, 124 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7cf0f31..c5af0aa 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1044,6 +1044,20 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
const libxl_mac *src);
  */
 #define LIBXL_HAVE_QED 1
 
+/* LIBXL_HAVE_REG_AER_EVENTS_HANDLER
+ *
+ * If it is defined, libxl has a library function called
+ * libxl_reg_aer_events_handler.
+ */
+#define LIBXL_HAVE_REG_AER_EVENTS_HANDLER 1
+
+/* LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER
+ *
+ * If it is defined, libxl has a library function called
+ * libxl_unreg_aer_events_handler.
+ */
+#define LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER 1
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 1ea789e..1aea906 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -184,6 +184,19 @@ void libxl_evdisable_domain_death(libxl_ctx *ctx, 
libxl_evgen_domain_death*);
* may generate only a DEATH event.
*/
 
+typedef struct libxl__aer_watch libxl_aer_watch;
+int libxl_reg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch **)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+  /*
+   * Registers a handler to handle the occurrence of unrecoverable AER errors.
+   * This function depends on the calling application running the libxl's
+   * internal event loop. Toolstacks that do not use libxl's internal
+   * event loop must arrange to have their own event loop created and enter
+   * libxl (say, call libxl_event_wait()), to enable the event to be processed.
+   */
+void libxl_unreg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch *)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+
 typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
 int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
 libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index afe6652..2b74286 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -352,6 +352,13 @@ struct libxl__ev_child {
 LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
 };
 
+/*
+ * Structure used for AER event handling.
+ */
+struct libxl__aer_watch {
+uint32_t domid;
+libxl__ev_xswatch watch;
+};
 
 /*
  * evgen structures, which are the state we use for generating
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 65ad5e5..feedf27 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1678,6 +1678,96 @@ static int libxl_device_pci_compare(libxl_device_pci *d1,
 return COMPARE_PCI(d1, d2);
 }
 
+static void aer_backend_watch_callback(libxl__egc *egc,
+   libxl__ev_xswatch *watch,
+   const char *watch_path,
+   const char *event_path)
+{
+EGC_GC;
+libxl_aer_watch *aer_ws = CONTAINER_OF(watch, *aer_ws, watch);
+int rc;
+uint32_t dom, bus, dev, fn;
+uint32_t domid = aer_ws->domid;
+char *p, *path;
+const char *aerFailedSBDF;
+libxl_device_pci pcidev;
+
+/* Extract the backend directory. */
+path = libxl__strdup(gc, event_path);
+p = strrchr(path, '/');
+if ((p == NULL) || (strcmp(p, "/aerFailedSBDF") != 0))
+return;
+/* Truncate the string so it points to the backend directory. */
+*p = '\0';
+
+/* Fetch the value of the failed PCI device. */
+rc = libxl__xs_read_checked(gc, XBT_NULL,
+GCSPRINTF("%s/aerFailedSBDF", path), );
+if (rc || !aerFailedSBDF)
+return;
+sscanf(aerFailedSBDF, "%x:%x:%x.%x", , , , );
+
+libxl_device_pci_init();
+pcidev_struct_fill(, dom, bus, dev, fn, 0);
+/* Forcibly remove the device from the guest */
+rc = libxl__device_pci_remove_common(gc, domid, , 1);
+if (rc)
+LOGD(ERROR, domid, " libxl__device_pci_remove_common() failed, rc=x%x",
+(unsigned int)rc);
+
+return;
+}
+
+int libxl_reg_aer_events_handler(libxl_ctx *ctx,
+ uint32_t domid,
+ libxl_aer_watch **aer_ws_out)
+{
+int rc = 0;
+int dom0_domid;
+char *be_path;
+libxl_aer_watch *aer_ws = NULL;
+

[Xen-devel] [PATCH v3 0/2] Containing AER unrecoverable errors

[Venu Busireddy]

This patch set is part of a set of patches that together allow containment
of unrecoverable AER errors from PCIe devices assigned to guests in
passthrough mode. The containment is achieved by forcibly removing the
erring PCIe device from the guest.

The original xen-pciback patch corresponding to this patch set is:
https://lists.xen.org/archives/html/xen-devel/2017-06/msg03274.html.
It will be reposted after this patch set is accepted.

Changes in v3:
  * Made the following changes suggested by Wei Liu.
- Added LIBXL_HAVE macros to libxl.h.
- Don't hard-code dom0's domid to 0. Instead, use libxl__get_domid().
- Corrected comments.
  * Made the following changes based on comments from Ian Jackson.
- Got rid of the global variable aer_watch.
- Added documentation (comments in code) for the new API calls.
- Removed the unnecessary writes to xenstore.

Changes in v2:
  - Instead of killing the guest and hiding the device, forcibly remove
the device from the guest.

Venu Busireddy (2):
  libxl: Implement the handler to handle unrecoverable AER errors.
  xl: Register the AER event handler to handle AER errors.

 tools/libxl/libxl.h  | 14 +++
 tools/libxl/libxl_event.h| 13 +++
 tools/libxl/libxl_internal.h |  7 
 tools/libxl/libxl_pci.c  | 90 
 tools/xl/xl_vmcontrol.c  |  9 +
 5 files changed, 133 insertions(+)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 0/2] Containing AER unrecoverable errors

[Venu Busireddy]

This patch set is part of a set of patches that together allow containment
of unrecoverable AER errors from PCIe devices assigned to guests in
passthrough mode. The containment is achieved by forcibly removing the
erring PCIe device from the guest.

Changes in v3:
  * Made the following changes suggested by Wei Liu.
- Added LIBXL_HAVE macros to libxl.h.
- Don't hard-code dom0's domid to 0. Instead, use libxl__get_domid().
- Corrected comments.
  * Made the following changes based on comments from Ian Jackson.
- Got rid of the global variable aer_watch.
- Added documentation (comments in code) for the new API calls.
- Removed the unnecessary writes to xenstore.

Changes in v2:
  - Instead of killing the guest and hiding the device, forcibly remove
the device from the guest.

Venu Busireddy (2):
  libxl: Implement the handler to handle unrecoverable AER errors.
  xl: Register the AER event handler to handle AER errors.

 tools/libxl/libxl.h  | 14 +++
 tools/libxl/libxl_event.h| 13 +++
 tools/libxl/libxl_internal.h |  7 
 tools/libxl/libxl_pci.c  | 90 
 tools/xl/xl_vmcontrol.c  |  9 +
 5 files changed, 133 insertions(+)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 2/2] xl: Register the AER event handler to handle AER errors

[Venu Busireddy]

When a guest is created, register the AER event handler to handle the
AER errors. When an AER error occurs, the handler will forcibly remove
the erring PCIe device from the guest.

Signed-off-by: Venu Busireddy 
---
 tools/xl/xl_vmcontrol.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 89c2b25..9855cdb 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -656,6 +656,7 @@ int create_domain(struct domain_create *dom_info)
 const char *restore_source = NULL;
 int migrate_fd = dom_info->migrate_fd;
 bool config_in_json;
+libxl_aer_watch *aer_ws = NULL;
 
 int i;
 int need_daemon = daemonize;
@@ -966,6 +967,12 @@ start:
 LOG("Waiting for domain %s (domid %u) to die [pid %ld]",
 d_config.c_info.name, domid, (long)getpid());
 
+ret = libxl_reg_aer_events_handler(ctx, domid, _ws);
+if (ret) {
+/* Log the error, and move on... */
+LOG("libxl_reg_aer_events_handler() failed, ret = 0x%08x", ret);
+}
+
 ret = libxl_evenable_domain_death(ctx, domid, 0, );
 if (ret) goto out;
 
@@ -993,6 +1000,7 @@ start:
 LOG("Domain %u has shut down, reason code %d 0x%x", domid,
 event->u.domain_shutdown.shutdown_reason,
 event->u.domain_shutdown.shutdown_reason);
+libxl_unreg_aer_events_handler(ctx, domid, aer_ws);
 switch (handle_domain_death(, event, _config)) {
 case DOMAIN_RESTART_SOFT_RESET:
 domid_soft_reset = domid;
@@ -1059,6 +1067,7 @@ start:
 
 case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
 LOG("Domain %u has been destroyed.", domid);
+libxl_unreg_aer_events_handler(ctx, domid, aer_ws);
 libxl_event_free(ctx, event);
 ret = 0;
 goto out;

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors

[Venu Busireddy]

Implement the callback function to handle unrecoverable AER errors, and
also the public APIs that can be used to register/unregister the handler.
When an AER error occurs, the handler will forcibly remove the erring
PCIe device from the guest.

Signed-off-by: Venu Busireddy 
---
 tools/libxl/libxl.h  | 14 +++
 tools/libxl/libxl_event.h| 13 +++
 tools/libxl/libxl_internal.h |  7 
 tools/libxl/libxl_pci.c  | 90 
 4 files changed, 124 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7cf0f31..c5af0aa 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1044,6 +1044,20 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
const libxl_mac *src);
  */
 #define LIBXL_HAVE_QED 1
 
+/* LIBXL_HAVE_REG_AER_EVENTS_HANDLER
+ *
+ * If it is defined, libxl has a library function called
+ * libxl_reg_aer_events_handler.
+ */
+#define LIBXL_HAVE_REG_AER_EVENTS_HANDLER 1
+
+/* LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER
+ *
+ * If it is defined, libxl has a library function called
+ * libxl_unreg_aer_events_handler.
+ */
+#define LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER 1
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 1ea789e..1aea906 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -184,6 +184,19 @@ void libxl_evdisable_domain_death(libxl_ctx *ctx, 
libxl_evgen_domain_death*);
* may generate only a DEATH event.
*/
 
+typedef struct libxl__aer_watch libxl_aer_watch;
+int libxl_reg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch **)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+  /*
+   * Registers a handler to handle the occurrence of unrecoverable AER errors.
+   * This function depends on the calling application running the libxl's
+   * internal event loop. Toolstacks that do not use libxl's internal
+   * event loop must arrange to have their own event loop created and enter
+   * libxl (say, call libxl_event_wait()), to enable the event to be processed.
+   */
+void libxl_unreg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch *)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+
 typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
 int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
 libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index afe6652..2b74286 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -352,6 +352,13 @@ struct libxl__ev_child {
 LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
 };
 
+/*
+ * Structure used for AER event handling.
+ */
+struct libxl__aer_watch {
+uint32_t domid;
+libxl__ev_xswatch watch;
+};
 
 /*
  * evgen structures, which are the state we use for generating
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 65ad5e5..feedf27 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1678,6 +1678,96 @@ static int libxl_device_pci_compare(libxl_device_pci *d1,
 return COMPARE_PCI(d1, d2);
 }
 
+static void aer_backend_watch_callback(libxl__egc *egc,
+   libxl__ev_xswatch *watch,
+   const char *watch_path,
+   const char *event_path)
+{
+EGC_GC;
+libxl_aer_watch *aer_ws = CONTAINER_OF(watch, *aer_ws, watch);
+int rc;
+uint32_t dom, bus, dev, fn;
+uint32_t domid = aer_ws->domid;
+char *p, *path;
+const char *aerFailedSBDF;
+libxl_device_pci pcidev;
+
+/* Extract the backend directory. */
+path = libxl__strdup(gc, event_path);
+p = strrchr(path, '/');
+if ((p == NULL) || (strcmp(p, "/aerFailedSBDF") != 0))
+return;
+/* Truncate the string so it points to the backend directory. */
+*p = '\0';
+
+/* Fetch the value of the failed PCI device. */
+rc = libxl__xs_read_checked(gc, XBT_NULL,
+GCSPRINTF("%s/aerFailedSBDF", path), );
+if (rc || !aerFailedSBDF)
+return;
+sscanf(aerFailedSBDF, "%x:%x:%x.%x", , , , );
+
+libxl_device_pci_init();
+pcidev_struct_fill(, dom, bus, dev, fn, 0);
+/* Forcibly remove the device from the guest */
+rc = libxl__device_pci_remove_common(gc, domid, , 1);
+if (rc)
+LOGD(ERROR, domid, " libxl__device_pci_remove_common() failed, rc=x%x",
+(unsigned int)rc);
+
+return;
+}
+
+int libxl_reg_aer_events_handler(libxl_ctx *ctx,
+ uint32_t domid,
+ libxl_aer_watch **aer_ws_out)
+{
+int rc = 0;
+int dom0_domid;
+char *be_path;
+libxl_aer_watch *aer_ws = NULL;
+

[Xen-devel] [linux-4.1 test] 112503: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

flight 112503 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112503/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm  15 guest-stop   fail in 112491 pass in 112503
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112491 
pass in 112503
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112491 
pass in 112503
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 112491

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 95
 build-arm64   2 hosts-allocate broken REGR. vs. 95
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 95

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 95
 build-arm64   3 capture-logs  broken blocked in 95
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 95
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 112491 blocked in 
95
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112491 
like 95
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 95
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 95
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 95
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 95
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 95
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 

Re: [Xen-devel] [PATCH v3] xen: get rid of paravirt op adjust_exception_frame

[Boris Ostrovsky]

> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 811e4ddb3f37..a3dcd83187ce 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -579,6 +579,71 @@ static void xen_write_ldt_entry(struct desc_struct *dt, 
> int entrynum,
>   preempt_enable();
>  }
>  
> +#ifdef CONFIG_X86_64
> +static struct {
> + void (*orig)(void);
> + void (*xen)(void);
> + bool ist_okay;
> + bool handle;
> +} trap_array[] = {
> + { debug, xen_xendebug, true, true },
> + { int3, xen_xenint3, true, true },
> + { double_fault, xen_double_fault, true, false },

Is it really worth adding 'handle' member to the structure because of a
single special case? We don't expect to ever have another such vector.

(TBH, I think current implementation of cvt_gate_to_trap() is clearer,
even if it is not as general as what is in this patch. I know that Andy
disagrees).

-boris

> +#ifdef CONFIG_X86_MCE
> + { machine_check, xen_machine_check, true, true },
> +#endif
> + { nmi, xen_nmi, true, true },
> + { overflow, xen_overflow, false, true },
> +#ifdef CONFIG_IA32_EMULATION
> + { entry_INT80_compat, xen_entry_INT80_compat, false, true },
> +#endif
> + { page_fault, xen_page_fault, false, true },
> + { divide_error, xen_divide_error, false, true },
> + { bounds, xen_bounds, false, true },
> + { invalid_op, xen_invalid_op, false, true },
> + { device_not_available, xen_device_not_available, false, true },
> + { coprocessor_segment_overrun, xen_coprocessor_segment_overrun,
> +   false, true },
> + { invalid_TSS, xen_invalid_TSS, false, true },
> + { segment_not_present, xen_segment_not_present, false, true },
> + { stack_segment, xen_stack_segment, false, true },
> + { general_protection, xen_general_protection, false, true },
> + { spurious_interrupt_bug, xen_spurious_interrupt_bug, false, true },
> + { coprocessor_error, xen_coprocessor_error, false, true },
> + { alignment_check, xen_alignment_check, false, true },
> + { simd_coprocessor_error, xen_simd_coprocessor_error, false, true },
> +#ifdef CONFIG_TRACING
> + { trace_page_fault, xen_trace_page_fault, false, true },
> +#endif
> +};
> +
> +static bool get_trap_addr(unsigned long *addr, unsigned int ist)
> +{
> + unsigned int nr;
> + bool handle = true, ist_okay = false;
> +
> + /*
> +  * Replace trap handler addresses by Xen specific ones.
> +  * Check for known traps using IST and whitelist them.
> +  * The debugger ones are the only ones we care about.
> +  * Xen will handle faults like double_fault, * so we should never see
> +  * them.  Warn if there's an unexpected IST-using fault handler.
> +  */
> + for (nr = 0; nr < ARRAY_SIZE(trap_array); nr++)
> + if (*addr == (unsigned long)trap_array[nr].orig) {
> + *addr = (unsigned long)trap_array[nr].xen;
> + ist_okay = trap_array[nr].ist_okay;
> + handle = trap_array[nr].handle;
> + break;
> + }
> +
> + if (WARN_ON(ist != 0 && !ist_okay))
> + handle = false;
> +
> + return handle;
> +}
> +#endif
> +
>  static int cvt_gate_to_trap(int vector, const gate_desc *val,
>   struct trap_info *info)
>  {
> @@ -591,40 +656,8 @@ static int cvt_gate_to_trap(int vector, const gate_desc 
> *val,
>  
>   addr = gate_offset(*val);
>  #ifdef CONFIG_X86_64
> - /*
> -  * Look for known traps using IST, and substitute them
> -  * appropriately.  The debugger ones are the only ones we care
> -  * about.  Xen will handle faults like double_fault,
> -  * so we should never see them.  Warn if
> -  * there's an unexpected IST-using fault handler.
> -  */
> - if (addr == (unsigned long)debug)
> - addr = (unsigned long)xen_debug;
> - else if (addr == (unsigned long)int3)
> - addr = (unsigned long)xen_int3;
> - else if (addr == (unsigned long)stack_segment)
> - addr = (unsigned long)xen_stack_segment;
> - else if (addr == (unsigned long)double_fault) {
> - /* Don't need to handle these */
> + if (!get_trap_addr(, val->ist))
>   return 0;
> -#ifdef CONFIG_X86_MCE
> - } else if (addr == (unsigned long)machine_check) {
> - /*
> -  * when xen hypervisor inject vMCE to guest,
> -  * use native mce handler to handle it
> -  */
> - ;
> -#endif
> - } else if (addr == (unsigned long)nmi)
> - /*
> -  * Use the native version as well.
> -  */
> - ;
> - else {
> - /* Some other trap using IST? */
> - if (WARN_ON(val->ist != 0))
> - return 0;
> - }
>  #endif   /* CONFIG_X86_64 */
>   info->address = addr;
>  

[Xen-devel] [linux-4.9 test] 112497: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 112497 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112497/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   5 host-ping-check-native   fail REGR. vs. 112405

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112405
 build-arm64-pvops 2 hosts-allocate  broken like 112405
 build-arm64   2 hosts-allocate  broken like 112405
 build-arm64-pvops 3 capture-logsbroken like 112405
 build-arm64   3 capture-logsbroken like 112405
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 112397
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112397
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112397
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112405
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112405
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112405
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxdb397d9c6e66afdd34ae430172db122632b5f8a7
baseline version:
 linuxefcfbfb1d8bf756d1b58fe215bf4e419d176435b

Last test of basis   112405  2017-08-01 03:50:17 Z6 days
Testing same since   112497  2017-08-07 02:26:34 Z0 days1 attempts

[Xen-devel] [ovmf baseline-only test] 71947: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71947 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71947/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8853c2afc51c2cab862acbef308f2588264e188b
baseline version:
 ovmf 97c567efd303f610ac16e12b4bf066d0240f6d0b

Last test of basis71945  2017-08-07 05:56:58 Z0 days
Testing same since71947  2017-08-07 17:47:20 Z0 days1 attempts


People who touched revisions under test:
  Chris Ruffin 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 8853c2afc51c2cab862acbef308f2588264e188b
Author: Chris Ruffin 
Date:   Thu Aug 3 04:30:06 2017 +0800

BaseTools/Conf: apply nasmb, asm16 build rule order

Prioritize nasmb rule over asm16 where both source types are specified.

Change-Id: I33ec348dab66b313ddb05cb15f2d8407a648c320
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chris Ruffin 
Reviewed-by: Liming Gao 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC v1] xen:rtds: towards work conserving RTDS

[Meng Xu]

On Mon, Aug 7, 2017 at 3:14 PM, Dario Faggioli
 wrote:
> On Mon, 2017-08-07 at 14:27 -0400, Meng Xu wrote:
>> On Mon, Aug 7, 2017 at 1:35 PM, Dario Faggioli
>>
>> > Is this wanted or expected?
>>
>> It is wanted.
>>
>> A VCPU i that has already got budget_i * priority_level_i time has
>> higher priority than another VCPU j that got budget_j *
>> priority_level_j time, where priority_level_j > priority_level_i.
>>
>> For the unreserved resource, a VCPU will gets roughly budget/period
>> proportional unreserved CPU time.
>>
>>
>> > Basically, if I'm not wrong, this means that the actual priority,
>> > during the extratime phase, is some combination of deadline and
>> > budget
>> > (which would make me think to utilization)... is this the case?
>>
>> Yes.
>> The higher utilization a VCPU has, the more extra time it will get in
>> the extratime phase.
>>
>> >
>> > I don't care much about the actual schedule during the extratime
>> > phase,
>> > in the sense that it doesn't have to be anything too complicated or
>> > super advanced... but I at least would like:
>> > - to know how it works, and hence what to expect,
>> > - for it to be roughly fair.
>>
>> The unreserved resource is proportionally allocated to VCPUs roughly
>> based on VCPU's budget/period.
>>
> Right. Then this deserves both:
> - a quick mention in the changelog
> - a little bit more detailed explanation in a comment close to one of
>   the place where the policy is enacted (or at the top of the file,
>   or, well, somewhere :-) )
>

Sure. I can do that in the next version.
Hopefully we can reach the agreement on the code based on this version
so that the next version can be the final version for this patch
series. Hopefully. :)

Best,

Meng

---
Meng Xu
PhD Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC v1] xen:rtds: towards work conserving RTDS

[Dario Faggioli]

On Mon, 2017-08-07 at 14:27 -0400, Meng Xu wrote:
> On Mon, Aug 7, 2017 at 1:35 PM, Dario Faggioli
> 
> > Is this wanted or expected?
> 
> It is wanted.
> 
> A VCPU i that has already got budget_i * priority_level_i time has
> higher priority than another VCPU j that got budget_j *
> priority_level_j time, where priority_level_j > priority_level_i.
> 
> For the unreserved resource, a VCPU will gets roughly budget/period
> proportional unreserved CPU time.
> 
> 
> > Basically, if I'm not wrong, this means that the actual priority,
> > during the extratime phase, is some combination of deadline and
> > budget
> > (which would make me think to utilization)... is this the case?
> 
> Yes.
> The higher utilization a VCPU has, the more extra time it will get in
> the extratime phase.
> 
> > 
> > I don't care much about the actual schedule during the extratime
> > phase,
> > in the sense that it doesn't have to be anything too complicated or
> > super advanced... but I at least would like:
> > - to know how it works, and hence what to expect,
> > - for it to be roughly fair.
> 
> The unreserved resource is proportionally allocated to VCPUs roughly
> based on VCPU's budget/period.
> 
Right. Then this deserves both:
- a quick mention in the changelog
- a little bit more detailed explanation in a comment close to one of 
  the place where the policy is enacted (or at the top of the file, 
  or, well, somewhere :-) )

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC v1] xen:rtds: towards work conserving RTDS

[Meng Xu]

On Mon, Aug 7, 2017 at 1:35 PM, Dario Faggioli
 wrote:
> On Sat, 2017-08-05 at 17:35 -0400, Meng Xu wrote:
>> >
>> > > @@ -966,8 +1001,16 @@ burn_budget(const struct scheduler *ops,
>> > > struct
>> > > rt_vcpu *svc, s_time_t now)
>> > >
>> > >  if ( svc->cur_budget <= 0 )
>> > >  {
>> > > -svc->cur_budget = 0;
>> > > -__set_bit(__RTDS_depleted, >flags);
>> > > +if ( is_work_conserving(svc) )
>> > > +{
>> > > +svc->priority_level++;
>> > >
>> >
>> >ASSERT(svc->priority_level <= 1);
>>
>> I'm sorry I didn't see this suggestion in previous email. I don't
>> think this assert makes sense.
>>
>> A vcpu that has extratime can have priority_level > 1.
>> For example, a VCPU (period = 100ms, budget = 10ms) runs alone on a
>> core. The VCPU may get its budget replenished  for 9 times in a
>> period. the vcpu's priority_level may be 9.
>>
> Ah, ok. Yes, I missed this, while I see this now.
>
> But doesn't this mean that, at a certain time t, between both CPUs that
> are both in 'etratime mode' (i.e., they've run out of budget, but
> they're running because they have extratime set), the one that has
> received less replenishments gets priority?

Yes.

>
> Is this wanted or expected?

It is wanted.

A VCPU i that has already got budget_i * priority_level_i time has
higher priority than another VCPU j that got budget_j *
priority_level_j time, where priority_level_j > priority_level_i.

For the unreserved resource, a VCPU will gets roughly budget/period
proportional unreserved CPU time.


> Basically, if I'm not wrong, this means that the actual priority,
> during the extratime phase, is some combination of deadline and budget
> (which would make me think to utilization)... is this the case?

Yes.
The higher utilization a VCPU has, the more extra time it will get in
the extratime phase.

>
> I don't care much about the actual schedule during the extratime phase,
> in the sense that it doesn't have to be anything too complicated or
> super advanced... but I at least would like:
> - to know how it works, and hence what to expect,
> - for it to be roughly fair.

The unreserved resource is proportionally allocated to VCPUs roughly
based on VCPU's budget/period.

Best,

Meng


---
Meng Xu
PhD Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC v1] xen:rtds: towards work conserving RTDS

[Dario Faggioli]

On Sat, 2017-08-05 at 17:35 -0400, Meng Xu wrote:
> > 
> > > @@ -966,8 +1001,16 @@ burn_budget(const struct scheduler *ops,
> > > struct
> > > rt_vcpu *svc, s_time_t now)
> > > 
> > >  if ( svc->cur_budget <= 0 )
> > >  {
> > > -svc->cur_budget = 0;
> > > -__set_bit(__RTDS_depleted, >flags);
> > > +if ( is_work_conserving(svc) )
> > > +{
> > > +svc->priority_level++;
> > > 
> > 
> >    ASSERT(svc->priority_level <= 1);
> 
> I'm sorry I didn't see this suggestion in previous email. I don't
> think this assert makes sense.
> 
> A vcpu that has extratime can have priority_level > 1.
> For example, a VCPU (period = 100ms, budget = 10ms) runs alone on a
> core. The VCPU may get its budget replenished  for 9 times in a
> period. the vcpu's priority_level may be 9.
> 
Ah, ok. Yes, I missed this, while I see this now.

But doesn't this mean that, at a certain time t, between both CPUs that
are both in 'etratime mode' (i.e., they've run out of budget, but
they're running because they have extratime set), the one that has
received less replenishments gets priority?

Is this wanted or expected?

Basically, if I'm not wrong, this means that the actual priority,
during the extratime phase, is some combination of deadline and budget
(which would make me think to utilization)... is this the case?

I don't care much about the actual schedule during the extratime phase,
in the sense that it doesn't have to be anything too complicated or
super advanced... but I at least would like:
- to know how it works, and hence what to expect,
- for it to be roughly fair.

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 112501: all pass - PUSHED

[osstest service owner]

flight 112501 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112501/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8853c2afc51c2cab862acbef308f2588264e188b
baseline version:
 ovmf 97c567efd303f610ac16e12b4bf066d0240f6d0b

Last test of basis   112495  2017-08-07 01:24:10 Z0 days
Testing same since   112501  2017-08-07 05:56:52 Z0 days1 attempts


People who touched revisions under test:
  Chris Ruffin 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=8853c2afc51c2cab862acbef308f2588264e188b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
8853c2afc51c2cab862acbef308f2588264e188b
+ branch=ovmf
+ revision=8853c2afc51c2cab862acbef308f2588264e188b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x8853c2afc51c2cab862acbef308f2588264e188b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

>>
>> Switching to bitfields was, btw, suggested by Jan at some point so if
>> the two of you agree on how to proceed I can go either way (but by
>> preference is to keep it as a single-bit bitfield).
>
> If you use a single-bit bitfield of bool (i.e bool need_flush : 1) you
> would address both Jan's comment and mine.

Haven't considered this. I thought you meant a fully-sized bool. I'll do
this, thanks.

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Andrew Cooper]

On 07/08/17 17:49, Boris Ostrovsky wrote:
> On 08/07/2017 12:20 PM, Andrew Cooper wrote:
>> On 07/08/17 17:06, Jan Beulich wrote:
>> Andrew Cooper  08/07/17 5:40 PM >>>
 On 07/08/17 16:38, Jan Beulich wrote:
> So a single NIC drove the system out of vectors? That's insane, I would
> say, i.e. I'd call this a misconfigured system. But yeah, if we really 
> want
> to get such a thing to work despite the insanity ...
 No.  That's one single (dual headed) card with 128 virtual functions each.
>>> But putting such in a single-core system is, well, not very reasonable. At
>>> the very least I'd expect the admin to limit the number of VFs then, or not
>>> load a driver in Dom0 for them (but only for the PF).
>> Its not a single core system, but cluster mode allocates vectors across
>> clusters, not cores. This turns even the largest server system into a
>> single core system as far as vector availability goes.
> In my case we have enough vectors on a fully-populated system (4
> sockets), which is how it was installed.
>
> However, we want to be able to reduce the number of processors and one
> such configuration is to limit processors to a single socket (which
> translates to a single cluster as far APIC is concerned). Requiring
> admins to also reduce number of virtual functions is probably somewhat
> complicated to explain/document (especially since this would depend on
> number of cores on a socket).

Netscalars usecase is a dual-socket system, but it already having to
under-utilise the interrupt capability of the hardware to be able to fit
a single interrupt from every device into the vector-space available in Xen.

More than once, we've discussed freeing up the legacy PIC range of
vectors, and freeing up the unallocated vectors in 0xfx.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xen/arm: Software Step ARMv8 - PC stuck on instruction

[James Morse]

Hi Florian,

On 03/08/17 17:00, Florian Jakobsmeier wrote:
> regarding your previous mails. I was able to single step every instruction
> of my module. The problem (or rather the solution) was to _disable_ the IRQ
> interrupts from within my guest module. This solves the problem of
> singlestepping a module which previously ended in a spinlock. But it does
> not solve the problem with system that is singlestepped with enabled IRQ's,
> as it still will be locked within a spinlock.

If I understand correctly: if you try to single-step a spinlock then you get
stuck in a loop. The code you want to single-step doesn't take any spinlocks,
but if you take an IRQ, the IRQ handler does.

[...]

> This is my module code which is executed in the DomU:
> 
> int init_module()
>> {
>> printk(KERN_INFO "### Init address 0x%lx\n", _module);
>> printk(KERN_INFO "Set function hook\n");
>> patch_function_hook();
>>
>> printk(KERN_INFO "Starting singlestep\n");
> 
>> local_irq_disable();
>> __asm__ __volatile__ ("SMC 1");
>> __asm__ __volatile__ ("SMC 1");

(Back-to-back SMCs, this explains why I thought you were missing the PC-advance
logic).


>> if(!already_trapped)
>> {
>> __asm__ __volatile__ ("NOP");
>> __asm__ __volatile__ ("NOP");
>> __asm__ __volatile__ ("NOP");
>>
>> //Just for keeping module busy while singlestep
>> for ( c = 0 ; c < n ; c++ )
>>
> When executing these exact steps, it is possible to singlestep the whole
> module. Without the local_irq_disable() the system will stop the module
> execution right after the first SMC.

What do you mean by 'stop'? Options are:
Fail to make progress by taking IRQs all the time instead?
Fail to make progress, instead taking a single step exception on the same
instruction forever.
(or something else)

[...]

> But: It's not possible to singlestep a system as long as the VM IRQ's are
> enabled. If we would activate single stepping with enabled interrupts, we
> will be locked in the mentioned spinlock.
> Because of this it is not possible to singlestep other application.
> Additionally it is not possible to print anything while singlestepping
> because, as far as I understood, the system will wait within a spinlock
> until the terminal is free to print.
>
> Do you have any idea why it's not possible to escape the lock while
> singlestepping? Like I mentioned, my guess is on timer interrupts, which
> should unlock the spinlock but generate problems with singlestep enabled at
> the same time. This would also explain why i can observe the control flow
> of my guest module with IRQ's being disabled.

I suspect you are trying to single-step Linux's spinlocks which use
load-exclusive/store-exclusive. (There is an annotated example in the ARM-ARM
'K9.3.1 Acquiring a lock').
LDAXR sets the 'exclusive monitor' and STXR only succeeds if the exclusive
monitor is still set. If another CPU accesses the memory protected by the
exclusive monitor, the monitor is cleared. This is how the spinlock code knows
it has to re-read its value and try to take the lock again.
Changing exception level also clears the exclusive monitor, so taking
single-step exception between a LDAXR/STXR pair means the loop has to be 
retried.

Ideally, you should avoid single-stepping atomic instruction sequences, as the
single-step mechanism has made them in-atomic, the CPU detects this and the code
then retries.

As a workaround (for just the case you are looking at), you could ask Xen's vgic
to empty the LR registers so that there are no pending guest interrupts, but
this doesn't guarantee you don't try and single-step atomic code.


The best way to fix this is for Xen to emulate the load/store exclusives. You
will need to ensure that no other vcpu for that domain is running between the
load and store. (This stops them from modifying the protected value, and means
they must retry their own load/store exclusives if they were in the same code).

You also have the problem that another vcpu may be holding the lock, so if the
single-stepped vcpu is not making progress with the emulated-and-single-stepped
sequence, you should run each other vcpu in the domain to see if they release
the lock.

Linux enters a low-power state by issuing a 'wfe' from the waiting CPU and a
'sev' from the releasing CPU, you may end up trapping these as you try and step
them.

This is going to be tricky to get right, I'm not aware of anything that allows
single-stepping of atomic regions like this today.


Thanks,

James

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Julien Grall]

On 07/08/17 17:57, Boris Ostrovsky wrote:





diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index ef84b72..d26b232 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -44,7 +44,16 @@ struct page_info
 /* Page is on a free list: ((count_info & PGC_count_mask) ==
0). */
 struct {
 /* Do TLBs need flushing for safety before next page
use? */
-bool_t need_tlbflush;
+unsigned long need_tlbflush:1;


You've turned need_tlbflush from bool to unsigned long : 1. But some
of the users use true/false or may rely on the boolean property.  So
it sounds like to me you want to use bool bitfields here (and in the
x86 part).


This is what we have (with this series applied):

root@ovs104> git grep need_tlbflush .
common/memory.c:bool need_tlbflush = false;
common/memory.c:
accumulate_tlbflush(_tlbflush, [j],
common/memory.c:if ( need_tlbflush )
common/page_alloc.c:bool need_tlbflush = false;
common/page_alloc.c:accumulate_tlbflush(_tlbflush,
[i],
common/page_alloc.c:if ( need_tlbflush )
* common/page_alloc.c:pg[i].u.free.need_tlbflush =
(page_get_owner([i]) != NULL);
common/page_alloc.c:if ( pg[i].u.free.need_tlbflush )
include/asm-arm/mm.h:unsigned long need_tlbflush:1;
include/asm-x86/mm.h:   unsigned long need_tlbflush:1;
include/xen/mm.h:static inline void accumulate_tlbflush(bool
*need_tlbflush,
include/xen/mm.h:if ( page->u.free.need_tlbflush &&
include/xen/mm.h: (!*need_tlbflush ||
include/xen/mm.h:*need_tlbflush = true;
root@ovs104>

The only possibly boolean-style use is '*' and event that I think is
allowed.

Stand-alone need_tlbflush variables above have nothing to do with this
change.


If you look at it, all of them use bool semantic. Now you mix bool and
int. We are trying to remove that in the new code, so please don't
introduce new one.



I am not sure I see how we are mixing the semantics here. :1
is really a tightly-packed bool.


It is not a bool. It is an unsigned int. So if I am not mistaken, if you 
assign 0x2, the variable will be 0 unless you do !!(...).


Whilst with bool you would get 1.



Switching to bitfields was, btw, suggested by Jan at some point so if
the two of you agree on how to proceed I can go either way (but by
preference is to keep it as a single-bit bitfield).


If you use a single-bit bitfield of bool (i.e bool need_flush : 1) you 
would address both Jan's comment and mine.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

>>>
 diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
 index ef84b72..d26b232 100644
 --- a/xen/include/asm-arm/mm.h
 +++ b/xen/include/asm-arm/mm.h
 @@ -44,7 +44,16 @@ struct page_info
  /* Page is on a free list: ((count_info & PGC_count_mask) ==
 0). */
  struct {
  /* Do TLBs need flushing for safety before next page
 use? */
 -bool_t need_tlbflush;
 +unsigned long need_tlbflush:1;
>>>
>>> You've turned need_tlbflush from bool to unsigned long : 1. But some
>>> of the users use true/false or may rely on the boolean property.  So
>>> it sounds like to me you want to use bool bitfields here (and in the
>>> x86 part).
>>
>> This is what we have (with this series applied):
>>
>> root@ovs104> git grep need_tlbflush .
>> common/memory.c:bool need_tlbflush = false;
>> common/memory.c:
>> accumulate_tlbflush(_tlbflush, [j],
>> common/memory.c:if ( need_tlbflush )
>> common/page_alloc.c:bool need_tlbflush = false;
>> common/page_alloc.c:accumulate_tlbflush(_tlbflush,
>> [i],
>> common/page_alloc.c:if ( need_tlbflush )
>> * common/page_alloc.c:pg[i].u.free.need_tlbflush =
>> (page_get_owner([i]) != NULL);
>> common/page_alloc.c:if ( pg[i].u.free.need_tlbflush )
>> include/asm-arm/mm.h:unsigned long need_tlbflush:1;
>> include/asm-x86/mm.h:   unsigned long need_tlbflush:1;
>> include/xen/mm.h:static inline void accumulate_tlbflush(bool
>> *need_tlbflush,
>> include/xen/mm.h:if ( page->u.free.need_tlbflush &&
>> include/xen/mm.h: (!*need_tlbflush ||
>> include/xen/mm.h:*need_tlbflush = true;
>> root@ovs104>
>>
>> The only possibly boolean-style use is '*' and event that I think is
>> allowed.
>>
>> Stand-alone need_tlbflush variables above have nothing to do with this
>> change.
>
> If you look at it, all of them use bool semantic. Now you mix bool and
> int. We are trying to remove that in the new code, so please don't
> introduce new one.


I am not sure I see how we are mixing the semantics here. :1
is really a tightly-packed bool.

Switching to bitfields was, btw, suggested by Jan at some point so if
the two of you agree on how to proceed I can go either way (but by
preference is to keep it as a single-bit bitfield).


>
>>
>>
>>>
 +
 +/*
 + * Index of the first *possibly* unscrubbed page in the
 buddy.
 + * One more than maximum possible order to accommodate
 + * INVALID_DIRTY_IDX.
 + */
 +#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
 +unsigned long first_dirty:MAX_ORDER + 1;
>>>
>>> We need to make sure that this union will not be bigger than unsigned
>>> long. Otherwise this will limit lower down the maximum amount of
>>> memory we support.
>>> So this likely means a BUILD_BUG_ON().
>>
>>
>> Are you concerned that (MAX_ORDER+1) will be larger than sizeof(unsigned
>> long)? If yes, the compiler should complain anyway, shouldn't it?
>
> I am more concerned about the sizeof of the union u to be larger than
> unsigned long.
>
> first_dirty should not be greater than 63 bits (or 31 bits for 32-bits
> architecture). Otherwise likely the compiler will add a padding
> between need_tlbflush and first_dirty. This would increase the
> page_info by 4/8 byte.
>
> The BUILD_BUG_ON(...) would be here to catch such error.

Oh, I see. Sure, I'll add it.

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Boris Ostrovsky]

On 08/07/2017 12:20 PM, Andrew Cooper wrote:
> On 07/08/17 17:06, Jan Beulich wrote:
> Andrew Cooper  08/07/17 5:40 PM >>>
>>> On 07/08/17 16:38, Jan Beulich wrote:
 So a single NIC drove the system out of vectors? That's insane, I would
 say, i.e. I'd call this a misconfigured system. But yeah, if we really want
 to get such a thing to work despite the insanity ...
>>> No.  That's one single (dual headed) card with 128 virtual functions each.
>> But putting such in a single-core system is, well, not very reasonable. At
>> the very least I'd expect the admin to limit the number of VFs then, or not
>> load a driver in Dom0 for them (but only for the PF).
> Its not a single core system, but cluster mode allocates vectors across
> clusters, not cores. This turns even the largest server system into a
> single core system as far as vector availability goes.

In my case we have enough vectors on a fully-populated system (4
sockets), which is how it was installed.

However, we want to be able to reduce the number of processors and one
such configuration is to limit processors to a single socket (which
translates to a single cluster as far APIC is concerned). Requiring
admins to also reduce number of virtual functions is probably somewhat
complicated to explain/document (especially since this would depend on
number of cores on a socket).

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Andrew Cooper]

On 07/08/17 17:06, Jan Beulich wrote:
 Andrew Cooper  08/07/17 5:40 PM >>>
>> On 07/08/17 16:38, Jan Beulich wrote:
>>> So a single NIC drove the system out of vectors? That's insane, I would
>>> say, i.e. I'd call this a misconfigured system. But yeah, if we really want
>>> to get such a thing to work despite the insanity ...
>> No.  That's one single (dual headed) card with 128 virtual functions each.
> But putting such in a single-core system is, well, not very reasonable. At
> the very least I'd expect the admin to limit the number of VFs then, or not
> load a driver in Dom0 for them (but only for the PF).

Its not a single core system, but cluster mode allocates vectors across
clusters, not cores. This turns even the largest server system into a
single core system as far as vector availability goes.

There was definitely a change in behaviour between Xen 4.1 and Xen 4.4. 
Looking through the ticket, it appears the regression was introduced by
your cluster IPI broadcast optimisation (which iirc was for the 64 vcpu
windows issue), but I'm struggling to locate it in Xens history.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Jan Beulich]

>>> Andrew Cooper  08/07/17 5:40 PM >>>
>On 07/08/17 16:38, Jan Beulich wrote:
>> So a single NIC drove the system out of vectors? That's insane, I would
>> say, i.e. I'd call this a misconfigured system. But yeah, if we really want
>> to get such a thing to work despite the insanity ...
>
>No.  That's one single (dual headed) card with 128 virtual functions each.

But putting such in a single-core system is, well, not very reasonable. At
the very least I'd expect the admin to limit the number of VFs then, or not
load a driver in Dom0 for them (but only for the PF).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 112499: tolerable trouble: blocked/broken/pass - PUSHED

[osstest service owner]

flight 112499 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112499/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112459
 build-arm64-pvops 2 hosts-allocate  broken like 112459
 build-arm64   2 hosts-allocate  broken like 112459
 build-arm64   3 capture-logsbroken like 112459
 build-arm64-xsm   3 capture-logsbroken like 112459
 build-arm64-pvops 3 capture-logsbroken like 112459
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112459
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112459
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112459
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  404d3632b974dfec4fb60471be7d8c2ab52c983a
baseline version:
 libvirt  d8e8b63d3063a832d8cbcd25a22fb8154ab6220f

Last test of basis   112459  2017-08-05 04:30:56 Z2 days
Testing same since   112499  2017-08-07 04:20:15 Z0 days1 attempts


People who touched revisions under test:
  Alexander Nusov 
  Roman Bogorodskiy 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at

Re: [Xen-devel] Is:livepatch-build-tools.git declare it supported? Was:Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature

[Jan Beulich]

>>> George Dunlap  08/07/17 12:27 PM >>>
>So it seems that people are still not quite clear about what I'm proposing.

And indeed your examples helped me understand better what you mean
(or at least I hope they did).

>Suppose someone builds a livepatch with the correct compiler, with a
>correct patch (that would fix the bug if rebooted into a new
>hypervisor), with correct fix-up code.  Suppose that the bug passes all
>reasonable testing; but that, *due to a bug in the tools*, the patch
>also gives PV guests access to hypervisor memory.  Is this a security
>issue?  Yes -- the human told it to do safe thing X ("build a livepatch
>based on correct inputs to fix this bug") and it did unsafe thing Y
>("build a livepatch that opens up a new security hole").

There's one more factor here: The livepatch tools may behave properly
with one version of the compiler, and improperly with another. Or they
may behave properly with the Oracle patched hypervisor sources, but
improperly with the Citrix ones (assuming every distro carries a different
set of patches on top of an upstream stable release or branch).

>We could even place more restrictions on the scope if we wanted to.  We
>could say that we only support the livepatch tools generating patches
>for XSAs.

For me, much depends on how tight such restrictions would be. I.e.
with the examples given above, how would we determine a canonical
livepatch-tools / hypervisor pair (or set of pairs)? After all tools
mis-behavior may be a result of some custom patch in someone's
derived tree.

>> This is very similar to what XSA-155 was - the GCC compiler optimizations
>> added a nice jump table that was accessed twice. And the offset was
>> retrieved from the shared ring.
>>
>> But we didn't do an XSA-155 for the GCC compiler. That is we didn't
>> file a ticket with GCC saying 'Hey, your compiler can create an race
>> on shared memory. Could you make your compiler be smarter in these cases'
>> We instead wrote code with this optimization in mind with more
>> barriers.
>
>Right -- so the gcc compiler guys are using a specification that allows
>that behavior.  So from their perspective, we told the compiler to do
>unsafe thing Y (or at least, said that we were OK with it doing unsafe
>thing Y), and it did unsafe thing Y -- a security issue for Xen, but not
>for gcc.  If gcc had *violated* the spec when causing the security
>issue, then we certainly would have called that a security issue in gcc.

But would we have issued an XSA? Wouldn't that rather be a CVE
against gcc then?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Andrew Cooper]

On 07/08/17 16:38, Jan Beulich wrote:
 Boris Ostrovsky  08/07/17 5:12 PM >>>
>> On 08/07/2017 10:52 AM, Jan Beulich wrote:
>> Andrew Cooper  08/07/17 4:39 PM >>>
 On 07/08/17 09:18, Jan Beulich wrote:
> Wouldn't it be sufficient for people running into vector shortage due to
> sharing to specify "x2apic_phys" on the command line?
 Had XenServer noticed this change in default earlier, I would have
 insisted that you make x2apic_phys the default.
>>> Change in default? About five and a half years ago I did implement cluster
>>> mode properly, but I wasn't able to spot a commit that changed the
>>> default from physical to cluster.
>>>
 On affected systems, problem manifests as an upgrade where the new
 hypervisor doesn't boot.  Recovering from this requires human
 intervention during the server boot.
>>> This needs some more explanation: Why would the hypervisor not boot?
>>> Even if you said Dom0 didn't boot, it wouldn't really be clear to me why,
>>> as running out of vectors would likely occur only after critical devices
>>> had their drivers loaded.
>>
>> If your critical device is a networking card with lots of functions? In
>> my case I had two cards. The first one was plumbed properly but the
>> second failed. It so happened that only the first one was required to
>> boot but I can see that in another configuration an init script might
>> require both to be initialized.
> So a single NIC drove the system out of vectors? That's insane, I would
> say, i.e. I'd call this a misconfigured system. But yeah, if we really want
> to get such a thing to work despite the insanity ...

No.  That's one single (dual headed) card with 128 virtual functions each.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Jan Beulich]

>>> Boris Ostrovsky  08/07/17 5:12 PM >>>
>On 08/07/2017 10:52 AM, Jan Beulich wrote:
> Andrew Cooper  08/07/17 4:39 PM >>>
>>> On 07/08/17 09:18, Jan Beulich wrote:
 Wouldn't it be sufficient for people running into vector shortage due to
 sharing to specify "x2apic_phys" on the command line?
>>> Had XenServer noticed this change in default earlier, I would have
>>> insisted that you make x2apic_phys the default.
>> Change in default? About five and a half years ago I did implement cluster
>> mode properly, but I wasn't able to spot a commit that changed the
>> default from physical to cluster.
>>
>>> On affected systems, problem manifests as an upgrade where the new
>>> hypervisor doesn't boot.  Recovering from this requires human
>>> intervention during the server boot.
>> This needs some more explanation: Why would the hypervisor not boot?
>> Even if you said Dom0 didn't boot, it wouldn't really be clear to me why,
>> as running out of vectors would likely occur only after critical devices
>> had their drivers loaded.
>
>
>If your critical device is a networking card with lots of functions? In
>my case I had two cards. The first one was plumbed properly but the
>second failed. It so happened that only the first one was required to
>boot but I can see that in another configuration an init script might
>require both to be initialized.

So a single NIC drove the system out of vectors? That's insane, I would
say, i.e. I'd call this a misconfigured system. But yeah, if we really want
to get such a thing to work despite the insanity ...

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Jan Beulich]

>>> Boris Ostrovsky  08/07/17 5:06 PM >>>
> --- a/xen/include/asm-x86/mach-generic/mach_apic.h
> +++ b/xen/include/asm-x86/mach-generic/mach_apic.h
> @@ -13,10 +13,11 @@
> #define INT_DELIVERY_MODE (genapic->int_delivery_mode)
> #define INT_DEST_MODE (genapic->int_dest_mode)
> #define TARGET_CPUS  (genapic->target_cpus())
> -#define init_apic_ldr (genapic->init_apic_ldr)
> -#define clustered_apic_check (genapic->clustered_apic_check) 
> -#define cpu_mask_to_apicid (genapic->cpu_mask_to_apicid)
> -#define vector_allocation_cpumask(cpu) 
> (genapic->vector_allocation_cpumask(cpu))
> +#define INIT_APIC_LDR (genapic->init_apic_ldr)
> +#define CLUSTERED_APIC_CHECK (genapic->clustered_apic_check) 
> +#define CPU_MASK_TO_APICID (genapic->cpu_mask_to_apicid)
> +#define VECTOR_ALLOCATION_CPUMASK(cpu, mask) \
> +(genapic->vector_allocation_cpumask(cpu, mask))
  
 I don't see the connection of the change in case of all of these to the 
 purpose
 of this patch.
>>> I need to include asm-x86/mach-generic/mach_apic.h in x2apic.c and
>> That's solely because of the use of TARGET_CPUS, isn't it? With the above
>> comment in mind, this could equally well be _online_map I think, making
>> explicit what is implicit right now.
>
>Yes, but it it won't prevent a caller from explicitly passing
>_online_map neither.

Right, but hence the suggestion to explicitly compare with _online_map.

>How about allowing assign_irq_vector() pass NULL mask to
>__assign_irq_vector() (I think this is the only place where it matters)?
>__assign_irq_vector() can then turn it into TARGET_CPUS and pass NULL to
>vector_allocation_cpumask().

That ought to be workable afaics.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Jan Beulich]

>>> Boris Ostrovsky  08/07/17 4:56 PM >>>
>On 08/07/2017 10:37 AM, Jan Beulich wrote:
>> Boris Ostrovsky  08/07/17 4:16 PM >>>
>>> On 08/06/2017 01:41 PM, Jan Beulich wrote:
>>> Boris Ostrovsky  08/04/17 7:03 PM >>>
> +/* See if any of the pages indeed need scrubbing. */
> +if ( first_dirty != INVALID_DIRTY_IDX )
> +{
> +if ( (1U << cur_order) > first_dirty )
> +{
> +for ( i = first_dirty ; i < (1U << cur_order); 
> i++ )
> +if ( test_bit(_PGC_need_scrub,
> +  _head[i].count_info) )
> +{
> +idx = i;
> +break;
> +}
 Why again do you need to look through all the pages here, rather than
 simply marking the chunks as needing scrubbing simply based on first_dirty?
 It seems to me that I've asked this before, which is a good indication that
 such special behavior would better have a comment attached.
>>> We want to make sure that there are in fact dirty pages in the
>>> (sub-)buddy: first_dirty is only a hint there *may be* some.
>> But why is that needed? Iirc you don't go to such length when splitting a
>> buddy during allocation.
>
>I felt that allocation is more time-critical and so I decided against
>trying to be "neat" as far as tracking dirty pages exactly.

I'd suggest to use the simpler approach here too, if the more involved one isn't
needed for correctness.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Julien Grall]

Hi,

On 07/08/17 15:46, Boris Ostrovsky wrote:

On 08/07/2017 06:45 AM, Julien Grall wrote:

Hi Boris,

I would have appreciated to be CCed as maintainer of the ARM bits...
Please use scripts/get_maintainers.pl in the future.


Ugh, sorry about that. (I did test builds for both ARM64 and ARM32, if
this make my transgression any less serious ;-))



On 04/08/17 18:05, Boris Ostrovsky wrote:

. so that it's easy to find pages that need to be scrubbed (those
pages are


Pointless .


diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index ef84b72..d26b232 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -44,7 +44,16 @@ struct page_info
 /* Page is on a free list: ((count_info & PGC_count_mask) ==
0). */
 struct {
 /* Do TLBs need flushing for safety before next page
use? */
-bool_t need_tlbflush;
+unsigned long need_tlbflush:1;


You've turned need_tlbflush from bool to unsigned long : 1. But some
of the users use true/false or may rely on the boolean property.  So
it sounds like to me you want to use bool bitfields here (and in the
x86 part).


This is what we have (with this series applied):

root@ovs104> git grep need_tlbflush .
common/memory.c:bool need_tlbflush = false;
common/memory.c:
accumulate_tlbflush(_tlbflush, [j],
common/memory.c:if ( need_tlbflush )
common/page_alloc.c:bool need_tlbflush = false;
common/page_alloc.c:accumulate_tlbflush(_tlbflush, [i],
common/page_alloc.c:if ( need_tlbflush )
* common/page_alloc.c:pg[i].u.free.need_tlbflush =
(page_get_owner([i]) != NULL);
common/page_alloc.c:if ( pg[i].u.free.need_tlbflush )
include/asm-arm/mm.h:unsigned long need_tlbflush:1;
include/asm-x86/mm.h:   unsigned long need_tlbflush:1;
include/xen/mm.h:static inline void accumulate_tlbflush(bool *need_tlbflush,
include/xen/mm.h:if ( page->u.free.need_tlbflush &&
include/xen/mm.h: (!*need_tlbflush ||
include/xen/mm.h:*need_tlbflush = true;
root@ovs104>

The only possibly boolean-style use is '*' and event that I think is
allowed.

Stand-alone need_tlbflush variables above have nothing to do with this
change.


If you look at it, all of them use bool semantic. Now you mix bool and 
int. We are trying to remove that in the new code, so please don't 
introduce new one.








+
+/*
+ * Index of the first *possibly* unscrubbed page in the
buddy.
+ * One more than maximum possible order to accommodate
+ * INVALID_DIRTY_IDX.
+ */
+#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
+unsigned long first_dirty:MAX_ORDER + 1;


We need to make sure that this union will not be bigger than unsigned
long. Otherwise this will limit lower down the maximum amount of
memory we support.
So this likely means a BUILD_BUG_ON().



Are you concerned that (MAX_ORDER+1) will be larger than sizeof(unsigned
long)? If yes, the compiler should complain anyway, shouldn't it?


I am more concerned about the sizeof of the union u to be larger than 
unsigned long.


first_dirty should not be greater than 63 bits (or 31 bits for 32-bits 
architecture). Otherwise likely the compiler will add a padding between 
need_tlbflush and first_dirty. This would increase the page_info by 4/8 
byte.


The BUILD_BUG_ON(...) would be here to catch such error.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Oleksandr Andrushchenko]

On 08/07/2017 04:55 PM, Clemens Ladisch wrote:

Oleksandr Andrushchenko wrote:

On 08/07/2017 04:11 PM, Clemens Ladisch wrote:

How does that interface work?

For the buffer received in .copy_user/.copy_kernel we send
a request to the backend and get response back (async) when it has copied
the bytes into HW/mixer/etc, so the buffer at frontend side can be reused.

So if the frontend sends too many (too large) requests, does the
backend wait until there is enough free space in the buffer before
it does the actual copying and then acks?

Well, the frontend should be backend agnostic,
In our implementation backend is a user-space application which sits
either on top of ALSA driver or PulseAudio: so, it acks correspondingly,
e.g, when, for example, ALSA driver completes .copy_user and returns
from the kernel

If yes, then these acks can be used as interrupts.

we can probably teach our backend to track periods elapsed for ALSA,
but not sure if it is possible for PulseAudio - do you know if this is also
doable for pulse?

Let's assume backend blocks until the buffer played/consumed...

   (You still
have to count frames, and call snd_pcm_period_elapsed() exactly
when a period boundary was reached or crossed.)

... and what if the buffer has multiple periods? So, that the backend sends
a single response for multiple periods (buffers with fractional period 
number

can be handled separately)?
We will have to either send snd_pcm_period_elapsed once (wrong, because
multiple periods consumed) or multiple times at one time with no delay 
(wrong,
because there will be a confusion that multiple periods were not 
reported for quite

some long time and then there is a burst of events)
Either way the behavior will not be the one desired (please correct me
if I am wrong here)


Splitting a large read/write into smaller requests to the backend
would improve the granularity of the known stream position.

The overall latency would be the sum of the sizes of the frontend
and backend buffers.


Why is the protocol designed this way?

We also work on para-virtualizing display device and there we tried to use
page flip events from backend to frontend to signal similar to
period interrupt for audio. When multiple displays (read multiple audio 
streams)
were in place we flooded with the system interrupts (which are period 
events in our case)

and performance dropped significantly. This is why we switched to
interrupt emulation, here via timer for audio. The main measures were:
1. Number of events between front and back
2. Latency
With timer approach we reduce 1) to the minimum which is a must (no period
interrupts), but 2) is still here
With emulated period interrupts (protocol events) we have issue with 1)
and still 2) remains.

So, to me, neither approach solves the problem for 100%, so we decided
to stick to timers. Hope, this gives more background on why we did things
the way we did.

  Wasn't the goal to expose
some 'real' sound card?


yes, but it can be implemented in different ways, please see above

Regards,
Clemens

Thank you for your interest,
Oleksandr

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Boris Ostrovsky]

On 08/07/2017 10:52 AM, Jan Beulich wrote:
 Andrew Cooper  08/07/17 4:39 PM >>>
>> On 07/08/17 09:18, Jan Beulich wrote:
>>> Wouldn't it be sufficient for people running into vector shortage due to
>>> sharing to specify "x2apic_phys" on the command line?
>> Had XenServer noticed this change in default earlier, I would have
>> insisted that you make x2apic_phys the default.
> Change in default? About five and a half years ago I did implement cluster
> mode properly, but I wasn't able to spot a commit that changed the
> default from physical to cluster.
>
>> On affected systems, problem manifests as an upgrade where the new
>> hypervisor doesn't boot.  Recovering from this requires human
>> intervention during the server boot.
> This needs some more explanation: Why would the hypervisor not boot?
> Even if you said Dom0 didn't boot, it wouldn't really be clear to me why,
> as running out of vectors would likely occur only after critical devices
> had their drivers loaded.


If your critical device is a networking card with lots of functions? In
my case I had two cards. The first one was plumbed properly but the
second failed. It so happened that only the first one was required to
boot but I can see that in another configuration an init script might
require both to be initialized.


-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Boris Ostrovsky]

 @@ -72,9 +73,13 @@ static void __init clustered_apic_check_x2apic(void)
 {
 }
>>>  >
 -static const cpumask_t *vector_allocation_cpumask_x2apic_cluster(int cpu)
 +static const cpumask_t *vector_allocation_cpumask_x2apic_cluster(int cpu,
 +const cpumask_t *cpumask)
 {
 -return per_cpu(cluster_cpus, cpu);
 +if ( cpumask != TARGET_CPUS )
>>> Is a pointer comparison (rather than a content one) here really correct in
>>> the general case?
>> When the caller is using TARGET_CPUS this is an indication that it
>> explicitly didn't care about sharing (in assign_irq_vector()). A caller
>> might want to have sharing on and provide a mask that has the same
>> content as TARGET_CPUS but is stored in a different location. This will
>> allow vector_allocation_cpumask_x2apic_cluster() to distinguish it from
>> a "don't care" case.
> Yes, I can see that intention. But you still wouldn't e.g. distinguish a 
> caller
> using TARGET_CPUS() from one passing _online_map.

True.

>
 --- a/xen/include/asm-x86/mach-generic/mach_apic.h
 +++ b/xen/include/asm-x86/mach-generic/mach_apic.h
 @@ -13,10 +13,11 @@
 #define INT_DELIVERY_MODE (genapic->int_delivery_mode)
 #define INT_DEST_MODE (genapic->int_dest_mode)
 #define TARGET_CPUS  (genapic->target_cpus())
 -#define init_apic_ldr (genapic->init_apic_ldr)
 -#define clustered_apic_check (genapic->clustered_apic_check) 
 -#define cpu_mask_to_apicid (genapic->cpu_mask_to_apicid)
 -#define vector_allocation_cpumask(cpu) 
 (genapic->vector_allocation_cpumask(cpu))
 +#define INIT_APIC_LDR (genapic->init_apic_ldr)
 +#define CLUSTERED_APIC_CHECK (genapic->clustered_apic_check) 
 +#define CPU_MASK_TO_APICID (genapic->cpu_mask_to_apicid)
 +#define VECTOR_ALLOCATION_CPUMASK(cpu, mask) \
 +(genapic->vector_allocation_cpumask(cpu, mask))
>>>  
>>> I don't see the connection of the change in case of all of these to the 
>>> purpose
>>> of this patch.
>> I need to include asm-x86/mach-generic/mach_apic.h in x2apic.c and
> That's solely because of the use of TARGET_CPUS, isn't it? With the above
> comment in mind, this could equally well be _online_map I think, making
> explicit what is implicit right now.

Yes, but it it won't prevent a caller from explicitly passing
_online_map neither.

How about allowing assign_irq_vector() pass NULL mask to
__assign_irq_vector() (I think this is the only place where it matters)?
__assign_irq_vector() can then turn it into TARGET_CPUS and pass NULL to
vector_allocation_cpumask().

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

On 08/07/2017 10:37 AM, Jan Beulich wrote:
> Boris Ostrovsky  08/07/17 4:16 PM >>>
>> On 08/06/2017 01:41 PM, Jan Beulich wrote:
>> Boris Ostrovsky  08/04/17 7:03 PM >>>
 +/* See if any of the pages indeed need scrubbing. */
 +if ( first_dirty != INVALID_DIRTY_IDX )
 +{
 +if ( (1U << cur_order) > first_dirty )
 +{
 +for ( i = first_dirty ; i < (1U << cur_order); 
 i++ )
 +if ( test_bit(_PGC_need_scrub,
 +  _head[i].count_info) )
 +{
 +idx = i;
 +break;
 +}
>>> Why again do you need to look through all the pages here, rather than
>>> simply marking the chunks as needing scrubbing simply based on first_dirty?
>>> It seems to me that I've asked this before, which is a good indication that
>>> such special behavior would better have a comment attached.
>> We want to make sure that there are in fact dirty pages in the
>> (sub-)buddy: first_dirty is only a hint there *may be* some.
> But why is that needed? Iirc you don't go to such length when splitting a
> buddy during allocation.

I felt that allocation is more time-critical and so I decided against
trying to be "neat" as far as tracking dirty pages exactly.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Jan Beulich]

>>> Andrew Cooper  08/07/17 4:39 PM >>>
>On 07/08/17 09:18, Jan Beulich wrote:
>> Wouldn't it be sufficient for people running into vector shortage due to
>> sharing to specify "x2apic_phys" on the command line?
>
>Had XenServer noticed this change in default earlier, I would have
>insisted that you make x2apic_phys the default.

Change in default? About five and a half years ago I did implement cluster
mode properly, but I wasn't able to spot a commit that changed the
default from physical to cluster.

>On affected systems, problem manifests as an upgrade where the new
>hypervisor doesn't boot.  Recovering from this requires human
>intervention during the server boot.

This needs some more explanation: Why would the hypervisor not boot?
Even if you said Dom0 didn't boot, it wouldn't really be clear to me why,
as running out of vectors would likely occur only after critical devices
had their drivers loaded.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

On 08/07/2017 06:45 AM, Julien Grall wrote:
> Hi Boris,
>
> I would have appreciated to be CCed as maintainer of the ARM bits...
> Please use scripts/get_maintainers.pl in the future.

Ugh, sorry about that. (I did test builds for both ARM64 and ARM32, if
this make my transgression any less serious ;-))

>
> On 04/08/17 18:05, Boris Ostrovsky wrote:
>> . so that it's easy to find pages that need to be scrubbed (those
>> pages are
>
> Pointless .
>
>> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
>> index ef84b72..d26b232 100644
>> --- a/xen/include/asm-arm/mm.h
>> +++ b/xen/include/asm-arm/mm.h
>> @@ -44,7 +44,16 @@ struct page_info
>>  /* Page is on a free list: ((count_info & PGC_count_mask) ==
>> 0). */
>>  struct {
>>  /* Do TLBs need flushing for safety before next page
>> use? */
>> -bool_t need_tlbflush;
>> +unsigned long need_tlbflush:1;
>
> You've turned need_tlbflush from bool to unsigned long : 1. But some
> of the users use true/false or may rely on the boolean property.  So
> it sounds like to me you want to use bool bitfields here (and in the
> x86 part).

This is what we have (with this series applied):

root@ovs104> git grep need_tlbflush .
common/memory.c:bool need_tlbflush = false;
common/memory.c:   
accumulate_tlbflush(_tlbflush, [j],
common/memory.c:if ( need_tlbflush )
common/page_alloc.c:bool need_tlbflush = false;
common/page_alloc.c:accumulate_tlbflush(_tlbflush, [i],
common/page_alloc.c:if ( need_tlbflush )
* common/page_alloc.c:pg[i].u.free.need_tlbflush =
(page_get_owner([i]) != NULL);
common/page_alloc.c:if ( pg[i].u.free.need_tlbflush )
include/asm-arm/mm.h:unsigned long need_tlbflush:1;
include/asm-x86/mm.h:   unsigned long need_tlbflush:1;
include/xen/mm.h:static inline void accumulate_tlbflush(bool *need_tlbflush,
include/xen/mm.h:if ( page->u.free.need_tlbflush &&
include/xen/mm.h: (!*need_tlbflush ||
include/xen/mm.h:*need_tlbflush = true;
root@ovs104>

The only possibly boolean-style use is '*' and event that I think is
allowed.

Stand-alone need_tlbflush variables above have nothing to do with this
change.


>
>> +
>> +/*
>> + * Index of the first *possibly* unscrubbed page in the
>> buddy.
>> + * One more than maximum possible order to accommodate
>> + * INVALID_DIRTY_IDX.
>> + */
>> +#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
>> +unsigned long first_dirty:MAX_ORDER + 1;
>
> We need to make sure that this union will not be bigger than unsigned
> long. Otherwise this will limit lower down the maximum amount of
> memory we support.
> So this likely means a BUILD_BUG_ON().


Are you concerned that (MAX_ORDER+1) will be larger than sizeof(unsigned
long)? If yes, the compiler should complain anyway, shouldn't it?


-boris



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Jan Beulich]

>>> Boris Ostrovsky  08/07/17 4:32 PM >>>
>On 08/07/2017 04:18 AM, Jan Beulich wrote:
> Boris Ostrovsky  07/31/17 10:03 PM >>>
>>> We have limited number (slightly under NR_DYNAMIC_VECTORS=192) of IRQ
>>> vectors that are available to each processor. Currently, when x2apic
>>> cluster mode is used (which is default), each vector is shared among
>>> all processors in the cluster. With many IRQs (as is the case on systems
>>> with multiple SR-IOV cards) and few clusters (e.g. single socket)
>>> there is a good chance that we will run out of vectors.
>>>
>>> This patch tries to decrease vector sharing between processors by
>>> assigning vector to a single processor if the assignment request (via
>>> __assign_irq_vector()) comes without explicitly specifying which
>>> processors are expected to share the interrupt. This typically happens
>>> during boot time (or possibly PCI hotplug) when create_irq(NUMA_NO_NODE)
>>> is called. When __assign_irq_vector() is called from
>>> set_desc_affinity() which provides sharing mask, vector sharing will
>>> continue to be performed, as before.
>> Wouldn't it be sufficient for people running into vector shortage due to
>> sharing to specify "x2apic_phys" on the command line?
>
>Yes, it would.
>
>The downside is that an installer (e.g. anaconda) would then have to
>figure out which systems need to be installed with this specific option.
>Even worse, this problem would show up on systems that have some of the
>processors taken offline (in BIOS) so during initial installation there
>would be no reason to switch to physical. Or a card might be added after
>the installation.
>
>In other words, I think x2apic_phys is more of a workaround in this case.

I'm not convinced; I'll wait to see if others have opinions one way or the 
other.

>>> @@ -72,9 +73,13 @@ static void __init clustered_apic_check_x2apic(void)
>>> {
>>> }
>>  >
>>> -static const cpumask_t *vector_allocation_cpumask_x2apic_cluster(int cpu)
>>> +static const cpumask_t *vector_allocation_cpumask_x2apic_cluster(int cpu,
>>> +const cpumask_t *cpumask)
>>> {
>>> -return per_cpu(cluster_cpus, cpu);
>>> +if ( cpumask != TARGET_CPUS )
>> Is a pointer comparison (rather than a content one) here really correct in
>> the general case?
>
>When the caller is using TARGET_CPUS this is an indication that it
>explicitly didn't care about sharing (in assign_irq_vector()). A caller
>might want to have sharing on and provide a mask that has the same
>content as TARGET_CPUS but is stored in a different location. This will
>allow vector_allocation_cpumask_x2apic_cluster() to distinguish it from
>a "don't care" case.

Yes, I can see that intention. But you still wouldn't e.g. distinguish a caller
using TARGET_CPUS() from one passing _online_map.

>>> --- a/xen/include/asm-x86/mach-generic/mach_apic.h
>>> +++ b/xen/include/asm-x86/mach-generic/mach_apic.h
>>> @@ -13,10 +13,11 @@
>>> #define INT_DELIVERY_MODE (genapic->int_delivery_mode)
>>> #define INT_DEST_MODE (genapic->int_dest_mode)
>>> #define TARGET_CPUS  (genapic->target_cpus())
>>> -#define init_apic_ldr (genapic->init_apic_ldr)
>>> -#define clustered_apic_check (genapic->clustered_apic_check) 
>>> -#define cpu_mask_to_apicid (genapic->cpu_mask_to_apicid)
>>> -#define vector_allocation_cpumask(cpu) 
>>> (genapic->vector_allocation_cpumask(cpu))
>>> +#define INIT_APIC_LDR (genapic->init_apic_ldr)
>>> +#define CLUSTERED_APIC_CHECK (genapic->clustered_apic_check) 
>>> +#define CPU_MASK_TO_APICID (genapic->cpu_mask_to_apicid)
>>> +#define VECTOR_ALLOCATION_CPUMASK(cpu, mask) \
>>> +(genapic->vector_allocation_cpumask(cpu, mask))
>>  
>> I don't see the connection of the change in case of all of these to the 
>> purpose
>> of this patch.
>
>I need to include asm-x86/mach-generic/mach_apic.h in x2apic.c and

That's solely because of the use of TARGET_CPUS, isn't it? With the above
comment in mind, this could equally well be _online_map I think, making
explicit what is implicit right now.

>keeping those 4 as lower-case would mess up static initializers of
>apic_x2apic_phys and apic_x2apic_cluster. Besides, switching them to
>upper case would make them consistent with (what I think are) similar
>definitions of the 3 top macros above.

If you really want to go that route, do the renaming in a precursor patch
please.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Andrew Cooper]

On 07/08/17 09:18, Jan Beulich wrote:
 Boris Ostrovsky  07/31/17 10:03 PM >>>
>> We have limited number (slightly under NR_DYNAMIC_VECTORS=192) of IRQ
>> vectors that are available to each processor. Currently, when x2apic
>> cluster mode is used (which is default), each vector is shared among
>> all processors in the cluster. With many IRQs (as is the case on systems
>> with multiple SR-IOV cards) and few clusters (e.g. single socket)
>> there is a good chance that we will run out of vectors.
>>
>> This patch tries to decrease vector sharing between processors by
>> assigning vector to a single processor if the assignment request (via
>> __assign_irq_vector()) comes without explicitly specifying which
>> processors are expected to share the interrupt. This typically happens
>> during boot time (or possibly PCI hotplug) when create_irq(NUMA_NO_NODE)
>> is called. When __assign_irq_vector() is called from
>> set_desc_affinity() which provides sharing mask, vector sharing will
>> continue to be performed, as before.
> Wouldn't it be sufficient for people running into vector shortage due to
> sharing to specify "x2apic_phys" on the command line?

Had XenServer noticed this change in default earlier, I would have
insisted that you make x2apic_phys the default.

On affected systems, problem manifests as an upgrade where the new
hypervisor doesn't boot.  Recovering from this requires human
intervention during the server boot.

As it was, the change went unnoticed for several releases upstream, so
I'm not sure if changing the default at this point is a sensible course
of action.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Jan Beulich]

 Boris Ostrovsky  08/07/17 4:16 PM >>>
>On 08/06/2017 01:41 PM, Jan Beulich wrote:
> Boris Ostrovsky  08/04/17 7:03 PM >>>
>>> +/* See if any of the pages indeed need scrubbing. */
>>> +if ( first_dirty != INVALID_DIRTY_IDX )
>>> +{
>>> +if ( (1U << cur_order) > first_dirty )
>>> +{
>>> +for ( i = first_dirty ; i < (1U << cur_order); i++ 
>>> )
>>> +if ( test_bit(_PGC_need_scrub,
>>> +  _head[i].count_info) )
>>> +{
>>> +idx = i;
>>> +break;
>>> +}
>> Why again do you need to look through all the pages here, rather than
>> simply marking the chunks as needing scrubbing simply based on first_dirty?
>> It seems to me that I've asked this before, which is a good indication that
>> such special behavior would better have a comment attached.
>
>We want to make sure that there are in fact dirty pages in the
>(sub-)buddy: first_dirty is only a hint there *may be* some.

But why is that needed? Iirc you don't go to such length when splitting a
buddy during allocation.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

[Boris Ostrovsky]

On 08/07/2017 04:18 AM, Jan Beulich wrote:
 Boris Ostrovsky  07/31/17 10:03 PM >>>
>> We have limited number (slightly under NR_DYNAMIC_VECTORS=192) of IRQ
>> vectors that are available to each processor. Currently, when x2apic
>> cluster mode is used (which is default), each vector is shared among
>> all processors in the cluster. With many IRQs (as is the case on systems
>> with multiple SR-IOV cards) and few clusters (e.g. single socket)
>> there is a good chance that we will run out of vectors.
>>
>> This patch tries to decrease vector sharing between processors by
>> assigning vector to a single processor if the assignment request (via
>> __assign_irq_vector()) comes without explicitly specifying which
>> processors are expected to share the interrupt. This typically happens
>> during boot time (or possibly PCI hotplug) when create_irq(NUMA_NO_NODE)
>> is called. When __assign_irq_vector() is called from
>> set_desc_affinity() which provides sharing mask, vector sharing will
>> continue to be performed, as before.
> Wouldn't it be sufficient for people running into vector shortage due to
> sharing to specify "x2apic_phys" on the command line?

Yes, it would.

The downside is that an installer (e.g. anaconda) would then have to
figure out which systems need to be installed with this specific option.
Even worse, this problem would show up on systems that have some of the
processors taken offline (in BIOS) so during initial installation there
would be no reason to switch to physical. Or a card might be added after
the installation.

In other words, I think x2apic_phys is more of a workaround in this case.

>
>> @@ -72,9 +73,13 @@ static void __init clustered_apic_check_x2apic(void)
>> {
>> }
>  >
>> -static const cpumask_t *vector_allocation_cpumask_x2apic_cluster(int cpu)
>> +static const cpumask_t *vector_allocation_cpumask_x2apic_cluster(int cpu,
>> +const cpumask_t *cpumask)
>> {
>> -return per_cpu(cluster_cpus, cpu);
>> +if ( cpumask != TARGET_CPUS )
> Is a pointer comparison (rather than a content one) here really correct in
> the general case?

When the caller is using TARGET_CPUS this is an indication that it
explicitly didn't care about sharing (in assign_irq_vector()). A caller
might want to have sharing on and provide a mask that has the same
content as TARGET_CPUS but is stored in a different location. This will
allow vector_allocation_cpumask_x2apic_cluster() to distinguish it from
a "don't care" case.

>
>> +return per_cpu(cluster_cpus, cpu);
>> +else
>> +return cpumask_of(cpu);
> Please avoid the "else" in cases like this.
>
>> --- a/xen/include/asm-x86/mach-generic/mach_apic.h
>> +++ b/xen/include/asm-x86/mach-generic/mach_apic.h
>> @@ -13,10 +13,11 @@
>> #define INT_DELIVERY_MODE (genapic->int_delivery_mode)
>> #define INT_DEST_MODE (genapic->int_dest_mode)
>> #define TARGET_CPUS  (genapic->target_cpus())
>> -#define init_apic_ldr (genapic->init_apic_ldr)
>> -#define clustered_apic_check (genapic->clustered_apic_check) 
>> -#define cpu_mask_to_apicid (genapic->cpu_mask_to_apicid)
>> -#define vector_allocation_cpumask(cpu) 
>> (genapic->vector_allocation_cpumask(cpu))
>> +#define INIT_APIC_LDR (genapic->init_apic_ldr)
>> +#define CLUSTERED_APIC_CHECK (genapic->clustered_apic_check) 
>> +#define CPU_MASK_TO_APICID (genapic->cpu_mask_to_apicid)
>> +#define VECTOR_ALLOCATION_CPUMASK(cpu, mask) \
>> +(genapic->vector_allocation_cpumask(cpu, mask))
>  
> I don't see the connection of the change in case of all of these to the 
> purpose
> of this patch.

I need to include asm-x86/mach-generic/mach_apic.h in x2apic.c and
keeping those 4 as lower-case would mess up static initializers of
apic_x2apic_phys and apic_x2apic_cluster. Besides, switching them to
upper case would make them consistent with (what I think are) similar
definitions of the 3 top macros above.


-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 112510: tolerable trouble: broken/pass - PUSHED

[osstest service owner]

flight 112510 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112510/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  dd050808ccc23f0a11d5596409f4245b9406a242
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z6 days
Failing since112418  2017-08-03 11:04:58 Z4 days   42 attempts
Testing same since   112510  2017-08-07 12:08:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Xiao Liang 
  xiliang 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=dd050808ccc23f0a11d5596409f4245b9406a242
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
dd050808ccc23f0a11d5596409f4245b9406a242
+ branch=xen-unstable-smoke
+ revision=dd050808ccc23f0a11d5596409f4245b9406a242
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = 

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

On 08/06/2017 01:41 PM, Jan Beulich wrote:
 Boris Ostrovsky  08/04/17 7:03 PM >>>
>> @@ -873,6 +916,8 @@ static int reserve_offlined_page(struct page_info *head)
>  >
>> while ( cur_order < head_order )
>> {
>> +unsigned int idx = INVALID_DIRTY_IDX;
> Is it correct for the variable to live in this scope, rather than ...
>
>> @@ -892,8 +937,28 @@ static int reserve_offlined_page(struct page_info *head)
>> {
>> merge:
> ... in this one? Of course it's less the variable scope itself, but the 
> initial
> value at the point here.

I should move it to the inner scope --- I actually *want* to
reinitialize it on each iteration.

>
>> /* We don't consider merging outside the head_order. */
>> -page_list_add_tail(cur_head, (node, zone, cur_order));
>> -PFN_ORDER(cur_head) = cur_order;
>> +
>> +/* See if any of the pages indeed need scrubbing. */
>> +if ( first_dirty != INVALID_DIRTY_IDX )
>> +{
>> +if ( (1U << cur_order) > first_dirty )
>> +{
>> +for ( i = first_dirty ; i < (1U << cur_order); i++ )
>> +if ( test_bit(_PGC_need_scrub,
>> +  _head[i].count_info) )
>> +{
>> +idx = i;
>> +break;
>> +}
> Why again do you need to look through all the pages here, rather than
> simply marking the chunks as needing scrubbing simply based on first_dirty?
> It seems to me that I've asked this before, which is a good indication that
> such special behavior would better have a comment attached.

We want to make sure that there are in fact dirty pages in the
(sub-)buddy: first_dirty is only a hint there *may be* some. That's why
I have the word "indeed" in the comment there but it's probably worth
expanding on that.

>
>> @@ -977,35 +1096,49 @@ static void free_heap_pages(
>  >
>> if ( (page_to_mfn(pg) & mask) )
>> {
>> +struct page_info *predecessor = pg - mask;
> For this and ...
>
>> }
>> else
>> {
>> +struct page_info *successor = pg + mask;
> ... this, it would certainly help readability of the patch here if the 
> introduction
> of the new local variables was broken out in a prereq patch. But yes, I should
> have asked for this earlier on, so I'm not going to insist.

Since I will be re-spinning this patch I will split this out.

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 4/8] mm: Scrub memory from idle loop

[Dario Faggioli]

On Fri, 2017-08-04 at 13:05 -0400, Boris Ostrovsky wrote:
> Instead of scrubbing pages during guest destruction (from
> free_heap_pages()) do this opportunistically, from the idle loop.
> 
> We might come to scrub_free_pages()from idle loop while another CPU
> uses mapcache override, resulting in a fault while trying to do
> __map_domain_page() in scrub_one_page(). To avoid this, make mapcache
> vcpu override a per-cpu variable.
> 
> Signed-off-by: Boris Ostrovsky 
>
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Clemens Ladisch]

Oleksandr Andrushchenko wrote:
> On 08/07/2017 04:11 PM, Clemens Ladisch wrote:
>> How does that interface work?
>
> For the buffer received in .copy_user/.copy_kernel we send
> a request to the backend and get response back (async) when it has copied
> the bytes into HW/mixer/etc, so the buffer at frontend side can be reused.

So if the frontend sends too many (too large) requests, does the
backend wait until there is enough free space in the buffer before
it does the actual copying and then acks?

If yes, then these acks can be used as interrupts.  (You still
have to count frames, and call snd_pcm_period_elapsed() exactly
when a period boundary was reached or crossed.)

Splitting a large read/write into smaller requests to the backend
would improve the granularity of the known stream position.

The overall latency would be the sum of the sizes of the frontend
and backend buffers.


Why is the protocol designed this way?  Wasn't the goal to expose
some 'real' sound card?


Regards,
Clemens

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Oleksandr Andrushchenko]

On 08/07/2017 04:11 PM, Clemens Ladisch wrote:

Oleksandr Andrushchenko wrote:

On 08/07/2017 01:27 PM, Clemens Ladisch wrote:

You have to implement period interrupts (and the .pointer callback)
based on when the samples are actually moved from/to the backend.

Do you think I can implement this in a slightly different way,
without a timer at all, by updating
substream->runtime->hw_ptr_base explicitly in the frontend driver?

As far as I am aware, hw_ptr_base is an internal field that drivers
are not supposed to change.

I know that and always considered not a good solution,
this is why I have timer to emulate things

Just use your own variable, and return it from the .pointer callback.

this can work, but see below

So, that way, whenever I get an ack/response from the backend that it has
successfully played the buffer

That response should come after every period.



How does that interface work?

For the buffer received in .copy_user/.copy_kernel we send
a request to the backend and get response back (async) when it has copied
the bytes into HW/mixer/etc, so the buffer at frontend side can be reused.
So, the amount of bytes in this exchange is not necessarily
a multiply of the period. Also, there is no way to synchronize period
sizes in the front driver and backend to make those equal.
There is also no event from the backend in the
protocol to tell that the period has elapsed, so
sending data in period's size buffers will not probably
help because of possible underruns

  Is it possible to change the period size,
or at least to detect what it is?


Unfortunately no, this is not in the protocol.




Regards,
Clemens

you can see the protocol at [1]

Thank you,
Oleksandr

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/include/xen/interface/io/sndif.h?h=for-next


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Clemens Ladisch]

Oleksandr Andrushchenko wrote:
> On 08/07/2017 01:27 PM, Clemens Ladisch wrote:
>> You have to implement period interrupts (and the .pointer callback)
>> based on when the samples are actually moved from/to the backend.
>
> Do you think I can implement this in a slightly different way,
> without a timer at all, by updating
> substream->runtime->hw_ptr_base explicitly in the frontend driver?

As far as I am aware, hw_ptr_base is an internal field that drivers
are not supposed to change.

Just use your own variable, and return it from the .pointer callback.

> So, that way, whenever I get an ack/response from the backend that it has
> successfully played the buffer

That response should come after every period.

How does that interface work?  Is it possible to change the period size,
or at least to detect what it is?


Regards,
Clemens

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/5] tools/libxenforeignmemory: add support for resource mapping

[Paul Durrant]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 04 August 2017 13:16
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org; Ian Jackson ;
> Wei Liu 
> Subject: Re: [PATCH 4/5] tools/libxenforeignmemory: add support for
> resource mapping
> 
> On Wed, Aug 02, 2017 at 10:59:48AM +0100, Paul Durrant wrote:
> > A previous patch introduced a new HYPERVISOR_memory_op to acquire
> guest
> > resources for direct priv-mapping.
> >
> > This patch adds new functionality into libxenforeignmemory to make use
> > of a new privcmd ioctl [1] that uses the new memory op to make such
> > resources available via mmap(2).
> >
> > [1]
> http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=c5cf
> 2b15f7a448277716a7e96fea1c93df6c17a5
> >
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > ---
> >  tools/include/xen-sys/Linux/privcmd.h  | 11 ++
> >  tools/libs/foreignmemory/core.c| 42 
> > 
> >  .../libs/foreignmemory/include/xenforeignmemory.h  | 39
> +++
> >  tools/libs/foreignmemory/libxenforeignmemory.map   |  5 +++
> >  tools/libs/foreignmemory/linux.c   | 45
> ++
> >  tools/libs/foreignmemory/private.h | 30 +++
> >  6 files changed, 172 insertions(+)
> 
> You forgot to bump the version number in Makefile

So I did. Shame that's not tied to the map file so that the added functions are 
not seen unless the version is bumped (in which case my testing would have 
caught it).

  Paul

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 5/5] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Paul Durrant]

> -Original Message-
> From: Marek Marczykowski-Górecki
> [mailto:marma...@invisiblethingslab.com]
> Sent: 04 August 2017 14:02
> To: Wei Liu 
> Cc: Paul Durrant ; xen-de...@lists.xenproject.org;
> Ian Jackson 
> Subject: Re: [PATCH 5/5] tools/libxenctrl: use new xenforeignmemory API to
> seed grant table
> 
> On Fri, Aug 04, 2017 at 01:26:21PM +0100, Wei Liu wrote:
> > On Wed, Aug 02, 2017 at 10:59:49AM +0100, Paul Durrant wrote:
> > > A previous patch added support for priv-mapping guest resources directly
> > > (rather than having to foreign-map, which requires P2M modification for
> > > HVM guests).
> > >
> > > This patch makes use of the new API to seed the guest grant table unless
> > > the underlying infrastructure (i.e. privcmd) doesn't support it, in which
> > > case the old scheme is used.
> > >
> >
> > The code mostly looks fine.
> >
> > What's the benefit of doing this?
> 
> Also, I see changed signature of xc_dom_gnttab_seed (it got is_hvm
> parameter). Wei, what is the policy for backward incompatible libxc API
> changes?
> 
> > > NOTE: The call to xc_dom_gnttab_hvm_seed() in
> hvm_build_set_params() was
> > >   actually unnecessary, as the grant table has already been seeded
> > >   by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().
> > >
> > > Signed-off-by: Paul Durrant 
> > > ---
> > > Cc: Ian Jackson 
> > > Cc: Wei Liu 
> >
> > BTW Marek needs to be CC on changes to Python bindings. I've done that
> > for you.
> 
> For Python bits:
> Acked-by: Marek Marczykowski-Górecki
> 

Thanks :-)

  Paul

> 
> > > ---
> > >  tools/libxc/include/xc_dom.h|   8 +--
> > >  tools/libxc/xc_dom_boot.c   | 102
> 
> > >  tools/libxc/xc_sr_restore_x86_hvm.c |  10 ++--
> > >  tools/libxc/xc_sr_restore_x86_pv.c  |   2 +-
> > >  tools/libxl/libxl_dom.c |   1 -
> > >  tools/python/xen/lowlevel/xc/xc.c   |   6 +--
> > >  6 files changed, 92 insertions(+), 37 deletions(-)
> > >
> > > diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> > > index ce47058c41..d6ca0a8680 100644
> > > --- a/tools/libxc/include/xc_dom.h
> > > +++ b/tools/libxc/include/xc_dom.h
> > > @@ -323,12 +323,8 @@ void *xc_dom_boot_domU_map(struct
> xc_dom_image *dom, xen_pfn_t pfn,
> > >  int xc_dom_boot_image(struct xc_dom_image *dom);
> > >  int xc_dom_compat_check(struct xc_dom_image *dom);
> > >  int xc_dom_gnttab_init(struct xc_dom_image *dom);
> > > -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > > -   xen_pfn_t console_gmfn,
> > > -   xen_pfn_t xenstore_gmfn,
> > > -   domid_t console_domid,
> > > -   domid_t xenstore_domid);
> > > -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
> > > +int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
> > > +   bool is_hvm,
> > > xen_pfn_t console_gmfn,
> > > xen_pfn_t xenstore_gmfn,
> > > domid_t console_domid,
> > > diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
> > > index c3b44dd399..fc3174ad7e 100644
> > > --- a/tools/libxc/xc_dom_boot.c
> > > +++ b/tools/libxc/xc_dom_boot.c
> > > @@ -280,11 +280,11 @@ static xen_pfn_t
> xc_dom_gnttab_setup(xc_interface *xch, domid_t domid)
> > >  return gmfn;
> > >  }
> > >
> > > -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
> > > -   xen_pfn_t console_gmfn,
> > > -   xen_pfn_t xenstore_gmfn,
> > > -   domid_t console_domid,
> > > -   domid_t xenstore_domid)
> > > +static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
> > > +  xen_pfn_t console_gmfn,
> > > +  xen_pfn_t xenstore_gmfn,
> > > +  domid_t console_domid,
> > > +  domid_t xenstore_domid)
> > >  {
> > >
> > >  xen_pfn_t gnttab_gmfn;
> > > @@ -337,11 +337,11 @@ int xc_dom_gnttab_seed(xc_interface *xch,
> domid_t domid,
> > >  return 0;
> > >  }
> > >
> > > -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > > -   xen_pfn_t console_gpfn,
> > > -   xen_pfn_t xenstore_gpfn,
> > > -   domid_t console_domid,
> > > -   domid_t xenstore_domid)
> > > +static int compat_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > > +  xen_pfn_t console_gpfn,
> > > +  xen_pfn_t xenstore_gpfn,
> > > +  domid_t console_domid,
> > > +  

Re: [Xen-devel] [PATCH 5/5] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Paul Durrant]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 04 August 2017 13:26
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org; Ian Jackson ;
> Wei Liu ; Marek Marczykowski-Górecki
> 
> Subject: Re: [PATCH 5/5] tools/libxenctrl: use new xenforeignmemory API to
> seed grant table
> 
> On Wed, Aug 02, 2017 at 10:59:49AM +0100, Paul Durrant wrote:
> > A previous patch added support for priv-mapping guest resources directly
> > (rather than having to foreign-map, which requires P2M modification for
> > HVM guests).
> >
> > This patch makes use of the new API to seed the guest grant table unless
> > the underlying infrastructure (i.e. privcmd) doesn't support it, in which
> > case the old scheme is used.
> >
> 
> The code mostly looks fine.
> 

Ok, thanks :-)

> What's the benefit of doing this?

The main benefit is not having to insert the grant table into an HVM guest's 
P2M, which potentially shatters a super-page mapping.

  Paul

> 
> > NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params()
> was
> >   actually unnecessary, as the grant table has already been seeded
> >   by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().
> >
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> 
> BTW Marek needs to be CC on changes to Python bindings. I've done that
> for you.
> 
> > ---
> >  tools/libxc/include/xc_dom.h|   8 +--
> >  tools/libxc/xc_dom_boot.c   | 102
> 
> >  tools/libxc/xc_sr_restore_x86_hvm.c |  10 ++--
> >  tools/libxc/xc_sr_restore_x86_pv.c  |   2 +-
> >  tools/libxl/libxl_dom.c |   1 -
> >  tools/python/xen/lowlevel/xc/xc.c   |   6 +--
> >  6 files changed, 92 insertions(+), 37 deletions(-)
> >
> > diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> > index ce47058c41..d6ca0a8680 100644
> > --- a/tools/libxc/include/xc_dom.h
> > +++ b/tools/libxc/include/xc_dom.h
> > @@ -323,12 +323,8 @@ void *xc_dom_boot_domU_map(struct
> xc_dom_image *dom, xen_pfn_t pfn,
> >  int xc_dom_boot_image(struct xc_dom_image *dom);
> >  int xc_dom_compat_check(struct xc_dom_image *dom);
> >  int xc_dom_gnttab_init(struct xc_dom_image *dom);
> > -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > -   xen_pfn_t console_gmfn,
> > -   xen_pfn_t xenstore_gmfn,
> > -   domid_t console_domid,
> > -   domid_t xenstore_domid);
> > -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
> > +int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
> > +   bool is_hvm,
> > xen_pfn_t console_gmfn,
> > xen_pfn_t xenstore_gmfn,
> > domid_t console_domid,
> > diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
> > index c3b44dd399..fc3174ad7e 100644
> > --- a/tools/libxc/xc_dom_boot.c
> > +++ b/tools/libxc/xc_dom_boot.c
> > @@ -280,11 +280,11 @@ static xen_pfn_t
> xc_dom_gnttab_setup(xc_interface *xch, domid_t domid)
> >  return gmfn;
> >  }
> >
> > -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
> > -   xen_pfn_t console_gmfn,
> > -   xen_pfn_t xenstore_gmfn,
> > -   domid_t console_domid,
> > -   domid_t xenstore_domid)
> > +static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
> > +  xen_pfn_t console_gmfn,
> > +  xen_pfn_t xenstore_gmfn,
> > +  domid_t console_domid,
> > +  domid_t xenstore_domid)
> >  {
> >
> >  xen_pfn_t gnttab_gmfn;
> > @@ -337,11 +337,11 @@ int xc_dom_gnttab_seed(xc_interface *xch,
> domid_t domid,
> >  return 0;
> >  }
> >
> > -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > -   xen_pfn_t console_gpfn,
> > -   xen_pfn_t xenstore_gpfn,
> > -   domid_t console_domid,
> > -   domid_t xenstore_domid)
> > +static int compat_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
> > +  xen_pfn_t console_gpfn,
> > +  xen_pfn_t xenstore_gpfn,
> > +  domid_t console_domid,
> > +  domid_t xenstore_domid)
> >  {
> >  int rc;
> >  xen_pfn_t scratch_gpfn;
> > @@ -380,7 +380,7 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch,
> domid_t domid,
> >  return -1;
> >  }
> >
> > -rc = xc_dom_gnttab_seed(xch, domid,
> > +rc = compat_gnttab_seed(xch, domid,
> >   

Re: [Xen-devel] [PATCH RESEND 00/11] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

On 08/07/2017 03:30 PM, Takashi Sakamoto wrote:

On Aug 7 2017 21:18, Oleksandr Andrushchenko wrote:
Your first patch includes code difference under line 26, thus it 
expects existence of a file 'sound/drivers/xen-front.c' in tree. 
However, the file is not introduced in any upstream yet; at least, 
Linus's tree and Iwai-san's tree.

I missed the very first patch in the series, this is why, my bad


When I did the same mistake, I take git-hash for a first commit in 
series as an argument into git-format-patch command. But this 
operation generated patchset which starts at second commit. I solved 
this to add '~', like.


$ git format-patch -s the-git-hash~...

Or pick up the hash for a commit just before a first commit in the 
series. For your information ;)



thank you for the hint, will use instead of specifying number of patches
(this is why I missed one and made so much noise)


Regards

Takashi Sakamoto

Thank you,
Oleksandr

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND 00/11] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Takashi Sakamoto]

On Aug 7 2017 21:18, Oleksandr Andrushchenko wrote:
Your first patch includes code difference under line 26, thus it 
expects existence of a file 'sound/drivers/xen-front.c' in tree. 
However, the file is not introduced in any upstream yet; at least, 
Linus's tree and Iwai-san's tree.

I missed the very first patch in the series, this is why, my bad


When I did the same mistake, I take git-hash for a first commit in 
series as an argument into git-format-patch command. But this operation 
generated patchset which starts at second commit. I solved this to add 
'~', like.


$ git format-patch -s the-git-hash~...

Or pick up the hash for a commit just before a first commit in the 
series. For your information ;)



Regards

Takashi Sakamoto

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND1 09/12] ALSA: vsnd: Add timer for period interrupt emulation

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Front sound driver has no real interrupts, so
playback/capture period passed interrupt needs to be emulated:
this is done via timer. Add required timer operations,
this is based on sound/drivers/dummy.c.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 121 ++
 1 file changed, 121 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 9f31e6832086..507c5eb343c8 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -67,12 +67,29 @@ struct sh_buf_info {
size_t vbuffer_sz;
 };
 
+struct sdev_alsa_timer_info {
+   spinlock_t lock;
+   struct timer_list timer;
+   unsigned long base_time;
+   /* fractional sample position (based HZ) */
+   unsigned int frac_pos;
+   unsigned int frac_period_rest;
+   /* buffer_size * HZ */
+   unsigned int frac_buffer_size;
+   /* period_size * HZ */
+   unsigned int frac_period_size;
+   unsigned int rate;
+   int elapsed;
+   struct snd_pcm_substream *substream;
+};
+
 struct sdev_pcm_stream_info {
int unique_id;
struct snd_pcm_hardware pcm_hw;
struct xdrv_evtchnl_info *evt_chnl;
bool is_open;
uint8_t req_next_id;
+   struct sdev_alsa_timer_info timer;
struct sh_buf_info sh_buf;
 };
 
@@ -148,6 +165,110 @@ static struct sdev_pcm_stream_info *sdrv_stream_get(
return stream;
 }
 
+static inline void sdrv_alsa_timer_rearm(struct sdev_alsa_timer_info *dpcm)
+{
+   mod_timer(>timer, jiffies +
+   (dpcm->frac_period_rest + dpcm->rate - 1) / dpcm->rate);
+}
+
+static void sdrv_alsa_timer_update(struct sdev_alsa_timer_info *dpcm)
+{
+   unsigned long delta;
+
+   delta = jiffies - dpcm->base_time;
+   if (!delta)
+   return;
+   dpcm->base_time += delta;
+   delta *= dpcm->rate;
+   dpcm->frac_pos += delta;
+   while (dpcm->frac_pos >= dpcm->frac_buffer_size)
+   dpcm->frac_pos -= dpcm->frac_buffer_size;
+   while (dpcm->frac_period_rest <= delta) {
+   dpcm->elapsed++;
+   dpcm->frac_period_rest += dpcm->frac_period_size;
+   }
+   dpcm->frac_period_rest -= delta;
+}
+
+static int sdrv_alsa_timer_start(struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+
+   spin_lock(>lock);
+   dpcm->base_time = jiffies;
+   sdrv_alsa_timer_rearm(dpcm);
+   spin_unlock(>lock);
+   return 0;
+}
+
+static int sdrv_alsa_timer_stop(struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+
+   spin_lock(>lock);
+   del_timer(>timer);
+   spin_unlock(>lock);
+   return 0;
+}
+
+static int sdrv_alsa_timer_prepare(struct snd_pcm_substream *substream)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+
+   dpcm->frac_pos = 0;
+   dpcm->rate = runtime->rate;
+   dpcm->frac_buffer_size = runtime->buffer_size * HZ;
+   dpcm->frac_period_size = runtime->period_size * HZ;
+   dpcm->frac_period_rest = dpcm->frac_period_size;
+   dpcm->elapsed = 0;
+   return 0;
+}
+
+static void sdrv_alsa_timer_callback(unsigned long data)
+{
+   struct sdev_alsa_timer_info *dpcm = (struct sdev_alsa_timer_info *)data;
+   int elapsed;
+
+   spin_lock(>lock);
+   sdrv_alsa_timer_update(dpcm);
+   sdrv_alsa_timer_rearm(dpcm);
+   elapsed = dpcm->elapsed;
+   dpcm->elapsed = 0;
+   spin_unlock(>lock);
+   if (elapsed)
+   snd_pcm_period_elapsed(dpcm->substream);
+}
+
+static snd_pcm_uframes_t sdrv_alsa_timer_pointer(
+   struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+   snd_pcm_uframes_t pos;
+
+   spin_lock(>lock);
+   sdrv_alsa_timer_update(dpcm);
+   pos = dpcm->frac_pos / HZ;
+   spin_unlock(>lock);
+   return pos;
+}
+
+static int sdrv_alsa_timer_create(struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+
+   spin_lock_init(>lock);
+   dpcm->substream = substream;
+   setup_timer(>timer, sdrv_alsa_timer_callback,
+   (unsigned long) dpcm);
+   return 0;
+}
+
 static void sdrv_copy_pcm_hw(struct snd_pcm_hardware *dst,
struct snd_pcm_hardware *src,
struct snd_pcm_hardware *ref_pcm_hw)
-- 
2.7.4

[Xen-devel] [PATCH RESEND1 06/12] ALSA: vsnd: Implement handling of shared buffers

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Implement shared buffer handling according to the
para-virtualized sound device protocol at xen/interface/io/sndif.h:
- manage buffer memory
- handle granted references
- handle page directories

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 178 ++
 1 file changed, 178 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index a92459b2737e..04ebc15757f4 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -58,6 +58,14 @@ struct xdrv_evtchnl_info {
uint16_t resp_id;
 };
 
+struct sh_buf_info {
+   int num_grefs;
+   grant_ref_t *grefs;
+   uint8_t *vdirectory;
+   uint8_t *vbuffer;
+   size_t vbuffer_sz;
+};
+
 struct cfg_stream {
int unique_id;
char *xenstore_path;
@@ -825,6 +833,176 @@ static void xdrv_remove_internal(struct xdrv_info 
*drv_info)
xdrv_evtchnl_free_all(drv_info);
 }
 
+static inline grant_ref_t sh_buf_get_dir_start(struct sh_buf_info *buf)
+{
+   if (!buf->grefs)
+   return GRANT_INVALID_REF;
+   return buf->grefs[0];
+}
+
+static inline void sh_buf_clear(struct sh_buf_info *buf)
+{
+   memset(buf, 0, sizeof(*buf));
+}
+
+static void sh_buf_free(struct sh_buf_info *buf)
+{
+   int i;
+
+   if (buf->grefs) {
+   for (i = 0; i < buf->num_grefs; i++)
+   if (buf->grefs[i] != GRANT_INVALID_REF)
+   gnttab_end_foreign_access(buf->grefs[i],
+   0, 0UL);
+   kfree(buf->grefs);
+   }
+   kfree(buf->vdirectory);
+   free_pages_exact(buf->vbuffer, buf->vbuffer_sz);
+   sh_buf_clear(buf);
+}
+
+/*
+ * number of grant references a page can hold with respect to the
+ * xendispl_page_directory header
+ */
+#define XENSND_NUM_GREFS_PER_PAGE ((XEN_PAGE_SIZE - \
+   offsetof(struct xensnd_page_directory, gref)) / \
+   sizeof(grant_ref_t))
+
+static void sh_buf_fill_page_dir(struct sh_buf_info *buf, int num_pages_dir)
+{
+   struct xensnd_page_directory *page_dir;
+   unsigned char *ptr;
+   int i, cur_gref, grefs_left, to_copy;
+
+   ptr = buf->vdirectory;
+   grefs_left = buf->num_grefs - num_pages_dir;
+   /*
+* skip grant references at the beginning, they are for pages granted
+* for the page directory itself
+*/
+   cur_gref = num_pages_dir;
+   for (i = 0; i < num_pages_dir; i++) {
+   page_dir = (struct xensnd_page_directory *)ptr;
+   if (grefs_left <= XENSND_NUM_GREFS_PER_PAGE) {
+   to_copy = grefs_left;
+   page_dir->gref_dir_next_page = GRANT_INVALID_REF;
+   } else {
+   to_copy = XENSND_NUM_GREFS_PER_PAGE;
+   page_dir->gref_dir_next_page = buf->grefs[i + 1];
+   }
+   memcpy(_dir->gref, >grefs[cur_gref],
+   to_copy * sizeof(grant_ref_t));
+   ptr += XEN_PAGE_SIZE;
+   grefs_left -= to_copy;
+   cur_gref += to_copy;
+   }
+}
+
+static int sh_buf_grant_refs(struct xenbus_device *xb_dev,
+   struct sh_buf_info *buf,
+   int num_pages_dir, int num_pages_vbuffer, int num_grefs)
+{
+   grant_ref_t priv_gref_head;
+   int ret, i, j, cur_ref;
+   int otherend_id;
+
+   ret = gnttab_alloc_grant_references(num_grefs, _gref_head);
+   if (ret)
+   return ret;
+
+   buf->num_grefs = num_grefs;
+   otherend_id = xb_dev->otherend_id;
+   j = 0;
+
+   for (i = 0; i < num_pages_dir; i++) {
+   cur_ref = gnttab_claim_grant_reference(_gref_head);
+   if (cur_ref < 0) {
+   ret = cur_ref;
+   goto fail;
+   }
+
+   gnttab_grant_foreign_access_ref(cur_ref, otherend_id,
+   xen_page_to_gfn(virt_to_page(buf->vdirectory +
+   XEN_PAGE_SIZE * i)), 0);
+   buf->grefs[j++] = cur_ref;
+   }
+
+   for (i = 0; i < num_pages_vbuffer; i++) {
+   cur_ref = gnttab_claim_grant_reference(_gref_head);
+   if (cur_ref < 0) {
+   ret = cur_ref;
+   goto fail;
+   }
+
+   gnttab_grant_foreign_access_ref(cur_ref, otherend_id,
+   xen_page_to_gfn(virt_to_page(buf->vbuffer +
+   XEN_PAGE_SIZE * i)), 0);
+   buf->grefs[j++] = cur_ref;
+   }
+
+   gnttab_free_grant_references(priv_gref_head);
+   sh_buf_fill_page_dir(buf, num_pages_dir);
+   return 0;
+
+fail:
+   gnttab_free_grant_references(priv_gref_head);
+   return ret;
+}
+
+static int 

[Xen-devel] [PATCH RESEND1 07/12] ALSA: vsnd: Introduce ALSA virtual sound driver

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Implement essential initialization of the sound driver:
- introduce required data structures
- handle driver registration
- handle sound card registration
- register sound driver on backend connection
- remove sound driver on backend disconnect

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 161 +-
 1 file changed, 159 insertions(+), 2 deletions(-)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 04ebc15757f4..f3e3f64f0aa6 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -19,13 +19,14 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -66,6 +67,33 @@ struct sh_buf_info {
size_t vbuffer_sz;
 };
 
+struct sdev_pcm_stream_info {
+   int unique_id;
+   struct snd_pcm_hardware pcm_hw;
+   struct xdrv_evtchnl_info *evt_chnl;
+   bool is_open;
+   uint8_t req_next_id;
+   struct sh_buf_info sh_buf;
+};
+
+struct sdev_pcm_instance_info {
+   struct sdev_card_info *card_info;
+   struct snd_pcm *pcm;
+   struct snd_pcm_hardware pcm_hw;
+   int num_pcm_streams_pb;
+   struct sdev_pcm_stream_info *streams_pb;
+   int num_pcm_streams_cap;
+   struct sdev_pcm_stream_info *streams_cap;
+};
+
+struct sdev_card_info {
+   struct xdrv_info *xdrv_info;
+   struct snd_card *card;
+   struct snd_pcm_hardware pcm_hw;
+   int num_pcm_instances;
+   struct sdev_pcm_instance_info *pcm_instances;
+};
+
 struct cfg_stream {
int unique_id;
char *xenstore_path;
@@ -99,6 +127,8 @@ struct xdrv_info {
struct xenbus_device *xb_dev;
spinlock_t io_lock;
struct mutex mutex;
+   bool sdrv_registered;
+   struct platform_device *sdrv_pdev;
int num_evt_channels;
struct xdrv_evtchnl_info *evt_chnls;
struct sdev_card_plat_data cfg_plat_data;
@@ -138,6 +168,132 @@ static struct snd_pcm_hardware sdrv_pcm_hw_default = {
.fifo_size = 0,
 };
 
+static int sdrv_new_pcm(struct sdev_card_info *card_info,
+   struct cfg_pcm_instance *instance_config,
+   struct sdev_pcm_instance_info *pcm_instance_info)
+{
+   return 0;
+}
+
+static int sdrv_probe(struct platform_device *pdev)
+{
+   struct sdev_card_info *card_info;
+   struct sdev_card_plat_data *platdata;
+   struct snd_card *card;
+   int ret, i;
+
+   platdata = dev_get_platdata(>dev);
+
+   dev_dbg(>dev, "Creating virtual sound card\n");
+
+   ret = snd_card_new(>dev, 0, XENSND_DRIVER_NAME, THIS_MODULE,
+   sizeof(struct sdev_card_info), );
+   if (ret < 0)
+   return ret;
+
+   card_info = card->private_data;
+   card_info->xdrv_info = platdata->xdrv_info;
+   card_info->card = card;
+   card_info->pcm_instances = devm_kcalloc(>dev,
+   platdata->cfg_card.num_pcm_instances,
+   sizeof(struct sdev_pcm_instance_info), GFP_KERNEL);
+   if (!card_info->pcm_instances) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   card_info->num_pcm_instances = platdata->cfg_card.num_pcm_instances;
+   card_info->pcm_hw = platdata->cfg_card.pcm_hw;
+
+   for (i = 0; i < platdata->cfg_card.num_pcm_instances; i++) {
+   ret = sdrv_new_pcm(card_info,
+   >cfg_card.pcm_instances[i],
+   _info->pcm_instances[i]);
+   if (ret < 0)
+   goto fail;
+   }
+
+   strncpy(card->driver, XENSND_DRIVER_NAME, sizeof(card->driver));
+   strncpy(card->shortname, platdata->cfg_card.name_short,
+   sizeof(card->shortname));
+   strncpy(card->longname, platdata->cfg_card.name_long,
+   sizeof(card->longname));
+
+   ret = snd_card_register(card);
+   if (ret < 0)
+   goto fail;
+
+   platform_set_drvdata(pdev, card);
+   return 0;
+
+fail:
+   snd_card_free(card);
+   return ret;
+}
+
+static int sdrv_remove(struct platform_device *pdev)
+{
+   struct sdev_card_info *info;
+   struct snd_card *card = platform_get_drvdata(pdev);
+
+   info = card->private_data;
+   dev_dbg(>dev, "Removing virtual sound card %d\n",
+   info->card->number);
+   snd_card_free(card);
+   return 0;
+}
+
+static struct platform_driver sdrv_info = {
+   .probe  = sdrv_probe,
+   .remove = sdrv_remove,
+   .driver = {
+   .name   = XENSND_DRIVER_NAME,
+   },
+};
+
+static void sdrv_cleanup(struct xdrv_info *drv_info)
+{
+   if (!drv_info->sdrv_registered)
+   return;
+
+   if (drv_info->sdrv_pdev) {
+   struct platform_device *sdrv_pdev;
+
+   sdrv_pdev = drv_info->sdrv_pdev;
+   

[Xen-devel] [PATCH RESEND1 10/12] ALSA: vsnd: Implement ALSA PCM operations

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Implement ALSA driver operations including:
- start/stop period interrupt emulation
- manage frontend/backend shraed buffers
- manage Xen bus event channel state

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 175 ++
 1 file changed, 163 insertions(+), 12 deletions(-)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 507c5eb343c8..7275e9cb38c0 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -151,6 +151,11 @@ struct xdrv_info {
struct sdev_card_plat_data cfg_plat_data;
 };
 
+static inline void sh_buf_clear(struct sh_buf_info *buf);
+static void sh_buf_free(struct sh_buf_info *buf);
+static int sh_buf_alloc(struct xenbus_device *xb_dev, struct sh_buf_info *buf,
+   unsigned int buffer_size);
+
 static struct sdev_pcm_stream_info *sdrv_stream_get(
struct snd_pcm_substream *substream)
 {
@@ -311,71 +316,217 @@ static void sdrv_copy_pcm_hw(struct snd_pcm_hardware 
*dst,
 
 static int sdrv_alsa_open(struct snd_pcm_substream *substream)
 {
-   return 0;
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct xdrv_info *xdrv_info;
+   unsigned long flags;
+   int ret;
+
+   sdrv_copy_pcm_hw(>hw, >pcm_hw, _instance->pcm_hw);
+   runtime->hw.info &= ~(SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID |
+   SNDRV_PCM_INFO_DOUBLE |
+   SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_NONINTERLEAVED |
+   SNDRV_PCM_INFO_RESUME |
+   SNDRV_PCM_INFO_PAUSE);
+   runtime->hw.info |= SNDRV_PCM_INFO_INTERLEAVED;
+
+   xdrv_info = pcm_instance->card_info->xdrv_info;
+
+   ret = sdrv_alsa_timer_create(substream);
+
+   spin_lock_irqsave(_info->io_lock, flags);
+   sh_buf_clear(>sh_buf);
+   stream->evt_chnl = _info->evt_chnls[stream->unique_id];
+   if (ret < 0)
+   stream->evt_chnl->state = EVTCHNL_STATE_DISCONNECTED;
+   else
+   stream->evt_chnl->state = EVTCHNL_STATE_CONNECTED;
+   spin_unlock_irqrestore(_info->io_lock, flags);
+   return ret;
 }
 
 static int sdrv_alsa_close(struct snd_pcm_substream *substream)
 {
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct xdrv_info *xdrv_info;
+   unsigned long flags;
+
+   xdrv_info = pcm_instance->card_info->xdrv_info;
+
+   sdrv_alsa_timer_stop(substream);
+
+   spin_lock_irqsave(_info->io_lock, flags);
+   stream->evt_chnl->state = EVTCHNL_STATE_DISCONNECTED;
+   spin_unlock_irqrestore(_info->io_lock, flags);
return 0;
 }
 
 static int sdrv_alsa_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
 {
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct xdrv_info *xdrv_info;
+   unsigned int buffer_size;
+   int ret;
+
+   buffer_size = params_buffer_bytes(params);
+   sh_buf_clear(>sh_buf);
+   xdrv_info = pcm_instance->card_info->xdrv_info;
+   ret = sh_buf_alloc(xdrv_info->xb_dev,
+   >sh_buf, buffer_size);
+   if (ret < 0)
+   goto fail;
return 0;
+
+fail:
+   dev_err(_info->xb_dev->dev,
+   "Failed to allocate buffers for stream idx %d\n",
+   stream->unique_id);
+   return ret;
 }
 
 static int sdrv_alsa_hw_free(struct snd_pcm_substream *substream)
 {
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct xdrv_info *xdrv_info;
+   unsigned long flags;
+
+   xdrv_info = pcm_instance->card_info->xdrv_info;
+   spin_lock_irqsave(_info->io_lock, flags);
+   sh_buf_free(>sh_buf);
+   spin_unlock_irqrestore(_info->io_lock, flags);
return 0;
 }
 
 static int sdrv_alsa_prepare(struct snd_pcm_substream *substream)
 {
-   return 0;
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   int ret = 0;
+
+   if (!stream->is_open)
+   ret = sdrv_alsa_timer_prepare(substream);
+   return ret;
 }
 
 static int sdrv_alsa_trigger(struct snd_pcm_substream *substream, int cmd)
 {
+   switch (cmd) {
+   case SNDRV_PCM_TRIGGER_START:
+   /* fall through */
+   case SNDRV_PCM_TRIGGER_RESUME:
+   return 

[Xen-devel] [PATCH RESEND1 08/12] ALSA: vsnd: Initialize virtul sound card

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Initialize virtual sound card with streams according to the
Xen store configuration.
Add stubs for stream PCM operations.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 232 ++
 1 file changed, 232 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index f3e3f64f0aa6..9f31e6832086 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -134,6 +134,129 @@ struct xdrv_info {
struct sdev_card_plat_data cfg_plat_data;
 };
 
+static struct sdev_pcm_stream_info *sdrv_stream_get(
+   struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream;
+
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+   stream = _instance->streams_pb[substream->number];
+   else
+   stream = _instance->streams_cap[substream->number];
+   return stream;
+}
+
+static void sdrv_copy_pcm_hw(struct snd_pcm_hardware *dst,
+   struct snd_pcm_hardware *src,
+   struct snd_pcm_hardware *ref_pcm_hw)
+{
+   *dst = *ref_pcm_hw;
+
+   if (src->formats)
+   dst->formats = src->formats;
+   if (src->buffer_bytes_max)
+   dst->buffer_bytes_max =
+   src->buffer_bytes_max;
+   if (src->period_bytes_min)
+   dst->period_bytes_min =
+   src->period_bytes_min;
+   if (src->period_bytes_max)
+   dst->period_bytes_max =
+   src->period_bytes_max;
+   if (src->periods_min)
+   dst->periods_min = src->periods_min;
+   if (src->periods_max)
+   dst->periods_max = src->periods_max;
+   if (src->rates)
+   dst->rates = src->rates;
+   if (src->rate_min)
+   dst->rate_min = src->rate_min;
+   if (src->rate_max)
+   dst->rate_max = src->rate_max;
+   if (src->channels_min)
+   dst->channels_min = src->channels_min;
+   if (src->channels_max)
+   dst->channels_max = src->channels_max;
+   if (src->buffer_bytes_max) {
+   dst->buffer_bytes_max = src->buffer_bytes_max;
+   dst->period_bytes_max = src->buffer_bytes_max /
+   src->periods_max;
+   dst->periods_max = dst->buffer_bytes_max /
+   dst->period_bytes_max;
+   }
+}
+
+static int sdrv_alsa_open(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_close(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   return 0;
+}
+
+static int sdrv_alsa_hw_free(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_prepare(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_trigger(struct snd_pcm_substream *substream, int cmd)
+{
+   return 0;
+}
+
+static inline snd_pcm_uframes_t sdrv_alsa_pointer(
+   struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_playback_copy_user(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, void __user *buf,
+   unsigned long bytes)
+{
+   return 0;
+}
+
+static int sdrv_alsa_playback_copy_kernel(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, void *buf, unsigned long bytes)
+{
+   return 0;
+}
+
+static int sdrv_alsa_capture_copy_user(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, void __user *buf,
+   unsigned long bytes)
+{
+   return 0;
+}
+
+static int sdrv_alsa_capture_copy_kernel(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, void *buf, unsigned long bytes)
+{
+   return 0;
+}
+
+static int sdrv_alsa_playback_fill_silence(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, unsigned long bytes)
+{
+   return 0;
+}
+
 #define MAX_XEN_BUFFER_SIZE(64 * 1024)
 #define MAX_BUFFER_SIZEMAX_XEN_BUFFER_SIZE
 #define MIN_PERIOD_SIZE64
@@ -168,10 +291,119 @@ static struct snd_pcm_hardware sdrv_pcm_hw_default = {
.fifo_size = 0,
 };
 
+/*
+ * FIXME: The mmaped data transfer is asynchronous and there is no
+ * ack signal from user-space when it is done. This is the
+ * reason it is not implemented in the PV driver as we do need
+ * to know when the buffer can be transferred to the backend.
+ */
+
+static struct snd_pcm_ops sdrv_alsa_playback_ops = {
+   .open = sdrv_alsa_open,
+   .close = sdrv_alsa_close,
+   .ioctl = snd_pcm_lib_ioctl,
+   

[Xen-devel] [PATCH RESEND1 12/12] ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Introduce Kconfig option to enable Xen para-virtualized sound
frontend driver. Also add sound frontend to the Makefile.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/Kconfig  | 12 
 sound/drivers/Makefile |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index 7144cc36e8ae..6b8fa6110ca3 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -235,4 +235,16 @@ config SND_AC97_POWER_SAVE_DEFAULT
 
  See SND_AC97_POWER_SAVE for more details.
 
+config SND_XEN_FRONTEND
+   tristate "Xen virtual sound front-end driver"
+   depends on SND_PCM && XEN
+   select XEN_XENBUS_FRONTEND
+   default n
+   help
+ This driver implements a front-end for the Xen
+ para-virtualized sound.
+
+ To compile this driver as a module, choose M here: the module
+ will be called snd-xen-front.
+
 endif  # SND_DRIVERS
diff --git a/sound/drivers/Makefile b/sound/drivers/Makefile
index 1a8440c8b138..70ed920a030f 100644
--- a/sound/drivers/Makefile
+++ b/sound/drivers/Makefile
@@ -11,6 +11,7 @@ snd-portman2x4-objs := portman2x4.o
 snd-serial-u16550-objs := serial-u16550.o
 snd-virmidi-objs := virmidi.o
 snd-ml403-ac97cr-objs := ml403-ac97cr.o pcm-indirect2.o
+snd-xen-front-objs := xen-front.o
 
 # Toplevel Module Dependency
 obj-$(CONFIG_SND_DUMMY) += snd-dummy.o
@@ -21,5 +22,6 @@ obj-$(CONFIG_SND_MTPAV) += snd-mtpav.o
 obj-$(CONFIG_SND_MTS64) += snd-mts64.o
 obj-$(CONFIG_SND_PORTMAN2X4) += snd-portman2x4.o
 obj-$(CONFIG_SND_ML403_AC97CR) += snd-ml403-ac97cr.o
+obj-$(CONFIG_SND_XEN_FRONTEND) += snd-xen-front.o
 
 obj-$(CONFIG_SND) += opl3/ opl4/ mpu401/ vx/ pcsp/
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND1 11/12] ALSA: vsnd: Implement communication with backend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Implement frontend to backend communication according to
the para-virtualized sound protocol: xen/interface/io/sndif.h.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 302 +++---
 1 file changed, 288 insertions(+), 14 deletions(-)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 7275e9cb38c0..8bfec43ef03a 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -38,6 +38,8 @@
  * because of the fact it is already in use/reserved by the PV console.
  */
 #define GRANT_INVALID_REF  0
+/* timeout in ms to wait for backend to respond */
+#define VSND_WAIT_BACK_MS  3000
 /* maximum number of supported streams */
 #define VSND_MAX_STREAM8
 
@@ -151,10 +153,12 @@ struct xdrv_info {
struct sdev_card_plat_data cfg_plat_data;
 };
 
+static inline void xdrv_evtchnl_flush(struct xdrv_evtchnl_info *channel);
 static inline void sh_buf_clear(struct sh_buf_info *buf);
 static void sh_buf_free(struct sh_buf_info *buf);
 static int sh_buf_alloc(struct xenbus_device *xb_dev, struct sh_buf_info *buf,
unsigned int buffer_size);
+static grant_ref_t sh_buf_get_dir_start(struct sh_buf_info *buf);
 
 static struct sdev_pcm_stream_info *sdrv_stream_get(
struct snd_pcm_substream *substream)
@@ -314,6 +318,234 @@ static void sdrv_copy_pcm_hw(struct snd_pcm_hardware *dst,
}
 }
 
+struct ALSA_SNDIF_SAMPLE_FORMAT {
+   uint8_t sndif;
+   snd_pcm_format_t alsa;
+};
+
+static struct ALSA_SNDIF_SAMPLE_FORMAT alsa_sndif_formats[] = {
+   {
+   .sndif = XENSND_PCM_FORMAT_U8,
+   .alsa = SNDRV_PCM_FORMAT_U8
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S8,
+   .alsa = SNDRV_PCM_FORMAT_S8
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U16_LE,
+   .alsa = SNDRV_PCM_FORMAT_U16_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U16_BE,
+   .alsa = SNDRV_PCM_FORMAT_U16_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S16_LE,
+   .alsa = SNDRV_PCM_FORMAT_S16_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S16_BE,
+   .alsa = SNDRV_PCM_FORMAT_S16_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U24_LE,
+   .alsa = SNDRV_PCM_FORMAT_U24_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U24_BE,
+   .alsa = SNDRV_PCM_FORMAT_U24_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S24_LE,
+   .alsa = SNDRV_PCM_FORMAT_S24_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S24_BE,
+   .alsa = SNDRV_PCM_FORMAT_S24_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U32_LE,
+   .alsa = SNDRV_PCM_FORMAT_U32_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U32_BE,
+   .alsa = SNDRV_PCM_FORMAT_U32_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S32_LE,
+   .alsa = SNDRV_PCM_FORMAT_S32_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S32_BE,
+   .alsa = SNDRV_PCM_FORMAT_S32_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_A_LAW,
+   .alsa = SNDRV_PCM_FORMAT_A_LAW
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_MU_LAW,
+   .alsa = SNDRV_PCM_FORMAT_MU_LAW
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_F32_LE,
+   .alsa = SNDRV_PCM_FORMAT_FLOAT_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_F32_BE,
+   .alsa = SNDRV_PCM_FORMAT_FLOAT_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_F64_LE,
+   .alsa = SNDRV_PCM_FORMAT_FLOAT64_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_F64_BE,
+   .alsa = SNDRV_PCM_FORMAT_FLOAT64_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_IEC958_SUBFRAME_LE,
+   .alsa = SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_IEC958_SUBFRAME_BE,
+   .alsa = SNDRV_PCM_FORMAT_IEC958_SUBFRAME_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_IMA_ADPCM,
+   .alsa = SNDRV_PCM_FORMAT_IMA_ADPCM
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_MPEG,
+   .alsa = SNDRV_PCM_FORMAT_MPEG
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_GSM,
+   .alsa = SNDRV_PCM_FORMAT_GSM
+   },
+};
+
+static int alsa_to_sndif_format(snd_pcm_format_t format)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(alsa_sndif_formats); i++)
+   if (alsa_sndif_formats[i].alsa == format)
+   return alsa_sndif_formats[i].sndif;
+ 

[Xen-devel] [PATCH RESEND1 05/12] ALSA: vsnd: Implement Xen event channel handling

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

1. Create event channels for all configured streams and publish
corresponding ring references and event channels in Xen store,
so backend can connect.
2. Implement event channel interrupt handler.
3. Create and destroy event channels with respect to Xen bus state.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 269 +-
 1 file changed, 268 insertions(+), 1 deletion(-)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index ef48cbf44cf2..a92459b2737e 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -24,14 +24,40 @@
 #include 
 
 #include 
+#include 
+#include 
 #include 
 #include 
 
 #include 
 
+/*
+ * FIXME: usage of grant reference 0 as invalid grant reference:
+ * grant reference 0 is valid, but never exposed to a PV driver,
+ * because of the fact it is already in use/reserved by the PV console.
+ */
+#define GRANT_INVALID_REF  0
 /* maximum number of supported streams */
 #define VSND_MAX_STREAM8
 
+enum xdrv_evtchnl_state {
+   EVTCHNL_STATE_DISCONNECTED,
+   EVTCHNL_STATE_CONNECTED,
+};
+
+struct xdrv_evtchnl_info {
+   struct xdrv_info *drv_info;
+   struct xen_sndif_front_ring ring;
+   int ring_ref;
+   int port;
+   int irq;
+   struct completion completion;
+   enum xdrv_evtchnl_state state;
+   /* latest response status and its corresponding id */
+   int resp_status;
+   uint16_t resp_id;
+};
+
 struct cfg_stream {
int unique_id;
char *xenstore_path;
@@ -65,6 +91,8 @@ struct xdrv_info {
struct xenbus_device *xb_dev;
spinlock_t io_lock;
struct mutex mutex;
+   int num_evt_channels;
+   struct xdrv_evtchnl_info *evt_chnls;
struct sdev_card_plat_data cfg_plat_data;
 };
 
@@ -102,6 +130,244 @@ static struct snd_pcm_hardware sdrv_pcm_hw_default = {
.fifo_size = 0,
 };
 
+static irqreturn_t xdrv_evtchnl_interrupt(int irq, void *dev_id)
+{
+   struct xdrv_evtchnl_info *channel = dev_id;
+   struct xdrv_info *drv_info = channel->drv_info;
+   struct xensnd_resp *resp;
+   RING_IDX i, rp;
+   unsigned long flags;
+
+   spin_lock_irqsave(_info->io_lock, flags);
+   if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED))
+   goto out;
+
+again:
+   rp = channel->ring.sring->rsp_prod;
+   /* ensure we see queued responses up to rp */
+   rmb();
+
+   for (i = channel->ring.rsp_cons; i != rp; i++) {
+   resp = RING_GET_RESPONSE(>ring, i);
+   if (resp->id != channel->resp_id)
+   continue;
+   switch (resp->operation) {
+   case XENSND_OP_OPEN:
+   /* fall through */
+   case XENSND_OP_CLOSE:
+   /* fall through */
+   case XENSND_OP_READ:
+   /* fall through */
+   case XENSND_OP_WRITE:
+   channel->resp_status = resp->status;
+   complete(>completion);
+   break;
+
+   default:
+   dev_err(_info->xb_dev->dev,
+   "Operation %d is not supported\n",
+   resp->operation);
+   break;
+   }
+   }
+
+   channel->ring.rsp_cons = i;
+   if (i != channel->ring.req_prod_pvt) {
+   int more_to_do;
+
+   RING_FINAL_CHECK_FOR_RESPONSES(>ring, more_to_do);
+   if (more_to_do)
+   goto again;
+   } else
+   channel->ring.sring->rsp_event = i + 1;
+
+out:
+   spin_unlock_irqrestore(_info->io_lock, flags);
+   return IRQ_HANDLED;
+}
+
+static inline void xdrv_evtchnl_flush(
+   struct xdrv_evtchnl_info *channel)
+{
+   int notify;
+
+   channel->ring.req_prod_pvt++;
+   RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(>ring, notify);
+   if (notify)
+   notify_remote_via_irq(channel->irq);
+}
+
+static void xdrv_evtchnl_free(struct xdrv_info *drv_info,
+   struct xdrv_evtchnl_info *channel)
+{
+   if (!channel->ring.sring)
+   return;
+
+   channel->state = EVTCHNL_STATE_DISCONNECTED;
+   channel->resp_status = -EIO;
+   complete_all(>completion);
+
+   if (channel->irq)
+   unbind_from_irqhandler(channel->irq, channel);
+   channel->irq = 0;
+
+   if (channel->port)
+   xenbus_free_evtchn(drv_info->xb_dev, channel->port);
+   channel->port = 0;
+
+   if (channel->ring_ref != GRANT_INVALID_REF)
+   gnttab_end_foreign_access(channel->ring_ref, 0,
+   (unsigned long)channel->ring.sring);
+   channel->ring_ref = GRANT_INVALID_REF;
+   

[Xen-devel] [PATCH RESEND1 03/12] ALSA: vsnd: Implement Xen bus state handling

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Initial handling for Xen bus states: implement
Xen bus state machine for the front driver according to
the state diagram and recovery flow from sound para-virtualized
protocol: xen/interface/io/sndif.h.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 92 +++
 1 file changed, 92 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 8c5de7b0e7b5..c4fd21cac3a7 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -36,9 +36,99 @@ static void xdrv_remove_internal(struct xdrv_info *drv_info)
 {
 }
 
+static int xdrv_be_on_initwait(struct xdrv_info *drv_info)
+{
+   return 0;
+}
+
+static inline int xdrv_be_on_connected(struct xdrv_info *drv_info)
+{
+   return 0;
+}
+
+static inline void xdrv_be_on_disconnected(struct xdrv_info *drv_info)
+{
+   xdrv_remove_internal(drv_info);
+}
+
 static void xdrv_be_on_changed(struct xenbus_device *xb_dev,
enum xenbus_state backend_state)
 {
+   struct xdrv_info *drv_info = dev_get_drvdata(_dev->dev);
+   int ret;
+
+   switch (backend_state) {
+   case XenbusStateReconfiguring:
+   /* fall through */
+   case XenbusStateReconfigured:
+   /* fall through */
+   case XenbusStateInitialised:
+   /* fall through */
+   break;
+
+   case XenbusStateInitialising:
+   if (xb_dev->state == XenbusStateInitialising)
+   break;
+
+   /* recovering after backend unexpected closure */
+   mutex_lock(_info->mutex);
+   xdrv_be_on_disconnected(drv_info);
+   mutex_unlock(_info->mutex);
+   xenbus_switch_state(xb_dev, XenbusStateInitialising);
+   break;
+
+   case XenbusStateInitWait:
+   if (xb_dev->state != XenbusStateInitialising)
+   break;
+
+   mutex_lock(_info->mutex);
+   ret = xdrv_be_on_initwait(drv_info);
+   mutex_unlock(_info->mutex);
+   if (ret < 0) {
+   xenbus_dev_fatal(xb_dev, ret,
+   "initializing " XENSND_DRIVER_NAME);
+   break;
+   }
+
+   xenbus_switch_state(xb_dev, XenbusStateInitialised);
+   break;
+
+   case XenbusStateConnected:
+   if (xb_dev->state != XenbusStateInitialised)
+   break;
+
+   mutex_lock(_info->mutex);
+   ret = xdrv_be_on_connected(drv_info);
+   mutex_unlock(_info->mutex);
+   if (ret < 0) {
+   xenbus_dev_fatal(xb_dev, ret,
+   "connecting " XENSND_DRIVER_NAME);
+   break;
+   }
+
+   xenbus_switch_state(xb_dev, XenbusStateConnected);
+   break;
+
+   case XenbusStateClosing:
+   /*
+* in this state backend starts freeing resources,
+* so let it go into closed state first, so we can also
+* remove ours
+*/
+   break;
+
+   case XenbusStateUnknown:
+   /* fall through */
+   case XenbusStateClosed:
+   if (xb_dev->state == XenbusStateClosed)
+   break;
+
+   mutex_lock(_info->mutex);
+   xdrv_be_on_disconnected(drv_info);
+   mutex_unlock(_info->mutex);
+   xenbus_switch_state(xb_dev, XenbusStateInitialising);
+   break;
+   }
 }
 
 static int xdrv_probe(struct xenbus_device *xb_dev,
@@ -56,6 +146,7 @@ static int xdrv_probe(struct xenbus_device *xb_dev,
spin_lock_init(_info->io_lock);
mutex_init(_info->mutex);
dev_set_drvdata(_dev->dev, drv_info);
+   xenbus_switch_state(xb_dev, XenbusStateInitialising);
return 0;
 }
 
@@ -63,6 +154,7 @@ static int xdrv_remove(struct xenbus_device *dev)
 {
struct xdrv_info *drv_info = dev_get_drvdata(>dev);
 
+   xenbus_switch_state(dev, XenbusStateClosed);
mutex_lock(_info->mutex);
xdrv_remove_internal(drv_info);
mutex_unlock(_info->mutex);
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND1 02/12] ALSA: vsnd: Implement driver's probe/remove

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Add essential driver private info structure, initialize
locks and implement probe/remove of the Xen frontend
driver.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 61779c36cae3..8c5de7b0e7b5 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -26,6 +26,16 @@
 
 #include 
 
+struct xdrv_info {
+   struct xenbus_device *xb_dev;
+   spinlock_t io_lock;
+   struct mutex mutex;
+};
+
+static void xdrv_remove_internal(struct xdrv_info *drv_info)
+{
+}
+
 static void xdrv_be_on_changed(struct xenbus_device *xb_dev,
enum xenbus_state backend_state)
 {
@@ -34,11 +44,28 @@ static void xdrv_be_on_changed(struct xenbus_device *xb_dev,
 static int xdrv_probe(struct xenbus_device *xb_dev,
const struct xenbus_device_id *id)
 {
+   struct xdrv_info *drv_info;
+
+   drv_info = devm_kzalloc(_dev->dev, sizeof(*drv_info), GFP_KERNEL);
+   if (!drv_info) {
+   xenbus_dev_fatal(xb_dev, -ENOMEM, "allocating device memory");
+   return -ENOMEM;
+   }
+
+   drv_info->xb_dev = xb_dev;
+   spin_lock_init(_info->io_lock);
+   mutex_init(_info->mutex);
+   dev_set_drvdata(_dev->dev, drv_info);
return 0;
 }
 
 static int xdrv_remove(struct xenbus_device *dev)
 {
+   struct xdrv_info *drv_info = dev_get_drvdata(>dev);
+
+   mutex_lock(_info->mutex);
+   xdrv_remove_internal(drv_info);
+   mutex_unlock(_info->mutex);
return 0;
 }
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND1 04/12] ALSA: vsnd: Read sound driver configuration from Xen store

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Read configuration values from Xen store according
to xen/interface/io/sndif.h protocol:
- introduce configuration structures for different
  components, e.g. sound card, device, stream
- read PCM HW parameters, e.g rate, format etc.
- detect stream type (capture/playback)
- read device and card parameters

Fill in platform data with the configuration read, so
it can be passed to sound driver later.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 530 ++
 1 file changed, 530 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index c4fd21cac3a7..ef48cbf44cf2 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -20,24 +20,554 @@
 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
 
 #include 
 
+/* maximum number of supported streams */
+#define VSND_MAX_STREAM8
+
+struct cfg_stream {
+   int unique_id;
+   char *xenstore_path;
+   struct snd_pcm_hardware pcm_hw;
+};
+
+struct cfg_pcm_instance {
+   char name[80];
+   int device_id;
+   struct snd_pcm_hardware pcm_hw;
+   int  num_streams_pb;
+   struct cfg_stream *streams_pb;
+   int  num_streams_cap;
+   struct cfg_stream *streams_cap;
+};
+
+struct cfg_card {
+   char name_short[32];
+   char name_long[80];
+   struct snd_pcm_hardware pcm_hw;
+   int num_pcm_instances;
+   struct cfg_pcm_instance *pcm_instances;
+};
+
+struct sdev_card_plat_data {
+   struct xdrv_info *xdrv_info;
+   struct cfg_card cfg_card;
+};
+
 struct xdrv_info {
struct xenbus_device *xb_dev;
spinlock_t io_lock;
struct mutex mutex;
+   struct sdev_card_plat_data cfg_plat_data;
 };
 
+#define MAX_XEN_BUFFER_SIZE(64 * 1024)
+#define MAX_BUFFER_SIZEMAX_XEN_BUFFER_SIZE
+#define MIN_PERIOD_SIZE64
+#define MAX_PERIOD_SIZE(MAX_BUFFER_SIZE / 8)
+#define USE_FORMATS(SNDRV_PCM_FMTBIT_U8 | \
+SNDRV_PCM_FMTBIT_S16_LE)
+#define USE_RATE   (SNDRV_PCM_RATE_CONTINUOUS | \
+SNDRV_PCM_RATE_8000_48000)
+#define USE_RATE_MIN   5512
+#define USE_RATE_MAX   48000
+#define USE_CHANNELS_MIN   1
+#define USE_CHANNELS_MAX   2
+#define USE_PERIODS_MIN2
+#define USE_PERIODS_MAX8
+
+static struct snd_pcm_hardware sdrv_pcm_hw_default = {
+   .info = (SNDRV_PCM_INFO_MMAP |
+SNDRV_PCM_INFO_INTERLEAVED |
+SNDRV_PCM_INFO_RESUME |
+SNDRV_PCM_INFO_MMAP_VALID),
+   .formats = USE_FORMATS,
+   .rates = USE_RATE,
+   .rate_min = USE_RATE_MIN,
+   .rate_max = USE_RATE_MAX,
+   .channels_min = USE_CHANNELS_MIN,
+   .channels_max = USE_CHANNELS_MAX,
+   .buffer_bytes_max = MAX_BUFFER_SIZE,
+   .period_bytes_min = MIN_PERIOD_SIZE,
+   .period_bytes_max = MAX_PERIOD_SIZE,
+   .periods_min = USE_PERIODS_MIN,
+   .periods_max = USE_PERIODS_MAX,
+   .fifo_size = 0,
+};
+
+struct CFG_HW_SAMPLE_RATE {
+   const char *name;
+   unsigned int mask;
+   unsigned int value;
+};
+
+static struct CFG_HW_SAMPLE_RATE cfg_hw_supported_rates[] = {
+   { .name = "5512",   .mask = SNDRV_PCM_RATE_5512,   .value = 5512 },
+   { .name = "8000",   .mask = SNDRV_PCM_RATE_8000,   .value = 8000 },
+   { .name = "11025",  .mask = SNDRV_PCM_RATE_11025,  .value = 11025 },
+   { .name = "16000",  .mask = SNDRV_PCM_RATE_16000,  .value = 16000 },
+   { .name = "22050",  .mask = SNDRV_PCM_RATE_22050,  .value = 22050 },
+   { .name = "32000",  .mask = SNDRV_PCM_RATE_32000,  .value = 32000 },
+   { .name = "44100",  .mask = SNDRV_PCM_RATE_44100,  .value = 44100 },
+   { .name = "48000",  .mask = SNDRV_PCM_RATE_48000,  .value = 48000 },
+   { .name = "64000",  .mask = SNDRV_PCM_RATE_64000,  .value = 64000 },
+   { .name = "96000",  .mask = SNDRV_PCM_RATE_96000,  .value = 96000 },
+   { .name = "176400", .mask = SNDRV_PCM_RATE_176400, .value = 176400 },
+   { .name = "192000", .mask = SNDRV_PCM_RATE_192000, .value = 192000 },
+};
+
+struct CFG_HW_SAMPLE_FORMAT {
+   const char *name;
+   u64 mask;
+};
+
+static struct CFG_HW_SAMPLE_FORMAT cfg_hw_supported_formats[] = {
+   {
+   .name = XENSND_PCM_FORMAT_U8_STR,
+   .mask = SNDRV_PCM_FMTBIT_U8
+   },
+   {
+   .name = XENSND_PCM_FORMAT_S8_STR,
+   .mask = SNDRV_PCM_FMTBIT_S8
+   },
+   {
+   .name = XENSND_PCM_FORMAT_U16_LE_STR,
+   .mask = SNDRV_PCM_FMTBIT_U16_LE
+   },
+   {
+   .name = XENSND_PCM_FORMAT_U16_BE_STR,
+   .mask = SNDRV_PCM_FMTBIT_U16_BE
+   },
+   {
+

[Xen-devel] [PATCH RESEND1 01/12] ALSA: vsnd: Introduce Xen para-virtualized sound frontend driver

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Introduce skeleton of the para-virtualized Xen sound
frontend driver. This patch only adds required
essential stubs.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 78 +++
 1 file changed, 78 insertions(+)
 create mode 100644 sound/drivers/xen-front.c

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
new file mode 100644
index ..61779c36cae3
--- /dev/null
+++ b/sound/drivers/xen-front.c
@@ -0,0 +1,78 @@
+/*
+ * Xen para-virtual sound device
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ *
+ * Based on: sound/drivers/dummy.c
+ *
+ * Copyright (C) 2016-2017 EPAM Systems Inc.
+ *
+ * Author: Oleksandr Andrushchenko 
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+static void xdrv_be_on_changed(struct xenbus_device *xb_dev,
+   enum xenbus_state backend_state)
+{
+}
+
+static int xdrv_probe(struct xenbus_device *xb_dev,
+   const struct xenbus_device_id *id)
+{
+   return 0;
+}
+
+static int xdrv_remove(struct xenbus_device *dev)
+{
+   return 0;
+}
+
+static const struct xenbus_device_id xdrv_ids[] = {
+   { XENSND_DRIVER_NAME },
+   { "" }
+};
+
+static struct xenbus_driver xen_driver = {
+   .ids = xdrv_ids,
+   .probe = xdrv_probe,
+   .remove = xdrv_remove,
+   .otherend_changed = xdrv_be_on_changed,
+};
+
+static int __init xdrv_init(void)
+{
+   if (!xen_domain())
+   return -ENODEV;
+
+   pr_info("Initialising Xen " XENSND_DRIVER_NAME " frontend driver\n");
+   return xenbus_register_frontend(_driver);
+}
+
+static void __exit xdrv_cleanup(void)
+{
+   pr_info("Unregistering Xen " XENSND_DRIVER_NAME " frontend driver\n");
+   xenbus_unregister_driver(_driver);
+}
+
+module_init(xdrv_init);
+module_exit(xdrv_cleanup);
+
+MODULE_DESCRIPTION("Xen virtual sound device frontend");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("xen:"XENSND_DRIVER_NAME);
+MODULE_SUPPORTED_DEVICE("{{ALSA,Virtual soundcard}}");
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

Resending because of rebase onto [2] + added missing patch

[1] https://xenproject.org/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next

Oleksandr Andrushchenko (12):
  ALSA: vsnd: Introduce Xen para-virtualized sound frontend driver
  ALSA: vsnd: Implement driver's probe/remove
  ALSA: vsnd: Implement Xen bus state handling
  ALSA: vsnd: Read sound driver configuration from Xen store
  ALSA: vsnd: Implement Xen event channel handling
  ALSA: vsnd: Implement handling of shared buffers
  ALSA: vsnd: Introduce ALSA virtual sound driver
  ALSA: vsnd: Initialize virtul sound card
  ALSA: vsnd: Add timer for period interrupt emulation
  ALSA: vsnd: Implement ALSA PCM operations
  ALSA: vsnd: Implement communication with backend
  ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

 sound/drivers/Kconfig |   12 +
 sound/drivers/Makefile|2 +
 sound/drivers/xen-front.c | 2107 +
 3 files changed, 2121 insertions(+)
 create mode 100644 sound/drivers/xen-front.c

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 112496: tolerable trouble: blocked/broken/fail/pass

[osstest service owner]

flight 112496 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112496/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112475
 build-arm64-pvops 2 hosts-allocate  broken like 112475
 build-arm64   2 hosts-allocate  broken like 112475
 build-arm64-xsm   3 capture-logsbroken like 112475
 build-arm64-pvops 3 capture-logsbroken like 112475
 build-arm64   3 capture-logsbroken like 112475
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112447
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112475
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112475
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112475
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112475
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112475
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112475
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112496  2017-08-07 02:01:01 Z0 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  

Re: [Xen-devel] [PATCH RESEND 00/11] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

On 08/07/2017 03:09 PM, Takashi Sakamoto wrote:

Hi,

On Aug 7 2017 20:50, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

Resending because of rebase onto [2]

[1] https://xenproject.org/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next


Oleksandr Andrushchenko (11):
   ALSA: vsnd: Implement driver's probe/remove
   ALSA: vsnd: Implement Xen bus state handling
   ALSA: vsnd: Read sound driver configuration from Xen store
   ALSA: vsnd: Implement Xen event channel handling
   ALSA: vsnd: Implement handling of shared buffers
   ALSA: vsnd: Introduce ALSA virtual sound driver
   ALSA: vsnd: Initialize virtul sound card
   ALSA: vsnd: Add timer for period interrupt emulation
   ALSA: vsnd: Implement ALSA PCM operations
   ALSA: vsnd: Implement communication with backend
   ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

  sound/drivers/Kconfig |   12 +
  sound/drivers/Makefile|2 +
  sound/drivers/xen-front.c | 2029 
+

  3 files changed, 2043 insertions(+)


This patchset is not proper yet.


really sorry for the mess :(
Your first patch includes code difference under line 26, thus it 
expects existence of a file 'sound/drivers/xen-front.c' in tree. 
However, the file is not introduced in any upstream yet; at least, 
Linus's tree and Iwai-san's tree.

I missed the very first patch in the series, this is why, my bad


You still work on your local branch, not for us.


sorry


Regards

Takashi Sakamoto



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND 00/11] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Takashi Sakamoto]

Hi,

On Aug 7 2017 20:50, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

Resending because of rebase onto [2]

[1] https://xenproject.org/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next

Oleksandr Andrushchenko (11):
   ALSA: vsnd: Implement driver's probe/remove
   ALSA: vsnd: Implement Xen bus state handling
   ALSA: vsnd: Read sound driver configuration from Xen store
   ALSA: vsnd: Implement Xen event channel handling
   ALSA: vsnd: Implement handling of shared buffers
   ALSA: vsnd: Introduce ALSA virtual sound driver
   ALSA: vsnd: Initialize virtul sound card
   ALSA: vsnd: Add timer for period interrupt emulation
   ALSA: vsnd: Implement ALSA PCM operations
   ALSA: vsnd: Implement communication with backend
   ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

  sound/drivers/Kconfig |   12 +
  sound/drivers/Makefile|2 +
  sound/drivers/xen-front.c | 2029 +
  3 files changed, 2043 insertions(+)


This patchset is not proper yet.

Your first patch includes code difference under line 26, thus it expects 
existence of a file 'sound/drivers/xen-front.c' in tree. However, the 
file is not introduced in any upstream yet; at least, Linus's tree and 
Iwai-san's tree.


You still work on your local branch, not for us.


Regards

Takashi Sakamoto

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND 10/11] ALSA: vsnd: Implement communication with backend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Implement frontend to backend communication according to
the para-virtualized sound protocol: xen/interface/io/sndif.h.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 302 +++---
 1 file changed, 288 insertions(+), 14 deletions(-)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 7275e9cb38c0..8bfec43ef03a 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -38,6 +38,8 @@
  * because of the fact it is already in use/reserved by the PV console.
  */
 #define GRANT_INVALID_REF  0
+/* timeout in ms to wait for backend to respond */
+#define VSND_WAIT_BACK_MS  3000
 /* maximum number of supported streams */
 #define VSND_MAX_STREAM8
 
@@ -151,10 +153,12 @@ struct xdrv_info {
struct sdev_card_plat_data cfg_plat_data;
 };
 
+static inline void xdrv_evtchnl_flush(struct xdrv_evtchnl_info *channel);
 static inline void sh_buf_clear(struct sh_buf_info *buf);
 static void sh_buf_free(struct sh_buf_info *buf);
 static int sh_buf_alloc(struct xenbus_device *xb_dev, struct sh_buf_info *buf,
unsigned int buffer_size);
+static grant_ref_t sh_buf_get_dir_start(struct sh_buf_info *buf);
 
 static struct sdev_pcm_stream_info *sdrv_stream_get(
struct snd_pcm_substream *substream)
@@ -314,6 +318,234 @@ static void sdrv_copy_pcm_hw(struct snd_pcm_hardware *dst,
}
 }
 
+struct ALSA_SNDIF_SAMPLE_FORMAT {
+   uint8_t sndif;
+   snd_pcm_format_t alsa;
+};
+
+static struct ALSA_SNDIF_SAMPLE_FORMAT alsa_sndif_formats[] = {
+   {
+   .sndif = XENSND_PCM_FORMAT_U8,
+   .alsa = SNDRV_PCM_FORMAT_U8
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S8,
+   .alsa = SNDRV_PCM_FORMAT_S8
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U16_LE,
+   .alsa = SNDRV_PCM_FORMAT_U16_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U16_BE,
+   .alsa = SNDRV_PCM_FORMAT_U16_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S16_LE,
+   .alsa = SNDRV_PCM_FORMAT_S16_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S16_BE,
+   .alsa = SNDRV_PCM_FORMAT_S16_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U24_LE,
+   .alsa = SNDRV_PCM_FORMAT_U24_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U24_BE,
+   .alsa = SNDRV_PCM_FORMAT_U24_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S24_LE,
+   .alsa = SNDRV_PCM_FORMAT_S24_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S24_BE,
+   .alsa = SNDRV_PCM_FORMAT_S24_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U32_LE,
+   .alsa = SNDRV_PCM_FORMAT_U32_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_U32_BE,
+   .alsa = SNDRV_PCM_FORMAT_U32_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S32_LE,
+   .alsa = SNDRV_PCM_FORMAT_S32_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_S32_BE,
+   .alsa = SNDRV_PCM_FORMAT_S32_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_A_LAW,
+   .alsa = SNDRV_PCM_FORMAT_A_LAW
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_MU_LAW,
+   .alsa = SNDRV_PCM_FORMAT_MU_LAW
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_F32_LE,
+   .alsa = SNDRV_PCM_FORMAT_FLOAT_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_F32_BE,
+   .alsa = SNDRV_PCM_FORMAT_FLOAT_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_F64_LE,
+   .alsa = SNDRV_PCM_FORMAT_FLOAT64_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_F64_BE,
+   .alsa = SNDRV_PCM_FORMAT_FLOAT64_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_IEC958_SUBFRAME_LE,
+   .alsa = SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_IEC958_SUBFRAME_BE,
+   .alsa = SNDRV_PCM_FORMAT_IEC958_SUBFRAME_BE
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_IMA_ADPCM,
+   .alsa = SNDRV_PCM_FORMAT_IMA_ADPCM
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_MPEG,
+   .alsa = SNDRV_PCM_FORMAT_MPEG
+   },
+   {
+   .sndif = XENSND_PCM_FORMAT_GSM,
+   .alsa = SNDRV_PCM_FORMAT_GSM
+   },
+};
+
+static int alsa_to_sndif_format(snd_pcm_format_t format)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(alsa_sndif_formats); i++)
+   if (alsa_sndif_formats[i].alsa == format)
+   return alsa_sndif_formats[i].sndif;
+ 

[Xen-devel] [PATCH RESEND 04/11] ALSA: vsnd: Implement Xen event channel handling

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

1. Create event channels for all configured streams and publish
corresponding ring references and event channels in Xen store,
so backend can connect.
2. Implement event channel interrupt handler.
3. Create and destroy event channels with respect to Xen bus state.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 269 +-
 1 file changed, 268 insertions(+), 1 deletion(-)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index ef48cbf44cf2..a92459b2737e 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -24,14 +24,40 @@
 #include 
 
 #include 
+#include 
+#include 
 #include 
 #include 
 
 #include 
 
+/*
+ * FIXME: usage of grant reference 0 as invalid grant reference:
+ * grant reference 0 is valid, but never exposed to a PV driver,
+ * because of the fact it is already in use/reserved by the PV console.
+ */
+#define GRANT_INVALID_REF  0
 /* maximum number of supported streams */
 #define VSND_MAX_STREAM8
 
+enum xdrv_evtchnl_state {
+   EVTCHNL_STATE_DISCONNECTED,
+   EVTCHNL_STATE_CONNECTED,
+};
+
+struct xdrv_evtchnl_info {
+   struct xdrv_info *drv_info;
+   struct xen_sndif_front_ring ring;
+   int ring_ref;
+   int port;
+   int irq;
+   struct completion completion;
+   enum xdrv_evtchnl_state state;
+   /* latest response status and its corresponding id */
+   int resp_status;
+   uint16_t resp_id;
+};
+
 struct cfg_stream {
int unique_id;
char *xenstore_path;
@@ -65,6 +91,8 @@ struct xdrv_info {
struct xenbus_device *xb_dev;
spinlock_t io_lock;
struct mutex mutex;
+   int num_evt_channels;
+   struct xdrv_evtchnl_info *evt_chnls;
struct sdev_card_plat_data cfg_plat_data;
 };
 
@@ -102,6 +130,244 @@ static struct snd_pcm_hardware sdrv_pcm_hw_default = {
.fifo_size = 0,
 };
 
+static irqreturn_t xdrv_evtchnl_interrupt(int irq, void *dev_id)
+{
+   struct xdrv_evtchnl_info *channel = dev_id;
+   struct xdrv_info *drv_info = channel->drv_info;
+   struct xensnd_resp *resp;
+   RING_IDX i, rp;
+   unsigned long flags;
+
+   spin_lock_irqsave(_info->io_lock, flags);
+   if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED))
+   goto out;
+
+again:
+   rp = channel->ring.sring->rsp_prod;
+   /* ensure we see queued responses up to rp */
+   rmb();
+
+   for (i = channel->ring.rsp_cons; i != rp; i++) {
+   resp = RING_GET_RESPONSE(>ring, i);
+   if (resp->id != channel->resp_id)
+   continue;
+   switch (resp->operation) {
+   case XENSND_OP_OPEN:
+   /* fall through */
+   case XENSND_OP_CLOSE:
+   /* fall through */
+   case XENSND_OP_READ:
+   /* fall through */
+   case XENSND_OP_WRITE:
+   channel->resp_status = resp->status;
+   complete(>completion);
+   break;
+
+   default:
+   dev_err(_info->xb_dev->dev,
+   "Operation %d is not supported\n",
+   resp->operation);
+   break;
+   }
+   }
+
+   channel->ring.rsp_cons = i;
+   if (i != channel->ring.req_prod_pvt) {
+   int more_to_do;
+
+   RING_FINAL_CHECK_FOR_RESPONSES(>ring, more_to_do);
+   if (more_to_do)
+   goto again;
+   } else
+   channel->ring.sring->rsp_event = i + 1;
+
+out:
+   spin_unlock_irqrestore(_info->io_lock, flags);
+   return IRQ_HANDLED;
+}
+
+static inline void xdrv_evtchnl_flush(
+   struct xdrv_evtchnl_info *channel)
+{
+   int notify;
+
+   channel->ring.req_prod_pvt++;
+   RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(>ring, notify);
+   if (notify)
+   notify_remote_via_irq(channel->irq);
+}
+
+static void xdrv_evtchnl_free(struct xdrv_info *drv_info,
+   struct xdrv_evtchnl_info *channel)
+{
+   if (!channel->ring.sring)
+   return;
+
+   channel->state = EVTCHNL_STATE_DISCONNECTED;
+   channel->resp_status = -EIO;
+   complete_all(>completion);
+
+   if (channel->irq)
+   unbind_from_irqhandler(channel->irq, channel);
+   channel->irq = 0;
+
+   if (channel->port)
+   xenbus_free_evtchn(drv_info->xb_dev, channel->port);
+   channel->port = 0;
+
+   if (channel->ring_ref != GRANT_INVALID_REF)
+   gnttab_end_foreign_access(channel->ring_ref, 0,
+   (unsigned long)channel->ring.sring);
+   channel->ring_ref = GRANT_INVALID_REF;
+   

[Xen-devel] [PATCH RESEND 06/11] ALSA: vsnd: Introduce ALSA virtual sound driver

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Implement essential initialization of the sound driver:
- introduce required data structures
- handle driver registration
- handle sound card registration
- register sound driver on backend connection
- remove sound driver on backend disconnect

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 161 +-
 1 file changed, 159 insertions(+), 2 deletions(-)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 04ebc15757f4..f3e3f64f0aa6 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -19,13 +19,14 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -66,6 +67,33 @@ struct sh_buf_info {
size_t vbuffer_sz;
 };
 
+struct sdev_pcm_stream_info {
+   int unique_id;
+   struct snd_pcm_hardware pcm_hw;
+   struct xdrv_evtchnl_info *evt_chnl;
+   bool is_open;
+   uint8_t req_next_id;
+   struct sh_buf_info sh_buf;
+};
+
+struct sdev_pcm_instance_info {
+   struct sdev_card_info *card_info;
+   struct snd_pcm *pcm;
+   struct snd_pcm_hardware pcm_hw;
+   int num_pcm_streams_pb;
+   struct sdev_pcm_stream_info *streams_pb;
+   int num_pcm_streams_cap;
+   struct sdev_pcm_stream_info *streams_cap;
+};
+
+struct sdev_card_info {
+   struct xdrv_info *xdrv_info;
+   struct snd_card *card;
+   struct snd_pcm_hardware pcm_hw;
+   int num_pcm_instances;
+   struct sdev_pcm_instance_info *pcm_instances;
+};
+
 struct cfg_stream {
int unique_id;
char *xenstore_path;
@@ -99,6 +127,8 @@ struct xdrv_info {
struct xenbus_device *xb_dev;
spinlock_t io_lock;
struct mutex mutex;
+   bool sdrv_registered;
+   struct platform_device *sdrv_pdev;
int num_evt_channels;
struct xdrv_evtchnl_info *evt_chnls;
struct sdev_card_plat_data cfg_plat_data;
@@ -138,6 +168,132 @@ static struct snd_pcm_hardware sdrv_pcm_hw_default = {
.fifo_size = 0,
 };
 
+static int sdrv_new_pcm(struct sdev_card_info *card_info,
+   struct cfg_pcm_instance *instance_config,
+   struct sdev_pcm_instance_info *pcm_instance_info)
+{
+   return 0;
+}
+
+static int sdrv_probe(struct platform_device *pdev)
+{
+   struct sdev_card_info *card_info;
+   struct sdev_card_plat_data *platdata;
+   struct snd_card *card;
+   int ret, i;
+
+   platdata = dev_get_platdata(>dev);
+
+   dev_dbg(>dev, "Creating virtual sound card\n");
+
+   ret = snd_card_new(>dev, 0, XENSND_DRIVER_NAME, THIS_MODULE,
+   sizeof(struct sdev_card_info), );
+   if (ret < 0)
+   return ret;
+
+   card_info = card->private_data;
+   card_info->xdrv_info = platdata->xdrv_info;
+   card_info->card = card;
+   card_info->pcm_instances = devm_kcalloc(>dev,
+   platdata->cfg_card.num_pcm_instances,
+   sizeof(struct sdev_pcm_instance_info), GFP_KERNEL);
+   if (!card_info->pcm_instances) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   card_info->num_pcm_instances = platdata->cfg_card.num_pcm_instances;
+   card_info->pcm_hw = platdata->cfg_card.pcm_hw;
+
+   for (i = 0; i < platdata->cfg_card.num_pcm_instances; i++) {
+   ret = sdrv_new_pcm(card_info,
+   >cfg_card.pcm_instances[i],
+   _info->pcm_instances[i]);
+   if (ret < 0)
+   goto fail;
+   }
+
+   strncpy(card->driver, XENSND_DRIVER_NAME, sizeof(card->driver));
+   strncpy(card->shortname, platdata->cfg_card.name_short,
+   sizeof(card->shortname));
+   strncpy(card->longname, platdata->cfg_card.name_long,
+   sizeof(card->longname));
+
+   ret = snd_card_register(card);
+   if (ret < 0)
+   goto fail;
+
+   platform_set_drvdata(pdev, card);
+   return 0;
+
+fail:
+   snd_card_free(card);
+   return ret;
+}
+
+static int sdrv_remove(struct platform_device *pdev)
+{
+   struct sdev_card_info *info;
+   struct snd_card *card = platform_get_drvdata(pdev);
+
+   info = card->private_data;
+   dev_dbg(>dev, "Removing virtual sound card %d\n",
+   info->card->number);
+   snd_card_free(card);
+   return 0;
+}
+
+static struct platform_driver sdrv_info = {
+   .probe  = sdrv_probe,
+   .remove = sdrv_remove,
+   .driver = {
+   .name   = XENSND_DRIVER_NAME,
+   },
+};
+
+static void sdrv_cleanup(struct xdrv_info *drv_info)
+{
+   if (!drv_info->sdrv_registered)
+   return;
+
+   if (drv_info->sdrv_pdev) {
+   struct platform_device *sdrv_pdev;
+
+   sdrv_pdev = drv_info->sdrv_pdev;
+   

[Xen-devel] [PATCH RESEND 01/11] ALSA: vsnd: Implement driver's probe/remove

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Add essential driver private info structure, initialize
locks and implement probe/remove of the Xen frontend
driver.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 61779c36cae3..8c5de7b0e7b5 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -26,6 +26,16 @@
 
 #include 
 
+struct xdrv_info {
+   struct xenbus_device *xb_dev;
+   spinlock_t io_lock;
+   struct mutex mutex;
+};
+
+static void xdrv_remove_internal(struct xdrv_info *drv_info)
+{
+}
+
 static void xdrv_be_on_changed(struct xenbus_device *xb_dev,
enum xenbus_state backend_state)
 {
@@ -34,11 +44,28 @@ static void xdrv_be_on_changed(struct xenbus_device *xb_dev,
 static int xdrv_probe(struct xenbus_device *xb_dev,
const struct xenbus_device_id *id)
 {
+   struct xdrv_info *drv_info;
+
+   drv_info = devm_kzalloc(_dev->dev, sizeof(*drv_info), GFP_KERNEL);
+   if (!drv_info) {
+   xenbus_dev_fatal(xb_dev, -ENOMEM, "allocating device memory");
+   return -ENOMEM;
+   }
+
+   drv_info->xb_dev = xb_dev;
+   spin_lock_init(_info->io_lock);
+   mutex_init(_info->mutex);
+   dev_set_drvdata(_dev->dev, drv_info);
return 0;
 }
 
 static int xdrv_remove(struct xenbus_device *dev)
 {
+   struct xdrv_info *drv_info = dev_get_drvdata(>dev);
+
+   mutex_lock(_info->mutex);
+   xdrv_remove_internal(drv_info);
+   mutex_unlock(_info->mutex);
return 0;
 }
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND 02/11] ALSA: vsnd: Implement Xen bus state handling

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Initial handling for Xen bus states: implement
Xen bus state machine for the front driver according to
the state diagram and recovery flow from sound para-virtualized
protocol: xen/interface/io/sndif.h.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 92 +++
 1 file changed, 92 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 8c5de7b0e7b5..c4fd21cac3a7 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -36,9 +36,99 @@ static void xdrv_remove_internal(struct xdrv_info *drv_info)
 {
 }
 
+static int xdrv_be_on_initwait(struct xdrv_info *drv_info)
+{
+   return 0;
+}
+
+static inline int xdrv_be_on_connected(struct xdrv_info *drv_info)
+{
+   return 0;
+}
+
+static inline void xdrv_be_on_disconnected(struct xdrv_info *drv_info)
+{
+   xdrv_remove_internal(drv_info);
+}
+
 static void xdrv_be_on_changed(struct xenbus_device *xb_dev,
enum xenbus_state backend_state)
 {
+   struct xdrv_info *drv_info = dev_get_drvdata(_dev->dev);
+   int ret;
+
+   switch (backend_state) {
+   case XenbusStateReconfiguring:
+   /* fall through */
+   case XenbusStateReconfigured:
+   /* fall through */
+   case XenbusStateInitialised:
+   /* fall through */
+   break;
+
+   case XenbusStateInitialising:
+   if (xb_dev->state == XenbusStateInitialising)
+   break;
+
+   /* recovering after backend unexpected closure */
+   mutex_lock(_info->mutex);
+   xdrv_be_on_disconnected(drv_info);
+   mutex_unlock(_info->mutex);
+   xenbus_switch_state(xb_dev, XenbusStateInitialising);
+   break;
+
+   case XenbusStateInitWait:
+   if (xb_dev->state != XenbusStateInitialising)
+   break;
+
+   mutex_lock(_info->mutex);
+   ret = xdrv_be_on_initwait(drv_info);
+   mutex_unlock(_info->mutex);
+   if (ret < 0) {
+   xenbus_dev_fatal(xb_dev, ret,
+   "initializing " XENSND_DRIVER_NAME);
+   break;
+   }
+
+   xenbus_switch_state(xb_dev, XenbusStateInitialised);
+   break;
+
+   case XenbusStateConnected:
+   if (xb_dev->state != XenbusStateInitialised)
+   break;
+
+   mutex_lock(_info->mutex);
+   ret = xdrv_be_on_connected(drv_info);
+   mutex_unlock(_info->mutex);
+   if (ret < 0) {
+   xenbus_dev_fatal(xb_dev, ret,
+   "connecting " XENSND_DRIVER_NAME);
+   break;
+   }
+
+   xenbus_switch_state(xb_dev, XenbusStateConnected);
+   break;
+
+   case XenbusStateClosing:
+   /*
+* in this state backend starts freeing resources,
+* so let it go into closed state first, so we can also
+* remove ours
+*/
+   break;
+
+   case XenbusStateUnknown:
+   /* fall through */
+   case XenbusStateClosed:
+   if (xb_dev->state == XenbusStateClosed)
+   break;
+
+   mutex_lock(_info->mutex);
+   xdrv_be_on_disconnected(drv_info);
+   mutex_unlock(_info->mutex);
+   xenbus_switch_state(xb_dev, XenbusStateInitialising);
+   break;
+   }
 }
 
 static int xdrv_probe(struct xenbus_device *xb_dev,
@@ -56,6 +146,7 @@ static int xdrv_probe(struct xenbus_device *xb_dev,
spin_lock_init(_info->io_lock);
mutex_init(_info->mutex);
dev_set_drvdata(_dev->dev, drv_info);
+   xenbus_switch_state(xb_dev, XenbusStateInitialising);
return 0;
 }
 
@@ -63,6 +154,7 @@ static int xdrv_remove(struct xenbus_device *dev)
 {
struct xdrv_info *drv_info = dev_get_drvdata(>dev);
 
+   xenbus_switch_state(dev, XenbusStateClosed);
mutex_lock(_info->mutex);
xdrv_remove_internal(drv_info);
mutex_unlock(_info->mutex);
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND 05/11] ALSA: vsnd: Implement handling of shared buffers

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Implement shared buffer handling according to the
para-virtualized sound device protocol at xen/interface/io/sndif.h:
- manage buffer memory
- handle granted references
- handle page directories

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 178 ++
 1 file changed, 178 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index a92459b2737e..04ebc15757f4 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -58,6 +58,14 @@ struct xdrv_evtchnl_info {
uint16_t resp_id;
 };
 
+struct sh_buf_info {
+   int num_grefs;
+   grant_ref_t *grefs;
+   uint8_t *vdirectory;
+   uint8_t *vbuffer;
+   size_t vbuffer_sz;
+};
+
 struct cfg_stream {
int unique_id;
char *xenstore_path;
@@ -825,6 +833,176 @@ static void xdrv_remove_internal(struct xdrv_info 
*drv_info)
xdrv_evtchnl_free_all(drv_info);
 }
 
+static inline grant_ref_t sh_buf_get_dir_start(struct sh_buf_info *buf)
+{
+   if (!buf->grefs)
+   return GRANT_INVALID_REF;
+   return buf->grefs[0];
+}
+
+static inline void sh_buf_clear(struct sh_buf_info *buf)
+{
+   memset(buf, 0, sizeof(*buf));
+}
+
+static void sh_buf_free(struct sh_buf_info *buf)
+{
+   int i;
+
+   if (buf->grefs) {
+   for (i = 0; i < buf->num_grefs; i++)
+   if (buf->grefs[i] != GRANT_INVALID_REF)
+   gnttab_end_foreign_access(buf->grefs[i],
+   0, 0UL);
+   kfree(buf->grefs);
+   }
+   kfree(buf->vdirectory);
+   free_pages_exact(buf->vbuffer, buf->vbuffer_sz);
+   sh_buf_clear(buf);
+}
+
+/*
+ * number of grant references a page can hold with respect to the
+ * xendispl_page_directory header
+ */
+#define XENSND_NUM_GREFS_PER_PAGE ((XEN_PAGE_SIZE - \
+   offsetof(struct xensnd_page_directory, gref)) / \
+   sizeof(grant_ref_t))
+
+static void sh_buf_fill_page_dir(struct sh_buf_info *buf, int num_pages_dir)
+{
+   struct xensnd_page_directory *page_dir;
+   unsigned char *ptr;
+   int i, cur_gref, grefs_left, to_copy;
+
+   ptr = buf->vdirectory;
+   grefs_left = buf->num_grefs - num_pages_dir;
+   /*
+* skip grant references at the beginning, they are for pages granted
+* for the page directory itself
+*/
+   cur_gref = num_pages_dir;
+   for (i = 0; i < num_pages_dir; i++) {
+   page_dir = (struct xensnd_page_directory *)ptr;
+   if (grefs_left <= XENSND_NUM_GREFS_PER_PAGE) {
+   to_copy = grefs_left;
+   page_dir->gref_dir_next_page = GRANT_INVALID_REF;
+   } else {
+   to_copy = XENSND_NUM_GREFS_PER_PAGE;
+   page_dir->gref_dir_next_page = buf->grefs[i + 1];
+   }
+   memcpy(_dir->gref, >grefs[cur_gref],
+   to_copy * sizeof(grant_ref_t));
+   ptr += XEN_PAGE_SIZE;
+   grefs_left -= to_copy;
+   cur_gref += to_copy;
+   }
+}
+
+static int sh_buf_grant_refs(struct xenbus_device *xb_dev,
+   struct sh_buf_info *buf,
+   int num_pages_dir, int num_pages_vbuffer, int num_grefs)
+{
+   grant_ref_t priv_gref_head;
+   int ret, i, j, cur_ref;
+   int otherend_id;
+
+   ret = gnttab_alloc_grant_references(num_grefs, _gref_head);
+   if (ret)
+   return ret;
+
+   buf->num_grefs = num_grefs;
+   otherend_id = xb_dev->otherend_id;
+   j = 0;
+
+   for (i = 0; i < num_pages_dir; i++) {
+   cur_ref = gnttab_claim_grant_reference(_gref_head);
+   if (cur_ref < 0) {
+   ret = cur_ref;
+   goto fail;
+   }
+
+   gnttab_grant_foreign_access_ref(cur_ref, otherend_id,
+   xen_page_to_gfn(virt_to_page(buf->vdirectory +
+   XEN_PAGE_SIZE * i)), 0);
+   buf->grefs[j++] = cur_ref;
+   }
+
+   for (i = 0; i < num_pages_vbuffer; i++) {
+   cur_ref = gnttab_claim_grant_reference(_gref_head);
+   if (cur_ref < 0) {
+   ret = cur_ref;
+   goto fail;
+   }
+
+   gnttab_grant_foreign_access_ref(cur_ref, otherend_id,
+   xen_page_to_gfn(virt_to_page(buf->vbuffer +
+   XEN_PAGE_SIZE * i)), 0);
+   buf->grefs[j++] = cur_ref;
+   }
+
+   gnttab_free_grant_references(priv_gref_head);
+   sh_buf_fill_page_dir(buf, num_pages_dir);
+   return 0;
+
+fail:
+   gnttab_free_grant_references(priv_gref_head);
+   return ret;
+}
+
+static int 

[Xen-devel] [PATCH RESEND 07/11] ALSA: vsnd: Initialize virtul sound card

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Initialize virtual sound card with streams according to the
Xen store configuration.
Add stubs for stream PCM operations.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 232 ++
 1 file changed, 232 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index f3e3f64f0aa6..9f31e6832086 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -134,6 +134,129 @@ struct xdrv_info {
struct sdev_card_plat_data cfg_plat_data;
 };
 
+static struct sdev_pcm_stream_info *sdrv_stream_get(
+   struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream;
+
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+   stream = _instance->streams_pb[substream->number];
+   else
+   stream = _instance->streams_cap[substream->number];
+   return stream;
+}
+
+static void sdrv_copy_pcm_hw(struct snd_pcm_hardware *dst,
+   struct snd_pcm_hardware *src,
+   struct snd_pcm_hardware *ref_pcm_hw)
+{
+   *dst = *ref_pcm_hw;
+
+   if (src->formats)
+   dst->formats = src->formats;
+   if (src->buffer_bytes_max)
+   dst->buffer_bytes_max =
+   src->buffer_bytes_max;
+   if (src->period_bytes_min)
+   dst->period_bytes_min =
+   src->period_bytes_min;
+   if (src->period_bytes_max)
+   dst->period_bytes_max =
+   src->period_bytes_max;
+   if (src->periods_min)
+   dst->periods_min = src->periods_min;
+   if (src->periods_max)
+   dst->periods_max = src->periods_max;
+   if (src->rates)
+   dst->rates = src->rates;
+   if (src->rate_min)
+   dst->rate_min = src->rate_min;
+   if (src->rate_max)
+   dst->rate_max = src->rate_max;
+   if (src->channels_min)
+   dst->channels_min = src->channels_min;
+   if (src->channels_max)
+   dst->channels_max = src->channels_max;
+   if (src->buffer_bytes_max) {
+   dst->buffer_bytes_max = src->buffer_bytes_max;
+   dst->period_bytes_max = src->buffer_bytes_max /
+   src->periods_max;
+   dst->periods_max = dst->buffer_bytes_max /
+   dst->period_bytes_max;
+   }
+}
+
+static int sdrv_alsa_open(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_close(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   return 0;
+}
+
+static int sdrv_alsa_hw_free(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_prepare(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_trigger(struct snd_pcm_substream *substream, int cmd)
+{
+   return 0;
+}
+
+static inline snd_pcm_uframes_t sdrv_alsa_pointer(
+   struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+static int sdrv_alsa_playback_copy_user(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, void __user *buf,
+   unsigned long bytes)
+{
+   return 0;
+}
+
+static int sdrv_alsa_playback_copy_kernel(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, void *buf, unsigned long bytes)
+{
+   return 0;
+}
+
+static int sdrv_alsa_capture_copy_user(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, void __user *buf,
+   unsigned long bytes)
+{
+   return 0;
+}
+
+static int sdrv_alsa_capture_copy_kernel(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, void *buf, unsigned long bytes)
+{
+   return 0;
+}
+
+static int sdrv_alsa_playback_fill_silence(struct snd_pcm_substream *substream,
+   int channel, unsigned long pos, unsigned long bytes)
+{
+   return 0;
+}
+
 #define MAX_XEN_BUFFER_SIZE(64 * 1024)
 #define MAX_BUFFER_SIZEMAX_XEN_BUFFER_SIZE
 #define MIN_PERIOD_SIZE64
@@ -168,10 +291,119 @@ static struct snd_pcm_hardware sdrv_pcm_hw_default = {
.fifo_size = 0,
 };
 
+/*
+ * FIXME: The mmaped data transfer is asynchronous and there is no
+ * ack signal from user-space when it is done. This is the
+ * reason it is not implemented in the PV driver as we do need
+ * to know when the buffer can be transferred to the backend.
+ */
+
+static struct snd_pcm_ops sdrv_alsa_playback_ops = {
+   .open = sdrv_alsa_open,
+   .close = sdrv_alsa_close,
+   .ioctl = snd_pcm_lib_ioctl,
+   

[Xen-devel] [PATCH RESEND 00/11] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

Resending because of rebase onto [2]

[1] https://xenproject.org/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next

Oleksandr Andrushchenko (11):
  ALSA: vsnd: Implement driver's probe/remove
  ALSA: vsnd: Implement Xen bus state handling
  ALSA: vsnd: Read sound driver configuration from Xen store
  ALSA: vsnd: Implement Xen event channel handling
  ALSA: vsnd: Implement handling of shared buffers
  ALSA: vsnd: Introduce ALSA virtual sound driver
  ALSA: vsnd: Initialize virtul sound card
  ALSA: vsnd: Add timer for period interrupt emulation
  ALSA: vsnd: Implement ALSA PCM operations
  ALSA: vsnd: Implement communication with backend
  ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

 sound/drivers/Kconfig |   12 +
 sound/drivers/Makefile|2 +
 sound/drivers/xen-front.c | 2029 +
 3 files changed, 2043 insertions(+)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Front sound driver has no real interrupts, so
playback/capture period passed interrupt needs to be emulated:
this is done via timer. Add required timer operations,
this is based on sound/drivers/dummy.c.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 121 ++
 1 file changed, 121 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 9f31e6832086..507c5eb343c8 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -67,12 +67,29 @@ struct sh_buf_info {
size_t vbuffer_sz;
 };
 
+struct sdev_alsa_timer_info {
+   spinlock_t lock;
+   struct timer_list timer;
+   unsigned long base_time;
+   /* fractional sample position (based HZ) */
+   unsigned int frac_pos;
+   unsigned int frac_period_rest;
+   /* buffer_size * HZ */
+   unsigned int frac_buffer_size;
+   /* period_size * HZ */
+   unsigned int frac_period_size;
+   unsigned int rate;
+   int elapsed;
+   struct snd_pcm_substream *substream;
+};
+
 struct sdev_pcm_stream_info {
int unique_id;
struct snd_pcm_hardware pcm_hw;
struct xdrv_evtchnl_info *evt_chnl;
bool is_open;
uint8_t req_next_id;
+   struct sdev_alsa_timer_info timer;
struct sh_buf_info sh_buf;
 };
 
@@ -148,6 +165,110 @@ static struct sdev_pcm_stream_info *sdrv_stream_get(
return stream;
 }
 
+static inline void sdrv_alsa_timer_rearm(struct sdev_alsa_timer_info *dpcm)
+{
+   mod_timer(>timer, jiffies +
+   (dpcm->frac_period_rest + dpcm->rate - 1) / dpcm->rate);
+}
+
+static void sdrv_alsa_timer_update(struct sdev_alsa_timer_info *dpcm)
+{
+   unsigned long delta;
+
+   delta = jiffies - dpcm->base_time;
+   if (!delta)
+   return;
+   dpcm->base_time += delta;
+   delta *= dpcm->rate;
+   dpcm->frac_pos += delta;
+   while (dpcm->frac_pos >= dpcm->frac_buffer_size)
+   dpcm->frac_pos -= dpcm->frac_buffer_size;
+   while (dpcm->frac_period_rest <= delta) {
+   dpcm->elapsed++;
+   dpcm->frac_period_rest += dpcm->frac_period_size;
+   }
+   dpcm->frac_period_rest -= delta;
+}
+
+static int sdrv_alsa_timer_start(struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+
+   spin_lock(>lock);
+   dpcm->base_time = jiffies;
+   sdrv_alsa_timer_rearm(dpcm);
+   spin_unlock(>lock);
+   return 0;
+}
+
+static int sdrv_alsa_timer_stop(struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+
+   spin_lock(>lock);
+   del_timer(>timer);
+   spin_unlock(>lock);
+   return 0;
+}
+
+static int sdrv_alsa_timer_prepare(struct snd_pcm_substream *substream)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+
+   dpcm->frac_pos = 0;
+   dpcm->rate = runtime->rate;
+   dpcm->frac_buffer_size = runtime->buffer_size * HZ;
+   dpcm->frac_period_size = runtime->period_size * HZ;
+   dpcm->frac_period_rest = dpcm->frac_period_size;
+   dpcm->elapsed = 0;
+   return 0;
+}
+
+static void sdrv_alsa_timer_callback(unsigned long data)
+{
+   struct sdev_alsa_timer_info *dpcm = (struct sdev_alsa_timer_info *)data;
+   int elapsed;
+
+   spin_lock(>lock);
+   sdrv_alsa_timer_update(dpcm);
+   sdrv_alsa_timer_rearm(dpcm);
+   elapsed = dpcm->elapsed;
+   dpcm->elapsed = 0;
+   spin_unlock(>lock);
+   if (elapsed)
+   snd_pcm_period_elapsed(dpcm->substream);
+}
+
+static snd_pcm_uframes_t sdrv_alsa_timer_pointer(
+   struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+   snd_pcm_uframes_t pos;
+
+   spin_lock(>lock);
+   sdrv_alsa_timer_update(dpcm);
+   pos = dpcm->frac_pos / HZ;
+   spin_unlock(>lock);
+   return pos;
+}
+
+static int sdrv_alsa_timer_create(struct snd_pcm_substream *substream)
+{
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct sdev_alsa_timer_info *dpcm = >timer;
+
+   spin_lock_init(>lock);
+   dpcm->substream = substream;
+   setup_timer(>timer, sdrv_alsa_timer_callback,
+   (unsigned long) dpcm);
+   return 0;
+}
+
 static void sdrv_copy_pcm_hw(struct snd_pcm_hardware *dst,
struct snd_pcm_hardware *src,
struct snd_pcm_hardware *ref_pcm_hw)
-- 
2.7.4

[Xen-devel] [PATCH RESEND 03/11] ALSA: vsnd: Read sound driver configuration from Xen store

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Read configuration values from Xen store according
to xen/interface/io/sndif.h protocol:
- introduce configuration structures for different
  components, e.g. sound card, device, stream
- read PCM HW parameters, e.g rate, format etc.
- detect stream type (capture/playback)
- read device and card parameters

Fill in platform data with the configuration read, so
it can be passed to sound driver later.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 530 ++
 1 file changed, 530 insertions(+)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index c4fd21cac3a7..ef48cbf44cf2 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -20,24 +20,554 @@
 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
 
 #include 
 
+/* maximum number of supported streams */
+#define VSND_MAX_STREAM8
+
+struct cfg_stream {
+   int unique_id;
+   char *xenstore_path;
+   struct snd_pcm_hardware pcm_hw;
+};
+
+struct cfg_pcm_instance {
+   char name[80];
+   int device_id;
+   struct snd_pcm_hardware pcm_hw;
+   int  num_streams_pb;
+   struct cfg_stream *streams_pb;
+   int  num_streams_cap;
+   struct cfg_stream *streams_cap;
+};
+
+struct cfg_card {
+   char name_short[32];
+   char name_long[80];
+   struct snd_pcm_hardware pcm_hw;
+   int num_pcm_instances;
+   struct cfg_pcm_instance *pcm_instances;
+};
+
+struct sdev_card_plat_data {
+   struct xdrv_info *xdrv_info;
+   struct cfg_card cfg_card;
+};
+
 struct xdrv_info {
struct xenbus_device *xb_dev;
spinlock_t io_lock;
struct mutex mutex;
+   struct sdev_card_plat_data cfg_plat_data;
 };
 
+#define MAX_XEN_BUFFER_SIZE(64 * 1024)
+#define MAX_BUFFER_SIZEMAX_XEN_BUFFER_SIZE
+#define MIN_PERIOD_SIZE64
+#define MAX_PERIOD_SIZE(MAX_BUFFER_SIZE / 8)
+#define USE_FORMATS(SNDRV_PCM_FMTBIT_U8 | \
+SNDRV_PCM_FMTBIT_S16_LE)
+#define USE_RATE   (SNDRV_PCM_RATE_CONTINUOUS | \
+SNDRV_PCM_RATE_8000_48000)
+#define USE_RATE_MIN   5512
+#define USE_RATE_MAX   48000
+#define USE_CHANNELS_MIN   1
+#define USE_CHANNELS_MAX   2
+#define USE_PERIODS_MIN2
+#define USE_PERIODS_MAX8
+
+static struct snd_pcm_hardware sdrv_pcm_hw_default = {
+   .info = (SNDRV_PCM_INFO_MMAP |
+SNDRV_PCM_INFO_INTERLEAVED |
+SNDRV_PCM_INFO_RESUME |
+SNDRV_PCM_INFO_MMAP_VALID),
+   .formats = USE_FORMATS,
+   .rates = USE_RATE,
+   .rate_min = USE_RATE_MIN,
+   .rate_max = USE_RATE_MAX,
+   .channels_min = USE_CHANNELS_MIN,
+   .channels_max = USE_CHANNELS_MAX,
+   .buffer_bytes_max = MAX_BUFFER_SIZE,
+   .period_bytes_min = MIN_PERIOD_SIZE,
+   .period_bytes_max = MAX_PERIOD_SIZE,
+   .periods_min = USE_PERIODS_MIN,
+   .periods_max = USE_PERIODS_MAX,
+   .fifo_size = 0,
+};
+
+struct CFG_HW_SAMPLE_RATE {
+   const char *name;
+   unsigned int mask;
+   unsigned int value;
+};
+
+static struct CFG_HW_SAMPLE_RATE cfg_hw_supported_rates[] = {
+   { .name = "5512",   .mask = SNDRV_PCM_RATE_5512,   .value = 5512 },
+   { .name = "8000",   .mask = SNDRV_PCM_RATE_8000,   .value = 8000 },
+   { .name = "11025",  .mask = SNDRV_PCM_RATE_11025,  .value = 11025 },
+   { .name = "16000",  .mask = SNDRV_PCM_RATE_16000,  .value = 16000 },
+   { .name = "22050",  .mask = SNDRV_PCM_RATE_22050,  .value = 22050 },
+   { .name = "32000",  .mask = SNDRV_PCM_RATE_32000,  .value = 32000 },
+   { .name = "44100",  .mask = SNDRV_PCM_RATE_44100,  .value = 44100 },
+   { .name = "48000",  .mask = SNDRV_PCM_RATE_48000,  .value = 48000 },
+   { .name = "64000",  .mask = SNDRV_PCM_RATE_64000,  .value = 64000 },
+   { .name = "96000",  .mask = SNDRV_PCM_RATE_96000,  .value = 96000 },
+   { .name = "176400", .mask = SNDRV_PCM_RATE_176400, .value = 176400 },
+   { .name = "192000", .mask = SNDRV_PCM_RATE_192000, .value = 192000 },
+};
+
+struct CFG_HW_SAMPLE_FORMAT {
+   const char *name;
+   u64 mask;
+};
+
+static struct CFG_HW_SAMPLE_FORMAT cfg_hw_supported_formats[] = {
+   {
+   .name = XENSND_PCM_FORMAT_U8_STR,
+   .mask = SNDRV_PCM_FMTBIT_U8
+   },
+   {
+   .name = XENSND_PCM_FORMAT_S8_STR,
+   .mask = SNDRV_PCM_FMTBIT_S8
+   },
+   {
+   .name = XENSND_PCM_FORMAT_U16_LE_STR,
+   .mask = SNDRV_PCM_FMTBIT_U16_LE
+   },
+   {
+   .name = XENSND_PCM_FORMAT_U16_BE_STR,
+   .mask = SNDRV_PCM_FMTBIT_U16_BE
+   },
+   {
+

[Xen-devel] [PATCH RESEND 09/11] ALSA: vsnd: Implement ALSA PCM operations

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Implement ALSA driver operations including:
- start/stop period interrupt emulation
- manage frontend/backend shraed buffers
- manage Xen bus event channel state

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/xen-front.c | 175 ++
 1 file changed, 163 insertions(+), 12 deletions(-)

diff --git a/sound/drivers/xen-front.c b/sound/drivers/xen-front.c
index 507c5eb343c8..7275e9cb38c0 100644
--- a/sound/drivers/xen-front.c
+++ b/sound/drivers/xen-front.c
@@ -151,6 +151,11 @@ struct xdrv_info {
struct sdev_card_plat_data cfg_plat_data;
 };
 
+static inline void sh_buf_clear(struct sh_buf_info *buf);
+static void sh_buf_free(struct sh_buf_info *buf);
+static int sh_buf_alloc(struct xenbus_device *xb_dev, struct sh_buf_info *buf,
+   unsigned int buffer_size);
+
 static struct sdev_pcm_stream_info *sdrv_stream_get(
struct snd_pcm_substream *substream)
 {
@@ -311,71 +316,217 @@ static void sdrv_copy_pcm_hw(struct snd_pcm_hardware 
*dst,
 
 static int sdrv_alsa_open(struct snd_pcm_substream *substream)
 {
-   return 0;
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct xdrv_info *xdrv_info;
+   unsigned long flags;
+   int ret;
+
+   sdrv_copy_pcm_hw(>hw, >pcm_hw, _instance->pcm_hw);
+   runtime->hw.info &= ~(SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID |
+   SNDRV_PCM_INFO_DOUBLE |
+   SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_NONINTERLEAVED |
+   SNDRV_PCM_INFO_RESUME |
+   SNDRV_PCM_INFO_PAUSE);
+   runtime->hw.info |= SNDRV_PCM_INFO_INTERLEAVED;
+
+   xdrv_info = pcm_instance->card_info->xdrv_info;
+
+   ret = sdrv_alsa_timer_create(substream);
+
+   spin_lock_irqsave(_info->io_lock, flags);
+   sh_buf_clear(>sh_buf);
+   stream->evt_chnl = _info->evt_chnls[stream->unique_id];
+   if (ret < 0)
+   stream->evt_chnl->state = EVTCHNL_STATE_DISCONNECTED;
+   else
+   stream->evt_chnl->state = EVTCHNL_STATE_CONNECTED;
+   spin_unlock_irqrestore(_info->io_lock, flags);
+   return ret;
 }
 
 static int sdrv_alsa_close(struct snd_pcm_substream *substream)
 {
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct xdrv_info *xdrv_info;
+   unsigned long flags;
+
+   xdrv_info = pcm_instance->card_info->xdrv_info;
+
+   sdrv_alsa_timer_stop(substream);
+
+   spin_lock_irqsave(_info->io_lock, flags);
+   stream->evt_chnl->state = EVTCHNL_STATE_DISCONNECTED;
+   spin_unlock_irqrestore(_info->io_lock, flags);
return 0;
 }
 
 static int sdrv_alsa_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
 {
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct xdrv_info *xdrv_info;
+   unsigned int buffer_size;
+   int ret;
+
+   buffer_size = params_buffer_bytes(params);
+   sh_buf_clear(>sh_buf);
+   xdrv_info = pcm_instance->card_info->xdrv_info;
+   ret = sh_buf_alloc(xdrv_info->xb_dev,
+   >sh_buf, buffer_size);
+   if (ret < 0)
+   goto fail;
return 0;
+
+fail:
+   dev_err(_info->xb_dev->dev,
+   "Failed to allocate buffers for stream idx %d\n",
+   stream->unique_id);
+   return ret;
 }
 
 static int sdrv_alsa_hw_free(struct snd_pcm_substream *substream)
 {
+   struct sdev_pcm_instance_info *pcm_instance =
+   snd_pcm_substream_chip(substream);
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   struct xdrv_info *xdrv_info;
+   unsigned long flags;
+
+   xdrv_info = pcm_instance->card_info->xdrv_info;
+   spin_lock_irqsave(_info->io_lock, flags);
+   sh_buf_free(>sh_buf);
+   spin_unlock_irqrestore(_info->io_lock, flags);
return 0;
 }
 
 static int sdrv_alsa_prepare(struct snd_pcm_substream *substream)
 {
-   return 0;
+   struct sdev_pcm_stream_info *stream = sdrv_stream_get(substream);
+   int ret = 0;
+
+   if (!stream->is_open)
+   ret = sdrv_alsa_timer_prepare(substream);
+   return ret;
 }
 
 static int sdrv_alsa_trigger(struct snd_pcm_substream *substream, int cmd)
 {
+   switch (cmd) {
+   case SNDRV_PCM_TRIGGER_START:
+   /* fall through */
+   case SNDRV_PCM_TRIGGER_RESUME:
+   return 

[Xen-devel] [PATCH RESEND 11/11] ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Introduce Kconfig option to enable Xen para-virtualized sound
frontend driver. Also add sound frontend to the Makefile.

Signed-off-by: Oleksandr Andrushchenko 
---
 sound/drivers/Kconfig  | 12 
 sound/drivers/Makefile |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig
index 7144cc36e8ae..6b8fa6110ca3 100644
--- a/sound/drivers/Kconfig
+++ b/sound/drivers/Kconfig
@@ -235,4 +235,16 @@ config SND_AC97_POWER_SAVE_DEFAULT
 
  See SND_AC97_POWER_SAVE for more details.
 
+config SND_XEN_FRONTEND
+   tristate "Xen virtual sound front-end driver"
+   depends on SND_PCM && XEN
+   select XEN_XENBUS_FRONTEND
+   default n
+   help
+ This driver implements a front-end for the Xen
+ para-virtualized sound.
+
+ To compile this driver as a module, choose M here: the module
+ will be called snd-xen-front.
+
 endif  # SND_DRIVERS
diff --git a/sound/drivers/Makefile b/sound/drivers/Makefile
index 1a8440c8b138..70ed920a030f 100644
--- a/sound/drivers/Makefile
+++ b/sound/drivers/Makefile
@@ -11,6 +11,7 @@ snd-portman2x4-objs := portman2x4.o
 snd-serial-u16550-objs := serial-u16550.o
 snd-virmidi-objs := virmidi.o
 snd-ml403-ac97cr-objs := ml403-ac97cr.o pcm-indirect2.o
+snd-xen-front-objs := xen-front.o
 
 # Toplevel Module Dependency
 obj-$(CONFIG_SND_DUMMY) += snd-dummy.o
@@ -21,5 +22,6 @@ obj-$(CONFIG_SND_MTPAV) += snd-mtpav.o
 obj-$(CONFIG_SND_MTS64) += snd-mts64.o
 obj-$(CONFIG_SND_PORTMAN2X4) += snd-portman2x4.o
 obj-$(CONFIG_SND_ML403_AC97CR) += snd-ml403-ac97cr.o
+obj-$(CONFIG_SND_XEN_FRONTEND) += snd-xen-front.o
 
 obj-$(CONFIG_SND) += opl3/ opl4/ mpu401/ vx/ pcsp/
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/11] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Takashi Sakamoto]

Hi,

On Aug 7 2017 16:43, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

[1] https://xenproject.org/

Oleksandr Andrushchenko (11):
   ALSA: vsnd: Implement driver's probe/remove
   ALSA: vsnd: Implement Xen bus state handling
   ALSA: vsnd: Read sound driver configuration from Xen store
   ALSA: vsnd: Implement Xen event channel handling
   ALSA: vsnd: Implement handling of shared buffers
   ALSA: vsnd: Introduce ALSA virtual sound driver
   ALSA: vsnd: Initialize virtul sound card
   ALSA: vsnd: Add timer for period interrupt emulation
   ALSA: vsnd: Implement ALSA PCM operations
   ALSA: vsnd: Implement communication with backend
   ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

  sound/drivers/Kconfig |   12 +
  sound/drivers/Makefile|2 +
  sound/drivers/xen-front.c | 2029 +
  3 files changed, 2043 insertions(+)


As a quick glance of your first patch, it's apparently based on your 
local working branch. I'd like you to post patchset again, which were 
rebased on current upstream[1], so that code reviewers can do their work.


[1] 'for-next' branch in Iwai-san's tree
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next


Regards

Takashi Sakamoto

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/11] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

Hi,

On 08/07/2017 02:28 PM, Takashi Sakamoto wrote:

Hi,

On Aug 7 2017 16:43, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

[1] https://xenproject.org/

Oleksandr Andrushchenko (11):
   ALSA: vsnd: Implement driver's probe/remove
   ALSA: vsnd: Implement Xen bus state handling
   ALSA: vsnd: Read sound driver configuration from Xen store
   ALSA: vsnd: Implement Xen event channel handling
   ALSA: vsnd: Implement handling of shared buffers
   ALSA: vsnd: Introduce ALSA virtual sound driver
   ALSA: vsnd: Initialize virtul sound card
   ALSA: vsnd: Add timer for period interrupt emulation
   ALSA: vsnd: Implement ALSA PCM operations
   ALSA: vsnd: Implement communication with backend
   ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

  sound/drivers/Kconfig |   12 +
  sound/drivers/Makefile|2 +
  sound/drivers/xen-front.c | 2029 
+

  3 files changed, 2043 insertions(+)


As a quick glance of your first patch, it's apparently based on your 
local working branch. 

sorry about that, I based the changes on v4.13-rc3 kernel sources
I'd like you to post patchset again, which were rebased on current 
upstream[1], so that code reviewers can do their work.

sure, will do that now


[1] 'for-next' branch in Iwai-san's tree
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next 




Regards

Takashi Sakamoto



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Oleksandr Andrushchenko]

Hi, Clemens!

On 08/07/2017 01:27 PM, Clemens Ladisch wrote:

Oleksandr Andrushchenko wrote:

Front sound driver has no real interrupts, so
playback/capture period passed interrupt needs to be emulated:
this is done via timer. Add required timer operations,
this is based on sound/drivers/dummy.c.

A 'real' sound card use the interrupt to synchronize the stream position
between the hardware and the driver.  The hardware triggers an interrupt
immediately after a period has been completely read (for playback) from
the ring buffer by the DMA unit; this tells the driver that it is now
again allowed to write to that part of the buffer.

Yes, I know that, thank you

The dummy driver has no hardware that accesses the buffer, so the period
interrupts are not synchronized to anything.

Exactly

   This is not a suitable
implementation when the samples are actually used.



If you issue interrupts based on the system timer, the position reported
by the .pointer callback and the position where the hardware (backend)
actually accesses the buffer will diverge, which will eventually corrupt
data.

Makes sense, but in my case the buffer from the frontend
is copied into backend's memory, so they don't share the
same buffer as real HW does. But it is still possible that
the new portion of data may arrive and backend will overwrite
the memory which hasn't been played yet because pointers are not
synchronized

You have to implement period interrupts (and the .pointer callback)
based on when the samples are actually moved from/to the backend.

Do you think I can implement this in a slightly different way,
without a timer at all, by updating
substream->runtime->hw_ptr_base explicitly in the frontend driver?
Like it was implemented [1], see virtualcard_pcm_pointer
(unfortunately, that driver didn't make it to the kernel).
So, that way, whenever I get an ack/response from the backend that it has
successfully played the buffer I can update hw_ptr_base at the frontend
and thus be always in sync to the backend.

Regards,
Clemens

Thank you,
Oleksandr

[1] http://marc.info/?l=xen-devel=142185395013970=4

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 112507: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 112507 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112507/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
112402
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 112402

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocatebroken baseline untested
 build-arm64   2 hosts-allocatebroken baseline untested
 build-arm64-pvops 3 capture-logs  broken baseline untested
 build-arm64   3 capture-logs  broken baseline untested
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  32e7db7f6fbb91dac1e4e1bbcab4851c4606e0fa
baseline version:
 xen  b8029db62eb2a06a204a8e2b69437d0927bd1ac4

Last test of basis   112402  2017-07-31 21:02:08 Z6 days
Failing since112418  2017-08-03 11:04:58 Z4 days   41 attempts
Testing same since   112448  2017-08-04 16:01:08 Z2 days   29 attempts


People who touched revisions under test:
  Andrii Anisov 
  He Chen 
  Ian Jackson 
  Iurii Konovalenko 
  Iurii Mykhalskyi 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Marek Marczykowski-Górecki 
  Praveen Kumar 
  Rusty Bird 
  Sergej Proskurin 
  Stefano Stabellini 
  Wei Liu 
  Xiao Liang 
  xiliang 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

(No revision log; it would be 726 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] i am not able to contact betweeen the bootwraooer and rootfile system in foundation model ARMv8 architecture

[Julien Grall]

Please avoid dropping xen-devel...

On 07/08/17 11:52, Raviprasad Gurikar wrote:

hii
i am not able to run the xen on fastmodel...please solve my problem.


I will not be able to help until you provide the details I asked below.

Cheers,



On Mon, Aug 7, 2017 at 4:19 PM, Julien Grall > wrote:



On 04/08/17 07:41, Raviprasad Gurikar wrote:

hi sir


Hello,

 I am student doing project on the arm virtualization using the xen
hypervisor i not able run the xen on the foundation model v8. i have
follow the xen arm crosscompilation and the xen arm
rootfilesystem then
i follwed the xen arm in fastmodel

https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/FastModels


.
please go through the attached document for the running


Please don't attach picture in e-mail sent to mailing list.

Looking at the log, Xen is stuck after enabling paging. Can you
please give the version of bootwrapper and xen you are using?

Cheers,

--
Julien Grall




--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] i am not able to contact betweeen the bootwraooer and rootfile system in foundation model ARMv8 architecture

[Julien Grall]

On 04/08/17 07:41, Raviprasad Gurikar wrote:

hi sir


Hello,


 I am student doing project on the arm virtualization using the xen
hypervisor i not able run the xen on the foundation model v8. i have
follow the xen arm crosscompilation and the xen arm rootfilesystem then
i follwed the xen arm in fastmodel
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/FastModels
.
please go through the attached document for the running


Please don't attach picture in e-mail sent to mailing list.

Looking at the log, Xen is stuck after enabling paging. Can you please 
give the version of bootwrapper and xen you are using?


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Patch for staging 2/2] x86: adjust place of an ASSERT to avoid crash when destroy a domain.

[Wei Liu]

On Mon, Aug 07, 2017 at 11:19:09AM +0100, Wei Liu wrote:
> Can we see about committing this patch as soon as possible? This is
> blocking osstest pushgate.

Andrew prodded me on irc to commit this patch. I have done so, along
with the doc patch.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist

[Julien Grall]

Hi Boris,

I would have appreciated to be CCed as maintainer of the ARM bits... 
Please use scripts/get_maintainers.pl in the future.


On 04/08/17 18:05, Boris Ostrovsky wrote:

. so that it's easy to find pages that need to be scrubbed (those pages are


Pointless .


diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index ef84b72..d26b232 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -44,7 +44,16 @@ struct page_info
 /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
 struct {
 /* Do TLBs need flushing for safety before next page use? */
-bool_t need_tlbflush;
+unsigned long need_tlbflush:1;


You've turned need_tlbflush from bool to unsigned long : 1. But some of 
the users use true/false or may rely on the boolean property.  So it 
sounds like to me you want to use bool bitfields here (and in the x86 part).



+
+/*
+ * Index of the first *possibly* unscrubbed page in the buddy.
+ * One more than maximum possible order to accommodate
+ * INVALID_DIRTY_IDX.
+ */
+#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
+unsigned long first_dirty:MAX_ORDER + 1;


We need to make sure that this union will not be bigger than unsigned 
long. Otherwise this will limit lower down the maximum amount of memory 
we support.

So this likely means a BUILD_BUG_ON().

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Clemens Ladisch]

Oleksandr Andrushchenko wrote:
> Front sound driver has no real interrupts, so
> playback/capture period passed interrupt needs to be emulated:
> this is done via timer. Add required timer operations,
> this is based on sound/drivers/dummy.c.

A 'real' sound card use the interrupt to synchronize the stream position
between the hardware and the driver.  The hardware triggers an interrupt
immediately after a period has been completely read (for playback) from
the ring buffer by the DMA unit; this tells the driver that it is now
again allowed to write to that part of the buffer.

The dummy driver has no hardware that accesses the buffer, so the period
interrupts are not synchronized to anything.  This is not a suitable
implementation when the samples are actually used.

If you issue interrupts based on the system timer, the position reported
by the .pointer callback and the position where the hardware (backend)
actually accesses the buffer will diverge, which will eventually corrupt
data.

You have to implement period interrupts (and the .pointer callback)
based on when the samples are actually moved from/to the backend.


Regards,
Clemens

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Is:livepatch-build-tools.git declare it supported? Was:Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature

[George Dunlap]

On 08/06/2017 01:07 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 03, 2017 at 06:21:30PM +0100, George Dunlap wrote:
>> On 08/03/2017 06:20 PM, George Dunlap wrote:
>>> On 07/03/2017 03:53 PM, Ross Lagerwall wrote:
 On 06/30/2017 02:42 PM, George Dunlap wrote:
> On 06/28/2017 05:18 PM, Ross Lagerwall wrote:
>> On 06/27/2017 10:17 AM, George Dunlap wrote:
>>> On 26/06/17 18:30, Andrew Cooper wrote:
 On 26/06/17 18:00, George Dunlap wrote:
> On 26/06/17 16:36, Ross Lagerwall wrote:
>> ...
>>> You seem to be simply refusing to use your imagination.  Step back.
>>> Imagine yourself in one year.  You come to the office and find an
>>> e-mail
>>> on security@ which says, "Livepatch tools open a security hole when
>>> compiling with gcc x.yy".  You realize that XenVerson ${LATEST-2} uses
>>> gcc x.yy, so you take a closer look at that livepatch, only to discover
>>> that the livepatches generated actually do contain the bug, but you
>>> missed it because ${LATEST-[0,1]} were perfectly fine (since they used
>>> newer versions of gcc), the difference was subtle, and it passed all
>>> the
>>> functional tests.
>>>
>>> Now all of the customers that have applied those patches are
>>> vulnerable.
>>>
>>> Do you:
>>>
>>> 1. Tell the reporter to post it publicly to xen-devel immediately,
>>> since
>>> livepatch tools are not security supported -- thus "zero-day"-ing all
>>> your customers (as well as anyone else who happens to have used x.yy to
>>> build a hypervisor)?
>>>
>>> 2. Secretly take advantage of Citrix' privileged position on the
>>> security list, and try to get an update out to your customers before it
>>> gets announced (but allowing everyone *else* using gcc x.yy to
>>> experience a zero-day)?
>>>
>>> 3. Issue an XSA so that everyone has the opportunity to fix things up
>>> before making a public announcement, and so that anyone not on the
>>> embargo list gets an alert, so they know to either update their own
>>> livepatches, or look for updates from their software provider?
>>>
>>> I think #3 is the only possible choice.
>>>
>>>-George
>>>
>>
>> The issue here is that any bug in livepatch-build-tools which still
>> results in output being generated would be a security issue, because
>> someone might have used it to patch a security issue.
>> livepatch-build-tools is certainly not stable enough yet (ever?) to be
>> treated in this fashion.
>
> You didn't answer my question.  If the situation described happens, what
> position do you want Andrew to be put in?  (If I missed a potential
> action, let me know.)
>

 I would choose #3 as it is the obvious choice. But I still don't think
 it is a sensible idea to have security support for the build tools, at
 least at this point. The same scenario could be posed for a nasty bug
 that affects Xen 4.4 only, but it is now just out of security support.
 IMO something being not supported doesn't preclude it from having an XSA
 released if there is a particularly nasty vulnerability found.
>>>
>>> Well basically I think we agree, but we're using different terms.  You
>>> want to say, "This isn't security supported, but if important bug is
>>> actually found then we'll issue an XSA".  I want to say, "This is
>>> security supported, because if an important bug is actually found we'll
>>> issue an XSA."
>>>
>>> So it seems to me there are likely two things that make you resistant to
>>> calling it "security supported":
>>>
>>> 1. The fear that we'll be issuing XSAs over trivial things that don't matter
>>>
>>> 2. The fear that people will not do due diligence when creating patches
>>> with the tools.
>>>
>>> I think #1 is just a misconception.  *Every* bug reported to us about
>>> any part of the code we go through the process of trying to determine
>>> its impact and whether we need to issue an XSA or not.  All of the
>>> examples put forward of things we don't want to issue an XSA for are
>>> things that I'm sure we would not issue an XSA for.
>>>
>>> For #2, that is a reasonable fear, but we can deal with that in a
>>> different way than calling the tools "unsupported".  We can, for
>>> instance, mention that in the documents.  We can add a warning message
>>> that the build tools output saying that the result should be manually
>>> inspected for correctness.
>>
>> We need to get a resolution on this.  Anyone else (particarly
>> committers) want to give their opinion?
> 
> Changing title as this is all about now livepatch-build-tools.
> 
> The livepatch-build-tools get a lot of usage around XSA times.
> And that is when the corner cases are being found. The three of them:
> 0c10457 Remove section alignment requirement
> b30d34c Ignore .discard sections
> 6327ab9 create-diff-object: Update fixup offsets in 

Re: [Xen-devel] [Patch for staging 2/2] x86: adjust place of an ASSERT to avoid crash when destroy a domain.

[Wei Liu]

Can we see about committing this patch as soon as possible? This is
blocking osstest pushgate.

On Mon, Aug 07, 2017 at 09:50:49AM +0800, Yi Sun wrote:
> In 'psr_free_cos', we should not use 'ASSERT(socket_info)' at the beginning
> because the 'socket_info' is allocated only if 'psr' boot parameter is set.
> So adjust its place to avoid crash.
> 
> Signed-off-by: Yi Sun 
> ---
>  xen/arch/x86/psr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index 7d9fa26..9ce8f17 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -1294,11 +1294,11 @@ static void psr_free_cos(struct domain *d)
>  {
>  unsigned int socket, cos;
>  
> -ASSERT(socket_info);
> -
>  if ( !d->arch.psr_cos_ids )
>  return;
>  
> +ASSERT(socket_info);
> +
>  /* Domain is destroyed so its cos_ref should be decreased. */
>  for ( socket = 0; socket < nr_sockets; socket++ )
>  {
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-3.18 test] 112494: trouble: blocked/broken/fail/pass

[osstest service owner]

flight 112494 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112494/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102
 build-arm64   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 build-arm64   3 capture-logs  broken blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112085
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112085
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux8c13fcce2c663b37c1134a3302b43e514961b5fa
baseline version:
 linuxdd8b674caeef9381345a6369fba29d425ff433f3

Last test of basis   112102  2017-07-21 17:53:24 Z   16 days
Testing same since   112351  

Re: [Xen-devel] [Question] how to avoid Xen using a memory range?

[Jan Beulich]

>>> Chao Gao  08/04/17 10:12 AM >>>
>I have a machine which has two numa nodes. The NODE0 contains
>memory range from 0 to 0x18400MB and NODE1 contains memory range
>from 0x18400MB to 0x1c400MB. The resource available to dom0 is
>restricted through adding "dom0_mem=10G dom0_nodes=0 dom0_max_vcpus=48"
>to Xen Command Line. Even though no guest is created, over 1GB memory of
>NODE1 is consumed according the output of 'xl info -n'. From 'xl
>debug-keys u', I found dom0 used a lot of pages of NODE1. And after
>adding "highmem-start=0x18400MB" to Xen Command Line to avoid relocating
>dom0's image to NODE1, near 1GB memory of NODE1 is still in
>use. Considering no cpu on NODE1, I think Xen won't allocate memory from
>NODE1 if no numa node is specified. Do you have some ideas about what is 
>using the memory of NODE1? and how to avoid this?

How to avoid it depends on understanding what it's being used for: You'll
have to do some debugging yourself to find out, I'm afraid. I, at least, have
no immediate idea.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel