Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin
Am Thu, 12 Apr 2018 19:25:43 +0200 schrieb Dario Faggioli : > Olaf, new patch! :-) BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc))); (XEN) CPU 36: d10v1 isr=0 runnbl=1 proc=36 pf=0 orq=0 csf=4 (XEN) CPU 33: d10v2 isr=0 runnbl=0 proc=33 pf=1 orq=0 csf=4 (XEN) CPU 20: d10v2 isr=0 runnbl=1 proc=20 pf=0 orq=0 csf=4 (XEN) CPU 32: d10v0 isr=0 runnbl=1 proc=32 pf=0 orq=0 csf=4 (XEN) CPU 33: d10v0 isr=0 runnbl=1 proc=12 pf=0 orq=0 csf=4 (XEN) CPU 36: d10v0 isr=0 runnbl=1 proc=36 pf=0 orq=0 csf=4 (XEN) CPU 31: d10v0 isr=0 runnbl=1 proc=31 pf=0 orq=0 csf=4 (XEN) Xen BUG at sched_credit.c:877 (XEN) [ Xen-4.11.20180411T100655.82540b66ce-180413055758 x86_64 debug=y Not tainted ] (XEN) CPU:31 (XEN) RIP:e008:[] sched_credit.c#csched_vcpu_migrate+0x52/0x54 (XEN) RFLAGS: 00010006 CONTEXT: hypervisor (XEN) rax: 830077be8000 rbx: 0020 rcx: 830adaca7d30 (XEN) rdx: 0020 rsi: 8300779b5000 rdi: 0033fc629000 (XEN) rbp: 83107d44fce8 rsp: 83107d44fce8 r8: 001f (XEN) r9: r10: 00ff00ff00ff00ff r11: 0f0f0f0f0f0f0f0f (XEN) r12: 83047cbf0188 r13: 83047cbe6188 r14: 82d0805c7180 (XEN) r15: 8300779b5000 cr0: 80050033 cr4: 26e0 (XEN) cr3: 000eb8239000 cr2: 7f867ef9835c (XEN) fsb: gsb: gss: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen code around (sched_credit.c#csched_vcpu_migrate+0x52/0x54): (XEN) 5d c3 0f 0b 0f 0b 0f 0b <0f> 0b 55 48 89 e5 48 8d 05 26 a9 39 00 48 8b 57 (XEN) Xen stack trace from rsp=83107d44fce8: (XEN)83107d44fcf8 82d080239419 83107d44fd68 82d08023a8d8 (XEN)82d0805c7160 82d0805c7180 01ff83107d44fd38 0020001f (XEN)000a 0296 8300779b5000 (XEN)83047cbf0188 0292 0004 82d0805b2520 (XEN)83107d44fdb8 82d08023c7ad 83047cbf0188 8300779b5000 (XEN)83107d44fdb8 830077be8000 8300779b5000 83047ffe7000 (XEN)001f 830adad2f000 83107d44fe08 82d08027a558 (XEN)83107d44fdd8 82d0802a8530 83107d44fe08 8300779b5000 (XEN)830077be8000 83047cbf0188 007c1960d213 0003 (XEN)83107d44fe98 82d0802397a9 8300779b5560 83047cbf01a0 (XEN)001f0044fe58 83047cbf0180 8300779b5000 8300779b5568 (XEN)83107d44fe78 830077be8000 8300779b5000 (XEN)8300779b5000 82d08059cc00 82d08059bc80 (XEN)83107d44 82d0805a3c80 83107d44fed8 82d08023d56a (XEN)82d080328bc1 8300779b5000 (XEN) 83107d44fee8 82d08023d5dd (XEN)7cef82bb00e7 82d080328d8b 88007d86d680 (XEN)88007d86d680 88007ea6 0001 (XEN) 8800870009c0 880087000908 (XEN) fffa deadbeefdeadf00d (XEN) Xen call trace: (XEN)[] sched_credit.c#csched_vcpu_migrate+0x52/0x54 (XEN)[] schedule.c#vcpu_move_locked+0x42/0xcc (XEN)[] schedule.c#vcpu_migrate+0x210/0x23b (XEN)[] context_saved+0x236/0x479 (XEN)[] context_switch+0xe9/0xf67 (XEN)[] schedule.c#schedule+0x306/0x6ab (XEN)[] softirq.c#__do_softirq+0x71/0x9a (XEN)[] do_softirq+0x13/0x15 (XEN)[] vmx_asm_do_vmentry+0x2b/0x30 (XEN) (XEN) Panic on CPU 31: (XEN) Xen BUG at sched_credit.c:877 (XEN) (XEN) Reboot in five seconds... pgprK8ecSB8vf.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [seabios baseline-only test] 74586: trouble: blocked/broken
This run is configured for baseline tests only. flight 74586 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74586/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-amd64 broken build-i386 broken build-i386-xsm broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-i386-xsm2 hosts-allocatebroken baseline untested build-amd64-xsm 2 hosts-allocatebroken baseline untested build-amd64-pvops 2 hosts-allocatebroken baseline untested build-i3862 hosts-allocatebroken baseline untested build-amd64 2 hosts-allocatebroken baseline untested build-i386-pvops 2 hosts-allocatebroken baseline untested build-i3863 capture-logs broken baseline untested build-amd64-xsm 3 capture-logs broken baseline untested build-amd64-pvops 3 capture-logs broken baseline untested build-amd64 3 capture-logs broken baseline untested build-i386-xsm3 capture-logs broken baseline untested build-i386-pvops 3 capture-logs broken baseline untested version targeted for testing: seabios d1343e6863dd287ce7d4fcb5169c9cff568f9d1b baseline version: seabios 4922d6cb391b8ea48a35a73c46e484cf5f1a9b1a Last test of basis74495 2018-04-05 12:21:43 Z7 days Testing same since74586 2018-04-13 03:22:28 Z0 days1 attempts People who touched revisions under test: Stefan Berger jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-qemuu-nested-amdblocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-win10-i386 blocked test-amd64-i386-
[Xen-devel] [ovmf baseline-only test] 74587: trouble: blocked/broken
This run is configured for baseline tests only. flight 74587 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74587/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-pvops broken build-i386-xsm broken build-amd64 broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64 2 hosts-allocatebroken baseline untested build-amd64-pvops 2 hosts-allocatebroken baseline untested build-amd64-xsm 2 hosts-allocatebroken baseline untested build-i386-pvops 2 hosts-allocatebroken baseline untested build-i386-xsm2 hosts-allocatebroken baseline untested build-i3862 hosts-allocatebroken baseline untested build-amd64-xsm 3 capture-logs broken baseline untested build-amd64 3 capture-logs broken baseline untested build-i3863 capture-logs broken baseline untested build-amd64-pvops 3 capture-logs broken baseline untested build-i386-xsm3 capture-logs broken baseline untested build-i386-pvops 3 capture-logs broken baseline untested version targeted for testing: ovmf bf453d581ecff2a73128873fd714a07508e2ab11 baseline version: ovmf 153f5c7a93be09403891404c06e5b0e24eb019a3 Last test of basis74584 2018-04-13 00:27:52 Z0 days Testing same since74587 2018-04-13 03:22:19 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek Steve Capper jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-step build-amd64 hosts-allocate broken-step build-amd64-pvops hosts-allocate broken-step build-amd64-xsm hosts-allocate broken-step build-i386-pvops hosts-allocate broken-step build-i386-xsm hosts-allocate broken-step build-i386 hosts-allocate broken-step build-amd64-xsm capture-logs broken-step build-amd64 capture-logs broken-step build-i386 capture-logs broken-step build-amd64-pvops capture-logs broken-step build-i386-xsm capture-logs broken-step build-i386-pvops capture-logs Push not applicable. commit bf453d581ecff2a73128873fd714a07508e2ab11 Author: Laszlo Ersek Date: Wed Apr 11 23:07:59 2018 +0200 ArmVirtPkg/ArmVirtQemu: hook NvVarStoreFormattedLib into VariableRuntimeDxe In spite of both ArmVirtQemu and ArmVirtQemuKernel formatting the variable store template at build time, link NvVarStoreFormattedLib into VariableRuntimeDxe via NULL class resolution on both platforms. This lets us test the depexes implemented in the previous patches. Cc: Ard Biesheuvel Cc: Leif Lindholm Cc: Steve Capper Cc: Supreeth Venkatesh Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel commit 8f4833bb305453fb30b886fee96888c4bdedbaa7 Author: Laszlo Erse
[Xen-devel] [xen-unstable-smoke test] 122223: regressions - trouble: blocked/fail
flight 13 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/13/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 122174 build-amd64 6 xen-buildfail REGR. vs. 122174 build-armhf 6 xen-buildfail REGR. vs. 122174 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen ba2931d4e38fac4e6960e10b245efd3badeb4aa2 baseline version: xen 82540b66ceb9318aa185f2488cbbbe479694de8f Last test of basis 122174 2018-04-11 11:01:17 Z1 days Failing since122191 2018-04-12 16:01:30 Z0 days7 attempts Testing same since 122193 2018-04-12 17:01:11 Z0 days6 attempts People who touched revisions under test: George Dunlap Ian Jackson Konrad Rzeszutek Wilk Lars Kurth Oleksandr Andrushchenko Oleksandr Grytsov jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked 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 Not pushing. commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2 Author: Oleksandr Andrushchenko Date: Wed Mar 7 10:21:20 2018 +0200 sndif: Add explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used. Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 41b4cff11f4c4a497067f543cb010d70119f1843 Author: Oleksandr Andrushchenko Date: Mon Feb 5 09:41:57 2018 +0200 sndif: Add explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Cc: Takashi Sakamoto Cc: Clemens Ladisch Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 3b7d3613a34ad6f0deeff211863578aaca0e3cd9 Author: Oleksandr Andrushchenko Date: Fri Mar 16 11:58:20 2018 +0200 sndif: Make requests and responses 64 octets long Extend the size
Re: [Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading
On Thu, Apr 12, 2018 at 09:29:34AM -0700, Raj, Ashok wrote:
>On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote:
>> From: Gao Chao
>>
>> This patch is to backport microcode improvement patches from linux
>> kernel. Below are the original patches description:
>>
>> commit a5321aec6412b20b5ad15db2d6b916c05349dbff
>> Author: Ashok Raj
>> Date: Wed Feb 28 11:28:46 2018 +0100
>>
>> x86/microcode: Synchronize late microcode loading
>>
>> Original idea by Ashok, completely rewritten by Borislav.
>>
>> Before you read any further: the early loading method is still the
>> preferred one and you should always do that. The following patch is
>> improving the late loading mechanism for long running jobs and cloud use
>> cases.
>>
>> Gather all cores and serialize the microcode update on them by doing it
>> one-by-one to make the late update process as reliable as possible and
>> avoid potential issues caused by the microcode update.
>>
>> [ Borislav: Rewrite completely. ]
>>
>> Co-developed-by: Borislav Petkov
>> Signed-off-by: Ashok Raj
>> Signed-off-by: Borislav Petkov
>> Signed-off-by: Thomas Gleixner
>> Tested-by: Tom Lendacky
>> Tested-by: Ashok Raj
>
>The tested by tags were good for linux upstream. Can you make sure
>you add your name under tested-by for xen?
Tested-by doesn't mean they have tested this patch. I just put the
original commits description here.
If Xen permits such tested-by from the sender and author, I will add one.
>
>> Reviewed-by: Tom Lendacky
>> Cc: Arjan Van De Ven
>> Link: https://lkml.kernel.org/r/20180228102846.13447-8...@alien8.de
>>
>> +static int do_microcode_update(void *_info)
>> +{
>> +struct microcode_info *info = _info;
>> +int error, ret = 0;
>> +
>> +error = __wait_for_cpus(&info->cpu_in, USEC_PER_SEC);
>> +if ( error )
>> +{
>> +ret = -EBUSY;
>> +return ret;
>> +}
>> +
>> +error = microcode_update_cpu(info->buffer, info->buffer_size);
>> +if ( error && !ret )
>> +ret = error;
>
>Isn't this redundant? can ret become non-zero in the check above?
Yes, it is redundant. I will also remove 'error' field from struct
microcode_info because stop_machine_run already has the ability to return the
first error code. Hence, don't need to implement it again here (this is the
reason why the above fragment is weird).
Thanks
Chao
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/5] SUPPORT.md: Distinguish descriptions from caveats
On 12/04/18 20:26, Ian Jackson wrote: > The new support matrix output puts a [*] after each entry in the > support matrix in many cases where the linked-to text is simply a > longer description of the feature. > > Remedy this by distinguishing text which expands on a feature > description from text which qualifies its support status. > > There are 3 patches to processing machinery, followed by two patches > to SUPPORT.md - one to make the distinction, throughout, and one to > document it. > > The patches to SUPPORT.md would ideally go to 4.10 too. > > 1/5 docs/parse-support-md: internals: Introduce docref_a > 2/5 docs/parse-support-md: internals: Rename HasText to > 3/5 SUPPORT.md, support matrix: Treat commentary before > 4/5 SUPPORT.md: Move descriptions up before Status info > 5/5 SUPPORT.md: Document the new text ordering rule For the complete series: Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading
On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote:
> From: Gao Chao
>
> This patch is to backport microcode improvement patches from linux
> kernel. Below are the original patches description:
>
> commit a5321aec6412b20b5ad15db2d6b916c05349dbff
> Author: Ashok Raj
> Date: Wed Feb 28 11:28:46 2018 +0100
>
> x86/microcode: Synchronize late microcode loading
>
> Original idea by Ashok, completely rewritten by Borislav.
>
> Before you read any further: the early loading method is still the
> preferred one and you should always do that. The following patch is
> improving the late loading mechanism for long running jobs and cloud use
> cases.
>
> Gather all cores and serialize the microcode update on them by doing it
> one-by-one to make the late update process as reliable as possible and
> avoid potential issues caused by the microcode update.
>
> [ Borislav: Rewrite completely. ]
>
> Co-developed-by: Borislav Petkov
> Signed-off-by: Ashok Raj
> Signed-off-by: Borislav Petkov
> Signed-off-by: Thomas Gleixner
> Tested-by: Tom Lendacky
> Tested-by: Ashok Raj
The tested by tags were good for linux upstream. Can you make sure
you add your name under tested-by for xen?
> Reviewed-by: Tom Lendacky
> Cc: Arjan Van De Ven
> Link: https://lkml.kernel.org/r/20180228102846.13447-8...@alien8.de
>
> +static int do_microcode_update(void *_info)
> +{
> +struct microcode_info *info = _info;
> +int error, ret = 0;
> +
> +error = __wait_for_cpus(&info->cpu_in, USEC_PER_SEC);
> +if ( error )
> +{
> +ret = -EBUSY;
> +return ret;
> +}
> +
> +error = microcode_update_cpu(info->buffer, info->buffer_size);
> +if ( error && !ret )
> +ret = error;
Isn't this redundant? can ret become non-zero in the check above?
> +/*
> + * Increase the wait timeout to a safe value here since we're serializing
> + * the microcode update and that could take a while on a large number of
> + * CPUs. And that is fine as the *actual* timeout will be determined by
> + * the last CPU finished updating and thus cut short
> + */
> +error = __wait_for_cpus(&info->cpu_out, USEC_PER_SEC *
> num_online_cpus());
> +if (error)
> +panic("Timeout when finishing updating microcode");
> +info->error = ret;
> +return ret;
> }
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122219: regressions - trouble: blocked/fail
flight 122219 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122219/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 122174 build-amd64 6 xen-buildfail REGR. vs. 122174 build-armhf 6 xen-buildfail REGR. vs. 122174 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen ba2931d4e38fac4e6960e10b245efd3badeb4aa2 baseline version: xen 82540b66ceb9318aa185f2488cbbbe479694de8f Last test of basis 122174 2018-04-11 11:01:17 Z1 days Failing since122191 2018-04-12 16:01:30 Z0 days6 attempts Testing same since 122193 2018-04-12 17:01:11 Z0 days5 attempts People who touched revisions under test: George Dunlap Ian Jackson Konrad Rzeszutek Wilk Lars Kurth Oleksandr Andrushchenko Oleksandr Grytsov jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked 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 Not pushing. commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2 Author: Oleksandr Andrushchenko Date: Wed Mar 7 10:21:20 2018 +0200 sndif: Add explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used. Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 41b4cff11f4c4a497067f543cb010d70119f1843 Author: Oleksandr Andrushchenko Date: Mon Feb 5 09:41:57 2018 +0200 sndif: Add explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Cc: Takashi Sakamoto Cc: Clemens Ladisch Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 3b7d3613a34ad6f0deeff211863578aaca0e3cd9 Author: Oleksandr Andrushchenko Date: Fri Mar 16 11:58:20 2018 +0200 sndif: Make requests and responses 64 octets long Extend the size
[Xen-devel] [libvirt test] 122182: regressions - FAIL
flight 122182 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/122182/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 15 guest-saverestorefail REGR. vs. 122005 test-amd64-i386-libvirt-pair 23 guest-migrate/dst_host/src_host fail REGR. vs. 122005 test-amd64-i386-libvirt 15 guest-saverestorefail REGR. vs. 122005 test-armhf-armhf-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 122005 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 122005 test-armhf-armhf-libvirt-raw 11 guest-start fail REGR. vs. 122005 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122005 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122005 test-amd64-amd64-libvirt-xsm 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 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail 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-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 dffe584aa4194b0667924632e9e1ae12c5520956 baseline version: libvirt 4300a56378cb4401ac2b66be5da985e94a4ca90c Last test of basis 122005 2018-04-07 03:34:15 Z5 days Failing since122154 2018-04-10 04:23:02 Z2 days3 attempts Testing same since 122182 2018-04-12 04:20:14 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Daniel P. Berrangé Erik Skultety Jim Fehlig John Ferlan Ján Tomko Michal Privoznik Vincent Bernat Wim ten Have jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass 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 pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair fail test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw fail test-amd64-amd64-libvirt-vhd pass -
[Xen-devel] [seabios test] 122202: tolerable FAIL - PUSHED
flight 122202 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/122202/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 121294 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 121294 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 121294 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 121294 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-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail 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 version targeted for testing: seabios d1343e6863dd287ce7d4fcb5169c9cff568f9d1b baseline version: seabios 4922d6cb391b8ea48a35a73c46e484cf5f1a9b1a Last test of basis 121294 2018-03-26 10:57:14 Z 17 days Testing same since 122202 2018-04-12 19:58:19 Z0 days1 attempts People who touched revisions under test: Stefan Berger 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 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 : To xenbits.xen.org:/home/xen/git/osstest/seabios.git 4922d6c..d1343e6 d1343e6863dd287ce7d4fcb5169c9cff568f9d1b -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 74584: trouble: blocked/broken
This run is configured for baseline tests only. flight 74584 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74584/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-pvops broken build-i386-xsm broken build-amd64 broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64 2 hosts-allocatebroken baseline untested build-amd64-pvops 2 hosts-allocatebroken baseline untested build-amd64-xsm 2 hosts-allocatebroken baseline untested build-i386-pvops 2 hosts-allocatebroken baseline untested build-i386-xsm2 hosts-allocatebroken baseline untested build-i3862 hosts-allocatebroken baseline untested build-amd64-xsm 3 capture-logs broken baseline untested build-amd64 3 capture-logs broken baseline untested build-i3863 capture-logs broken baseline untested build-amd64-pvops 3 capture-logs broken baseline untested build-i386-xsm3 capture-logs broken baseline untested build-i386-pvops 3 capture-logs broken baseline untested version targeted for testing: ovmf 153f5c7a93be09403891404c06e5b0e24eb019a3 baseline version: ovmf 8b0e67821bd66af70433ee4bb858325f3033609a Last test of basis74580 2018-04-12 00:49:45 Z1 days Testing same since74584 2018-04-13 00:27:52 Z0 days1 attempts People who touched revisions under test: Feng, YunhuaX Kinney, Michael D Michael D Kinney Yunhua Feng jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-step build-amd64 hosts-allocate broken-step build-amd64-pvops hosts-allocate broken-step build-amd64-xsm hosts-allocate broken-step build-i386-pvops hosts-allocate broken-step build-i386-xsm hosts-allocate broken-step build-i386 hosts-allocate broken-step build-amd64-xsm capture-logs broken-step build-amd64 capture-logs broken-step build-i386 capture-logs broken-step build-amd64-pvops capture-logs broken-step build-i386-xsm capture-logs broken-step build-i386-pvops capture-logs Push not applicable. commit 153f5c7a93be09403891404c06e5b0e24eb019a3 Author: Kinney, Michael D Date: Mon Apr 9 15:47:19 2018 -0700 SignedCapsulePkg/SystemFirmwareReportDxe: Pass thru on same handle https://bugzilla.tianocore.org/show_bug.cgi?id=928 Use HandleProtocol() to pass thru a SetImage() call to the System FMP Protocol that must be on the same handle as the FMP Protocol. Cc: Jiewen Yao Signed-off-by: Michael D Kinney Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao commit d69d9227d046211265de1fab5580c50a65944614 Author: Kinney, Michael D Date: Sat Mar 31 10:17:29 2018 -0700 SignedCapsulePkg/SystemFirmwareUpdateDxe: Single FMP https://
[Xen-devel] [xen-unstable-smoke test] 122215: regressions - trouble: blocked/fail
flight 122215 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122215/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 122174 build-amd64 6 xen-buildfail REGR. vs. 122174 build-armhf 6 xen-buildfail REGR. vs. 122174 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen ba2931d4e38fac4e6960e10b245efd3badeb4aa2 baseline version: xen 82540b66ceb9318aa185f2488cbbbe479694de8f Last test of basis 122174 2018-04-11 11:01:17 Z1 days Failing since122191 2018-04-12 16:01:30 Z0 days5 attempts Testing same since 122193 2018-04-12 17:01:11 Z0 days4 attempts People who touched revisions under test: George Dunlap Ian Jackson Konrad Rzeszutek Wilk Lars Kurth Oleksandr Andrushchenko Oleksandr Grytsov jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked 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 Not pushing. commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2 Author: Oleksandr Andrushchenko Date: Wed Mar 7 10:21:20 2018 +0200 sndif: Add explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used. Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 41b4cff11f4c4a497067f543cb010d70119f1843 Author: Oleksandr Andrushchenko Date: Mon Feb 5 09:41:57 2018 +0200 sndif: Add explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Cc: Takashi Sakamoto Cc: Clemens Ladisch Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 3b7d3613a34ad6f0deeff211863578aaca0e3cd9 Author: Oleksandr Andrushchenko Date: Fri Mar 16 11:58:20 2018 +0200 sndif: Make requests and responses 64 octets long Extend the size
[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-arm64-xsm testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 7782db9260d4c6499458de4e8d9866bc0427e143 Bug not present: a569c6f815fb6a18c64b8f122f5e2bbecd32 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/122217/ commit 7782db9260d4c6499458de4e8d9866bc0427e143 Author: Ian Jackson Date: Fri Apr 6 19:09:02 2018 +0100 docs/gen-html-index: Extract titles from HTML documents Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/122217.bisection-summary --basis-template=122174 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build Searching for failure / basis pass: 122215 fail [host=laxton1] / 122174 ok. Failure / basis pass flights: 122215 / 122174 Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 5c3fdee026a204a59cb392e43a313ab558de9682 ba2931d4e38fac4e6960e10b245efd3badeb4aa2 Basis pass 5c3fdee026a204a59cb392e43a313ab558de9682 82540b66ceb9318aa185f2488cbbbe479694de8f Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#5c3fdee026a204a59cb392e43a313ab558de9682-5c3fdee026a204a59cb392e43a313ab558de9682 git://xenbits.xen.org/xen.git#82540b66ceb9318aa185f2488cbbbe479694de8f-ba2931d4e38fac4e6960e10b245efd3badeb4aa2 Loaded 1001 nodes in revision graph Searching for test results: 122191 fail 5c3fdee026a204a59cb392e43a313ab558de9682 f246d42665a6023c248c5b3e374da5691df63f6f 122196 pass 5c3fdee026a204a59cb392e43a313ab558de9682 82540b66ceb9318aa185f2488cbbbe479694de8f 122174 pass 5c3fdee026a204a59cb392e43a313ab558de9682 82540b66ceb9318aa185f2488cbbbe479694de8f 122192 pass 5c3fdee026a204a59cb392e43a313ab558de9682 82540b66ceb9318aa185f2488cbbbe479694de8f 122193 fail 5c3fdee026a204a59cb392e43a313ab558de9682 ba2931d4e38fac4e6960e10b245efd3badeb4aa2 122194 fail 5c3fdee026a204a59cb392e43a313ab558de9682 f246d42665a6023c248c5b3e374da5691df63f6f 122199 fail 5c3fdee026a204a59cb392e43a313ab558de9682 ba2931d4e38fac4e6960e10b245efd3badeb4aa2 122198 fail 5c3fdee026a204a59cb392e43a313ab558de9682 ba2931d4e38fac4e6960e10b245efd3badeb4aa2 122205 pass 5c3fdee026a204a59cb392e43a313ab558de9682 a569c6f815fb6a18c64b8f122f5e2bbecd32 122206 fail 5c3fdee026a204a59cb392e43a313ab558de9682 1e4a834a8f5d970e68cff6d9c16710194bc46537 122209 fail 5c3fdee026a204a59cb392e43a313ab558de9682 7782db9260d4c6499458de4e8d9866bc0427e143 122210 pass 5c3fdee026a204a59cb392e43a313ab558de9682 a569c6f815fb6a18c64b8f122f5e2bbecd32 122207 fail 5c3fdee026a204a59cb392e43a313ab558de9682 ba2931d4e38fac4e6960e10b245efd3badeb4aa2 122211 fail 5c3fdee026a204a59cb392e43a313ab558de9682 7782db9260d4c6499458de4e8d9866bc0427e143 122214 pass 5c3fdee026a204a59cb392e43a313ab558de9682 a569c6f815fb6a18c64b8f122f5e2bbecd32 122215 fail 5c3fdee026a204a59cb392e43a313ab558de9682 ba2931d4e38fac4e6960e10b245efd3badeb4aa2 122217 fail 5c3fdee026a204a59cb392e43a313ab558de9682 7782db9260d4c6499458de4e8d9866bc0427e143 Searching for interesting versions Result found: flight 122174 (pass), for basis pass Result found: flight 122193 (fail), for basis failure Repro found: flight 122196 (pass), for basis pass Repro found: flight 122198 (fail), for basis failure 0 revisions at 5c3fdee026a204a59cb392e43a313ab558de9682 a569c6f815fb6a18c64b8f122f5e2bbecd32 No revisions left to test, checking graph state. Result found: flight 122205 (pass), for last pass Result found: flight 122209 (fail), for first failure Repro found: flight 122210 (pass), for last pass Repro found: flight 122211 (fail), for first failure Repro found: flight 122214 (pass), for last pass Repro found: flight 122217 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 7782db9260d4c6499458de4e8d9866bc0427e143 Bug not present: a569c6f815fb6a18c64b8f122f5e2bbecd32 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/122217/ commit 7782db9260d4c6499458de4e8d9866bc0427e143 Author: Ian Jackson Date: Fri Apr 6 19:09:02 2018 +0100 docs/gen-html-index: Extract titles from HTML documents Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth Revision graph left in /home/logs/res
Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction
On Thu, 12 Apr 2018 16:32:57 + Lars Kurth wrote: >Hi all, > >I had an action to set up a call on discussing the future direction of >PCI Emulation. I CC’ed everyone who raised an interest. I propose to >use Gotomeeting unless there are objections. > >As far as I can tell, we have people in the following time-zones: PST >to EST and BST. Not sure where Alexey is based, but it looks as if > >16:00 – 17:00 BST >17:00 – 18:00 BST >18:00 – 19:00 BST >BST = UTC+1 Ideally, any time before 17:00 UTC would be preferable for my timezone (UTC+10), but the 18:00 – 19:00 BST option should ok too (although much less preferable, unticked '18:00–19:00 BST' checkboxes in the poll to reflect this). >may work. For me Mon, Wed and Fri’s generally work at those >time-slots. Next week is a little busy for me, so I would prefer the >following week. If you could fill out the following Google poll, if >this week works that would be great. Otherwise please scream. > >https://doodle.com/poll/gdnmcrvnibmw563n > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 122200: all pass - PUSHED
flight 122200 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/122200/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf bf453d581ecff2a73128873fd714a07508e2ab11 baseline version: ovmf 153f5c7a93be09403891404c06e5b0e24eb019a3 Last test of basis 122178 2018-04-12 00:54:11 Z0 days Testing same since 122200 2018-04-12 19:58:18 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek Steve Capper 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 : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 153f5c7a93..bf453d581e bf453d581ecff2a73128873fd714a07508e2ab11 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 baseline-only test] 74583: trouble: blocked/broken
This run is configured for baseline tests only. flight 74583 linux-3.18 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74583/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-amd64 broken build-armhf-pvopsbroken build-i386 broken build-arm64-xsm broken build-i386-xsm broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-arm64-pvopsbroken build-armhf-xsm broken build-armhf broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1)
[Xen-devel] [xen-unstable baseline-only test] 74582: trouble: blocked/broken
This run is configured for baseline tests only. flight 74582 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74582/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev broken build-armhf-pvopsbroken build-arm64-xsm broken build-amd64-xtf broken build-amd64-xsm broken build-i386-pvops broken build-arm64-pvopsbroken build-armhf-xsm broken build-i386-prev broken build-arm64 broken build-amd64 broken build-i386 broken build-i386-xsm broken build-amd64-pvopsbroken build-armhf broken build-i3862 hosts-allocate broken REGR. vs. 74558 build-i386-pvops 2 hosts-allocate broken REGR. vs. 74558 build-armhf 2 hosts-allocate broken REGR. vs. 74558 build-i386-xsm2 hosts-allocate broken REGR. vs. 74558 build-armhf-pvops 2 hosts-allocate broken REGR. vs. 74558 build-i386-prev 2 hosts-allocate broken REGR. vs. 74558 build-amd64-pvops 2 hosts-allocate broken REGR. vs. 74558 build-amd64 2 hosts-allocate broken REGR. vs. 74558 build-armhf-xsm 2 hosts-allocate broken REGR. vs. 74558 build-amd64-xsm 2 hosts-allocate broken REGR. vs. 74558 build-amd64-xtf 2 hosts-allocate broken REGR. vs. 74558 build-amd64-prev 2 hosts-allocate broken REGR. vs. 74558 Tests which did not succeed, but are not blocking: test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-xtf-amd64-amd64-11 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-31 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl
[Xen-devel] [distros-debian-wheezy test] 74581: trouble: blocked/broken
flight 74581 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74581/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386 broken build-arm64 broken build-amd64-pvopsbroken build-armhf broken build-i386-pvops broken build-amd64 broken build-arm64-pvopsbroken build-armhf 2 hosts-allocate broken REGR. vs. 74248 build-amd64-pvops 2 hosts-allocate broken REGR. vs. 74248 build-armhf-pvops 2 hosts-allocate broken REGR. vs. 74248 build-i386-pvops 2 hosts-allocate broken REGR. vs. 74248 build-i3862 hosts-allocate broken REGR. vs. 74248 build-amd64 2 hosts-allocate broken REGR. vs. 74248 build-i386-pvops 3 capture-logsbroken REGR. vs. 74248 build-i3863 capture-logsbroken REGR. vs. 74248 build-amd64-pvops 3 capture-logsbroken REGR. vs. 74248 build-amd64 3 capture-logsbroken REGR. vs. 74248 Tests which did not succeed, but are not blocking: test-amd64-i386-i386-wheezy-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-wheezy-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-wheezy-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-wheezy-netboot-pygrub 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken blocked in 74248 build-arm64 2 hosts-allocate broken blocked in 74248 build-arm64-pvops 3 capture-logs broken blocked in 74248 build-arm64 3 capture-logs broken blocked in 74248 build-armhf 3 capture-logs broken like 74248 build-armhf-pvops 3 capture-logs broken like 74248 baseline version: flight 74248 jobs: build-amd64 broken build-arm64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-arm64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked test-amd64-i386-i386-wheezy-netboot-pvgrub blocked test-amd64-i386-amd64-wheezy-netboot-pygrub blocked test-amd64-amd64-i386-wheezy-netboot-pygrub blocked 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. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 74580: trouble: blocked/broken
This run is configured for baseline tests only. flight 74580 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74580/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-pvops broken build-i386-xsm broken build-amd64 broken build-i386-xsm2 hosts-allocate broken REGR. vs. 74576 build-amd64-pvops 2 hosts-allocate broken REGR. vs. 74576 build-i3862 hosts-allocate broken REGR. vs. 74576 build-i386-pvops 2 hosts-allocate broken REGR. vs. 74576 build-amd64-xsm 2 hosts-allocate broken REGR. vs. 74576 build-amd64 2 hosts-allocate broken REGR. vs. 74576 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64-xsm 3 capture-logs broken blocked in 74576 build-amd64 3 capture-logs broken blocked in 74576 build-i3863 capture-logs broken blocked in 74576 build-amd64-pvops 3 capture-logs broken blocked in 74576 build-i386-xsm3 capture-logs broken blocked in 74576 build-i386-pvops 3 capture-logs broken blocked in 74576 version targeted for testing: ovmf 8b0e67821bd66af70433ee4bb858325f3033609a baseline version: ovmf 13d909f89a3cee1c1f6b851a4cda7bd1a44e90ae Last test of basis74576 2018-04-11 04:54:42 Z1 days Testing same since74580 2018-04-12 00:49:45 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek Yonghong Zhu jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked 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 broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-step build-i386-xsm hosts-allocate broken-step build-amd64-pvops hosts-allocate broken-step build-i386 hosts-allocate broken-step build-i386-pvops hosts-allocate broken-step build-amd64-xsm hosts-allocate broken-step build-amd64 hosts-allocate broken-step build-amd64-xsm capture-logs broken-step build-amd64 capture-logs broken-step build-i386 capture-logs broken-step build-amd64-pvops capture-logs broken-step build-i386-xsm capture-logs broken-step build-i386-pvops capture-logs Push not applicable. commit 8b0e67821bd66af70433ee4bb858325f3033609a Author: Yonghong Zhu Date: Tue Apr 10 21:26:32 2018 +0800 BaseTools: Fix the build error caused by eca980c0c899 Roll back the fixed at build pcd collection to include the pcd in Module and Library. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yonghong Zhu Tested-by: Laszlo Ersek Reviewed-by: Liming Gao commit 6301d2e24ab67786fa36a6d87e7a0f6625e7b831 Author: Laszlo Ersek Date: Tue Apr 10 19:34:50 2018 +0200 OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg in March 2010, in adjacent commits b0f5144676fa and efd82c5794ec. In the past eight ye
[Xen-devel] [xen-unstable-smoke test] 122207: regressions - trouble: blocked/fail
flight 122207 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122207/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 122174 build-amd64 6 xen-buildfail REGR. vs. 122174 build-armhf 6 xen-buildfail REGR. vs. 122174 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen ba2931d4e38fac4e6960e10b245efd3badeb4aa2 baseline version: xen 82540b66ceb9318aa185f2488cbbbe479694de8f Last test of basis 122174 2018-04-11 11:01:17 Z1 days Failing since122191 2018-04-12 16:01:30 Z0 days4 attempts Testing same since 122193 2018-04-12 17:01:11 Z0 days3 attempts People who touched revisions under test: George Dunlap Ian Jackson Konrad Rzeszutek Wilk Lars Kurth Oleksandr Andrushchenko Oleksandr Grytsov jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked 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 Not pushing. commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2 Author: Oleksandr Andrushchenko Date: Wed Mar 7 10:21:20 2018 +0200 sndif: Add explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used. Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 41b4cff11f4c4a497067f543cb010d70119f1843 Author: Oleksandr Andrushchenko Date: Mon Feb 5 09:41:57 2018 +0200 sndif: Add explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Cc: Takashi Sakamoto Cc: Clemens Ladisch Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 3b7d3613a34ad6f0deeff211863578aaca0e3cd9 Author: Oleksandr Andrushchenko Date: Fri Mar 16 11:58:20 2018 +0200 sndif: Make requests and responses 64 octets long Extend the size
[Xen-devel] broken build on staging docs
Since change 7782db9260d4c6499458de4e8d9866bc0427e143 the build has been broken. See https://gitlab.com/xen-project/xen/pipelines/20403549 for logs. Ultimately its because HTML::TreeBuilder::XPath is now a required Perl module. Previously the only necessary Perl modules where those shipped in the core of Perl. While I've got no problem updating all the containers to include it, there is a bit of a conundrum where CentOS/RHEL don't actually package and include it. I've also checked EPEL and its not included. Not sure what approach folks would like to take as this will require people to bust out CPAN for RHEL/CentOS based builds. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 122177: regressions - FAIL
flight 122177 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122177/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-shadow15 guest-saverestorefail REGR. vs. 122144 build-i386-libvirt6 libvirt-buildfail REGR. vs. 122144 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122144 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122144 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122144 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122144 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122144 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122144 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-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-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 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail 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: qemuu38e83a71d02e026d4a6d0ab1ef9855c4924c2c68 baseline version: qemuu915d34c5f99b0ab91517c69f54272bfdb6ca2b32 Last test of basis 122144 2018-04-09 19:01:09 Z3 days Failing since122165 2018-04-10 23:20:31 Z1 days2 attempts Testing same since 122177 2018-04-11 23:26:15 Z0 days1 attempts People who touched revisions under test: Alexey Kardashevskiy Andrey Smirnov BALATON Zoltan Christian Borntraeger Cornelia Huck Daniel P. Berrangé David Gibson David Hildenbrand Dr. David Alan Gilbert Eric Auger Eric Blake Gerd Hoffmann Greg Kurz James Cowg
[Xen-devel] [linux-3.18 test] 122180: tolerable FAIL - PUSHED
flight 122180 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122180/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 122166 pass in 122180 test-armhf-armhf-xl-vhd 7 xen-boot fail pass in 122166 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail pass in 122166 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 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-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail baseline untested test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 122166 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 122166 never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 121320 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 121320 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 121320 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 121320 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 121320 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 121320 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 121320 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail 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-xl-pvshim12 guest-start fail never pass 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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail 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-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-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-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-libvirt-xsm 13 migrate-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 build-arm64-pvops 6 kernel-build fail 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-qemut-ws16-amd64 17 guest-stop 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-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail 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-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linuxfb625ba7025f2e791b870f25fe4b19eb3b4c0f32 baseline version: linux9764536dc592144beee43c987fef45d2e91ca55c Last test of basis 121320 2018-03-28 02:34:55 Z 15 days Failing since122094 2018-04-08 10:18:48 Z4 days6 attempts Testing sam
Re: [Xen-devel] [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly
On Thu, 12 Apr 2018, Julien Grall wrote:
> On 12/04/18 00:46, Stefano Stabellini wrote:
> > On Wed, 11 Apr 2018, Julien Grall wrote:
> > > On 11/04/18 14:19, Mirela Simonovic wrote:
> > > > Freeing percpu area is done when a non-boot CPU is disabled upon
> > > > suspend.
> > > > This use to be scheduled for execution after a period of time, what
> > > > caused
> > > > the following racing issues. If CPU is enabled after it is disabled and
> > > > before the freeing of percpu area is performed, Xen would crash upon
> > > > initializing percpu area because per cpu offset is not marked as
> > > > INVALID_PERCPU_AREA (this suppose to happen when cpu area is freed).
> > > > To resolve the racing issue, free percpu area right away instead
> > > > scheduling it for later.
> > >
> > > The reason of using the RCU is you want to make sure that none of the
> > > other
> > > CPUs will access that percpu data before freeing it. So I don't think this
> > > patch is valid.
> > >
> > > It looks like to me a rcu barrier is missing after calling cpu_down
> > > somewhere
> > > in the CPU off path. I am not entirely sure where.
> >
> > We need a rcu_barrier(). Perhaps, it could be added on cpu_on before
> > initializing the percpu area?
>
> Do you mind giving a bit more details on your thought? cpu_up looks a strange
> place as no one should access the percpu area after the CPU is down. So it
> feels the rcu_barrier should be somewhere before PSCI_cpu_off is called.
Yes, it feels strange to do it on cpu_on, it would be more obvious on
cpu_off, but we don't actually need to _free_percpu_area on cpu_off,
right? We only need to make sure it is done before cpu_percpu_callback
is called on cpu_on.
My suggestion would be to evaluate if it is possible to introduce the
rcu_barrier() on the resume path before cpu_percpu_callback, maybe in
start_secondary.
I was also looking at xen/arch/x86/acpi/power.c:enter_state and noticed
that they chose to call rcu_barrier() on enable_cpu before
enable_nonboot_cpus().
> > > >
> > > > Signed-off-by: Mirela Simonovic
> > > > ---
> > > >xen/arch/arm/percpu.c | 2 +-
> > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/xen/arch/arm/percpu.c b/xen/arch/arm/percpu.c
> > > > index 25442c48fe..e4e8405f43 100644
> > > > --- a/xen/arch/arm/percpu.c
> > > > +++ b/xen/arch/arm/percpu.c
> > > > @@ -46,7 +46,7 @@ static void free_percpu_area(unsigned int cpu)
> > > >{
> > > >struct free_info *info = &per_cpu(free_info, cpu);
> > > >info->cpu = cpu;
> > > > -call_rcu(&info->rcu, _free_percpu_area);
> > > > +_free_percpu_area(&info->rcu);
> > > >}
> > > > static int cpu_percpu_callback(
> > > >
> > >
> > > --
> > > Julien Grall
> > >
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122198: regressions - trouble: blocked/fail
flight 122198 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122198/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 122174 build-amd64 6 xen-buildfail REGR. vs. 122174 build-armhf 6 xen-buildfail REGR. vs. 122174 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen ba2931d4e38fac4e6960e10b245efd3badeb4aa2 baseline version: xen 82540b66ceb9318aa185f2488cbbbe479694de8f Last test of basis 122174 2018-04-11 11:01:17 Z1 days Failing since122191 2018-04-12 16:01:30 Z0 days3 attempts Testing same since 122193 2018-04-12 17:01:11 Z0 days2 attempts People who touched revisions under test: George Dunlap Ian Jackson Konrad Rzeszutek Wilk Lars Kurth Oleksandr Andrushchenko Oleksandr Grytsov jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked 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 Not pushing. commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2 Author: Oleksandr Andrushchenko Date: Wed Mar 7 10:21:20 2018 +0200 sndif: Add explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used. Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 41b4cff11f4c4a497067f543cb010d70119f1843 Author: Oleksandr Andrushchenko Date: Mon Feb 5 09:41:57 2018 +0200 sndif: Add explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Cc: Takashi Sakamoto Cc: Clemens Ladisch Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 3b7d3613a34ad6f0deeff211863578aaca0e3cd9 Author: Oleksandr Andrushchenko Date: Fri Mar 16 11:58:20 2018 +0200 sndif: Make requests and responses 64 octets long Extend the size
[Xen-devel] [linux-linus test] 122176: regressions - FAIL
flight 122176 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/122176/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 118324 test-amd64-i386-examine 8 reboot fail REGR. vs. 118324 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 118324 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 118324 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 118324 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118324 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 118324 test-amd64-i386-xl7 xen-boot fail REGR. vs. 118324 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 118324 test-arm64-arm64-libvirt-xsm 11 debian-fixup fail REGR. vs. 118324 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 118324 test-armhf-armhf-xl-multivcpu 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-xl 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-xl-xsm 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 118324 test-armhf-armhf-libvirt 10 debian-install fail REGR. vs. 118324 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118324 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324 test-amd64-i386-xl-pvshim 7 xen-boot fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-bootfail never pass test-amd64-i386-xl-shadow 7 xen-boot fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-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-libvirt-xsm 13 migrate-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
[Xen-devel] [xen-unstable-smoke test] 122193: regressions - trouble: blocked/fail
flight 122193 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122193/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 122174 build-amd64 6 xen-buildfail REGR. vs. 122174 build-armhf 6 xen-buildfail REGR. vs. 122174 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a version targeted for testing: xen ba2931d4e38fac4e6960e10b245efd3badeb4aa2 baseline version: xen 82540b66ceb9318aa185f2488cbbbe479694de8f Last test of basis 122174 2018-04-11 11:01:17 Z1 days Failing since122191 2018-04-12 16:01:30 Z0 days2 attempts Testing same since 122193 2018-04-12 17:01:11 Z0 days1 attempts People who touched revisions under test: George Dunlap Ian Jackson Konrad Rzeszutek Wilk Lars Kurth Oleksandr Andrushchenko Oleksandr Grytsov jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked 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 Not pushing. commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2 Author: Oleksandr Andrushchenko Date: Wed Mar 7 10:21:20 2018 +0200 sndif: Add explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used. Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 41b4cff11f4c4a497067f543cb010d70119f1843 Author: Oleksandr Andrushchenko Date: Mon Feb 5 09:41:57 2018 +0200 sndif: Add explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Takashi Iwai Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai Cc: Takashi Sakamoto Cc: Clemens Ladisch Signed-off-by: Konrad Rzeszutek Wilk Release-acked-by: Juergen Gross commit 3b7d3613a34ad6f0deeff211863578aaca0e3cd9 Author: Oleksandr Andrushchenko Date: Fri Mar 16 11:58:20 2018 +0200 sndif: Make requests and responses 64 octets long Extend the size
Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th
Hi All, >> We'd like to explore both FreeRTOS in dom0 and dom0-less options. I think >> there were some patches while ago for dom0-less xen. > > "Dom0-less" is a great name actually :-) > > Up until now, we discussed this topic under the name of "create multiple > guests from device tree". There are no patches (as far as I know), but > it was submitted as the Xen on ARM project for Outreachy this year. > There are patches for a different project to setup shared memory regions > from the xl config file (no need for grant table or xenbus support). > > I have been in discussion with Stefano over this topic and would be interested to take this up. Regards, ~Praveen. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RESEND] xen/sndif: Sync up with the canonical definition in Xen
On Thu, Apr 12, 2018 at 01:46:33PM -0400, Boris Ostrovsky wrote: > On 04/12/2018 01:26 PM, Oleksandr Andrushchenko wrote: > > This is the sync up with the canonical definition of the sound > > protocol in Xen: > > > > 1. Protocol version was referenced in the protocol description, > >but missed its definition. Fixed by adding a constant > >for current protocol version. > > > > 2. Some of the request descriptions have "reserved" fields > >missed: fixed by adding corresponding entries. > > > > 3. Extend the size of the requests and responses to 64 octets. > >Bump protocol version to 2. > > > > 4. Add explicit back and front synchronization > >In order to provide explicit synchronization between backend and > >frontend the following changes are introduced in the protocol: > > - add new ring buffer for sending asynchronous events from > > backend to frontend to report number of bytes played by the > > frontend (XENSND_EVT_CUR_POS) > > - introduce trigger events for playback control: start/stop/pause/resume > > - add "req-" prefix to event-channel and ring-ref to unify naming > > of the Xen event channels for requests and events > > > > 5. Add explicit back and front parameter negotiation > >In order to provide explicit stream parameter negotiation between > >backend and frontend the following changes are introduced in the > > protocol: > >add XENSND_OP_HW_PARAM_QUERY request to read/update > >configuration space for the parameters given: request passes > >desired parameter's intervals/masks and the response to this request > >returns allowed min/max intervals/masks to be used. > > > > Signed-off-by: Oleksandr Andrushchenko > > Signed-off-by: Oleksandr Grytsov > > Cc: Konrad Rzeszutek Wilk > > Cc: Takashi Iwai > > --- > > Reviewed-by: Boris Ostrovsky > Reviewed-by: Konrad Rzeszutek Wilk Thank you! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/5] SUPPORT.md: Distinguish descriptions from caveats
Ian Jackson writes ("[PATCH 0/5] SUPPORT.md: Distinguish descriptions from
caveats"):
> The new support matrix output puts a [*] after each entry in the
> support matrix in many cases where the linked-to text is simply a
> longer description of the feature.
Example output:
https://xenbits.xen.org/people/iwj/2018/support-matrix-example-B-v1/t.html
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/5] SUPPORT.md: Document the new text ordering rule
Signed-off-by: Ian Jackson --- SUPPORT.md | 5 + 1 file changed, 5 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 5ae84cf..098262b 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -725,6 +725,11 @@ The file is in markdown format. The machine-readable fragments are markdown literals containing RFC-822-like (deb822-like) data. +In each case, descriptions which expand on the name of a feature as +provided in the section heading, precede the Status indications. +Any paragraphs which follow the Status indication are caveats or +qualifications of the information provided in Status fields. + ## Keys found in the Feature Support subsections ### Status -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/5] docs/parse-support-md: internals: Rename HasText to HasCaveat
No functional change.
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index 5bf8405..6953930 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -34,7 +34,7 @@ our $toplevel_sectlist = new_sectlist();
# $sectlist->{KEY}{Children} = a further $sectlist
# $sectlist->{KEY}{Key} = KEY
# $sectlist->{KEY}{RealSect} = containing real section in @insections, so
-# $sectlist->{KEY}{RealSect}{HasText}[VI] = trueish iff there was a Para
+# $sectlist->{KEY}{RealSect}{HasCaveat}[VI] = trueish iff other in a Para
# $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html
# A $sectnode represents a single section from the original markdown
# document. Its subsections are in Children.
@@ -57,7 +57,7 @@ our @insections;
# $insections[]{Headline} = markdown content
# these next are only defined for real sections, not Status elements
# $insections[]{Anchor} = string
-# $insections[]{HasText} = array, $sectlist->{HasText} will refer to this
+# $insections[]{HasCaveat} = array, $sectlist->{HasCaveat} will refer to this
our $had_unknown;
# adding new variable ? it must be reset in r_toplevel
@@ -77,14 +77,14 @@ sub ri_Header {
Key => $id,
Anchor => $id,
Headline => $hl,
- HasText => [],
+ HasCaveat => [],
};
#print STDERR Dumper(\@insections);
}
sub ri_Para {
if (@insections) {
-$insections[$#insections]{HasText}[$version_index] = 1;
+$insections[$#insections]{HasCaveat}[$version_index] = 1;
}
};
@@ -366,7 +366,7 @@ sub write_output_row ($) {
my $nextcell = '';
if (!defined $colspan) { # first row of this RealSect
$colspan= ' colspan="2"';
-if ($sectnode->{RealSect}{HasText}[$i] && $st
+if ($sectnode->{RealSect}{HasCaveat}[$i] && $st
&& $sectnode->{RealSect}{Anchor}) {
my $rows = $sectnode->{RealSect}{Rows};
$nextcell = sprintf '', $rows;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/5] docs/parse-support-md: internals: Introduce docref_a
No functional change.
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index decda33..5bf8405 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -318,6 +318,12 @@ sub o { print @_ or die $!; }
our @pending_headings;
+sub docref_a ($$) {
+my ($i, $realsect) = @_;
+return sprintf '',
+$version_urls[$i], $realsect->{Anchor};
+}
+
sub write_output_row ($) {
my ($sectnode) = @_;
#print STDERR 'WOR ', Dumper($d, $sectnode);
@@ -364,8 +370,8 @@ sub write_output_row ($) {
&& $sectnode->{RealSect}{Anchor}) {
my $rows = $sectnode->{RealSect}{Rows};
$nextcell = sprintf '', $rows;
-$nextcell .= sprintf '[*]',
-$version_urls[$i], $sectnode->{RealSect}{Anchor};
+$nextcell .= docref_a $i, $sectnode->{RealSect};
+$nextcell .= '[*]';
$nextcell .= '';
$colspan = '';
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/5] SUPPORT.md: Move descriptions up before Status info
This turns all the things which were treated as caveats, but which don't need to be footnoted in the matrix, into descriptions. For the benefit of the support matrix generator, this patch (or a version of it) should be backported to 4.10. Signed-off-by: Ian Jackson --- SUPPORT.md | 213 - 1 file changed, 111 insertions(+), 102 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index 264b23f..5ae84cf 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -58,32 +58,29 @@ for the definitions of the support status levels etc. ### ARM/GICv3 ITS -Status: Experimental - Extension to the GICv3 interrupt controller to support MSI. +Status: Experimental + ## Guest Type ### x86/PV -Status: Supported - Traditional Xen PV guest No hardware requirements -### x86/HVM +Status: Supported -Status, domU: Supported +### x86/HVM Fully virtualised guest using hardware virtualisation extensions Requires hardware virtualisation support (Intel VMX / AMD SVM) -### x86/PVH - Status, domU: Supported -Status, dom0: Experimental + +### x86/PVH PVH is a next-generation paravirtualized mode designed to take advantage of hardware virtualization support when possible. @@ -93,12 +90,15 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM). Dom0 support requires an IOMMU (Intel VT-d / AMD IOMMU). -### ARM +Status, domU: Supported +Status, dom0: Experimental -Status: Supported +### ARM ARM only has one guest type at the moment +Status: Supported + ## Toolstack ### xl @@ -107,12 +107,12 @@ ARM only has one guest type at the moment ### Direct-boot kernel image format +Format which the toolstack accepts for direct-boot kernels + Supported, x86: bzImage, ELF Supported, ARM32: zImage Supported, ARM64: Image -Format which the toolstack accepts for direct-boot kernels - ### Dom0 init support for xl Status, SysV: Supported @@ -121,10 +121,10 @@ Format which the toolstack accepts for direct-boot kernels ### JSON output support for xl -Status: Experimental - Output of information in machine-parseable JSON format +Status: Experimental + ### Open vSwitch integration for xl Status, Linux: Supported @@ -157,17 +157,18 @@ Output of information in machine-parseable JSON format ### Hypervisor 'debug keys' -Status: Supported, not security supported - These are functions triggered either from the host serial console, or via the xl 'debug-keys' command, which cause Xen to dump various hypervisor state to the console. +Status: Supported, not security supported + ### Hypervisor synchronous console output (sync_console) +Xen command-line flag to force synchronous console output. + Status: Supported, not security supported -Xen command-line flag to force synchronous console output. Useful for debugging, but not suitable for production environments due to incurred overhead. @@ -179,56 +180,54 @@ Debugger to debug ELF guests ### Soft-reset for PV guests -Status: Supported - Soft-reset allows a new kernel to start 'from scratch' with a fresh VM state, but with all the memory from the previous state of the VM intact. This is primarily designed to allow "crash kernels", which can do core dumps of memory to help with debugging in the event of a crash. -### xentrace +Status: Supported -Status, x86: Supported +### xentrace Tool to capture Xen trace buffer data -### gcov +Status, x86: Supported -Status: Supported, Not security supported +### gcov Export hypervisor coverage data suitable for analysis by gcov or lcov. +Status: Supported, Not security supported + ## Memory Management ### Dynamic memory control -Status: Supported - Allows a guest to add or remove memory after boot-time. This is typically done by a guest kernel agent known as a "balloon driver". -### Populate-on-demand memory +Status: Supported -Status, x86 HVM: Supported +### Populate-on-demand memory This is a mechanism that allows normal operating systems with only a balloon driver to boot with memory < maxmem. -### Memory Sharing +Status, x86 HVM: Supported -Status, x86 HVM: Expermental +### Memory Sharing Allow sharing of identical pages between guests -### Memory Paging +Status, x86 HVM: Expermental -Status, x86 HVM: Experimenal +### Memory Paging Allow pages belonging to guests to be paged to disk -### Transcendent Memory +Status, x86 HVM: Experimenal -Status: Experimental +### Transcendent Memory Transcendent Memory (tmem) allows the creation of hypervisor memory pools which guests can use to store memory @@ -236,96 +235,100 @@ rather than caching in its own memory or swapping to disk. Having these in the hypervisor can allow more efficient aggregate use of memory across VMs. -### Alternative p2m +Status: Experimental -Statu
[Xen-devel] [PATCH 0/5] SUPPORT.md: Distinguish descriptions from caveats
The new support matrix output puts a [*] after each entry in the support matrix in many cases where the linked-to text is simply a longer description of the feature. Remedy this by distinguishing text which expands on a feature description from text which qualifies its support status. There are 3 patches to processing machinery, followed by two patches to SUPPORT.md - one to make the distinction, throughout, and one to document it. The patches to SUPPORT.md would ideally go to 4.10 too. 1/5 docs/parse-support-md: internals: Introduce docref_a 2/5 docs/parse-support-md: internals: Rename HasText to 3/5 SUPPORT.md, support matrix: Treat commentary before 4/5 SUPPORT.md: Move descriptions up before Status info 5/5 SUPPORT.md: Document the new text ordering rule Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/5] SUPPORT.md, support matrix: Treat commentary before status as description
Running text in feature sections in the markdown document currently
might be (i) a caveat, qualifying or clarifying the support statement
(ii) a plain description of the feature.
Caveats can be version-specific and deserve the [*] annotation in the
relevant feature matrix cell. They must link to SUPPORT.html for the
specific version.
Descriptions are not version specific. In that case the [*]
annotation is visusal noise. Rather, it is better to make a hyperlink
out of the text which is being expanded on. The hyperlink can point
to any appropriate version.
There is a question about how to notate this distinction in
SUPPORT.md. After IRL discussion with George and Lars I propose that
we should put text which helps describe a feature (ie, which expands
on a section heading) after the heading but before the Status
indications; whereas, caveats and supplementary information about
the actual status, should follow the Status block.
This patch implements this distinction in the support matrix
generator. Only paragraphs containing _only_ italic content count as
descriptive; anything else is treated as a caveat.
In the code:
* Add a new entry to RealSect, HasDescription
* When parsing, track whether we are before or after the first Status
block in a new variable $has_feature.
* In ri_Para, set HasDescription set to the input document index
when we encounter text before the first feature.
* When writing a `heading' (ie, the table cell for a feature name)
look for HasDescription and make an appropriate hyperlink.
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index 6953930..653d216 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -35,6 +35,7 @@ our $toplevel_sectlist = new_sectlist();
# $sectlist->{KEY}{Key} = KEY
# $sectlist->{KEY}{RealSect} = containing real section in @insections, so
# $sectlist->{KEY}{RealSect}{HasCaveat}[VI] = trueish iff other in a Para
+# $sectlist->{KEY}{RealSect}{HasDescription} = VI for some Emph in Para
# $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html
# A $sectnode represents a single section from the original markdown
# document. Its subsections are in Children.
@@ -58,8 +59,10 @@ our @insections;
# these next are only defined for real sections, not Status elements
# $insections[]{Anchor} = string
# $insections[]{HasCaveat} = array, $sectlist->{HasCaveat} will refer to this
+# $insections[]{HasDescription} VI, likewise
our $had_unknown;
+our $had_feature;
# adding new variable ? it must be reset in r_toplevel
#-- parsing --
@@ -78,13 +81,20 @@ sub ri_Header {
Anchor => $id,
Headline => $hl,
HasCaveat => [],
+ HasDescription => undef,
};
#print STDERR Dumper(\@insections);
+$had_feature = 0;
}
sub ri_Para {
-if (@insections) {
-$insections[$#insections]{HasCaveat}[$version_index] = 1;
+return unless @insections;
+my $insection = $insections[$#insections];
+
+if ($had_feature) {
+$insection->{HasCaveat}[$version_index] = 1;
+} else {
+$insection->{HasDescription} //= $version_index;
}
};
@@ -92,6 +102,8 @@ sub parse_feature_entry ($) {
my ($value) = @_;
die unless @insections;
+$had_feature = 1;
+
my $sectnode;
my $realsect;
foreach my $s (@insections) {
@@ -183,6 +195,7 @@ sub r_toplevel ($) {
@insections = ();
$had_unknown = undef;
+$had_feature = undef;
foreach my $e (@$i) {
next unless ref $e eq 'ARRAY';
@@ -346,7 +359,14 @@ sub write_output_row ($) {
$span->('col', $maxdepth - $heading->{Depth} + 1)
if !%{ $heading->{Children} };
o(' align="left">');
+my $end_a = '';
+my $desc_i = $heading->{RealSect}{HasDescription};
+if (defined $desc_i) {
+o(docref_a $desc_i, $heading->{RealSect});
+$end_a= '';
+}
o($heading->{Headline});
+o($end_a);
o('');
}
if (%{ $sectnode->{Children} }) {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 9/9] xen/x86: use PCID feature
Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.
We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
2 values for the non-XPTI case:
- guest active and in kernel mode
- guest active and in user mode
- hypervisor active and guest in user mode (XPTI only)
- hypervisor active and guest in kernel mode (XPTI only)
We use PCID only if PCID _and_ INVPCID are supported. With PCID in use
we disable global pages in cr4. A command line parameter controls in
which cases PCID is being used.
As the non-XPTI case has shown not to perform better with PCID at least
on some machines the default is to use PCID only for domains subject to
XPTI.
With PCID enabled we always disable global pages. This avoids having to
either flush the complete TLB or do a cycle through all PCID values
when invalidating a single global page.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V6.1:
- address some minor comments (Jan Beulich)
V6:
- split off pv_guest_cr4_to_real_cr4() conversion to function into new
patch (Andrew Cooper)
- changed some comments (Jan Beulich, Andrew Cooper)
V5:
- use X86_CR3_ADDR_MASK instead of ~X86_CR3_PCID_MASK (Jan Beulich)
- add some const qualifiers (Jan Beulich)
- mask X86_CR3_ADDR_MASK with PADDR_MASK (Jan Beulich)
- add flushing the TLB from old PCID related entries in write_cr3_cr4()
(Jan Beulich)
V4:
- add cr3 mask for page table address and use that in dbg_pv_va2mfn()
(Jan Beulich)
- use invpcid_flush_all_nonglobals() instead of invpcid_flush_all()
(Jan Beulich)
- use PCIDs 0/1 when running in Xen or without XPTI, 2/3 with XPTI in
guest (Jan Beulich)
- ASSERT cr4.pge and cr4.pcide are never active at the same time
(Jan Beulich)
- make pv_guest_cr4_to_real_cr4() a real function
V3:
- support PCID for non-XPTI case, too
- add command line parameter for controlling usage of PCID
- check PCID active by using cr4.pcide (Jan Beulich)
---
docs/misc/xen-command-line.markdown | 14 +++
xen/arch/x86/flushtlb.c | 47 -
xen/arch/x86/mm.c | 16 +++-
xen/arch/x86/pv/dom0_build.c| 1 +
xen/arch/x86/pv/domain.c| 81 -
xen/include/asm-x86/domain.h| 4 +-
xen/include/asm-x86/processor.h | 3 ++
xen/include/asm-x86/pv/domain.h | 31 ++
8 files changed, 191 insertions(+), 6 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 451a4fa566..f8950a3bb2 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1451,6 +1451,20 @@ All numbers specified must be hexadecimal ones.
This option can be specified more than once (up to 8 times at present).
+### pcid (x86)
+> `= | xpti=`
+
+> Default: `xpti`
+
+> Can be modified at runtime (change takes effect only for domains created
+ afterwards)
+
+If available, control usage of the PCID feature of the processor for
+64-bit pv-domains. PCID can be used either for no domain at all (`false`),
+for all of them (`true`), only for those subject to XPTI (`xpti`) or for
+those not subject to XPTI (`no-xpti`). The feature is used only in case
+INVPCID is supported and not disabled via `invpcid=false`.
+
### ple\_gap
> `= `
diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index e28bf04a37..8dd184d8be 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
/* Debug builds: Wrap frequently to stress-test the wrap logic. */
#ifdef NDEBUG
@@ -93,6 +94,7 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
{
unsigned long flags, old_cr4;
u32 t;
+unsigned long old_pcid = cr3_pcid(read_cr3());
/* This non-reentrant function is sometimes called in interrupt context. */
local_irq_save(flags);
@@ -102,14 +104,34 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
old_cr4 = read_cr4();
if ( old_cr4 & X86_CR4_PGE )
{
+/*
+ * X86_CR4_PGE set means PCID is inactive.
+ * We have to purge the TLB via flipping cr4.pge.
+ */
old_cr4 = cr4 & ~X86_CR4_PGE;
write_cr4(old_cr4);
}
+else if ( use_invpcid )
+/*
+ * Flushing the TLB via INVPCID is necessary only in case PCIDs are
+ * in use, which is true only with INVPCID being available.
+ * Without PCID usage the following write_cr3() will purge the TLB
+ * (we are in the cr4.pge off path) of all entries.
+ * Using invpcid_flush_all_nonglobals() seems to be faster than
+ * invpcid_flush_all(), so use that.
+ */
+invpcid_flush_all_nonglobals();
write_cr3(cr3);
if ( old_cr4 != cr4 )
write_cr4(cr4);
+else if ( old_pcid != cr3_pcid(cr3) )
+/*
+ * Make sure no TLB entries related to the old PCI
[Xen-devel] [PATCH v7 0/9] xen/x86: various XPTI speedups
This patch series aims at reducing the overhead of the XPTI Meltdown mitigation. Patch 1 had been posted before, the main changes in this patch are due to addressing Jan's comments on my first version. The main objective of that patch is to avoid copying the L4 page table each time the guest is being activated, as often the contents didn't change while the hypervisor was active. Patch 2 adds a new helper for writing cr3 instead of open coding the inline assembly in multiple places. Patch 3 sets the stage for being able to activate XPTI per domain. As a first step it is now possible to switch XPTI off for dom0 via the xpti boot parameter. Patch 4 adds support for using the INVPCID instruction for flushing the TLB. Patch 5 reduces the costs of TLB flushes even further: as we don't make any use of global TLB entries with XPTI being active we can avoid removing all global TLB entries on TLB flushes by simply deactivating the global pages in CR4. Patch 6 prepares using PCIDs in patch 6. For that purpose it was necessary to allow CR3 values with bit 63 set in order to avoid flushing TLB entries when writing CR3. This requires a modification of Jan's rather clever state machine with positive and negative CR3 values for the hypervisor by using a dedicated flag byte instead. Patch 7 converts pv_guest_cr4_to_real_cr4() from a macro to a function as it was becoming more and more complex. Patch 8 adds some PCID helper functions for accessing the different parts of cr3 (address and pcid part). Patch 9 is the main performance contributor: by making use of the PCID feature (if available) TLB entries can survive CR3 switches. The TLB needs to be flushed on context switches only and not when switching between guest and hypervisor or guest kernel and user mode. On my machine (Intel i7-4600M) using the PCID feature in the non-XPTI case showed a slightly worse performance than using global pages instead (using PCID and global pages is a bad idea as invalidating global pages in this case would need a complete TLB flush). For this reason I've decided to use PCID for XPTI only as the default. That can easily be changed by using the command line parameter "pcid=true". The complete series has been verified to still mitigate against Meltdown attacks. A simple performance test (make -j 4 in the Xen hypervisor directory) showed significant improvements compared to the state without this series. Numbers are seconds, stddev in braces. xpti=false elapsed system user unpatched: 88.42 ( 2.01) 94.49 ( 1.38) 180.40 ( 1.41) patched : 89.45 ( 3.10) 96.47 ( 3.22) 181.34 ( 1.98) xpti=true elapsed system user unpatched: 113.43 ( 3.68) 165.44 ( 4.41) 183.30 ( 1.72) patched : 92.76 ( 2.11) 103.39 ( 1.13) 184.86 ( 0.12) Juergen Gross (9): x86/xpti: avoid copying L4 page table contents when possible xen/x86: add a function for modifying cr3 xen/x86: support per-domain flag for xpti xen/x86: use invpcid for flushing the TLB xen/x86: disable global pages for domains with XPTI active xen/x86: use flag byte for decision whether xen_cr3 is valid xen/x86: convert pv_guest_cr4_to_real_cr4() to a function xen/x86: add some cr3 helpers xen/x86: use PCID feature docs/misc/xen-command-line.markdown | 37 +- xen/arch/x86/cpu/mtrr/generic.c | 37 +- xen/arch/x86/debug.c| 2 +- xen/arch/x86/domain.c | 6 +-- xen/arch/x86/domain_page.c | 2 +- xen/arch/x86/flushtlb.c | 98 ++--- xen/arch/x86/mm.c | 86 ++-- xen/arch/x86/mm/shadow/multi.c | 4 ++ xen/arch/x86/pv/dom0_build.c| 8 +-- xen/arch/x86/pv/domain.c| 89 - xen/arch/x86/setup.c| 27 +++--- xen/arch/x86/smp.c | 2 +- xen/arch/x86/smpboot.c | 6 ++- xen/arch/x86/spec_ctrl.c| 70 ++ xen/arch/x86/x86_64/asm-offsets.c | 2 + xen/arch/x86/x86_64/compat/entry.S | 5 +- xen/arch/x86/x86_64/entry.S | 78 - xen/common/efi/runtime.c| 4 +- xen/include/asm-x86/current.h | 23 +++-- xen/include/asm-x86/domain.h| 17 +++ xen/include/asm-x86/flushtlb.h | 4 +- xen/include/asm-x86/invpcid.h | 2 + xen/include/asm-x86/processor.h | 18 +++ xen/include/asm-x86/pv/domain.h | 31 xen/include/asm-x86/spec_ctrl.h | 4 ++ xen/include/asm-x86/x86-defns.h | 4 +- 26 files changed, 521 insertions(+), 145 deletions(-) -- 2.13.6 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 7/9] xen/x86: convert pv_guest_cr4_to_real_cr4() to a function
pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert
it from a macro to an ordinary function.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V6:
- new patch, split off from (old) patch 7 (Andrew Cooper)
---
xen/arch/x86/mm.c| 14 ++
xen/include/asm-x86/domain.h | 11 ++-
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4997047edf..6aa0c34bae 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -500,6 +500,20 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
v->arch.cr3 = mfn_x(mfn) << PAGE_SHIFT;
}
+unsigned long pv_guest_cr4_to_real_cr4(const struct vcpu *v)
+{
+const struct domain *d = v->domain;
+unsigned long cr4;
+
+cr4 = v->arch.pv_vcpu.ctrlreg[4] & ~X86_CR4_DE;
+cr4 |= mmu_cr4_features & (X86_CR4_PSE | X86_CR4_SMEP | X86_CR4_SMAP |
+ X86_CR4_OSXSAVE | X86_CR4_FSGSBASE);
+cr4 |= d->arch.pv_domain.xpti ? 0 : X86_CR4_PGE;
+cr4 |= d->arch.vtsc ? X86_CR4_TSD : 0;
+
+return cr4;
+}
+
void write_ptbase(struct vcpu *v)
{
struct cpu_info *cpu_info = get_cpu_info();
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index b7894dc8c8..9627058cd0 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -615,15 +615,8 @@ void vcpu_show_registers(const struct vcpu *);
unsigned long pv_guest_cr4_fixup(const struct vcpu *, unsigned long guest_cr4);
/* Convert between guest-visible and real CR4 values. */
-#define pv_guest_cr4_to_real_cr4(v) \
-(((v)->arch.pv_vcpu.ctrlreg[4] \
- | (mmu_cr4_features \
- & (X86_CR4_PSE | X86_CR4_SMEP |\
-X86_CR4_SMAP | X86_CR4_OSXSAVE |\
-X86_CR4_FSGSBASE)) \
- | ((v)->domain->arch.pv_domain.xpti ? 0 : X86_CR4_PGE) \
- | ((v)->domain->arch.vtsc ? X86_CR4_TSD : 0)) \
- & ~X86_CR4_DE)
+unsigned long pv_guest_cr4_to_real_cr4(const struct vcpu *v);
+
#define real_cr4_to_pv_guest_cr4(c) \
((c) & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_TSD | \
X86_CR4_OSXSAVE | X86_CR4_SMEP | \
--
2.13.6
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 6/9] xen/x86: use flag byte for decision whether xen_cr3 is valid
Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to
be switched on entry to Xen, or negative for keeping the value while
indicating not to restore %cr3, or positive in case %cr3 is to be
restored.
Switch to use a flag byte instead of a negative xen_cr3 value in order
to allow %cr3 values with the high bit set in case we want to keep TLB
entries when using the PCID feature.
This reduces the number of branches in interrupt handling and results
in better performance (e.g. parallel make of the Xen hypervisor on my
system was using about 3% less system time).
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V3:
- renamed use_xen_cr3 to better fitting use_pv_cr3
- corrected comment regarding semantics of use_pv_cr3 (Jan Beulich)
- prefer 32-bit operations over 8- or 16-bit ones (Jan Beulich)
---
xen/arch/x86/domain.c | 1 +
xen/arch/x86/mm.c | 3 +-
xen/arch/x86/smpboot.c | 2 ++
xen/arch/x86/x86_64/asm-offsets.c | 1 +
xen/arch/x86/x86_64/compat/entry.S | 5 ++--
xen/arch/x86/x86_64/entry.S| 59 --
xen/include/asm-x86/current.h | 12 +---
7 files changed, 41 insertions(+), 42 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 9b001a03ec..801ac33810 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1696,6 +1696,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
ASSERT(local_irq_is_enabled());
+get_cpu_info()->use_pv_cr3 = false;
get_cpu_info()->xen_cr3 = 0;
if ( unlikely(dirty_cpu != cpu) && dirty_cpu != VCPU_CPU_CLEAN )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 73a38e8715..4997047edf 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -517,7 +517,8 @@ void write_ptbase(struct vcpu *v)
}
else
{
-/* Make sure to clear xen_cr3 before pv_cr3. */
+/* Make sure to clear use_pv_cr3 and xen_cr3 before pv_cr3. */
+cpu_info->use_pv_cr3 = false;
cpu_info->xen_cr3 = 0;
/* switch_cr3_cr4() serializes. */
switch_cr3_cr4(v->arch.cr3, new_cr4);
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 980192e71f..d21020c510 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -324,6 +324,7 @@ void start_secondary(void *unused)
*/
spin_debug_disable();
+get_cpu_info()->use_pv_cr3 = false;
get_cpu_info()->xen_cr3 = 0;
get_cpu_info()->pv_cr3 = 0;
@@ -1123,6 +1124,7 @@ void __init smp_prepare_boot_cpu(void)
per_cpu(scratch_cpumask, cpu) = &scratch_cpu0mask;
#endif
+get_cpu_info()->use_pv_cr3 = false;
get_cpu_info()->xen_cr3 = 0;
get_cpu_info()->pv_cr3 = 0;
}
diff --git a/xen/arch/x86/x86_64/asm-offsets.c
b/xen/arch/x86/x86_64/asm-offsets.c
index 9e2aefb00f..7ad024cf37 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -144,6 +144,7 @@ void __dummy__(void)
OFFSET(CPUINFO_use_shadow_spec_ctrl, struct cpu_info,
use_shadow_spec_ctrl);
OFFSET(CPUINFO_bti_ist_info, struct cpu_info, bti_ist_info);
OFFSET(CPUINFO_root_pgt_changed, struct cpu_info, root_pgt_changed);
+OFFSET(CPUINFO_use_pv_cr3, struct cpu_info, use_pv_cr3);
DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
BLANK();
diff --git a/xen/arch/x86/x86_64/compat/entry.S
b/xen/arch/x86/x86_64/compat/entry.S
index ae2bb4bf1e..b909977e33 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -210,10 +210,9 @@ ENTRY(cstar_enter)
GET_STACK_END(bx)
mov STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rcx
-neg %rcx
+test %rcx, %rcx
jz.Lcstar_cr3_okay
-mov %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
-neg %rcx
+movb $0, STACK_CPUINFO_FIELD(use_pv_cr3)(%rbx)
mov %rcx, %cr3
movq $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
.Lcstar_cr3_okay:
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 5f0758d64f..8b7d1c48ad 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -154,6 +154,7 @@ restore_all_guest:
rep movsq
.Lrag_copy_done:
mov %r9, STACK_CPUINFO_FIELD(xen_cr3)(%rdx)
+movb $1, STACK_CPUINFO_FIELD(use_pv_cr3)(%rdx)
mov %rax, %cr3
.Lrag_keep_cr3:
@@ -202,14 +203,9 @@ restore_all_xen:
* case we return to late PV exit code (from an NMI or #MC).
*/
GET_STACK_END(bx)
-mov STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rdx
+cmpb $0, STACK_CPUINFO_FIELD(use_pv_cr3)(%rbx)
+UNLIKELY_START(ne, exit_cr3)
mov STACK_CPUINFO_FIELD(pv_cr3)(%rbx), %rax
-test %rdx, %rdx
-/*
- * Ideally the condition would be "nsz", but such doesn't exist,
- * so "g" will have to do.
- */
-UNLIKELY_START(g, exit_cr3)
mov %rax, %cr3
UNLIKELY_END(exit_cr3)
@@ -251,10 +24
[Xen-devel] [PATCH v7 8/9] xen/x86: add some cr3 helpers
Add some helper macros to access the address and pcid parts of cr3.
Use those helpers where appropriate.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V6:
- new patch (Andrew Cooper)
---
xen/arch/x86/debug.c| 2 +-
xen/arch/x86/domain_page.c | 2 +-
xen/include/asm-x86/processor.h | 10 ++
xen/include/asm-x86/x86-defns.h | 4 +++-
4 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index 9159f32db4..a500df01ac 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -98,7 +98,7 @@ dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t
pgd3val)
l2_pgentry_t l2e, *l2t;
l1_pgentry_t l1e, *l1t;
unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3);
-mfn_t mfn = maddr_to_mfn(cr3);
+mfn_t mfn = maddr_to_mfn(cr3_pa(cr3));
DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", vaddr, dp->domain_id,
cr3, pgd3val);
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 11b6a5421a..0c24530ed9 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -51,7 +51,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
if ( (v = idle_vcpu[smp_processor_id()]) == current )
sync_local_execstate();
/* We must now be running on the idle page table. */
-ASSERT(read_cr3() == __pa(idle_pg_table));
+ASSERT(cr3_pa(read_cr3()) == __pa(idle_pg_table));
}
return v;
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 71d32c0333..36628459dc 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -288,6 +288,16 @@ static inline void write_cr3(unsigned long val)
asm volatile ( "mov %0, %%cr3" : : "r" (val) : "memory" );
}
+static inline unsigned long cr3_pa(unsigned long cr3)
+{
+return cr3 & X86_CR3_ADDR_MASK;
+}
+
+static inline unsigned long cr3_pcid(unsigned long cr3)
+{
+return cr3 & X86_CR3_PCID_MASK;
+}
+
static inline unsigned long read_cr4(void)
{
return get_cpu_info()->cr4;
diff --git a/xen/include/asm-x86/x86-defns.h b/xen/include/asm-x86/x86-defns.h
index ff8d66be3c..904041e1ab 100644
--- a/xen/include/asm-x86/x86-defns.h
+++ b/xen/include/asm-x86/x86-defns.h
@@ -45,7 +45,9 @@
/*
* Intel CPU flags in CR3
*/
-#define X86_CR3_NOFLUSH (_AC(1, ULL) << 63)
+#define X86_CR3_NOFLUSH(_AC(1, ULL) << 63)
+#define X86_CR3_ADDR_MASK (PAGE_MASK & PADDR_MASK)
+#define X86_CR3_PCID_MASK _AC(0x0fff, ULL) /* Mask for PCID */
/*
* Intel CPU features in CR4
--
2.13.6
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 1/9] x86/xpti: avoid copying L4 page table contents when possible
For mitigation of Meltdown the current L4 page table is copied to the
cpu local root page table each time a 64 bit pv guest is entered.
Copying can be avoided in cases where the guest L4 page table hasn't
been modified while running the hypervisor, e.g. when handling
interrupts or any hypercall not modifying the L4 page table or %cr3.
So add a per-cpu flag indicating whether the copying should be
performed and set that flag only when loading a new %cr3 or modifying
the L4 page table. This includes synchronization of the cpu local
root page table with other cpus, so add a special synchronization flag
for that case.
A simple performance check (compiling the hypervisor via "make -j 4")
in dom0 with 4 vcpus shows a significant improvement:
- real time drops from 112 seconds to 103 seconds
- system time drops from 142 seconds to 131 seconds
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V7:
- add missing flag setting in shadow code
V6:
- correct an error from rebasing to staging in assembly part
V4:
- move setting of root_pgt_changed flag in flush_area_local() out of
irq disabled section (Jan Beulich)
- move setting of root_pgt_changed in make_cr3() to _toggle_guest_pt()
(Jan Beulich)
- remove most conditionals in write_ptbase() (Jan Beulich)
- don't set root_pgt_changed in do_mmu_update() for modification of
the user page table (Jan Beulich)
V3:
- set flag locally only if affected L4 is active (Jan Beulich)
- add setting flag to flush_area_mask() (Jan Beulich)
- set flag in make_cr3() only if called for current active vcpu
To be applied on top of Jan's "Meltdown band-aid overhead reduction"
series
---
xen/arch/x86/flushtlb.c | 3 +++
xen/arch/x86/mm.c | 36 +++-
xen/arch/x86/mm/shadow/multi.c| 4
xen/arch/x86/pv/domain.c | 2 ++
xen/arch/x86/smp.c| 2 +-
xen/arch/x86/x86_64/asm-offsets.c | 1 +
xen/arch/x86/x86_64/entry.S | 9 +++--
xen/include/asm-x86/current.h | 8
xen/include/asm-x86/flushtlb.h| 2 ++
9 files changed, 51 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 8a7a76b8ff..38cedf3b22 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -160,5 +160,8 @@ unsigned int flush_area_local(const void *va, unsigned int
flags)
local_irq_restore(irqfl);
+if ( flags & FLUSH_ROOT_PGTBL )
+get_cpu_info()->root_pgt_changed = true;
+
return flags;
}
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9fe5583fc3..7d960c742e 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -502,6 +502,7 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
void write_ptbase(struct vcpu *v)
{
+get_cpu_info()->root_pgt_changed = true;
write_cr3(v->arch.cr3);
}
@@ -3699,18 +3700,27 @@ long do_mmu_update(
break;
rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
-/*
- * No need to sync if all uses of the page can be accounted
- * to the page lock we hold, its pinned status, and uses on
- * this (v)CPU.
- */
-if ( !rc && !cpu_has_no_xpti &&
- ((page->u.inuse.type_info & PGT_count_mask) >
- (1 + !!(page->u.inuse.type_info & PGT_pinned) +
- (pagetable_get_pfn(curr->arch.guest_table) == mfn) +
- (pagetable_get_pfn(curr->arch.guest_table_user) ==
-mfn))) )
-sync_guest = true;
+if ( !rc && !cpu_has_no_xpti )
+{
+bool local_in_use = false;
+
+if ( pagetable_get_pfn(curr->arch.guest_table) == mfn )
+{
+local_in_use = true;
+get_cpu_info()->root_pgt_changed = true;
+}
+
+/*
+ * No need to sync if all uses of the page can be
+ * accounted to the page lock we hold, its pinned
+ * status, and uses on this (v)CPU.
+ */
+if ( (page->u.inuse.type_info & PGT_count_mask) >
+ (1 + !!(page->u.inuse.type_info & PGT_pinned) +
+ (pagetable_get_pfn(curr->arch.guest_table_user)
==
+ mfn) + local_in_use) )
+sync_guest = true;
+}
break;
case PGT_writable_page:
@@ -3825,7 +3835,7 @@ long do_mmu_update(
cpumask_andnot(mask, pt_owner->dirty_cpumask, cpumask_of(cpu));
if ( !cpumask_empt
[Xen-devel] [PATCH v7 2/9] xen/x86: add a function for modifying cr3
Instead of having multiple places with more or less identical asm
statements just have one function doing a write to cr3.
As this function should be named write_cr3() rename the current
write_cr3() function to switch_cr3().
Suggested-by: Andrew Copper
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V6:
- new patch
---
xen/arch/x86/flushtlb.c | 4 ++--
xen/arch/x86/mm.c | 2 +-
xen/arch/x86/pv/domain.c| 2 +-
xen/common/efi/runtime.c| 4 ++--
xen/include/asm-x86/flushtlb.h | 2 +-
xen/include/asm-x86/processor.h | 5 +
6 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 38cedf3b22..788c61d81a 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -71,7 +71,7 @@ static void post_flush(u32 t)
this_cpu(tlbflush_time) = t;
}
-void write_cr3(unsigned long cr3)
+void switch_cr3(unsigned long cr3)
{
unsigned long flags, cr4;
u32 t;
@@ -83,7 +83,7 @@ void write_cr3(unsigned long cr3)
cr4 = read_cr4();
write_cr4(cr4 & ~X86_CR4_PGE);
-asm volatile ( "mov %0, %%cr3" : : "r" (cr3) : "memory" );
+write_cr3(cr3);
write_cr4(cr4);
post_flush(t);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 7d960c742e..e245d96a97 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -503,7 +503,7 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
void write_ptbase(struct vcpu *v)
{
get_cpu_info()->root_pgt_changed = true;
-write_cr3(v->arch.cr3);
+switch_cr3(v->arch.cr3);
}
/*
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index b1c40373fa..be40843b05 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -220,7 +220,7 @@ static void _toggle_guest_pt(struct vcpu *v)
get_cpu_info()->root_pgt_changed = true;
/* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
-asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
+write_cr3(v->arch.cr3);
if ( !(v->arch.flags & TF_kernel_mode) )
return;
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 3dbc2e8ee5..4e5ddfef4f 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -111,7 +111,7 @@ struct efi_rs_state efi_rs_enter(void)
lgdt(&gdt_desc);
}
-write_cr3(virt_to_maddr(efi_l4_pgtable));
+switch_cr3(virt_to_maddr(efi_l4_pgtable));
return state;
}
@@ -120,7 +120,7 @@ void efi_rs_leave(struct efi_rs_state *state)
{
if ( !state->cr3 )
return;
-write_cr3(state->cr3);
+switch_cr3(state->cr3);
if ( is_pv_vcpu(current) && !is_idle_vcpu(current) )
{
struct desc_ptr gdt_desc = {
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 052f0fa403..5515f73b7f 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -84,7 +84,7 @@ static inline unsigned long read_cr3(void)
}
/* Write pagetable base and implicitly tick the tlbflush clock. */
-void write_cr3(unsigned long cr3);
+void switch_cr3(unsigned long cr3);
/* flush_* flag fields: */
/*
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index db9988ab33..71d32c0333 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -283,6 +283,11 @@ static inline unsigned long read_cr2(void)
return cr2;
}
+static inline void write_cr3(unsigned long val)
+{
+asm volatile ( "mov %0, %%cr3" : : "r" (val) : "memory" );
+}
+
static inline unsigned long read_cr4(void)
{
return get_cpu_info()->cr4;
--
2.13.6
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 4/9] xen/x86: use invpcid for flushing the TLB
If possible use the INVPCID instruction for flushing the TLB instead of
toggling cr4.pge for that purpose.
While at it remove the dependency on cr4.pge being required for mtrr
loading, as this will be required later anyway.
Add a command line option "invpcid" for controlling the use of
INVPCID (default to true).
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V6:
- reword invpcid parameter description (Andrew Cooper)
- add __read_mostly to use_invpcid definition (Andrew Cooper)
V5:
- use pre_flush() as an initializer in do_tlb_flush() (Jan Beulich)
- introduce boolean use_invpcid instead of clearing X86_FEATURE_INVPCID
(Jan Beulich)
V4:
- option "invpcid" instead of "noinvpcid" (Jan Beulich)
V3:
- new patch
---
docs/misc/xen-command-line.markdown | 9 +
xen/arch/x86/cpu/mtrr/generic.c | 37 ++---
xen/arch/x86/flushtlb.c | 29 +++--
xen/arch/x86/setup.c| 8
xen/include/asm-x86/invpcid.h | 2 ++
5 files changed, 64 insertions(+), 21 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index d4f758487a..451a4fa566 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1380,6 +1380,15 @@ Because responsibility for APIC setup is shared between
Xen and the
domain 0 kernel this option is automatically propagated to the domain
0 command line.
+### invpcid (x86)
+> `= `
+
+> Default: `true`
+
+By default, Xen will use the INVPCID instruction for TLB management if
+it is available. This option can be used to cause Xen to fall back to
+older mechanisms, which are generally slower.
+
### noirqbalance
> `= `
diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index e9c0e5e059..7ba0c3f0fe 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -400,8 +401,10 @@ static DEFINE_SPINLOCK(set_atomicity_lock);
* has been called.
*/
-static void prepare_set(void)
+static bool prepare_set(void)
{
+ unsigned long cr4;
+
/* Note that this is not ideal, since the cache is only
flushed/disabled
for this CPU while the MTRRs are changed, but changing this requires
more invasive changes to the way the kernel boots */
@@ -412,18 +415,24 @@ static void prepare_set(void)
write_cr0(read_cr0() | X86_CR0_CD);
wbinvd();
- /* TLB flushing here relies on Xen always using CR4.PGE. */
- BUILD_BUG_ON(!(XEN_MINIMAL_CR4 & X86_CR4_PGE));
- write_cr4(read_cr4() & ~X86_CR4_PGE);
+ cr4 = read_cr4();
+ if (cr4 & X86_CR4_PGE)
+ write_cr4(cr4 & ~X86_CR4_PGE);
+ else if (use_invpcid)
+ invpcid_flush_all();
+ else
+ write_cr3(read_cr3());
/* Save MTRR state */
rdmsrl(MSR_MTRRdefType, deftype);
/* Disable MTRRs, and set the default type to uncached */
mtrr_wrmsr(MSR_MTRRdefType, deftype & ~0xcff);
+
+ return cr4 & X86_CR4_PGE;
}
-static void post_set(void)
+static void post_set(bool pge)
{
/* Intel (P6) standard MTRRs */
mtrr_wrmsr(MSR_MTRRdefType, deftype);
@@ -432,7 +441,12 @@ static void post_set(void)
write_cr0(read_cr0() & ~X86_CR0_CD);
/* Reenable CR4.PGE (also flushes the TLB) */
- write_cr4(read_cr4() | X86_CR4_PGE);
+ if (pge)
+ write_cr4(read_cr4() | X86_CR4_PGE);
+ else if (use_invpcid)
+ invpcid_flush_all();
+ else
+ write_cr3(read_cr3());
spin_unlock(&set_atomicity_lock);
}
@@ -441,14 +455,15 @@ static void generic_set_all(void)
{
unsigned long mask, count;
unsigned long flags;
+ bool pge;
local_irq_save(flags);
- prepare_set();
+ pge = prepare_set();
/* Actually set the state */
mask = set_mtrr_state();
- post_set();
+ post_set(pge);
local_irq_restore(flags);
/* Use the atomic bitops to update the global mask */
@@ -457,7 +472,6 @@ static void generic_set_all(void)
set_bit(count, &smp_changes_mask);
mask >>= 1;
}
-
}
static void generic_set_mtrr(unsigned int reg, unsigned long base,
@@ -474,11 +488,12 @@ static void generic_set_mtrr(unsigned int reg, unsigned
long base,
{
unsigned long flags;
struct mtrr_var_range *vr;
+ bool pge;
vr = &mtrr_state.var_ranges[reg];
local_irq_save(flags);
- prepare_set();
+ pge = prepare_set();
if (size == 0) {
/* The invalid bit is kept in the mask, so we simply clear the
@@ -499,7 +514,7 @@ static void generic_set_mtrr(unsigned int reg, unsigned
long base,
mtrr_wrmsr(MSR_IA32_MTRR
[Xen-devel] [PATCH v7 3/9] xen/x86: support per-domain flag for xpti
Instead of switching XPTI globally on or off add a per-domain flag for
that purpose. This allows to modify the xpti boot parameter to support
running dom0 without Meltdown mitigations. Using "xpti=nodom0" as boot
parameter will achieve that.
Move the xpti boot parameter handling to xen/arch/x86/pv/domain.c as
it is pv-domain specific.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V6.1:
- address some minor comments (Jan Beulich)
V6:
- modify xpti boot parameter options (Andrew Cooper)
- move xpti_init() code to spec_ctrl.c (Andrew Cooper)
- irework init of per-domain xpti flag (Andrew Cooper)
V3:
- latch get_cpu_info() return value in variable (Jan Beulich)
- call always xpti_domain_init() for pv dom0 (Jan Beulich)
- add __init annotations (Jan Beulich)
- drop per domain XPTI message (Jan Beulich)
- document xpti=default support (Jan Beulich)
- move domain xpti flag into a padding hole (Jan Beulich)
---
docs/misc/xen-command-line.markdown | 14 ++--
xen/arch/x86/mm.c | 17 +++--
xen/arch/x86/pv/dom0_build.c| 1 +
xen/arch/x86/pv/domain.c| 6
xen/arch/x86/setup.c| 19 --
xen/arch/x86/smpboot.c | 4 +--
xen/arch/x86/spec_ctrl.c| 70 +
xen/include/asm-x86/current.h | 3 +-
xen/include/asm-x86/domain.h| 3 ++
xen/include/asm-x86/spec_ctrl.h | 4 +++
10 files changed, 115 insertions(+), 26 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index b353352adf..d4f758487a 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1955,14 +1955,24 @@ clustered mode. The default, given no hint from the
**FADT**, is cluster
mode.
### xpti
-> `= `
+> `= List of [ default | | dom0= | domu= ]`
-> Default: `false` on AMD hardware
+> Default: `false` on hardware not vulnerable to Meltdown (e.g. AMD)
> Default: `true` everywhere else
Override default selection of whether to isolate 64-bit PV guest page
tables.
+`true` activates page table isolation even on hardware not vulnerable by
+Meltdown for all domains.
+
+`false` deactivates page table isolation on all systems for all domains.
+
+`default` sets the default behaviour.
+
+With `dom0` and `domu` it is possible to control page table isolation
+for dom0 or guest domains only.
+
### xsave
> `= `
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index e245d96a97..9c36614099 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -502,8 +502,21 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
void write_ptbase(struct vcpu *v)
{
-get_cpu_info()->root_pgt_changed = true;
-switch_cr3(v->arch.cr3);
+struct cpu_info *cpu_info = get_cpu_info();
+
+if ( is_pv_vcpu(v) && v->domain->arch.pv_domain.xpti )
+{
+cpu_info->root_pgt_changed = true;
+cpu_info->pv_cr3 = __pa(this_cpu(root_pgt));
+switch_cr3(v->arch.cr3);
+}
+else
+{
+/* Make sure to clear xen_cr3 before pv_cr3; switch_cr3() serializes.
*/
+cpu_info->xen_cr3 = 0;
+switch_cr3(v->arch.cr3);
+cpu_info->pv_cr3 = 0;
+}
}
/*
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 5b4325b87f..d148395919 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -387,6 +387,7 @@ int __init dom0_construct_pv(struct domain *d,
if ( compat32 )
{
d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 1;
+d->arch.pv_domain.xpti = false;
v->vcpu_info = (void *)&d->shared_info->compat.vcpu_info[0];
if ( setup_compat_arg_xlat(v) != 0 )
BUG();
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index be40843b05..ce1a1a9d35 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
static void noreturn continue_nonidle_domain(struct vcpu *v)
@@ -75,6 +76,8 @@ int switch_compat(struct domain *d)
d->arch.x87_fip_width = 4;
+d->arch.pv_domain.xpti = false;
+
return 0;
undo_and_fail:
@@ -205,6 +208,9 @@ int pv_domain_initialise(struct domain *d)
/* 64-bit PV guest by default. */
d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
+d->arch.pv_domain.xpti = opt_xpti & (is_hardware_domain(d)
+ ? OPT_XPTI_DOM0 : OPT_XPTI_DOMU);
+
return 0;
fail:
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b2baee3d2c..f803980b97 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -169,9 +169,6 @@ static int __init parse_smap_param(const char *s)
}
custom_param("smap", parse_smap_param);
-static int8_t __initdata opt_xpti = -1;
-boolean_param("xpti", opt_xpti);
-
bool __read_mostly acpi_disabled;
bool __initdata acpi_force;
static char __initdata acpi_param[10] = "";
@@ -1546,22 +1543,6 @
[Xen-devel] [PATCH v7 5/9] xen/x86: disable global pages for domains with XPTI active
Instead of flushing the TLB from global pages when switching address
spaces with XPTI being active just disable global pages via %cr4
completely when a domain subject to XPTI is active. This avoids the
need for extra TLB flushes as loading %cr3 will remove all TLB
entries.
In order to avoid states with cr3/cr4 having inconsistent values
(e.g. global pages being activated while cr3 already specifies a XPTI
address space) move loading of the new cr4 value to write_ptbase()
(actually to switch_cr3_cr4() called by write_ptbase()).
This requires to use switch_cr3_cr4() instead of write_ptbase() when
building dom0 in order to avoid setting cr4 with cr4.smap set.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V7:
- use switch_cr3_cr4() in dom0_build.c
V6:
- don't call read_cr4() multiple times in switch_cr3_cr4()
(Andrew Cooper)
V4:
- don't use mmu_cr4_features for setting new cr4 value (Jan Beulich)
- use simpler scheme for setting X86_CR4_PGE in
pv_guest_cr4_to_real_cr4() (Jan Beulich)
V3:
- move cr4 loading for all domains from *_ctxt_switch_to() to
write_cr3_cr4() called by write_ptbase() (Jan Beulich)
- rebase
---
xen/arch/x86/domain.c | 5 -
xen/arch/x86/flushtlb.c| 17 -
xen/arch/x86/mm.c | 14 +++---
xen/arch/x86/pv/dom0_build.c | 6 +++---
xen/arch/x86/x86_64/entry.S| 10 --
xen/common/efi/runtime.c | 4 ++--
xen/include/asm-x86/domain.h | 3 ++-
xen/include/asm-x86/flushtlb.h | 2 +-
8 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3d9c19d055..9b001a03ec 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1523,17 +1523,12 @@ void paravirt_ctxt_switch_from(struct vcpu *v)
void paravirt_ctxt_switch_to(struct vcpu *v)
{
root_pgentry_t *root_pgt = this_cpu(root_pgt);
-unsigned long cr4;
if ( root_pgt )
root_pgt[root_table_offset(PERDOMAIN_VIRT_START)] =
l4e_from_page(v->domain->arch.perdomain_l3_pg,
__PAGE_HYPERVISOR_RW);
-cr4 = pv_guest_cr4_to_real_cr4(v);
-if ( unlikely(cr4 != read_cr4()) )
-write_cr4(cr4);
-
if ( unlikely(v->arch.debugreg[7] & DR7_ACTIVE_MASK) )
activate_debugregs(v);
diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index fc3b0a3268..e28bf04a37 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -89,20 +89,27 @@ static void do_tlb_flush(void)
post_flush(t);
}
-void switch_cr3(unsigned long cr3)
+void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
{
-unsigned long flags, cr4;
+unsigned long flags, old_cr4;
u32 t;
/* This non-reentrant function is sometimes called in interrupt context. */
local_irq_save(flags);
t = pre_flush();
-cr4 = read_cr4();
-write_cr4(cr4 & ~X86_CR4_PGE);
+old_cr4 = read_cr4();
+if ( old_cr4 & X86_CR4_PGE )
+{
+old_cr4 = cr4 & ~X86_CR4_PGE;
+write_cr4(old_cr4);
+}
+
write_cr3(cr3);
-write_cr4(cr4);
+
+if ( old_cr4 != cr4 )
+write_cr4(cr4);
post_flush(t);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9c36614099..73a38e8715 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -503,20 +503,28 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
void write_ptbase(struct vcpu *v)
{
struct cpu_info *cpu_info = get_cpu_info();
+unsigned long new_cr4;
+
+new_cr4 = (is_pv_vcpu(v) && !is_idle_vcpu(v))
+ ? pv_guest_cr4_to_real_cr4(v)
+ : ((read_cr4() & ~X86_CR4_TSD) | X86_CR4_PGE);
if ( is_pv_vcpu(v) && v->domain->arch.pv_domain.xpti )
{
cpu_info->root_pgt_changed = true;
cpu_info->pv_cr3 = __pa(this_cpu(root_pgt));
-switch_cr3(v->arch.cr3);
+switch_cr3_cr4(v->arch.cr3, new_cr4);
}
else
{
-/* Make sure to clear xen_cr3 before pv_cr3; switch_cr3() serializes.
*/
+/* Make sure to clear xen_cr3 before pv_cr3. */
cpu_info->xen_cr3 = 0;
-switch_cr3(v->arch.cr3);
+/* switch_cr3_cr4() serializes. */
+switch_cr3_cr4(v->arch.cr3, new_cr4);
cpu_info->pv_cr3 = 0;
}
+
+ASSERT(is_pv_vcpu(v) || read_cr4() == mmu_cr4_features);
}
/*
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index d148395919..4465a059a8 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -717,7 +717,7 @@ int __init dom0_construct_pv(struct domain *d,
update_cr3(v);
/* We run on dom0's page tables for the final part of the build process. */
-write_ptbase(v);
+switch_cr3_cr4(v->arch.cr3, read_cr4());
mapcache_override_current(v);
/* Copy the OS image and free temporary buffer. */
@@ -738,7 +738,7 @@ int __init dom0_construct_pv(struct domain *d,
(parms.virt_hypercall >= v_end) )
{
mapc
[Xen-devel] [GIT PULL] xen: fixes for 4.17-rc1
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.17-rc1-tag xen: fixes for 4.17-rc1 It contains only a few fixes of Xen related core code and drivers. Thanks. Juergen arch/x86/xen/enlighten_pv.c | 8 arch/x86/xen/xen-head.S | 4 +++- drivers/acpi/processor_perflib.c | 11 +-- drivers/xen/xen-acpi-processor.c | 30 +++--- drivers/xen/xenbus/xenbus_dev_frontend.c | 16 drivers/xen/xenbus/xenbus_xs.c | 4 +++- include/acpi/processor.h | 2 ++ include/xen/interface/features.h | 23 +++ 8 files changed, 79 insertions(+), 19 deletions(-) Boris Ostrovsky (1): xen/pvh: Indicate XENFEAT_linux_rsdp_unrestricted to Xen Dan Carpenter (1): xen/acpi: off by one in read_acpi_id() Jason Andryuk (1): x86/xen: Delay get_cpu_cap until stack canary is established Joao Martins (1): xen/acpi: upload _PSD info for non Dom0 CPUs too Simon Gaiser (3): xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling xen: xenbus: Catch closing of non existent transactions xen: xenbus_dev_frontend: Verify body of XS_TRANSACTION_END ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Linux Dom0 console handling (again)
On 04/12/2018 04:06 AM, Jan Beulich wrote:
> Jürgen, Boris,
>
> looks like commit 47b02f4c62 ("x86/xen: add tty0 and hvc0 as
> preferred consoles for dom0") doesn't get us quite there yet - non-
> kernel boot output (and a console prompt) still doesn't appear on
> the screen.
Hmm.. I get both kernel and systemd output, as well as console prompt,
on both serial and screen.
Is there a specific set of console-related boot options that causes this
problem?
-boris
> For now I'm using
>
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -1409,8 +1409,11 @@ asmlinkage __visible void __init xen_sta
> xen_boot_params_init_edd();
> }
>
> - add_preferred_console("tty", 0, NULL);
> + if (!boot_params.screen_info.orig_video_isVGA)
> + add_preferred_console("tty", 0, NULL);
> add_preferred_console("hvc", 0, NULL);
> + if (boot_params.screen_info.orig_video_isVGA)
> + add_preferred_console("tty", 0, NULL);
>
> #ifdef CONFIG_PCI
> /* PCI BIOS service won't work from a PV guest. */
>
> but that looks more like a hack, not the least because
> - orig_video_isVGA is always set for Dom0 (independent of whether
> there actually is any VGA, let alone the question of whether there's
> any monitor connected),
> - XenoLinux iirc had non-kernel output (but not the prompt) appear
> on both the screen and the serial console (albeit that may have
> been only with older Linux, i.e. I'm not certain this not being the
> case anymore is an effect of the Xen-specific pieces being
> different).
>
> Thoughts?
>
> Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RESEND] xen/sndif: Sync up with the canonical definition in Xen
On 04/12/2018 01:26 PM, Oleksandr Andrushchenko wrote: > This is the sync up with the canonical definition of the sound > protocol in Xen: > > 1. Protocol version was referenced in the protocol description, >but missed its definition. Fixed by adding a constant >for current protocol version. > > 2. Some of the request descriptions have "reserved" fields >missed: fixed by adding corresponding entries. > > 3. Extend the size of the requests and responses to 64 octets. >Bump protocol version to 2. > > 4. Add explicit back and front synchronization >In order to provide explicit synchronization between backend and >frontend the following changes are introduced in the protocol: > - add new ring buffer for sending asynchronous events from > backend to frontend to report number of bytes played by the > frontend (XENSND_EVT_CUR_POS) > - introduce trigger events for playback control: start/stop/pause/resume > - add "req-" prefix to event-channel and ring-ref to unify naming > of the Xen event channels for requests and events > > 5. Add explicit back and front parameter negotiation >In order to provide explicit stream parameter negotiation between >backend and frontend the following changes are introduced in the protocol: >add XENSND_OP_HW_PARAM_QUERY request to read/update >configuration space for the parameters given: request passes >desired parameter's intervals/masks and the response to this request >returns allowed min/max intervals/masks to be used. > > Signed-off-by: Oleksandr Andrushchenko > Signed-off-by: Oleksandr Grytsov > Cc: Konrad Rzeszutek Wilk > Cc: Takashi Iwai > --- Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RESEND] xen/sndif: Sync up with the canonical definition in Xen
This is the sync up with the canonical definition of the sound protocol in Xen: 1. Protocol version was referenced in the protocol description, but missed its definition. Fixed by adding a constant for current protocol version. 2. Some of the request descriptions have "reserved" fields missed: fixed by adding corresponding entries. 3. Extend the size of the requests and responses to 64 octets. Bump protocol version to 2. 4. Add explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events 5. Add explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameters given: request passes desired parameter's intervals/masks and the response to this request returns allowed min/max intervals/masks to be used. Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai --- include/xen/interface/io/sndif.h | 322 +-- 1 file changed, 306 insertions(+), 16 deletions(-) diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h index 5c918276835e..78bb5d9f8d83 100644 --- a/include/xen/interface/io/sndif.h +++ b/include/xen/interface/io/sndif.h @@ -36,6 +36,13 @@ #include "ring.h" #include "../grant_table.h" +/* + ** + * Protocol version + ** + */ +#define XENSND_PROTOCOL_VERSION2 + /* ** * Feature and Parameter Negotiation @@ -106,6 +113,8 @@ * * /local/domain/1/device/vsnd/0/0/0/ring-ref = "386" * /local/domain/1/device/vsnd/0/0/0/event-channel = "15" + * /local/domain/1/device/vsnd/0/0/0/evt-ring-ref = "1386" + * /local/domain/1/device/vsnd/0/0/0/evt-event-channel = "215" * *-- Stream 1, capture * @@ -115,6 +124,8 @@ * * /local/domain/1/device/vsnd/0/0/1/ring-ref = "384" * /local/domain/1/device/vsnd/0/0/1/event-channel = "13" + * /local/domain/1/device/vsnd/0/0/1/evt-ring-ref = "1384" + * /local/domain/1/device/vsnd/0/0/1/evt-event-channel = "213" * *--- PCM device 1 * @@ -128,6 +139,8 @@ * * /local/domain/1/device/vsnd/0/1/0/ring-ref = "387" * /local/domain/1/device/vsnd/0/1/0/event-channel = "151" + * /local/domain/1/device/vsnd/0/1/0/evt-ring-ref = "1387" + * /local/domain/1/device/vsnd/0/1/0/evt-event-channel = "351" * *--- PCM device 2 * @@ -140,6 +153,8 @@ * * /local/domain/1/device/vsnd/0/2/0/ring-ref = "389" * /local/domain/1/device/vsnd/0/2/0/event-channel = "152" + * /local/domain/1/device/vsnd/0/2/0/evt-ring-ref = "1389" + * /local/domain/1/device/vsnd/0/2/0/evt-event-channel = "452" * ** *Backend XenBus Nodes @@ -285,6 +300,23 @@ * The Xen grant reference granting permission for the backend to map * a sole page in a single page sized ring buffer. * + *- Stream Event Transport Parameters - + * + * This communication path is used to deliver asynchronous events from backend + * to frontend, set up per stream. + * + * evt-event-channel + * Values: + * + * The identifier of the Xen event channel used to signal activity + * in the ring buffer. + * + * evt-ring-ref + * Values: + * + * The Xen grant reference granting permission for the backend to map + * a sole page in a single page sized ring buffer. + * ** * STATE DIAGRAMS ** @@ -432,6 +464,20 @@ #define XENSND_OP_GET_VOLUME 5 #define XENSND_OP_MUTE 6 #define XENSND_OP_UNMUTE 7 +#define XENSND_OP_TRIGGER 8 +#define XENSND_OP_HW_PARAM_QUERY 9 + +#define XENSND_OP_TRIGGER_START
Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin
On Thu, 2018-04-12 at 17:38 +0200, Dario Faggioli wrote:
> On Thu, 2018-04-12 at 15:15 +0200, Dario Faggioli wrote:
> > On Thu, 2018-04-12 at 14:45 +0200, Olaf Hering wrote:
> > >
> > > dies after the first iteration.
> > >
> > > BUG_ON(!test_bit(_VPF_migrating, &prev->pause_flags));
> > >
>
> Update. I replaced this:
>
Olaf, new patch! :-)
FTR, a previous version of this (where I was not printing
smp_processor_id() and prev->is_running), produced the output that I am
attaching below.
Looks to me like, while on the crashing CPU, we are here [*]:
void context_saved(struct vcpu *prev)
{
...
if ( unlikely(prev->pause_flags & VPF_migrating) )
{
unsigned long flags;
spinlock_t *lock = vcpu_schedule_lock_irqsave(prev, &flags);
if (vcpu_runnable(prev) || !test_bit(_VPF_migrating,
&prev->pause_flags))
printk("CPU %u: d%uv%d isr=%u runnbl=%d proc=%d pf=%lu orq=%d
csf=%u\n",
smp_processor_id(), prev->domain->domain_id, prev->vcpu_id,
prev->is_running, vcpu_runnable(prev),
prev->processor, prev->pause_flags,
SCHED_OP(vcpu_scheduler(prev), onrunq, prev),
SCHED_OP(vcpu_scheduler(prev), csflags, prev));
[*]
if ( prev->runstate.state == RUNSTATE_runnable )
vcpu_runstate_change(prev, RUNSTATE_offline, NOW());
BUG_ON(curr_on_cpu(prev->processor) == prev);
SCHED_OP(vcpu_scheduler(prev), sleep, prev);
vcpu_schedule_unlock_irqrestore(lock, flags, prev);
vcpu_migrate(prev);
}
}
On the "other CPU", we might be around here [**]:
static void vcpu_migrate(struct vcpu *v)
{
...
if ( v->is_running ||
!test_and_clear_bit(_VPF_migrating, &v->pause_flags) )
{
sched_spin_unlock_double(old_lock, new_lock, flags);
return;
}
vcpu_move_locked(v, new_cpu);
sched_spin_unlock_double(old_lock, new_lock, flags);
[**]
if ( old_cpu != new_cpu )
sched_move_irqs(v);
/* Wake on new CPU. */
vcpu_wake(v);
}
(XEN) d10v1 runnbl=0 proc=22 pf=1 orq=0 csf=4
(XEN) d10v0 runnbl=1 proc=20 pf=0 orq=0 csf=4
(XEN) d10v0 runnbl=1 proc=25 pf=0 orq=0 csf=4
(XEN) d10v2 runnbl=1 proc=31 pf=0 orq=0 csf=4
(XEN) d10v2 runnbl=1 proc=10 pf=0 orq=1 csf=0
(XEN) d10v0 runnbl=1 proc=30 pf=0 orq=0 csf=4
(XEN) d10v0 runnbl=1 proc=15 pf=0 orq=0 csf=4
(XEN) d10v3 runnbl=1 proc=13 pf=0 orq=1 csf=0
(XEN) d10v2 runnbl=1 proc=39 pf=0 orq=0 csf=4
(XEN) d10v3 runnbl=1 proc=32 pf=0 orq=0 csf=4
(XEN) d10v2 runnbl=1 proc=20 pf=0 orq=0 csf=4
(XEN) d10v2 runnbl=1 proc=20 pf=0 orq=0 csf=4
(XEN) d10v1 runnbl=0 proc=26 pf=1 orq=0 csf=4
(XEN) d10v3 runnbl=1 proc=16 pf=0 orq=0 csf=4
(XEN) Xen BUG at sched_credit.c:877
(XEN) [ Xen-4.11.20180411T100655.82540b66ce-180412155659 x86_64 debug=y
Not tainted ]
(XEN) CPU:16
(XEN) RIP:e008:[]
sched_credit.c#csched_vcpu_migrate+0x52/0x54
(XEN) RFLAGS: 00010006 CONTEXT: hypervisor (d6v0)
(XEN) rax: 8300779c9000 rbx: 0012 rcx: 830adac719f0
(XEN) rdx: 0012 rsi: 8300779b2000 rdi: 0033ff8bb000
(XEN) rbp: 83087cfb7ce8 rsp: 83087cfb7ce8 r8: 0010
(XEN) r9: r10: 00ff00ff00ff00ff r11: 0f0f0f0f0f0f0f0f
(XEN) r12: 83047fe82188 r13: 83047fe70188 r14: 82d0805c7180
(XEN) r15: 8300779b2000 cr0: 8005003b cr4: 26e0
(XEN) cr3: 000f8404b000 cr2: 7f18dfeca000
(XEN) fsb: gsb: gss:
(XEN) ds: es: fs: gs: ss: cs: e008
(XEN) Xen code around
(sched_credit.c#csched_vcpu_migrate+0x52/0x54):
(XEN) 5d c3 0f 0b 0f 0b 0f 0b <0f> 0b 55 48 89 e5 48 8d 05 26 a9 39 00 48 8b 57
(XEN) Xen stack trace from rsp=83087cfb7ce8:
(XEN)83087cfb7cf8 82d080239419 83087cfb7d68 82d08023a8d8
(XEN)82d0805c7160 82d0805c7180 01ff83087cfb7d78 00120010
(XEN)0092 0296 0003 8300779b2000
(XEN)83047fe82188 0292 0004 82d0805b2520
(XEN)83087cfb7db8 82d08023c795 83087cfb7d98 8300779b2000
(XEN)83087cfb7db8 8300779c9000 8300779b2000 830ad6463000
(XEN)0010 830adad26000 83087cfb7e08 82d08027a538
(XEN)83087cfb7dd8 82d0802a8510 83087cfb7e08 8300779b2000
(XEN)8300779c9000 83047fe82188 008405ba3022 0003
(XEN)83087cfb7e98 82d0802397a9 8300779b2560 83047fe821a0
(XEN)001000fb7e58 83047fe82180 82d080328ba1 8300779b2000
(XEN)830adad26000 8300779c9000 01c9c380 82d080302000
(XEN)8300779b2000 82d08059c480 82d08059bc80
(XEN)83087cfb7fff 82d0805a3c80 83087cfb7ed8 82d08023d552
(XEN)82d080328ba1
Re: [Xen-devel] [PATCH 0/5] for-linux/sndif: add explicit back and front synchronization
On 04/12/2018 08:13 PM, Boris Ostrovsky wrote: On 04/12/2018 12:55 PM, Oleksandr Andrushchenko wrote: On 04/12/2018 07:55 PM, Boris Ostrovsky wrote: On 04/12/2018 12:11 PM, Oleksandr Andrushchenko wrote: Hello, Konrad, Takashi! Could you please review the *Linux Kernel* version of the changes? As I said in the cover letter below there is no functional changes comparing to the corresponding Xen version, but spaces to tabs. Still, formally, I have to drop the R-b tags and request for the new review. Is there any reason why this all can't be done in a single patch? Just to preserve the history of the changes? The history is tracked in Xen tree and since you are only updating the header file I don't think we gain much by repeating it here. makes sense This is just syncing up with the canonical definition in Xen. Do you want me to squash and resend? Yes, please. will do -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/5] for-linux/sndif: add explicit back and front synchronization
On 04/12/2018 12:55 PM, Oleksandr Andrushchenko wrote: > On 04/12/2018 07:55 PM, Boris Ostrovsky wrote: >> On 04/12/2018 12:11 PM, Oleksandr Andrushchenko wrote: >>> Hello, Konrad, Takashi! >>> >>> Could you please review the *Linux Kernel* version of the changes? >>> As I said in the cover letter below there is no functional changes >>> comparing to the corresponding Xen version, but spaces to tabs. >>> Still, formally, I have to drop the R-b tags and request for the new >>> review. >> Is there any reason why this all can't be done in a single patch? > Just to preserve the history of the changes? The history is tracked in Xen tree and since you are only updating the header file I don't think we gain much by repeating it here. >> This is just syncing up with the canonical definition in Xen. > Do you want me to squash and resend? Yes, please. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11 0/3] x86/pv: Fixes to debug register handling
At this point, I think these patches are plausible candidates for inclusion into 4.11. Whether they want backporting is a slightly harder matter, as these patches necesserily alter some error values for the get/set_debug_reg() hypercalls. If however there is objection to these going into 4.11, they can sit in x86-next until the 4.12 window opens. Andrew Cooper (3): x86/pv: Introduce and use x86emul_read_dr() x86/pv: Introduce and use x86emul_write_dr() x86/traps: Misc non-functional improvements to set_debugreg() xen/arch/x86/pv/emul-priv-op.c | 24 +-- xen/arch/x86/pv/misc-hypercalls.c | 18 ++--- xen/arch/x86/traps.c | 67 --- xen/arch/x86/x86_emulate.c | 73 ++ xen/arch/x86/x86_emulate/x86_emulate.h | 5 +++ 5 files changed, 127 insertions(+), 60 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/3] x86/traps: Misc non-functional improvements to set_debugreg()
* Change 'int i' to being unsigned, and move it into its most narrow scope.
* Fold the access_ok() checks for %dr{0..3}. This halves the compiled size
of the function.
* Additional newlines in appropriate places.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
---
xen/arch/x86/traps.c | 35 +--
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 0073c8f..c624fb4 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2006,34 +2006,24 @@ void activate_debugregs(const struct vcpu *curr)
*/
long set_debugreg(struct vcpu *v, unsigned int reg, unsigned long value)
{
-int i;
struct vcpu *curr = current;
switch ( reg )
{
-case 0:
-if ( !access_ok(value, sizeof(long)) )
-return -EPERM;
-if ( v == curr )
-write_debugreg(0, value);
-break;
-case 1:
-if ( !access_ok(value, sizeof(long)) )
-return -EPERM;
-if ( v == curr )
-write_debugreg(1, value);
-break;
-case 2:
-if ( !access_ok(value, sizeof(long)) )
-return -EPERM;
-if ( v == curr )
-write_debugreg(2, value);
-break;
-case 3:
+case 0 ... 3:
if ( !access_ok(value, sizeof(long)) )
return -EPERM;
+
if ( v == curr )
-write_debugreg(3, value);
+{
+switch ( reg )
+{
+case 0: write_debugreg(0, value); break;
+case 1: write_debugreg(1, value); break;
+case 2: write_debugreg(2, value); break;
+case 3: write_debugreg(3, value); break;
+}
+}
break;
case 4:
@@ -2085,7 +2075,7 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
/* DR7.{G,L}E = 0 => debugging disabled for this domain. */
if ( value & DR7_ACTIVE_MASK )
{
-unsigned int io_enable = 0;
+unsigned int i, io_enable = 0;
for ( i = DR_CONTROL_SHIFT; i < 32; i += DR_CONTROL_SIZE )
{
@@ -2113,6 +2103,7 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
if ( v == curr )
write_debugreg(7, value);
break;
+
default:
return -ENODEV;
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/3] x86/pv: Introduce and use x86emul_write_dr()
set_debugreg() has several bugs:
* %dr4/5 should function correctly as aliases of %dr6/7 when CR4.DE is clear.
* Attempting to set the upper 32 bits of %dr6/7 should fail with #GP[0]
rather than be silently corrected and complete.
* For emulation, the #UD and #GP[0] cases need properly distinguishing. Use
-ENODEV for #UD cases, leaving -EINVAL (bad bits) and -EPERM (not allowed to
use that valid bit) as before for hypercall callers.
* A write which clears %dr7.L/G leaves the IO shadow intact, meaning that
subsequent reads of %dr7 will see stale IO watchpoint configuration.
Implement x86emul_write_dr() as a thin wrapper around set_debugreg().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
---
xen/arch/x86/pv/emul-priv-op.c | 9 +
xen/arch/x86/traps.c | 32 +++-
xen/arch/x86/x86_emulate.c | 24
xen/arch/x86/x86_emulate/x86_emulate.h | 2 ++
4 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 61702d9..15f42b3 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -794,13 +794,6 @@ static int write_cr(unsigned int reg, unsigned long val,
return X86EMUL_UNHANDLEABLE;
}
-static int write_dr(unsigned int reg, unsigned long val,
-struct x86_emulate_ctxt *ctxt)
-{
-return do_set_debugreg(reg, val) == 0
- ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
-}
-
static inline uint64_t guest_misc_enable(uint64_t val)
{
val &= ~(MSR_IA32_MISC_ENABLE_PERF_AVAIL |
@@ -1293,7 +1286,7 @@ static const struct x86_emulate_ops priv_op_ops = {
.read_cr = read_cr,
.write_cr= write_cr,
.read_dr = x86emul_read_dr,
-.write_dr= write_dr,
+.write_dr= x86emul_write_dr,
.write_xcr = x86emul_write_xcr,
.read_msr= read_msr,
.write_msr = write_msr,
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 63c6569..0073c8f 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1998,6 +1998,12 @@ void activate_debugregs(const struct vcpu *curr)
}
}
+/*
+ * Used by hypercalls and the emulator.
+ * -ENODEV => #UD
+ * -EINVAL => #GP Invalid bit
+ * -EPERM => #GP Valid bit, but not permitted to use
+ */
long set_debugreg(struct vcpu *v, unsigned int reg, unsigned long value)
{
int i;
@@ -2029,7 +2035,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
if ( v == curr )
write_debugreg(3, value);
break;
+
+case 4:
+if ( v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE )
+return -ENODEV;
+
+/* Fallthrough */
case 6:
+/* The upper 32 bits are strictly reserved. */
+if ( value != (uint32_t)value )
+return -EINVAL;
+
/*
* DR6: Bits 4-11,16-31 reserved (set to 1).
* Bit 12 reserved (set to 0).
@@ -2039,7 +2055,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
if ( v == curr )
write_debugreg(6, value);
break;
+
+case 5:
+if ( v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE )
+return -ENODEV;
+
+/* Fallthrough */
case 7:
+/* The upper 32 bits are strictly reserved. */
+if ( value != (uint32_t)value )
+return -EINVAL;
+
/*
* DR7: Bit 10 reserved (set to 1).
* Bits 11-12,14-15 reserved (set to 0).
@@ -2052,6 +2078,10 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
*/
if ( value & DR_GENERAL_DETECT )
return -EPERM;
+
+/* Zero the IO shadow before recalculating the real %dr7 */
+v->arch.debugreg[5] = 0;
+
/* DR7.{G,L}E = 0 => debugging disabled for this domain. */
if ( value & DR7_ACTIVE_MASK )
{
@@ -2084,7 +2114,7 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
write_debugreg(7, value);
break;
default:
-return -EINVAL;
+return -ENODEV;
}
v->arch.debugreg[reg] = value;
diff --git a/xen/arch/x86/x86_emulate.c b/xen/arch/x86/x86_emulate.c
index d260bdc..30f89ad 100644
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -15,6 +15,7 @@
#include /* current_cpu_info */
#include
#include /* cpu_has_amd_erratum() */
+#include
/* Avoid namespace pollution. */
#undef cmpxchg
@@ -127,6 +128,29 @@ int x86emul_read_dr(unsigned int reg, unsigned long *val,
return X86EMUL_OKAY;
}
+int x86emul_write_dr(unsigned int reg, unsigned long val,
+ struct x86_emulate_ctxt *ctxt)
+{
+struct vcpu *curr = current;
+
+/* HVM support requires a bit more plumbing b
[Xen-devel] [PATCH 1/3] x86/pv: Introduce and use x86emul_read_dr()
do_get_debugreg() has several bugs:
* The %cr4.de condition is inverted. %dr4/5 should be accessible only when
%cr4.de is disabled.
* When %cr4.de is disabled, emulation should yield #UD rather than complete
with zero.
* Using -EINVAL for errors is a broken ABI, as it overlaps with valid values
near the top of the address space.
Introduce a common x86emul_read_dr() handler (as we will eventually want to
add HVM support) which separates its success/failure indication from the data
value, and have do_get_debugreg() call into the handler.
The ABI of do_get_debugreg() remains broken, but switches from -EINVAL to
-ENODEV for compatibility with the changes in the following patch.
Take the opportunity to add a missing local variable block to x86_emulate.c
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
---
xen/arch/x86/pv/emul-priv-op.c | 15 +--
xen/arch/x86/pv/misc-hypercalls.c | 18 +++--
xen/arch/x86/x86_emulate.c | 49 ++
xen/arch/x86/x86_emulate/x86_emulate.h | 3 +++
4 files changed, 56 insertions(+), 29 deletions(-)
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index b456408..61702d9 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -794,19 +794,6 @@ static int write_cr(unsigned int reg, unsigned long val,
return X86EMUL_UNHANDLEABLE;
}
-static int read_dr(unsigned int reg, unsigned long *val,
- struct x86_emulate_ctxt *ctxt)
-{
-unsigned long res = do_get_debugreg(reg);
-
-if ( IS_ERR_VALUE(res) )
-return X86EMUL_UNHANDLEABLE;
-
-*val = res;
-
-return X86EMUL_OKAY;
-}
-
static int write_dr(unsigned int reg, unsigned long val,
struct x86_emulate_ctxt *ctxt)
{
@@ -1305,7 +1292,7 @@ static const struct x86_emulate_ops priv_op_ops = {
.read_segment= read_segment,
.read_cr = read_cr,
.write_cr= write_cr,
-.read_dr = read_dr,
+.read_dr = x86emul_read_dr,
.write_dr= write_dr,
.write_xcr = x86emul_write_xcr,
.read_msr= read_msr,
diff --git a/xen/arch/x86/pv/misc-hypercalls.c
b/xen/arch/x86/pv/misc-hypercalls.c
index 5862130..1619be7 100644
--- a/xen/arch/x86/pv/misc-hypercalls.c
+++ b/xen/arch/x86/pv/misc-hypercalls.c
@@ -30,22 +30,10 @@ long do_set_debugreg(int reg, unsigned long value)
unsigned long do_get_debugreg(int reg)
{
-struct vcpu *curr = current;
+unsigned long val;
+int res = x86emul_read_dr(reg, &val, NULL);
-switch ( reg )
-{
-case 0 ... 3:
-case 6:
-return curr->arch.debugreg[reg];
-case 7:
-return (curr->arch.debugreg[7] |
-curr->arch.debugreg[5]);
-case 4 ... 5:
-return ((curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) ?
-curr->arch.debugreg[reg + 2] : 0);
-}
-
-return -EINVAL;
+return res == X86EMUL_OKAY ? val : -ENODEV;
}
long do_fpu_taskswitch(int set)
diff --git a/xen/arch/x86/x86_emulate.c b/xen/arch/x86/x86_emulate.c
index 0729edc..d260bdc 100644
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -87,3 +87,52 @@ int x86emul_write_xcr(unsigned int reg, uint64_t val,
return X86EMUL_OKAY;
}
+
+/* Called with NULL ctxt in hypercall context. */
+int x86emul_read_dr(unsigned int reg, unsigned long *val,
+struct x86_emulate_ctxt *ctxt)
+{
+struct vcpu *curr = current;
+
+/* HVM support requires a bit more plumbing before it will work. */
+ASSERT(is_pv_vcpu(curr));
+
+switch ( reg )
+{
+case 0 ... 3:
+case 6:
+*val = curr->arch.debugreg[reg];
+break;
+
+case 7:
+*val = (curr->arch.debugreg[7] |
+curr->arch.debugreg[5]);
+break;
+
+case 4 ... 5:
+if ( !(curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) )
+{
+*val = curr->arch.debugreg[reg + 2];
+break;
+}
+
+/* Fallthrough */
+default:
+if ( ctxt )
+x86_emul_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC, ctxt);
+
+return X86EMUL_EXCEPTION;
+}
+
+return X86EMUL_OKAY;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h
b/xen/arch/x86/x86_emulate/x86_emulate.h
index 13385b0..2ae0518 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -722,6 +722,9 @@ int x86emul_read_xcr(unsigned int reg, uint64_t *val,
int x86emul_write_xcr(unsigned int reg, uint64_t val,
struct x86_emulate_ctxt *ctxt);
+int x86emul_read_dr(unsigned int reg, unsigned long *val,
+struct x86_emulate_ctxt *ctxt);
+
#e
Re: [Xen-devel] [PATCH 0/5] for-linux/sndif: add explicit back and front synchronization
On 04/12/2018 07:55 PM, Boris Ostrovsky wrote: On 04/12/2018 12:11 PM, Oleksandr Andrushchenko wrote: Hello, Konrad, Takashi! Could you please review the *Linux Kernel* version of the changes? As I said in the cover letter below there is no functional changes comparing to the corresponding Xen version, but spaces to tabs. Still, formally, I have to drop the R-b tags and request for the new review. Is there any reason why this all can't be done in a single patch? Just to preserve the history of the changes? This is just syncing up with the canonical definition in Xen. Do you want me to squash and resend? -boris Thank you, Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/5] for-linux/sndif: add explicit back and front synchronization
On 04/12/2018 12:11 PM, Oleksandr Andrushchenko wrote: > Hello, Konrad, Takashi! > > Could you please review the *Linux Kernel* version of the changes? > As I said in the cover letter below there is no functional changes > comparing to the corresponding Xen version, but spaces to tabs. > Still, formally, I have to drop the R-b tags and request for the new > review. Is there any reason why this all can't be done in a single patch? This is just syncing up with the canonical definition in Xen. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/7] xen/arm: Restore IRQ affinity after hotplugging a CPU
On Wed, 2018-04-11 at 15:19 +0200, Mirela Simonovic wrote: > Secondary pCPUs will be offlined on system suspend and hotplugged > on resume. When offlining secondary CPUs all interrupts targeted > to those CPUs will be routed to the boot CPU. The boot CPU > is responsible for finalizing suspend procedure. All wake-up > interrupts are therefore targeted to the boot CPU. > There is no wake-up interrupt involved in the process of unpausing domains during resume. So, I that that what you mean is "the interrups that the vcpus receive once they're running again. And even in that case, rather than "All", is it "The interrupts received until the first time the vcpu goes through vcpu_migrate()", as vcpu_migrate() does call sched_move_irq()? Note that I'm not (trying to) being picky, I'm just trying to undestand. :-) > Existing code > was missing the restoration of interrupts affinity after > hotplugging a CPU. > Either use hot-unplug and hotplug, or offline and online. I think the latter is better in this case. > This patch restores the IRQ affinity after > a CPU is hotplugged. > > Signed-off-by: Mirela Simonovic > diff --git a/xen/common/schedule.c b/xen/common/schedule.c > index 343ab6306e..e3956019bc 100644 > --- a/xen/common/schedule.c > +++ b/xen/common/schedule.c > @@ -724,6 +725,9 @@ void restore_vcpu_affinity(struct domain *d) > lock = vcpu_schedule_lock_irq(v); > v->processor = SCHED_OP(vcpu_scheduler(v), pick_cpu, v); > spin_unlock_irq(lock); > + > +if ( affinity_was_broken ) > +sched_move_irqs(v); > But I guess that, more than on whether or not the affinity was broken, you are interested in whether or not v->processor changed. In fact, for the vcpus that had 0 in v->processor at the beginning of this function, and also have 0 in there now, there is no need to call sched_move_irq(), is there? Similarly, if the affinity of a vcpu has not been broken, but pick_cpu end up selecting a different v->processor, you do want to call sched_move_irq(), I think. If I'm right, I think it would be better to do, at the beginning of the for: unsigned int old_cpu = v->processor; And here: if (old_cpu != v->processor) sched_move_irqs(v); And I'd also add a comment (above the if()), briefly saying how this is necessary to match/undo the call work of vcpu_move_nosched() in cpu_disable_scheduler(). Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction
On 12/04/2018, 17:41, "Roger Pau Monne" wrote: On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote: >may work. For me Mon, Wed and Fri’s generally work at those time-slots. >Next week is a little busy for me, so I would prefer the following week. >If you could fill out the following Google poll, if this week works that >would be great. Otherwise please scream. I'm afraid I'm on vacations from the 21st to the 29th of April, so I won't be able to join the meeting unless we move it to the week after. Let's see what people think of the current dates. Roger. Hi, I changed the dates to the week after. Poll so far has been invalidated. See https://doodle.com/poll/gdnmcrvnibmw563n Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122191: regressions - trouble: blocked/fail
flight 122191 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122191/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 122174 build-amd64 6 xen-buildfail REGR. vs. 122174 build-armhf 6 xen-buildfail REGR. vs. 122174 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen f246d42665a6023c248c5b3e374da5691df63f6f baseline version: xen 82540b66ceb9318aa185f2488cbbbe479694de8f Last test of basis 122174 2018-04-11 11:01:17 Z1 days Testing same since 122191 2018-04-12 16:01:30 Z0 days1 attempts People who touched revisions under test: George Dunlap Ian Jackson Lars Kurth jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked 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 Not pushing. commit f246d42665a6023c248c5b3e374da5691df63f6f Author: Ian Jackson Date: Fri Apr 6 18:13:50 2018 +0100 docs/Makefile: Format SUPPORT.md into the toplevel Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth commit 539f93945cad06fd90784716be1dc8d2624b6f66 Author: Ian Jackson Date: Fri Apr 6 18:12:37 2018 +0100 docs/Makefile: Introduce GENERATE_PANDOC_RULE_RAW We are going to want to format SUPPORT.md which does not match the filename patterns in docs/. So provide a way to make an ad-hoc rule using pandoc with the standard options. No functional change in this patch. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth commit 1e4a834a8f5d970e68cff6d9c16710194bc46537 Author: Ian Jackson Date: Fri Apr 6 19:09:16 2018 +0100 docs/gen-html-index: Support documents at the toplevel There are none yet. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth commit 7782db9260d4c6499458de4e8d9866bc0427e143 Author: Ian Jackson Date: Fri Apr 6 19:09:02 2018 +0100 docs/gen-html-index: Extract titles from HTML documents Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth commit a569c6f815fb6a18c64b8f122f5e2bbecd32 Author: Ian Jackson Date: Fri Apr 6 18:16:35 2018 +0100 SUPPORT.md: Syntax: Provide a title rather than a spurious empty section This commits (more or less) this file to be processed with pandoc, rather than other markdown processors. There is, unfortunately, no widely-accepted way to declare a title for the document. I tested feeding the document to markdown(1) on Debian jessie and it reproduced the % line as if it were simple text. I guess many other markdown processors will do something similarly tolerable. My internet searches did not discover a markdown processor that used lines starting with % for something else. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: George Dunlap Acked-by: Lars Kurth commit ebbd0299089a698c39d4ced966df5831944b4305 Author: Ian Jackson Date: Fri Apr 6 15:20:22 2018 +0100 SUPPORT.md: Syntax: Fix a typo "States" Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: George
Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction
On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote: >Hi all, > > > >I had an action to set up a call on discussing the future direction of PCI >Emulation. I CC’ed everyone who raised an interest. I propose to use >Gotomeeting unless there are objections. > > > >As far as I can tell, we have people in the following time-zones: PST to >EST and BST. Not sure where Alexey is based, but it looks as if > > > >16:00 – 17:00 BST > >17:00 – 18:00 BST > >18:00 – 19:00 BST > >BST = UTC+1 > > > >may work. For me Mon, Wed and Fri’s generally work at those time-slots. >Next week is a little busy for me, so I would prefer the following week. >If you could fill out the following Google poll, if this week works that >would be great. Otherwise please scream. I'm afraid I'm on vacations from the 21st to the 29th of April, so I won't be able to join the meeting unless we move it to the week after. Let's see what people think of the current dates. Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction
Hi all, I had an action to set up a call on discussing the future direction of PCI Emulation. I CC’ed everyone who raised an interest. I propose to use Gotomeeting unless there are objections. As far as I can tell, we have people in the following time-zones: PST to EST and BST. Not sure where Alexey is based, but it looks as if 16:00 – 17:00 BST 17:00 – 18:00 BST 18:00 – 19:00 BST BST = UTC+1 may work. For me Mon, Wed and Fri’s generally work at those time-slots. Next week is a little busy for me, so I would prefer the following week. If you could fill out the following Google poll, if this week works that would be great. Otherwise please scream. https://doodle.com/poll/gdnmcrvnibmw563n If you are not on the CC list and want to be CC’ed on the invite, please add your e-mail address to the google poll (after your name) Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 v3 0/11] Provide support matrix generator
Ian Jackson writes ("Re: [PATCH for-4.11 v3 0/11] Provide support matrix
generator"):
> For 8-11 I'm awaiting any opinions about the output and in particular
> whether to include
> > + 11/11] docs/parse-support-md: Identical [*]: only use extra
> > table cell if necessary
AFter IRL discussions with Lars and George I have dropped 11/11.
I have also amended 10/11 to drop the `}' in the multi-row [*]
cells. v4 is below, and I am about to push it and its two
predecessors.
FAOD, these three do not want to go to 4.10.
Thanks,
Ian.
From 6bd34dc33a237df1af0b4bfec212b5c9e8705745 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Thu, 12 Apr 2018 12:59:24 +0100
Subject: [PATCH v4 3/3] docs/parse-support-md: Unify identical [*] in footnotes
A section in the SUPPORT.md may mention multiple
Status, something: Supported
and then have some text. The text is linked to from [*] footnotes
in the table. But, this means that each bit of text needs to
apply to multiple rows.
Before this commit this was a separate [*] after each applicable item.
But multiple apparently-different links to the same thing are annoying
for the reader.
So, in this commit we combine them. Formatting the result is not
entirely trivial.
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
---
v3: New patch
v3.1: Drop `}' in multi-row [*] notes. I put this in to help work
around firefox bugs eg
https://bugzilla.mozilla.org/show_bug.cgi?id=244135
but I have been convinced it is not generally wanted.
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index 83768cf..decda33 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -17,6 +17,7 @@ use Tie::IxHash;
use IO::File;
use CGI qw(escapeHTML);
use Data::Dumper;
+use POSIX;
#-- accumulating input/output --
@@ -285,9 +286,14 @@ sub count_rows_sectnode ($) {
$rows++ if $sectnode->{Status};
$rows += count_rows_sectlist $sectnode->{Children};
$sectnode->{Rows} = $rows;
+$sectnode->{RealSect}{Rows} = $rows;
return $rows;
}
+# Now we have
+# $sectnode->{Rows}
+# $sectnode->{RealSect}{Rows}
+
sub count_rows_sectlist ($) {
my ($sectlist) = @_;
my $rows = 0;
@@ -349,22 +355,34 @@ sub write_output_row ($) {
}
for (my $i=0; $i<@version_urls; $i++) {
my $st = $sectnode->{Status}[$i];
+
+my $colspan = $sectnode->{RealSect}{ColSpan}[$i];
+my $nextcell = '';
+if (!defined $colspan) { # first row of this RealSect
+$colspan= ' colspan="2"';
+if ($sectnode->{RealSect}{HasText}[$i] && $st
+&& $sectnode->{RealSect}{Anchor}) {
+my $rows = $sectnode->{RealSect}{Rows};
+$nextcell = sprintf '', $rows;
+$nextcell .= sprintf '[*]',
+$version_urls[$i], $sectnode->{RealSect}{Anchor};
+$nextcell .= '';
+$colspan = '';
+}
+$sectnode->{RealSect}{ColSpan}[$i] = $colspan;
+}
+
$st //= '-';
-o('');
+o("");
my $end_a = '';
if ($sectnode->{Key} eq 'release-support--xen-version') {
o(sprintf '', $version_urls[$i]);
$end_a = '';
}
o(escapeHTML($st));
-if ($sectnode->{RealSect}{HasText}[$i]
-&& $sectnode->{Status}[$i]
-&& $sectnode->{RealSect}{Anchor}) {
-o(sprintf '[*]',
- $version_urls[$i], $sectnode->{RealSect}{Anchor});
-}
o($end_a);
o('');
+o($nextcell);
}
o("\n");
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 01/11] SUPPORT.md: Syntax: Fix some bullet lists
Ian Jackson writes ("[PATCH 01/11] SUPPORT.md: Syntax: Fix some bullet lists"):
> Continuations of bullet list items must be indented by exactly 4
> spaces (according to pandoc_markdown(5) on Debian jessie).
Please disregard this and the next mail, which were sent by mistake.
I think I managed to kill it after 02/11.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
On 04/11/2018 11:04 AM, Razvan Cojocaru wrote: >> After much debugging, it turns out that the >> "p2m_is_ram(p2mt)" test in hvm_hap_nested_page_fault() fails if I switch >> to the new altp2m view fast enough, and that in turn disables the >> logdirty processing gated on it > > Actually as it turns out the exit doesn't happen at all anymore so > hvm_hap_nested_page_fault() doesn't get called (I've added a printk() in > hvm_hap_nested_page_fault() just before "/* Check access permissions > first, then handle faults */" and it doesn't appear). This is what seems to be happening, the following call traces end up calling p2m_altp2m_propagate_change() after switching to the new altp2m view early: (XEN) Xen call trace: (XEN)[] p2m_altp2m_propagate_change+0x4e/0x508 (XEN)[] p2m-ept.c#ept_set_entry+0x7e4/0x8c4 (XEN)[] p2m_set_entry+0xe2/0x124 (XEN)[] p2m.c#p2m_remove_page+0x1f3/0x209 (XEN)[] guest_physmap_remove_page+0x18c/0x214 (XEN)[] guest_remove_page+0x27b/0x2d3 (XEN)[] do_memory_op+0x502/0x22f8 (XEN)[] pv_hypercall+0x1f4/0x440 (XEN)[] lstar_enter+0x115/0x120 and (XEN) Xen call trace: (XEN)[] p2m_altp2m_propagate_change+0x4e/0x508 (XEN)[] p2m-ept.c#ept_set_entry+0x7e4/0x8c4 (XEN)[] p2m_set_entry+0xe2/0x124 (XEN)[] guest_physmap_add_entry+0x7c3/0xacd (XEN)[] do_memory_op+0x8f8/0x22f8 (XEN)[] pv_hypercall+0x1f4/0x440 (XEN)[] lstar_enter+0x115/0x120 So clearly it's the external pages described earlier by George and Alexey landing. p2m_altp2m_propagate_change() then proceeds to do nothing (because gfn > p2m->max_remapped_gfn, _and_ m == INVALID_MFN). Next, in hvm_hap_nested_page_fault() p2m_altp2m_lazy_copy() returns 1, which leads to the function just exiting with no further logdirty checks (there's a goto out; that jumps them), and then that's it, I don't see any more page faults for those gfns. I've tried an assorted array of strategies: change p2m_altp2m_propagate_change() to always call set_entry() on the altp2m view, doing set_entry() for every gfn in the hostp2m into the new altp2m view in p2m_init_altp2m_ept() (a combination of these), trying to run the logdirty code in hvm_hap_nested_page_fault() before the goto out corresponding to p2m_altp2m_lazy_copy(). None of these things has worked. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 01/11] SUPPORT.md: Syntax: Fix some bullet lists
Continuations of bullet list items must be indented by exactly 4 spaces (according to pandoc_markdown(5) on Debian jessie). This is most easily achieved by making the bullet list items have two spaces before the `*'. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: George Dunlap Acked-by: Lars Kurth --- SUPPORT.md | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index c72a25b..1c5220b 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -783,40 +783,40 @@ What is the risk of it exhibiting bugs? General answers to the above: - * **Here be dragons** + * **Here be dragons** - Pretty likely to still crash / fail to work. - Not recommended unless you like life on the bleeding edge. +Pretty likely to still crash / fail to work. +Not recommended unless you like life on the bleeding edge. - * **Quirky** + * **Quirky** - Mostly works but may have odd behavior here and there. - Recommended for playing around or for non-production use cases. +Mostly works but may have odd behavior here and there. +Recommended for playing around or for non-production use cases. - * **Normal** + * **Normal** - Ready for production use +Ready for production use ### Interface stability If I build a system based on the current interfaces, will they still work when I upgrade to the next version? - * **Not stable** + * **Not stable** - Interface is still in the early stages and - still fairly likely to be broken in future updates. +Interface is still in the early stages and +still fairly likely to be broken in future updates. - * **Provisionally stable** + * **Provisionally stable** - We're not yet promising backwards compatibility, - but we think this is probably the final form of the interface. - It may still require some tweaks. +We're not yet promising backwards compatibility, +but we think this is probably the final form of the interface. +It may still require some tweaks. - * **Stable** + * **Stable** - We will try very hard to avoid breaking backwards compatibility, - and to fix any regressions that are reported. +We will try very hard to avoid breaking backwards compatibility, +and to fix any regressions that are reported. ### Security supported -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 02/11] SUPPORT.md: Syntax: Fix a typo "States"
Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: George Dunlap Acked-by: Lars Kurth --- SUPPORT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SUPPORT.md b/SUPPORT.md index 1c5220b..e447069 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -360,7 +360,7 @@ Guest-side driver capable of speaking the Xen PV block protocol Status, FreeBSD: Supported, Security support external Status, NetBSD: Supported, Security support external Status, OpenBSD: Supported, Security support external -States, Windows: Supported +Status, Windows: Supported Guest-side driver capable of speaking the Xen PV networking protocol -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/5] for-linux/sndif: add explicit back and front synchronization
Hello, Konrad, Takashi! Could you please review the *Linux Kernel* version of the changes? As I said in the cover letter below there is no functional changes comparing to the corresponding Xen version, but spaces to tabs. Still, formally, I have to drop the R-b tags and request for the new review. Thank you, Oleksandr P.S. Minus GlobalLogic e-mails which bounce On 04/12/2018 07:00 PM, Oleksandr Andrushchenko wrote: Hello, all! This is the syncup version of the sound protocol changes for Linux Kernel with the only difference from the corresponding Xen version being spaces to tabs conversion. Regradless of this only change I have dropped R-b tags received for Xen version. In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - bump protocol version to 2 - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events - add XENSND_OP_HW_PARAM_QUERY request to read/update stream configuration space: request passes desired intervals/formats for the stream parameters and the response returns allowed intervals and formats mask that can be used. - MAJOR: changed req/resp/evt packet sizes from 32 to 64 octets - Reworked XENSND_OP_HW_PARAM_QUERY so it now sends all parameters at once, allowing to check all the configuration space. - Minor documentation cleanup (added missed "reserved" fields) Oleksandr Andrushchenko (5): xen/sndif: Introduce protocol version xen/sndif: Fix missed "reserved" fields in comments xen/sndif: Make requests and responses 64 octets long xen/sndif: Add explicit back and front synchronization xen/sndif: Add explicit back and front parameter negotiation include/xen/interface/io/sndif.h | 322 +-- 1 file changed, 306 insertions(+), 16 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/5] xen/sndif: Fix missed "reserved" fields in comments
Some of the request descriptions have "reserved" fields
missed: fix this by adding corresponidng entries.
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/sndif.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
index fc1752cf5a16..b775df96f021 100644
--- a/include/xen/interface/io/sndif.h
+++ b/include/xen/interface/io/sndif.h
@@ -680,6 +680,8 @@ struct xensnd_rw_req {
* +++++
* | length | 16
* +++++
+ * | reserved | 20
+ * +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
* | reserved | 32
@@ -720,6 +722,8 @@ struct xensnd_rw_req {
* +++++
* | length | 16
* +++++
+ * | reserved | 20
+ * +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
* | reserved | 32
--
2.17.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/5] xen/sndif: Make requests and responses 64 octets long
Extend the size of the requests and responses to 64 octets.
Bump protocol version to 2.
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/sndif.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
index b775df96f021..d48175f1a3d2 100644
--- a/include/xen/interface/io/sndif.h
+++ b/include/xen/interface/io/sndif.h
@@ -41,7 +41,7 @@
* Protocol version
**
*/
-#define XENSND_PROTOCOL_VERSION1
+#define XENSND_PROTOCOL_VERSION2
/*
**
@@ -533,7 +533,7 @@
*
*-- Requests -
*
- * All request packets have the same length (32 octets)
+ * All request packets have the same length (64 octets)
* All request packets have common header:
* 01 2 3octet
* +++++
@@ -570,7 +570,7 @@
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
- * | reserved | 32
+ * | reserved | 64
* +++++
*
* pcm_rate - uint32_t, stream data rate, Hz
@@ -639,7 +639,7 @@ struct xensnd_page_directory {
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
- * | reserved | 32
+ * | reserved | 64
* +++++
*
* Request read/write - used for read (for capture) or write (for playback):
@@ -657,7 +657,7 @@ struct xensnd_page_directory {
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
- * | reserved | 32
+ * | reserved | 64
* +++++
*
* operation - XENSND_OP_READ for read or XENSND_OP_WRITE for write
@@ -684,7 +684,7 @@ struct xensnd_rw_req {
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
- * | reserved | 32
+ * | reserved | 64
* +++++
*
* operation - XENSND_OP_SET_VOLUME for volume set
@@ -726,7 +726,7 @@ struct xensnd_rw_req {
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
- * | reserved | 32
+ * | reserved | 64
* +++++
*
* operation - XENSND_OP_MUTE for mute or XENSND_OP_UNMUTE for unmute
@@ -759,7 +759,7 @@ struct xensnd_rw_req {
/*
*-- Responses
*
- * All response packets have the same length (32 octets)
+ * All response packets have the same length (64 octets)
*
* Response for all requests:
* 01 2 3octet
@@ -772,7 +772,7 @@ struct xensnd_rw_req {
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
- * | reserved | 32
+ * | reserved | 64
* +++++
*
* id - uint16_t, copied from the request
@@ -787,7 +787,7 @@ struct xensnd_req {
union {
struct xensnd_open_req open;
[Xen-devel] [PATCH 0/5] for-linux/sndif: add explicit back and front synchronization
Hello, all! This is the syncup version of the sound protocol changes for Linux Kernel with the only difference from the corresponding Xen version being spaces to tabs conversion. Regradless of this only change I have dropped R-b tags received for Xen version. In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - bump protocol version to 2 - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events - add XENSND_OP_HW_PARAM_QUERY request to read/update stream configuration space: request passes desired intervals/formats for the stream parameters and the response returns allowed intervals and formats mask that can be used. - MAJOR: changed req/resp/evt packet sizes from 32 to 64 octets - Reworked XENSND_OP_HW_PARAM_QUERY so it now sends all parameters at once, allowing to check all the configuration space. - Minor documentation cleanup (added missed "reserved" fields) Oleksandr Andrushchenko (5): xen/sndif: Introduce protocol version xen/sndif: Fix missed "reserved" fields in comments xen/sndif: Make requests and responses 64 octets long xen/sndif: Add explicit back and front synchronization xen/sndif: Add explicit back and front parameter negotiation include/xen/interface/io/sndif.h | 322 +-- 1 file changed, 306 insertions(+), 16 deletions(-) -- 2.17.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/5] xen/sndif: Introduce protocol version
Protocol version was referenced in the protocol description, but missed its definition. Fix this by adding a constant for current protocol version. Signed-off-by: Oleksandr Andrushchenko --- include/xen/interface/io/sndif.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h index 5c918276835e..fc1752cf5a16 100644 --- a/include/xen/interface/io/sndif.h +++ b/include/xen/interface/io/sndif.h @@ -36,6 +36,13 @@ #include "ring.h" #include "../grant_table.h" +/* + ** + * Protocol version + ** + */ +#define XENSND_PROTOCOL_VERSION1 + /* ** * Feature and Parameter Negotiation -- 2.17.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/5] xen/sndif: Add explicit back and front synchronization
In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Cc: Konrad Rzeszutek Wilk Cc: Takashi Iwai --- include/xen/interface/io/sndif.h | 162 ++- 1 file changed, 161 insertions(+), 1 deletion(-) diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h index d48175f1a3d2..131c3b469d4a 100644 --- a/include/xen/interface/io/sndif.h +++ b/include/xen/interface/io/sndif.h @@ -113,6 +113,8 @@ * * /local/domain/1/device/vsnd/0/0/0/ring-ref = "386" * /local/domain/1/device/vsnd/0/0/0/event-channel = "15" + * /local/domain/1/device/vsnd/0/0/0/evt-ring-ref = "1386" + * /local/domain/1/device/vsnd/0/0/0/evt-event-channel = "215" * *-- Stream 1, capture * @@ -122,6 +124,8 @@ * * /local/domain/1/device/vsnd/0/0/1/ring-ref = "384" * /local/domain/1/device/vsnd/0/0/1/event-channel = "13" + * /local/domain/1/device/vsnd/0/0/1/evt-ring-ref = "1384" + * /local/domain/1/device/vsnd/0/0/1/evt-event-channel = "213" * *--- PCM device 1 * @@ -135,6 +139,8 @@ * * /local/domain/1/device/vsnd/0/1/0/ring-ref = "387" * /local/domain/1/device/vsnd/0/1/0/event-channel = "151" + * /local/domain/1/device/vsnd/0/1/0/evt-ring-ref = "1387" + * /local/domain/1/device/vsnd/0/1/0/evt-event-channel = "351" * *--- PCM device 2 * @@ -147,6 +153,8 @@ * * /local/domain/1/device/vsnd/0/2/0/ring-ref = "389" * /local/domain/1/device/vsnd/0/2/0/event-channel = "152" + * /local/domain/1/device/vsnd/0/2/0/evt-ring-ref = "1389" + * /local/domain/1/device/vsnd/0/2/0/evt-event-channel = "452" * ** *Backend XenBus Nodes @@ -292,6 +300,23 @@ * The Xen grant reference granting permission for the backend to map * a sole page in a single page sized ring buffer. * + *- Stream Event Transport Parameters - + * + * This communication path is used to deliver asynchronous events from backend + * to frontend, set up per stream. + * + * evt-event-channel + * Values: + * + * The identifier of the Xen event channel used to signal activity + * in the ring buffer. + * + * evt-ring-ref + * Values: + * + * The Xen grant reference granting permission for the backend to map + * a sole page in a single page sized ring buffer. + * ** * STATE DIAGRAMS ** @@ -439,6 +464,19 @@ #define XENSND_OP_GET_VOLUME 5 #define XENSND_OP_MUTE 6 #define XENSND_OP_UNMUTE 7 +#define XENSND_OP_TRIGGER 8 + +#define XENSND_OP_TRIGGER_START0 +#define XENSND_OP_TRIGGER_PAUSE1 +#define XENSND_OP_TRIGGER_STOP 2 +#define XENSND_OP_TRIGGER_RESUME 3 + +/* + ** + * EVENT CODES + ** + */ +#define XENSND_EVT_CUR_POS 0 /* ** @@ -455,6 +493,8 @@ #define XENSND_FIELD_VCARD_LONG_NAME "long-name" #define XENSND_FIELD_RING_REF "ring-ref" #define XENSND_FIELD_EVT_CHNL "event-channel" +#define XENSND_FIELD_EVT_RING_REF "evt-ring-ref" +#define XENSND_FIELD_EVT_EVT_CHNL "evt-event-channel" #define XENSND_FIELD_DEVICE_NAME "name" #define XENSND_FIELD_TYPE "type" #define XENSND_FIELD_STREAM_UNIQUE_ID "unique-id" @@ -566,7 +606,9 @@ * +++++ * | gref_directory | 24 * +++++ - * | reserved | 28 + * | period_sz | 28 + * +++++ + * | reserved
[Xen-devel] [PATCH 5/5] xen/sndif: Add explicit back and front parameter negotiation
In order to provide explicit stream parameter negotiation between
backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update
configuration space for the parameters given: request passes
desired parameter's intervals/masks and the response to this request
returns allowed min/max intervals/masks to be used.
Parameters supported by this request/response:
- format mask
- sample rate interval
- number of channels interval
- buffer size, interval, frames
- period size, interval, frames
Signed-off-by: Oleksandr Andrushchenko
Cc: Konrad Rzeszutek Wilk
Cc: Takashi Iwai
---
include/xen/interface/io/sndif.h | 133 +--
1 file changed, 126 insertions(+), 7 deletions(-)
diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
index 131c3b469d4a..78bb5d9f8d83 100644
--- a/include/xen/interface/io/sndif.h
+++ b/include/xen/interface/io/sndif.h
@@ -465,6 +465,7 @@
#define XENSND_OP_MUTE 6
#define XENSND_OP_UNMUTE 7
#define XENSND_OP_TRIGGER 8
+#define XENSND_OP_HW_PARAM_QUERY 9
#define XENSND_OP_TRIGGER_START0
#define XENSND_OP_TRIGGER_PAUSE1
@@ -832,28 +833,142 @@ struct xensnd_trigger_req {
};
/*
- *-- Responses
+ * Request stream parameter ranges: request intervals and
+ * masks of supported ranges for stream configuration values.
*
- * All response packets have the same length (64 octets)
+ * Sound device configuration for a particular stream is a limited subset
+ * of the multidimensional configuration available on XenStore, e.g.
+ * once the frame rate has been selected there is a limited supported range
+ * for sample rates becomes available (which might be the same set configured
+ * on XenStore or less). For example, selecting 96kHz sample rate may limit
+ * number of channels available for such configuration from 4 to 2, etc.
+ * Thus, each call to XENSND_OP_HW_PARAM_QUERY may reduce configuration
+ * space making it possible to iteratively get the final stream
configuration,
+ * used in XENSND_OP_OPEN request.
+ *
+ * See response format for this request.
*
- * Response for all requests:
* 01 2 3octet
* +++++
- * | id|operation |reserved| 4
+ * | id| _HW_PARAM_QUERY|reserved| 4
* +++++
- * | status | 8
+ * | reserved | 8
+ * +++++
+ * | formats mask low 32-bit | 12
+ * +++++
+ * | formats mask high 32-bit | 16
+ * +++++
+ * | min rate | 20
+ * +++++
+ * | max rate | 24
+ * +++++
+ * |min channels | 28
+ * +++++
+ * |max channels | 32
+ * +++++
+ * | min buffer frames | 36
+ * +++++
+ * | max buffer frames | 40
+ * +++++
+ * | min period frames | 44
+ * +++++
+ * | max period frames | 48
* +++++
- * | reserved | 12
+ * | reserved | 52
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
* | reserved | 64
* +++++
*
+ * formats - uint64_
Re: [Xen-devel] [PATCH for-4.11 v3 0/11] Provide support matrix generator
On 12/04/2018, 13:28, "Ian Jackson" wrote: This series provides code to generate a feature support matrix, to replace the one on the wiki. You can see an example of the output here: https://xenbits.xen.org/people/iwj/2018/support-matrix-example-v3a/t.html I prefer this one. It's cleaner and easier to navigate. I would leave out the "}" in the navigation though. I suppose, we also need to add "Supported-Until" and "Security-Support-Until" for the 4.10 stuff and roll this into the format changes for SUPPORT.md Let me know when committed and the page is there, such that I can commit "[PATCH governance.git] Make Security Policy Doc ready to become a CNA" That probably needs a couple of ACKs though, but it doesn't change the policy substance, so maybe it doesn't I am proposing not to repost just to change the URL (once generated) Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin
On Thu, 2018-04-12 at 15:15 +0200, Dario Faggioli wrote:
> On Thu, 2018-04-12 at 14:45 +0200, Olaf Hering wrote:
> >
> > dies after the first iteration.
> >
> > BUG_ON(!test_bit(_VPF_migrating, &prev->pause_flags));
> >
>
Update. I replaced this:
+BUG_ON(vcpu_runnable(prev));
+BUG_ON(!test_bit(_VPF_migrating, &prev->pause_flags));
with this, in the patch:
+if (vcpu_runnable(prev) || !test_bit(_VPF_migrating,
&prev->pause_flags))
+printk("d%uv%d runnbl=%d proc=%d pf=%lu\n",
prev->domain->domain_id, prev->vcpu_id,
+ vcpu_runnable(prev), prev->processor, prev->pause_flags);
+BUG_ON(!test_bit(_VPF_migrating, &prev->pause_flags));
Output is:
(XEN) d10v0 runnbl=1 proc=31 pf=0
(XEN) Xen BUG at schedule.c:1572
On CPU 16.
It is still the BUG_ON(!test_bit(VPF_migrating)) which is triggering (I
actually meant to get rid of that as well, but I forgot.)
So, it looks like before, we did not hit BUG_ON(vcpu_runnable(prev)),
while in this run, vcpu_runnable(prev) is 1. I mean, I know it's a
race, but... wow...
We are in here because VPF_migrating was set, but it must be getting
cleared, concurrently with us, at about this time.
We are on CPU 16, inside context_saved(), and our 'prev' is d10v0. This
means its 'processor' should still be 16. But it's 31, so someone has
changed it already. I'm assuming it has been the vcpu_migrate() from
vcpu_set_affinity(). And this could very well be fine, but then, why we
also, when inside vcpu_migrate(), find VPF_migrating set?
I'll add more debugging to check if the vcpu is in a runqueue...
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v19 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 12 April 2018 16:28
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PATCH v19 10/11] common: add a new mappable resource
> type: XENMEM_resource_grant_table
>
> >>> On 29.03.18 at 17:36, wrote:
> > @@ -967,6 +968,54 @@ static long xatp_permission_check(struct domain
> *d, unsigned int space)
> > return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> > }
> >
> > +static int acquire_grant_table(struct domain *d, unsigned int id,
> > + unsigned long frame,
> > + unsigned int nr_frames,
> > + xen_pfn_t mfn_list[])
> > +{
> > +unsigned int i = nr_frames;
> > +
> > +/*
> > + * FIXME: It is not currently safe to map grant status frames if they
> > + *will be inserted into the caller's P2M, because these
> > + *insertions are not yet properly reference counted.
> > + *This restriction can be removed when appropriate reference
> > + *counting is added.
> > + */
> > +if ( paging_mode_translate(current->domain) &&
> > + (id == XENMEM_resource_grant_table_id_status) )
> > +return -EOPNOTSUPP;
>
> I don't understand why this is for status frames only: The refcounting
> problem
> exists in any case (at the very least when the guest goes away but the
> mapping
> domain survives). The ioreq server use is fine because the page gets
> assigned
> to the domain intended to do the mapping.
Ok. I had limited to status frames as they can go away on a version change but,
yes, it should cover both for a tools domain that's not fully trusted.
>
> However, besides tightening the check, there can also be a little bit of
> relaxation, I think: At least the hardware domain can do such mappings, as
> we trust it anyway (and it won't - for the foreseeable future - go away).
>
Right. I'll adjust accordingly.
Paul
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v19 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table
>>> On 29.03.18 at 17:36, wrote:
> @@ -967,6 +968,54 @@ static long xatp_permission_check(struct domain *d,
> unsigned int space)
> return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> }
>
> +static int acquire_grant_table(struct domain *d, unsigned int id,
> + unsigned long frame,
> + unsigned int nr_frames,
> + xen_pfn_t mfn_list[])
> +{
> +unsigned int i = nr_frames;
> +
> +/*
> + * FIXME: It is not currently safe to map grant status frames if they
> + *will be inserted into the caller's P2M, because these
> + *insertions are not yet properly reference counted.
> + *This restriction can be removed when appropriate reference
> + *counting is added.
> + */
> +if ( paging_mode_translate(current->domain) &&
> + (id == XENMEM_resource_grant_table_id_status) )
> +return -EOPNOTSUPP;
I don't understand why this is for status frames only: The refcounting problem
exists in any case (at the very least when the guest goes away but the mapping
domain survives). The ioreq server use is fine because the page gets assigned
to the domain intended to do the mapping.
However, besides tightening the check, there can also be a little bit of
relaxation, I think: At least the hardware domain can do such mappings, as
we trust it anyway (and it won't - for the foreseeable future - go away).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 v3 0/11] Provide support matrix generator
Ian Jackson writes ("[PATCH for-4.11 v3 0/11] Provide support matrix
generator"):
> This series provides code to generate a feature support matrix, to
> replace the one on the wiki. You can see an example of the output
> here:
I spoke to Wei IRL and he expressed a disinclination to review my
matrix generation machinery :-) and said I should commit it.
So I have pushed patches 1-7 to staging right away. When they are
through to master, I intend to push them to staging-4.10, unless
someone objects.
For 8-11 I'm awaiting any opinions about the output and in particular
whether to include
> + 11/11] docs/parse-support-md: Identical [*]: only use extra
> table cell if necessary
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/5] sndif: add explicit back and front synchronization
On 04/12/2018 05:31 PM, Konrad Rzeszutek Wilk wrote: On Wed, Mar 21, 2018 at 09:15:36AM +0200, Oleksandr Andrushchenko wrote: On 03/20/2018 10:22 PM, Takashi Iwai wrote: On Mon, 19 Mar 2018 08:22:19 +0100, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hello, all! In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - bump protocol version to 2 - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events - add XENSND_OP_HW_PARAM_QUERY request to read/update stream configuration space: request passes desired intervals/formats for the stream parameters and the response returns allowed intervals and formats mask that can be used. Changes since v2: 1. Konrad's r-b tag for version patch 2. MAJOR: changed req/resp/evt packet sizes from 32 to 64 octets 3. Reworked XENSND_OP_HW_PARAM_QUERY so it now sends all parameters at once, allowing to check all the configuration space. 4. Minor documentation cleanup (added missed "reserved" fields) Changes since v1: 1. Changed protocol version definition from string to integer, so it can easily be used in comparisons. Konrad, I have removed your r-b tag for the reason of this change. 2. In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval (mask) and the response to this request returns min/max interval (mask) for the parameter to be used. Parameters supported by this request/response: - format mask - sample rate interval - number of channels interval - buffer size, interval, frames - period size, interval, frames I can't judge exactly about the protocol without the actual FE/BE implementations, but the change looks good to me, especially if you've already tested something. Thank you, I have tested the changes and need them to start upstreaming the frontend driver used to test the protocol. Do you mind if I put your Acked-by (or you prefer Reviewed-by?) tag to these patches: [PATCH v3 4/5] sndif: Add explicit back and front synchronization [PATCH v3 5/5] sndif: Add explicit back and front parameter negotiation Please note, that the changes first to be merged into Xen and then I'll prepare the same, but for the kernel If other people have no concern, let's go ahead with FE/BE stuff. Konrad, are you ok with the changes? Yes. Thank you for your persistence. Can you also add: Reviewed-by: Konrad Rzeszutek Wilk Great, can you please add r-b tags while applying or you want me to resend with r-b tags? Thank you! thanks, Takashi Thank you, Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/5] sndif: add explicit back and front synchronization
On Wed, Mar 21, 2018 at 09:15:36AM +0200, Oleksandr Andrushchenko wrote: > On 03/20/2018 10:22 PM, Takashi Iwai wrote: > > On Mon, 19 Mar 2018 08:22:19 +0100, > > Oleksandr Andrushchenko wrote: > > > From: Oleksandr Andrushchenko > > > > > > Hello, all! > > > > > > In order to provide explicit synchronization between backend and > > > frontend the following changes are introduced in the protocol: > > > - bump protocol version to 2 > > > - add new ring buffer for sending asynchronous events from > > > backend to frontend to report number of bytes played by the > > > frontend (XENSND_EVT_CUR_POS) > > > - introduce trigger events for playback control: start/stop/pause/resume > > > - add "req-" prefix to event-channel and ring-ref to unify naming > > > of the Xen event channels for requests and events > > > - add XENSND_OP_HW_PARAM_QUERY request to read/update > > > stream configuration space: request passes desired intervals/formats > > > for > > > the stream parameters and the response returns allowed intervals and > > > formats mask that can be used. > > > > > > Changes since v2: > > > 1. Konrad's r-b tag for version patch > > > 2. MAJOR: changed req/resp/evt packet sizes from 32 to 64 octets > > > 3. Reworked XENSND_OP_HW_PARAM_QUERY so it now sends all > > > parameters at once, allowing to check all the configuration > > > space. > > > 4. Minor documentation cleanup (added missed "reserved" fields) > > > > > > Changes since v1: > > > > > > 1. Changed protocol version definition from string to integer, > > > so it can easily be used in comparisons. > > > Konrad, I have removed your r-b tag for the reason of this change. > > > > > > 2. In order to provide explicit stream parameter negotiation between > > > backend and frontend the following changes are introduced in the protocol: > > > add XENSND_OP_HW_PARAM_QUERY request to read/update > > > configuration space for the parameter given: request passes > > > desired parameter interval (mask) and the response to this request > > > returns min/max interval (mask) for the parameter to be used. > > > > > > Parameters supported by this request/response: > > > - format mask > > > - sample rate interval > > > - number of channels interval > > > - buffer size, interval, frames > > > - period size, interval, frames > > I can't judge exactly about the protocol without the actual FE/BE > > implementations, but the change looks good to me, especially if you've > > already tested something. > Thank you, I have tested the changes and need them to start upstreaming > the frontend driver used to test the protocol. > Do you mind if I put your Acked-by (or you prefer Reviewed-by?) tag to these > patches: > > [PATCH v3 4/5] sndif: Add explicit back and front synchronization > [PATCH v3 5/5] sndif: Add explicit back and front parameter negotiation > > Please note, that the changes first to be merged into Xen and then I'll > prepare > the same, but for the kernel > > > > If other people have no concern, let's go ahead with FE/BE stuff. > Konrad, are you ok with the changes? Yes. Thank you for your persistence. Can you also add: Reviewed-by: Konrad Rzeszutek Wilk Thank you! > > > > thanks, > > > > Takashi > Thank you, > Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] possible I/O emulation state machine issue
>>> On 28.03.18 at 18:35, wrote: > Its one of the many items on the TODO list, along with maintaining a > proper virtual TLB to avoid rewalks during a single emulation. Having thought about this some more I agree that for correctness a virtual TLB would be sufficient. Also caching values read might help performance a little, but at the expense of quite a bit more logic/space to maintain that extra information. Hence I guess the TLB-only solution is going to be preferable. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM
Hi Peng, Sorry for late response, this email got buried and I accidentally saw it now. On Thu, Apr 12, 2018 at 4:26 AM, Peng Fan wrote: > Hi Edgar, > >> -Original Message- >> From: Edgar E. Iglesias [mailto:edgar.igles...@xilinx.com] >> Sent: 2018年3月26日 19:43 >> To: Peng Fan >> Cc: Mirela Simonovic ; xen-de...@lists.xen.org; >> sstabell...@kernel.org; julien.gr...@linaro.org >> Subject: Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for >> ARM >> >> On Mon, Mar 26, 2018 at 09:51:40AM +, Peng Fan wrote: >> > Hi Mirela, >> > >> > Good to know that you are working suspend/resume support. Currently we >> > are also trying to support this on i.MX8, just wonder do you have any >> > open source available to support suspend to ram? >> > We don't have suspend to RAM support available in open source yet. However, we are starting the upstream (just the first series covering CPU hotplug is submitted so far). >> > > + >> > > +Suspend to RAM (in the following text 'suspend') for ARM in Xen >> > > +should be coordinated using ARM PSCI standard [1]. >> > > + >> > > +Ideally, EL1/2 should suspend in the following order: >> > > +1) Unprivileged guests (DomUs) suspend >> > > +2) Privileged guest (Dom0) suspends >> > > +3) Xen suspends >> > > + >> > > +However, suspending unprivileged guests is not mandatory for >> > > +suspending >> > > +Dom0 and Xen. System suspend initiated by Dom0 (step 2) is >> > > +considered to be an ultimate decision to suspend the physical >> > > +machine. Suspending of Xen (step 3) is triggered whenever Dom0 >> > > +completes suspend. Xen suspend leads to the full suspend of EL2. >> > > + >> > > +If an unprivileged guest is not suspended at the moment when Dom0 >> > > +initiates its own suspend, the guest will be paused on Xen's >> > > +suspend and unpaused on Xen's resume. That way, a guest which >> > > +doesn't have power management support cannot prevent the physical >> > > +system from suspending when the decision to suspend is made by >> > > +privileged software >> > > (Dom0). >> > > + >> > > +Each guest in the system is responsible for suspending the devices it >> > > owns. >> > > +If a guest does not suspend a device, the device will continue to >> > > +operate as it is configured at the moment when the system suspends. >> > > +If a device triggers an interrupt while the physical system is >> > > +suspended, the >> > > system will resume. >> > > + >> > > +It is recommended for an unprivileged guest to participate in power >> > > +management in the following scenario: >> > > +Assume unprivileged guest owns a device which will trigger >> > > +interrupt at some point. This interrupt will wake-up the system. If >> > > +such a behavior is not wanted, coordination between Dom0 and the >> > > +guest is required in order to inform the guest about the intended >> > > physical >> system suspend. >> > > +Then, the guest will have a chance to suspend the device or respond >> > > +to the >> > > request in an abort fashion. >> > > + >> > > +Since this proposal is focused on implementing PSCI-based suspend >> > > +mechanisms in Xen, communication with or among the guests is not >> > > +covered by >> > > this document. >> > > +The order of suspending the guests is assumed to be guaranteed by >> > > +the software running in EL1. >> > > + >> > > +This document covers the following: >> > > +1) Mechanism for suspending/resuming a guest: >> > > + 1.1) Suspend is initiated by the guest >> > > + 1.2) Resume is initiated by a device interrupt >> > > +2) Mechanism for pausing/unpausing running guests when Dom0 >> > > +suspends >> > >> > Will this take care of passthroughed devices for DomU? >> > > Thanks for your reply. Sorry for late reply > >> Hi Peng, >> >> The ZynqMP uses the EEMI Firmware interface to do power-management. >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.x >> ilinx.com%2Fsupport%2Fdocumentation%2Fuser_guides%2Fug1200-eemi-api.p >> df&data=02%7C01%7Cpeng.fan%40nxp.com%7C021307a245394e945cbf08d59 >> 30ebb3c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6365766138 >> 46476140&sdata=xwyil1ar7VXXYPJb2yXxYPWJvR5mVEb6wokggdt0ZH4%3D&re >> served=0 > > Yes. I see. > >> >> In our case, we've implemented an EEMI mediator in Xen that traps EEMI >> requests from domU's and makes sure that the guest owns the device it is >> trying >> to operate on. >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. >> com%2FXilinx%2Fxen%2Fblob%2Fxilinx%2Fstable-4.9%2Fxen%2Farch%2Farm% >> 2Fplatforms%2Fxilinx-zynqmp-eemi.c&data=02%7C01%7Cpeng.fan%40nxp.com >> %7C021307a245394e945cbf08d5930ebb3c%7C686ea1d3bc2b4c6fa92cd99c5c3 >> 01635%7C0%7C0%7C636576613846476140&sdata=33AdCyBLxUYIR6h%2BtZzx >> TrnYpOZ86IMFySmjHA2%2Fits%3D&reserved=0 >> >> So domU will first issue the usual EEMI calls as it would in a >> non-virtualized case >> to suspend all it's devices. Once that has happened, the guest will issue >> PSCI calls >> to suspend the VM. So,
[Xen-devel] [ovmf test] 122178: all pass - PUSHED
flight 122178 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/122178/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 153f5c7a93be09403891404c06e5b0e24eb019a3 baseline version: ovmf 8b0e67821bd66af70433ee4bb858325f3033609a Last test of basis 122168 2018-04-11 04:49:35 Z1 days Testing same since 122178 2018-04-12 00:54:11 Z0 days1 attempts People who touched revisions under test: Feng, YunhuaX Kinney, Michael D Michael D Kinney Yunhua Feng 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 : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 8b0e67821b..153f5c7a93 153f5c7a93be09403891404c06e5b0e24eb019a3 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/7] xen/arm: Remove __initdata and __init to enable CPU hotplug
Hi Julien,
On Thu, Apr 12, 2018 at 2:56 PM, Julien Grall wrote:
> Hi,
>
> On 12/04/18 13:50, Mirela Simonovic wrote:
>>
>> Hi,
>>
>> On Thu, Apr 12, 2018 at 11:03 AM, Julien Grall
>> wrote:
>>>
>>> Hi,
>>>
>>> On 12/04/18 01:07, Stefano Stabellini wrote:
On Wed, 11 Apr 2018, Mirela Simonovic wrote:
>
>
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 5666efcd3a..d15ea8df5e 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -52,8 +52,8 @@ nodemask_t __read_mostly node_online_map = { { [0] =
> 1UL } };
>static unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
> __attribute__((__aligned__(STACK_SIZE)));
>-/* Initial boot cpu data */
> -struct init_info __initdata init_data =
> +/* Boot cpu data */
> +struct init_info init_data =
>{
>.stack = cpu0_boot_stack,
>};
Don't you also want to remove __initdata from cpu0_boot_stack?
>>>
>>>
>>
>> Somehow I didn't observe this as a problem... After taking a deeper
>> look now I understand that secondary CPUs reuse this stack to boot. So
>> I agree, __initdata from cpu0_boot_stack should be removed.
>
>
> No it should not be removed. cpu0_boot_stack is only used for Xen is booted
> (e.g CPU0 jumping at _start). In the suspend/resume case you are not going
> to use that patch for CPU0.
>
Thanks for clarification. I need to correct myself - I missed the fact
that the boot CPU updated init_data.stack for a secondary CPU to point
to its idle_vcpu's stack (in __cpu_up). So you're right,
cpu0_boot_stack will never be used again after the CPU0 boots and
therefore the __initdata should not be removed.
>>
>>>
>>> I am not sure about this. When you go idle, you could re-use the
>>> idle_vcpu[0]->arch.stack. So you save 12K in resident memory.
>>>
>>
>> I'm not sure I follow this, maybe Stefano can comment.
>
>
> Each CPU have an associated idle vCPU used for context switch and running
> idle mode. That idle vCPU contains the stack that is used for boot CPU.
>
> In the case of CPU0, you can not use idle vCPU stack when booting because it
> is not initialized. However during suspend/resume case, you will already
> have the idle_vcpu[0]->stack in hand. So there are no need to use
> cpu0_boot_stack.
>
> However, do you really need to setup the stack on resume?
>
There is no need to use cpu0_boot_stack for CPU0 on resume. The
idle_vcpu's stack is used and it has to be used if we want to resume
execution from where we suspended. We just save/restore SP on
suspend/resume.
Thanks,
Mirela
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/7] xen/arm/psci: Implement CPU_OFF PSCI call (physical interface)
On 12/04/18 12:33, Mirela Simonovic wrote: On Wed, Apr 11, 2018 at 4:46 PM, Julien Grall wrote: On 11/04/18 14:19, Mirela Simonovic wrote: local_irq_disable(); cpu_is_dead = true; /* Make sure the write happens before we sleep forever */ dsb(sy); isb(); +/* PSCI cpu off call will return only in case of an error */ +errno = call_psci_cpu_off(); +printk(XENLOG_DEBUG "PSCI cpu off call failed for CPU#%d err=%d\n", + get_processor_id(), errno); +isb(); What are you trying to achieve with the isb() here? I use to have a problem that the wfi below gets executed before the call_psci_cpu_off(). Adding isb() fixed the issue. However, I tried now to reproduce the problem and it doesn't show up. I still believe isb() should be here, please let me know if you disagree (I obviously can't prove the claim now). The problem you describe can't be possible with the code you have because call_psci_cpu_off() is issuing a SMC. SMC will lead to change exception level and therefore have a context-synchronization barrier. This is obviously based on the assumption you don't have an errata on your CPU exposing the behavior you describe. For that you would need to check errata notice for your CPU and/or try to reproduce. However, what you would need is a dsb(sy); isb(); to drain the write buffer if you print a message. Furthermore, now on platform without CPU off support (e.g non-PSCI platform and PSCI 0.1) you will log an error message that may worry people. In reality, PSCI cpu_off will unlikely fail, so you probably want to add a panic in call_psci_cpu_off instead. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 11/11] docs/parse-support-md: Identical [*]: only use extra table cell if necessary
On 12/04/18 14:28, Ian Jackson wrote: > Otherwise paste [*] right onto the end. > > I'm not sure if this is desirable. > > Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 10/11] docs/parse-support-md: Unify identical [*] in footnotes
On 12/04/18 14:28, Ian Jackson wrote: > A section in the SUPPORT.md may mention multiple >Status, something: Supported > and then have some text. The text is linked to from [*] footnotes > in the table. But, this means that each bit of text needs to > apply to multiple rows. > > Before this commit this was a separate [*] after each applicable item. > But multiple apparently-different links to the same thing are annoying > for the reader. > > So, in this commit we combine them. Formatting the result is not > entirely trivial. > > Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin
On Thu, 2018-04-12 at 14:45 +0200, Olaf Hering wrote: > Am Thu, 12 Apr 2018 12:16:34 +0200 > schrieb Dario Faggioli : > > > Olaf, new patch. Please, remove _everything_ and apply _only_ this > > one. > > dies after the first iteration. > > BUG_ON(!test_bit(_VPF_migrating, &prev->pause_flags)); > So, VPF_migrating is set, when we enter the if() and decide to call vcpu_sleep_nosync() and vcpu_migrate(), but is not set here, once we have taken the lock. Interestingly, we did not hit BUG_ON(vcpu_runnable(prev)), right before that... Anyway, there is only once place where VPF_migrating is reset, and that is in vcpu_migrate(). So, basing on our theory that we are running concurrently with vcpu_set_affinity(), it's the call to vcpu_migrate() from vcpu_set_affinity() that resets it. I need to think a bit more (I'm trying to picture the exact scenario) but as of now, it still does not make sense... As it looks to me that now it is the call to vcpu_sleep_nosync(), also from vcpu_set_affinity(), that should have removed prev from the runqueue. True that vcpu_migrate() ends with vcpu_wake(), which put is back in a runqueue, but then again the our vcpu_migrate(), here in context_saved(), finding that VPF_migrate() is off, should *not* call vcpu_move_locked(). This is getting insane (or I am)... :-O Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/7] xen/arm: Remove __initdata and __init to enable CPU hotplug
Hi,
On 12/04/18 13:50, Mirela Simonovic wrote:
Hi,
On Thu, Apr 12, 2018 at 11:03 AM, Julien Grall wrote:
Hi,
On 12/04/18 01:07, Stefano Stabellini wrote:
On Wed, 11 Apr 2018, Mirela Simonovic wrote:
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 5666efcd3a..d15ea8df5e 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -52,8 +52,8 @@ nodemask_t __read_mostly node_online_map = { { [0] =
1UL } };
static unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
__attribute__((__aligned__(STACK_SIZE)));
-/* Initial boot cpu data */
-struct init_info __initdata init_data =
+/* Boot cpu data */
+struct init_info init_data =
{
.stack = cpu0_boot_stack,
};
Don't you also want to remove __initdata from cpu0_boot_stack?
Somehow I didn't observe this as a problem... After taking a deeper
look now I understand that secondary CPUs reuse this stack to boot. So
I agree, __initdata from cpu0_boot_stack should be removed.
No it should not be removed. cpu0_boot_stack is only used for Xen is
booted (e.g CPU0 jumping at _start). In the suspend/resume case you are
not going to use that patch for CPU0.
I am not sure about this. When you go idle, you could re-use the
idle_vcpu[0]->arch.stack. So you save 12K in resident memory.
I'm not sure I follow this, maybe Stefano can comment.
Each CPU have an associated idle vCPU used for context switch and
running idle mode. That idle vCPU contains the stack that is used for
boot CPU.
In the case of CPU0, you can not use idle vCPU stack when booting
because it is not initialized. However during suspend/resume case, you
will already have the idle_vcpu[0]->stack in hand. So there are no need
to use cpu0_boot_stack.
However, do you really need to setup the stack on resume?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/7] xen/arm: Remove __initdata and __init to enable CPU hotplug
Hi,
On Thu, Apr 12, 2018 at 11:03 AM, Julien Grall wrote:
> Hi,
>
> On 12/04/18 01:07, Stefano Stabellini wrote:
>>
>> On Wed, 11 Apr 2018, Mirela Simonovic wrote:
>>>
>>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>>> index 5666efcd3a..d15ea8df5e 100644
>>> --- a/xen/arch/arm/smpboot.c
>>> +++ b/xen/arch/arm/smpboot.c
>>> @@ -52,8 +52,8 @@ nodemask_t __read_mostly node_online_map = { { [0] =
>>> 1UL } };
>>> static unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
>>> __attribute__((__aligned__(STACK_SIZE)));
>>> -/* Initial boot cpu data */
>>> -struct init_info __initdata init_data =
>>> +/* Boot cpu data */
>>> +struct init_info init_data =
>>> {
>>> .stack = cpu0_boot_stack,
>>> };
>>
>>
>> Don't you also want to remove __initdata from cpu0_boot_stack?
>
Somehow I didn't observe this as a problem... After taking a deeper
look now I understand that secondary CPUs reuse this stack to boot. So
I agree, __initdata from cpu0_boot_stack should be removed.
>
> I am not sure about this. When you go idle, you could re-use the
> idle_vcpu[0]->arch.stack. So you save 12K in resident memory.
>
I'm not sure I follow this, maybe Stefano can comment.
Thanks,
Mirela
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin
Am Thu, 12 Apr 2018 12:16:34 +0200 schrieb Dario Faggioli : > Olaf, new patch. Please, remove _everything_ and apply _only_ this one. dies after the first iteration. BUG_ON(!test_bit(_VPF_migrating, &prev->pause_flags)); (XEN) Xen BUG at schedule.c:1570 (XEN) [ Xen-4.11.20180411T100655.82540b66ce-1.xen_unstable x86_64 debug=y Not tainted ] (XEN) CPU:29 (XEN) RIP:e008:[] context_saved+0x1a3/0x32c (XEN) RFLAGS: 00010046 CONTEXT: hypervisor (XEN) rax: 0001 rbx: 8300779b3000 rcx: 83047fe04188 (XEN) rdx: rsi: 6218 rdi: 83047fe0418e (XEN) rbp: 830880057db8 rsp: 830880057d78 r8: 0001 (XEN) r9: r10: ffc0 r11: 83047fe8e0a0 (XEN) r12: 83047fe04188 r13: 0292 r14: 82d0805c7180 (XEN) r15: 82d0805b2520 cr0: 80050033 cr4: 26e0 (XEN) cr3: 000b62f19000 cr2: 006af6e8 (XEN) fsb: gsb: gss: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen code around (context_saved+0x1a3/0x32c): (XEN) 00 e9 09 ff ff ff 0f 0b <0f> 0b e8 a7 bc 06 00 49 89 c6 83 bb c8 00 00 00 (XEN) Xen stack trace from rsp=830880057d78: (XEN)83047cde2f40 8300779b3000 830880057db8 830077bea000 (XEN)8300779b3000 83047ffe7000 001d 83052b234000 (XEN)830880057e08 82d08027a3d8 830880057dd8 82d0802a83b0 (XEN)830880057e08 8300779b3000 830077bea000 83047fe04188 (XEN)0056c1375e97 0002 830880057e98 82d080239783 (XEN)8300779b3560 83047fe041a0 001d00057e58 83047fe04180 (XEN)82d080328a41 8300779b3000 83052b234000 830077bea000 (XEN) 82d080301f00 8300779b3000 82d08059cb00 (XEN)82d08059bc80 830880057fff 82d0805a3c80 (XEN)830880057ed8 82d08023d3f7 82d080328a41 8300779b3000 (XEN) (XEN)830880057ee8 82d08023d46a 7cf77ffa80e7 82d080328c0b (XEN)88008696 88008696 88008696 (XEN)0002 81d4c180 0008 000a7c976ba7 (XEN)0001 81020e50 (XEN) beefbeef (XEN)81060182 00bfbeef 0246 880086963ed8 (XEN)beef beef beef beef (XEN)beef 001d 830077bea000 0033ff83d000 (XEN)26e0 00047fe06000 0400 (XEN) Xen call trace: (XEN)[] context_saved+0x1a3/0x32c (XEN)[] context_switch+0xe9/0xf67 (XEN)[] schedule.c#schedule+0x306/0x6ab (XEN)[] softirq.c#__do_softirq+0x71/0x9a (XEN)[] do_softirq+0x13/0x15 (XEN)[] vmx_asm_do_vmentry+0x2b/0x30 Olaf pgpPc4UJee8qp.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 05/11] docs/gen-html-index: Support documents at the toplevel
There are none yet.
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Acked-by: Lars Kurth
---
docs/gen-html-index | 4
1 file changed, 4 insertions(+)
diff --git a/docs/gen-html-index b/docs/gen-html-index
index 5b43b42..8258e2b 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -137,6 +137,10 @@ sub dirs($)
return @dirs;
}
+foreach my $of (grep { !m{/} } @docs) {
+$top .= make_link($of,'');
+}
+
foreach my $od (sort { $a cmp $b } uniq map { dirs($_) } @docs) {
my @d = (grep /^\Q$od\E/, @docs);
if ( @d == 1 and $d[0] eq "$od/index.html" )
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 11/11] docs/parse-support-md: Identical [*]: only use extra table cell if necessary
Otherwise paste [*] right onto the end.
I'm not sure if this is desirable.
Signed-off-by: Ian Jackson
---
v3: New patch
---
docs/parse-support-md | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index 38c8326..f91adca 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -358,18 +358,26 @@ sub write_output_row ($) {
my $colspan = $sectnode->{RealSect}{ColSpan}[$i];
my $nextcell = '';
+my $suffix = $sectnode->{RealSect}{AlwaysSuffix};
if (!defined $colspan) { # first row of this RealSect
$colspan= ' colspan="2"';
if ($sectnode->{RealSect}{HasText}[$i] && $st
&& $sectnode->{RealSect}{Anchor}) {
my $rows = $sectnode->{RealSect}{Rows};
-$nextcell = sprintf '', $rows;
-my @nce = ($rows>1 ? ('}') : ('')) x $rows;
-$nce[floor(($rows-1)/2)] .= sprintf '[*]',
+my $asterisk = sprintf '[*]',
$version_urls[$i], $sectnode->{RealSect}{Anchor};
-$nextcell .= join '', @nce;
-$nextcell .= '';
-$colspan = '';
+if ($rows > 1) {
+$nextcell = sprintf '', $rows;
+my @nce = ($rows>1 ? ('}') : ('')) x $rows;
+$nce[floor(($rows-1)/2)] .= $asterisk;
+$nextcell .= join '', @nce;
+$nextcell .= '';
+$suffix = '[*]';
+$sectnode->{RealSect}{AlwaysSuffix} = $suffix;
+$colspan = '';
+} else {
+$suffix = $asterisk;
+}
}
$sectnode->{RealSect}{ColSpan}[$i] = $colspan;
}
@@ -383,6 +391,7 @@ sub write_output_row ($) {
}
o(escapeHTML($st));
o($end_a);
+o($suffix // '');
o('');
o($nextcell);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 08/11] docs: Provide parse-support-md
This utility reads json format pandoc output, from parsing one or more
SUPPORT.md files, and generates an HTML table element containing the
principal version and feature information.
This is rather hairier than I anticipated when I started out; hence
the 400-odd-line Perl script.
Machinery to assemble the appropriate inputs for parse-support-md
will be in the next commit.
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Acked-by: Lars Kurth
---
v2: New in this version of the series.
v3: Refactor to introduce RealSect
v3: Add [*] footnote to all applicable entries, not just the last
---
docs/parse-support-md | 414 ++
1 file changed, 414 insertions(+)
create mode 100755 docs/parse-support-md
diff --git a/docs/parse-support-md b/docs/parse-support-md
new file mode 100755
index 000..83768cf
--- /dev/null
+++ b/docs/parse-support-md
@@ -0,0 +1,414 @@
+#!/usr/bin/perl -w
+#
+# Written with reference to pandoc_markdown from Debian jessie
+# We require atx-style headers
+#
+# usage:
+# pandoc -t json SUPPORT.md >j-unstable
+# git-cat-file ... | pandoc -t json >j-4.10
+# docs/parse-support-md \
+#j-unstable https://xenbits/unstable/SUPPORT.html
+#j-4.10 https://xenbits/4.10/SUPPORT.html
+# or equivalent
+
+use strict;
+use JSON;
+use Tie::IxHash;
+use IO::File;
+use CGI qw(escapeHTML);
+use Data::Dumper;
+
+#-- accumulating input/output --
+
+# This combines information from all of the input files.
+
+sub new_sectlist () { { } };
+our $toplevel_sectlist = new_sectlist();
+# an $sectlist is
+# { } nothing seen yet
+# a tied hashref something seen
+# (tied $sectlist)is an object of type Tie::IxHash
+# $sectlist->{KEY} a $sectnode:
+# $sectlist->{KEY}{Status}[VI] = absent or markdown content
+# $sectlist->{KEY}{Children} = a further $sectlist
+# $sectlist->{KEY}{Key} = KEY
+# $sectlist->{KEY}{RealSect} = containing real section in @insections, so
+# $sectlist->{KEY}{RealSect}{HasText}[VI] = trueish iff there was a Para
+# $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html
+# A $sectnode represents a single section from the original markdown
+# document. Its subsections are in Children.
+#
+# Also, the input syntax:
+#Status, something or other: Supported
+# is treated as a $sectnode, is as if it were a subsection -
+# one called `something or other'.
+#
+# KEY is the Anchor, or derived from the `something or other'.
+# It is used to match up identical features in different versions.
+
+#-- state for this input file --
+
+our $version_index;
+our @version_urls;
+
+our @insections;
+# $insections[]{Key} = string
+# $insections[]{Headline} = markdown content
+# these next are only defined for real sections, not Status elements
+# $insections[]{Anchor} = string
+# $insections[]{HasText} = array, $sectlist->{HasText} will refer to this
+
+our $had_unknown;
+# adding new variable ? it must be reset in r_toplevel
+
+#-- parsing --
+
+sub ri_Header {
+my ($c) = @_;
+my ($level, $infos, $hl) = @$c;
+#print STDERR 'RI_HEADER ', Dumper($c, \@c);
+my ($id) = @$infos;
+die unless $level >= 1;
+die unless $level-2 <= $#insections;
+$#insections = $level-2;
+push @insections,
+{
+ Key => $id,
+ Anchor => $id,
+ Headline => $hl,
+ HasText => [],
+};
+#print STDERR Dumper(\@insections);
+}
+
+sub ri_Para {
+if (@insections) {
+$insections[$#insections]{HasText}[$version_index] = 1;
+}
+};
+
+sub parse_feature_entry ($) {
+my ($value) = @_;
+die unless @insections;
+
+my $sectnode;
+my $realsect;
+foreach my $s (@insections) {
+my $sectlist = $sectnode
+? $sectnode->{Children} : $toplevel_sectlist;
+my $key = $s->{Key};
+$realsect = $s if $s->{Anchor};
+tie %$sectlist, 'Tie::IxHash' unless tied %$sectlist;
+#print STDERR "PARSE_FEATURE_ENTRY ", Dumper($s);
+$sectlist->{$key} //=
+{
+ Children => new_sectlist(),
+ Headline => $s->{Headline},
+ Key => $key,
+ RealSect => $realsect,
+};
+$sectnode = $sectlist->{$key};
+}
+die unless $sectnode;
+$sectnode->{Status}[$version_index] = $value;
+}
+
+sub ri_CodeBlock {
+my ($c) = @_;
+my ($infos, $text) = @$c;
+
+if ($text =~ m{^(?: Functional\ completeness
+ | Functional\ stability
+ | Interface\ stability
+ | Security\ supported ) \:}x) {
+# ignore this
+return;
+}
+die "$had_unknown / $text ?" if $had_unknown;
+
+my $toplevel = $text =~ m{^Xen-Version:};
+
+foreach my $l (split /\n/, $text) {
+$l =~ s/\s*$//;
+next unless $l =~ m/\S/;
+
+my ($descr, $value) =
+$toplevel
+? $l =~ m{^([A-Z][
[Xen-devel] [PATCH 04/11] docs/gen-html-index: Extract titles from HTML documents
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Acked-by: Lars Kurth
---
docs/gen-html-index | 13 +
1 file changed, 13 insertions(+)
diff --git a/docs/gen-html-index b/docs/gen-html-index
index e9792bf..5b43b42 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -10,6 +10,7 @@ use warnings;
use Getopt::Long;
use IO::File;
use File::Basename;
+use HTML::TreeBuilder::XPath;
Getopt::Long::Configure('bundling');
@@ -64,6 +65,18 @@ sub make_linktext ($) {
return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
$l =~ s/.(?:html|txt)$//g;
return $index{$l} if exists $index{$l};
+
+my $from_html;
+eval {
+my $tree = new HTML::TreeBuilder::XPath;
+my $f = "$outdir/$l.html";
+open F, '<', $f or die "$l $f $!";
+$tree->parse_file(\*F) or die;
+close F;
+$from_html = $tree->findvalue("/html/head/title");
+};
+return $from_html if $from_html;
+
return basename($l);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 10/11] docs/parse-support-md: Unify identical [*] in footnotes
A section in the SUPPORT.md may mention multiple
Status, something: Supported
and then have some text. The text is linked to from [*] footnotes
in the table. But, this means that each bit of text needs to
apply to multiple rows.
Before this commit this was a separate [*] after each applicable item.
But multiple apparently-different links to the same thing are annoying
for the reader.
So, in this commit we combine them. Formatting the result is not
entirely trivial.
Signed-off-by: Ian Jackson
---
v3: New patch
---
docs/parse-support-md | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index 83768cf..38c8326 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -17,6 +17,7 @@ use Tie::IxHash;
use IO::File;
use CGI qw(escapeHTML);
use Data::Dumper;
+use POSIX;
#-- accumulating input/output --
@@ -285,9 +286,14 @@ sub count_rows_sectnode ($) {
$rows++ if $sectnode->{Status};
$rows += count_rows_sectlist $sectnode->{Children};
$sectnode->{Rows} = $rows;
+$sectnode->{RealSect}{Rows} = $rows;
return $rows;
}
+# Now we have
+# $sectnode->{Rows}
+# $sectnode->{RealSect}{Rows}
+
sub count_rows_sectlist ($) {
my ($sectlist) = @_;
my $rows = 0;
@@ -349,22 +355,36 @@ sub write_output_row ($) {
}
for (my $i=0; $i<@version_urls; $i++) {
my $st = $sectnode->{Status}[$i];
+
+my $colspan = $sectnode->{RealSect}{ColSpan}[$i];
+my $nextcell = '';
+if (!defined $colspan) { # first row of this RealSect
+$colspan= ' colspan="2"';
+if ($sectnode->{RealSect}{HasText}[$i] && $st
+&& $sectnode->{RealSect}{Anchor}) {
+my $rows = $sectnode->{RealSect}{Rows};
+$nextcell = sprintf '', $rows;
+my @nce = ($rows>1 ? ('}') : ('')) x $rows;
+$nce[floor(($rows-1)/2)] .= sprintf '[*]',
+$version_urls[$i], $sectnode->{RealSect}{Anchor};
+$nextcell .= join '', @nce;
+$nextcell .= '';
+$colspan = '';
+}
+$sectnode->{RealSect}{ColSpan}[$i] = $colspan;
+}
+
$st //= '-';
-o('');
+o("");
my $end_a = '';
if ($sectnode->{Key} eq 'release-support--xen-version') {
o(sprintf '', $version_urls[$i]);
$end_a = '';
}
o(escapeHTML($st));
-if ($sectnode->{RealSect}{HasText}[$i]
-&& $sectnode->{Status}[$i]
-&& $sectnode->{RealSect}{Anchor}) {
-o(sprintf '[*]',
- $version_urls[$i], $sectnode->{RealSect}{Anchor});
-}
o($end_a);
o('');
+o($nextcell);
}
o("\n");
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 09/11] docs: Provide support-matrix-generate, to generate a support matrix in HTML
This archaeology script:
- figures out what the current and previous Xen versions were
- looks for appropriate git branches for them
- finds SUPPORT.md for each one
- feeds its findings to parse-support-md
We do not intend to integrate this into docs/Makefile, because it
relies on the git history. Instead, we will take the rune provided in
the head comment and paste a variant of it into an appropriate cronjob
on xenbits.
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Acked-by: Lars Kurth
---
v3: Provide -D option.
---
.gitignore | 1 +
docs/misc/support-matrix-head.html | 41
docs/support-matrix-generate | 186 +
3 files changed, 228 insertions(+)
create mode 100644 docs/misc/support-matrix-head.html
create mode 100755 docs/support-matrix-generate
diff --git a/.gitignore b/.gitignore
index cd57530..7004349 100644
--- a/.gitignore
+++ b/.gitignore
@@ -43,6 +43,7 @@ config/Paths.mk
build-*
dist/*
+docs/tmp.*
docs/html/
docs/man/xl.cfg.pod.5
docs/man/xl.pod.1
diff --git a/docs/misc/support-matrix-head.html
b/docs/misc/support-matrix-head.html
new file mode 100644
index 000..7cc2776
--- /dev/null
+++ b/docs/misc/support-matrix-head.html
@@ -0,0 +1,41 @@
+
+
+Xen versions and feature support matrix
+
+
+
+Xen versions and features support matrix
+
+This table summarises the support status of Xen releases,
+and of individual features within each release.
+
+Important notes
+
+The matrix is extracted automatically
+from the formal support status documents
+in each Xen release.
+The full formal support status document
+is linked to from the column heading for each version.
+
+
+The individual entries are summaries;
+where a specific entry has more information in the full
+document a link, denoted [*], is provided.
+The statuses Supported, Experimental, and so on,
+are likewise defined in the full document.
+
+
+Sometimes the same feature, or a similar feature,
+is named differently
+in the documentation for different releases.
+In such cases the table will show it as
+two separate features,
+with a discontinuity in support,
+even though support may have been continuous.
+
+
+The support status of versions earlier than listed here
+is documented
+https://wiki.xenproject.org/wiki/Xen_Project_Release_Features";>on
the wiki.
+
+Support Matrix
diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate
new file mode 100755
index 000..b5ce3f4
--- /dev/null
+++ b/docs/support-matrix-generate
@@ -0,0 +1,186 @@
+#!/bin/bash
+
+# usage:
+# cd xen.git
+# docs/support-matrix-generate [-D] \
+# refs/remotes/origin/master \
+# https://xenbits.xen.org/docs/unstable/SUPPORT.html \
+# refs/remotes/origin/stable-NN \
+# https://xenbits.xen.org/docs/NN-testing/SUPPORT.html\
+#
+# NN is a *literal* in the above rune! It will be substituted with
+# the appropriate version number.
+#
+# The idea is that we use staging's version of this script, and it
+# looks into the git history and various git remote tracking refs to
+# find the various versions of SUPPORT.md.
+#
+# The arguments specify the git refs to look in, and also the URLs for
+# the SUPPORT.html (which are needed so that we can make
+# cross-reference links). We provide the ref and url (i) for unstable
+# (ii) in template form for all previous versions.
+
+# Algorithm:
+#
+# We start with `refs/remotes/origin/master' and process its
+# SUPPORT.md into json.
+#
+# Then we try to find the next previous revision. This is done by
+# extracting the current version number from xen/Makefile. (We make
+# some slight assumption about how xen/Makefile's xenversion target
+# works, because we want to be able to do this without checking out
+# the whole tree for the version in question.) Then we use git log on
+# xen/Makefile to try to find a commit where the version changed.
+# This gives us the previous version number, NN.
+#
+# That is substituted into the `refs/remotes/origin/stable-NN'
+# argument to get the tip of the relevant branch. That in turns
+# contains another SUPPORT.md. We keep going until either the ref
+# itself is missing, or we get to a ref with no SUPPORT.md.
+
+set -e
+set -o posix
+set -o pipefail
+
+fail () { echo >&2 "$0: $1"; exit 12; }
+
+args=()
+
+case "$1" in
+-D) args+=("$1"); shift ;;
+-*) fail 'bad usage' ;;
+--) shift; break ;;
+esac
+
+case "$#" in
+4) ;;
+*) fail 'bad usage' ;;
+esac
+
+current_ref=$1
+current_url=$2
+pattern_ref=$3
+pattern_url=$4
+
+tmp_prefix="docs/tmp.support-matrix"
+tmp_mdfile="$tmp_prefix.md"
+tmp_revisions="$tmp_prefix.revisions.html"
+
+versionfile=xen/Makefile
+tmp_versionfile="$tmp_prefix.xen.make"
+
+cat do
