Re: [Xen-devel] [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
On Thu, Jan 31, 2019 at 08:07:29AM +0100, Christophe Leroy wrote:
>
>
> Le 31/01/2019 à 07:44, Christophe Leroy a écrit :
> >
> >
> >Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
> >>On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
> >>>
> >>>
> >>>Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock
> allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
> Reviewed-by: Guo Ren # c-sky
> Acked-by: Paul Burton # MIPS
> Acked-by: Heiko Carstens # s390
> Reviewed-by: Juergen Gross # Xen
> ---
> >>>
> >>>[...]
> >>>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 7ea5dc6..ad94242 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> >>>
> >>>[...]
> >>>
> @@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned
> long size, int nid)
> memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> + if (!sparsemap_buf)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
> from=%lx\n",
> + __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
> +
> >>>
> >>>memblock_alloc_try_nid_raw() does not panic (help explicitly says:
> >>>Does not
> >>>zero allocated memory, does not panic if request cannot be satisfied.).
> >>
> >>"Does not panic" does not mean it always succeeds.
> >
> >I agree, but at least here you are changing the behaviour by making it
> >panic explicitly. Are we sure there are not cases where the system could
> >just continue functionning ? Maybe a WARN_ON() would be enough there ?
>
> Looking more in details, it looks like everything is done to live with
> sparsemap_buf NULL, all functions using it check it so having it NULL
> shouldn't imply a panic I believe, see code below.
You are right, I'm preparing the fix right now.
> static void *sparsemap_buf __meminitdata;
> static void *sparsemap_buf_end __meminitdata;
>
> static void __init sparse_buffer_init(unsigned long size, int nid)
> {
> WARN_ON(sparsemap_buf); /* forgot to call sparse_buffer_fini()? */
> sparsemap_buf =
> memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> sparsemap_buf_end = sparsemap_buf + size;
> }
>
> static void __init sparse_buffer_fini(void)
> {
> unsigned long size = sparsemap_buf_end - sparsemap_buf;
>
> if (sparsemap_buf && size > 0)
> memblock_free_early(__pa(sparsemap_buf), size);
> sparsemap_buf = NULL;
> }
>
> void * __meminit sparse_buffer_alloc(unsigned long size)
> {
> void *ptr = NULL;
>
> if (sparsemap_buf) {
> ptr = PTR_ALIGN(sparsemap_buf, size);
> if (ptr + size > sparsemap_buf_end)
> ptr = NULL;
> else
> sparsemap_buf = ptr + size;
> }
> return ptr;
> }
>
>
> Christophe
>
--
Sincerely yours,
Mike.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
Le 31/01/2019 à 07:44, Christophe Leroy a écrit :
Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock
allocators with
adjustment of parameters to include only relevant ones.
The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.
@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);
Signed-off-by: Mike Rapoport
Reviewed-by: Guo Ren # c-sky
Acked-by: Paul Burton # MIPS
Acked-by: Heiko Carstens # s390
Reviewed-by: Juergen Gross # Xen
---
[...]
diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
[...]
@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned
long size, int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+ if (!sparsemap_buf)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+
memblock_alloc_try_nid_raw() does not panic (help explicitly says:
Does not
zero allocated memory, does not panic if request cannot be satisfied.).
"Does not panic" does not mean it always succeeds.
I agree, but at least here you are changing the behaviour by making it
panic explicitly. Are we sure there are not cases where the system could
just continue functionning ? Maybe a WARN_ON() would be enough there ?
Looking more in details, it looks like everything is done to live with
sparsemap_buf NULL, all functions using it check it so having it NULL
shouldn't imply a panic I believe, see code below.
static void *sparsemap_buf __meminitdata;
static void *sparsemap_buf_end __meminitdata;
static void __init sparse_buffer_init(unsigned long size, int nid)
{
WARN_ON(sparsemap_buf); /* forgot to call sparse_buffer_fini()? */
sparsemap_buf =
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
sparsemap_buf_end = sparsemap_buf + size;
}
static void __init sparse_buffer_fini(void)
{
unsigned long size = sparsemap_buf_end - sparsemap_buf;
if (sparsemap_buf && size > 0)
memblock_free_early(__pa(sparsemap_buf), size);
sparsemap_buf = NULL;
}
void * __meminit sparse_buffer_alloc(unsigned long size)
{
void *ptr = NULL;
if (sparsemap_buf) {
ptr = PTR_ALIGN(sparsemap_buf, size);
if (ptr + size > sparsemap_buf_end)
ptr = NULL;
else
sparsemap_buf = ptr + size;
}
return ptr;
}
Christophe
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
Le 31/01/2019 à 07:41, Mike Rapoport a écrit :
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock allocators with
adjustment of parameters to include only relevant ones.
The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.
@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);
Signed-off-by: Mike Rapoport
Reviewed-by: Guo Ren # c-sky
Acked-by: Paul Burton# MIPS
Acked-by: Heiko Carstens # s390
Reviewed-by: Juergen Gross # Xen
---
[...]
diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
[...]
@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long size,
int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+ if (!sparsemap_buf)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+
memblock_alloc_try_nid_raw() does not panic (help explicitly says: Does not
zero allocated memory, does not panic if request cannot be satisfied.).
"Does not panic" does not mean it always succeeds.
I agree, but at least here you are changing the behaviour by making it
panic explicitly. Are we sure there are not cases where the system could
just continue functionning ? Maybe a WARN_ON() would be enough there ?
Christophe
Stephen Rothwell reports a boot failure due to this change.
Please see my reply on that thread.
Christophe
sparsemap_buf_end = sparsemap_buf + size;
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
On Thu, Jan 31, 2019 at 07:07:46AM +0100, Christophe Leroy wrote:
>
>
> Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
> >Add check for the return value of memblock_alloc*() functions and call
> >panic() in case of error.
> >The panic message repeats the one used by panicing memblock allocators with
> >adjustment of parameters to include only relevant ones.
> >
> >The replacement was mostly automated with semantic patches like the one
> >below with manual massaging of format strings.
> >
> >@@
> >expression ptr, size, align;
> >@@
> >ptr = memblock_alloc(size, align);
> >+ if (!ptr)
> >+panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> >size, align);
> >
> >Signed-off-by: Mike Rapoport
> >Reviewed-by: Guo Ren # c-sky
> >Acked-by: Paul Burton # MIPS
> >Acked-by: Heiko Carstens # s390
> >Reviewed-by: Juergen Gross # Xen
> >---
>
> [...]
>
> >diff --git a/mm/sparse.c b/mm/sparse.c
> >index 7ea5dc6..ad94242 100644
> >--- a/mm/sparse.c
> >+++ b/mm/sparse.c
>
> [...]
>
> >@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long
> >size, int nid)
> > memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> > __pa(MAX_DMA_ADDRESS),
> > MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> >+if (!sparsemap_buf)
> >+panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
> >from=%lx\n",
> >+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
> >+
>
> memblock_alloc_try_nid_raw() does not panic (help explicitly says: Does not
> zero allocated memory, does not panic if request cannot be satisfied.).
"Does not panic" does not mean it always succeeds.
> Stephen Rothwell reports a boot failure due to this change.
Please see my reply on that thread.
> Christophe
>
> > sparsemap_buf_end = sparsemap_buf + size;
> > }
> >
>
--
Sincerely yours,
Mike.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 132591: regressions - FAIL
flight 132591 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/132591/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 guest-start/debianhvm.repeat fail REGR. vs. 131842 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 131842 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131842 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 131842 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 131842 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 131842 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 131842 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuub4fbe1f65a4769c09e6bf2d79fc84360f840f40e baseline version: qemuu147923b1a901a0370f83a0f4c58ec1baffef22f0 Last test of basis 131842 2019-01-09 00:37:22 Z 22 days Failing since131892 2019-01-09 23:37:00 Z 21 days 19 attempts Testing same since 132591 2019-01-29 21:51:30 Z1 days1 attempts People who touched revisions under test: Aaron Lindsay Aaron Lindsay Aaron Lindsay Aaron Lindsay OS Aleksandar Markovic Alex Bennée Alex Williamson Alexander Graf Alexander Kanavin Alexandro Sanchez Bach Alexey Kardashevskiy Alistair Francis Andrew Jeffery Anthony PERARD BALATON Zoltan Borislav Petkov Christian Borntraeger Christophe Fergeau Cleber Rosa Collin Walling Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Gibson David Hildenbrand Dongli Zhang Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Eduardo Otubo Emilio G. Cota Eric Auger Eric Blake Fam Zheng Fei Li Fei Li Frediano Ziglio Fredrik Noring Gerd Hoffmann Greg Kurz Guenter Roeck Igor Mammedov Janosch Frank Jian Wang Joel Stanley John Snow Jon Diekema Juan Quintela Julia Suvorova Kamal Heib Kashyap Chamarthy Laurent Vivier Laurent Vivier Li Feng Li Qiang Luc Michel Marc-André Lureau Marcel Apfelbaum Mark Cave-Ayland Markus Armbruster Max Filippov Michael Clark Michael Roth Michael S. Tsirkin Nisarg Shah Palmer Dabbelt Paolo Bonzini Paul Durrant Peng Hao
Re: [Xen-devel] [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
Le 21/01/2019 à 09:04, Mike Rapoport a écrit :
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock allocators with
adjustment of parameters to include only relevant ones.
The replacement was mostly automated with semantic patches like the one
below with manual massaging of format strings.
@@
expression ptr, size, align;
@@
ptr = memblock_alloc(size, align);
+ if (!ptr)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
size, align);
Signed-off-by: Mike Rapoport
Reviewed-by: Guo Ren # c-sky
Acked-by: Paul Burton# MIPS
Acked-by: Heiko Carstens # s390
Reviewed-by: Juergen Gross # Xen
---
[...]
diff --git a/mm/sparse.c b/mm/sparse.c
index 7ea5dc6..ad94242 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
[...]
@@ -425,6 +436,10 @@ static void __init sparse_buffer_init(unsigned long size,
int nid)
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
__pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+ if (!sparsemap_buf)
+ panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d
from=%lx\n",
+ __func__, size, PAGE_SIZE, nid, __pa(MAX_DMA_ADDRESS));
+
memblock_alloc_try_nid_raw() does not panic (help explicitly says: Does
not zero allocated memory, does not panic if request cannot be satisfied.).
Stephen Rothwell reports a boot failure due to this change.
Christophe
sparsemap_buf_end = sparsemap_buf + size;
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 132595: regressions - FAIL
flight 132595 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/132595/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 129475 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 129475 version targeted for testing: ovmf d5788777bcc75936cc0e6acb540a5ee6ac77866b baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z 86 days Failing since129526 2018-11-06 20:49:26 Z 85 days 278 attempts Testing same since 132567 2019-01-29 14:29:34 Z1 days2 attempts People who touched revisions under test: Achin Gupta Alex James Ard Biesheuvel Ashish Singhal Bob Feng bob.c.f...@intel.com BobCF Carsey, Jaben Chasel Chiu Chasel, Chiu Chen A Chen Chu, Maggie Dandan Bi David Wei Derek Lin Eric Dong Eugene Cohen Fan, ZhijuX Felix Polyudov Feng, Bob C Fu Siyuan Gary Lin Hao Wu Jaben Carsey Jagadeesh Ujja Jeff Brasen Jian J Wang Jiaxin Wu Jiewen Yao Julien Grall Krzysztof Koch Laszlo Ersek Leif Lindholm Liming Gao Liu Yu Maggie Chu Marc Zyngier Marcin Wojtas Mike Maslenkin Ming Huang Pedroa Liu Ray Ni Ruiyu Ni Sami Mujawar shenglei Shenglei Zhang Siyuan Fu Songpeng Li Star Zeng Sughosh Ganu Sumit Garg Sun, Zailiang Thomas Abraham Thomas Rydman Ting Ye Tomasz Michalec Vijayenthiran Subramaniam Vladimir Olovyannikov Vladimir Olovyannikov via edk2-devel Wang BinX A Wu Jiaxin Ye Ting Yonghong Zhu yuchenlin Zailiang Sun Zhang, Chao B Zhao, ZhiqiangX Zhiju.Fan zhijufan ZhiqiangX Zhao zwei4 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 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7907 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 132579: regressions - FAIL
flight 132579 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/132579/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 128858 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 128858 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 128858 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 128858 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 128858 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 128858 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 128858 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 128858 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 128858 test-amd64-i386-xl7 xen-boot fail REGR. vs. 128858 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 128858 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 128858 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 128858 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 128858 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 128858 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 128858 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 128858 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 128858 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128858 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128858 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128858 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128858 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128858 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128858 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 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-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail
[Xen-devel] [xen-4.9-testing test] 132582: regressions - FAIL
flight 132582 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/132582/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130954 test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 130954 test-amd64-amd64-pygrub 10 debian-di-installfail REGR. vs. 130954 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 130954 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 130954 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 130954 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 130954 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 130954 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 130954 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 130954 test-amd64-amd64-xl-rtds 10 debian-install fail like 130954 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 130954 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 130954 test-amd64-amd64-libvirt 13 migrate-support-checkfail 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-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen 0437ba0e578d089eb24fc493575cd0e8f2584ec7 baseline version: xen 7f01558d9b3fc4011741e9f469c96fd93dd8454e Last test of basis 130954 2018-12-03 03:12:41 Z 59 days Failing since132484 2019-01-26 01:36:39 Z5 days2 attempts Testing same since 132582 2019-01-29 18:50:03 Z1 days1 attempts People who touched revisions under test: Julien Grall Shameer Kolothum Stefano Stabellini Stefano Stabellini jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev
[Xen-devel] [PATCH v7 15/15] MAINTAINERS: add new section for Argo and self as maintainer
Signed-off-by: Christopher Clark --- v5 whitespace: tabs MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e99d39e..a0cda4f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -158,6 +158,13 @@ S: Supported F: xen/arch/x86/hvm/svm/ F: xen/arch/x86/cpu/vpmu_amd.c +ARGO +M: Christopher Clark +S: Maintained +F: xen/include/public/argo.h +F: xen/include/xen/argo.h +F: xen/common/argo.c + ARINC653 SCHEDULER M: Josh Whitehead M: Robert VanVossen -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 06/15] xen/arm: introduce guest_handle_for_field()
ARM port of c/s bb544585: "introduce guest_handle_for_field()"
This helper turns a field of a GUEST_HANDLE into a GUEST_HANDLE.
Signed-off-by: Christopher Clark
Reviewed-by: Paul Durrant
Reviewed-by: Stefano Stabellini
---
v3: Added Stefano's Reviewed-by
v2: Added Paul's Reviewed-by
xen/include/asm-arm/guest_access.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/include/asm-arm/guest_access.h
b/xen/include/asm-arm/guest_access.h
index 224d2a0..8997a1c 100644
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -63,6 +63,9 @@ int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa,
void *buf,
_y; \
})
+#define guest_handle_for_field(hnd, type, fld) \
+((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
+
#define guest_handle_from_ptr(ptr, type)\
((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
#define const_guest_handle_from_ptr(ptr, type) \
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 07/15] argo: implement the register op
The register op is used by a domain to register a region of memory for receiving messages from either a specified other domain, or, if specifying a wildcard, any domain. This operation creates a mapping within Xen's private address space that will remain resident for the lifetime of the ring. In subsequent commits, the hypervisor will use this mapping to copy data from a sending domain into this registered ring, making it accessible to the domain that registered the ring to receive data. Wildcard any-sender rings are default disabled and registration will be refused with EPERM unless they have been specifically enabled with the new mac-permissive flag that is added to the argo boot option here. The reason why the default for wildcard rings is 'deny' is that there is currently no means to protect the ring from DoS by a noisy domain spamming the ring, affecting other domains ability to send to it. This will be addressed with XSM policy controls in subsequent work. Since denying access to any-sender rings is a significant functional constraint, the new option "mac-permissive" for the argo bootparam enables overriding this. eg: "argo=1,mac-permissive=1" The p2m type of the memory supplied by the guest for the ring must be p2m_ram_rw and the memory will be pinned as PGT_writable_page while the ring is registered. This hypercall op and its interface currently only supports 4K-sized pages. Signed-off-by: Christopher Clark Tested-by: Chris Patterson --- v6 #09 Jan: add compat ABI v6 #07 Jan: add argo_message_header to xlat.lst and invoke the CHECK v6 #07 Jan: xlat.lst: move argo struct entries to alphabetical position v5 #07 Roger: add BUILD_BUG_ON for MAX_RING_SIZE, PAGE_SIZE v5 #07 Roger: gprintk(XENLOG_ERR,.. for denied existing ring v5: add compat validation macros to primary source file: common/argo.c v5 : convert hypercall arg structs to struct form for compat checking v5: dropped external file for compat macros: common/compat/argo.c v4 v3#07 Jan: shrink critical sections in register_ring v4 v3#07 Jan: revise register flag MASK in header, note 32-bitness of args v4 feedback: use standard data structures per common code, not loop macros v4 Andrew: use the single argo command line option list v4 #07 Jan: rewrite find_ring_mfn to use check_get_page_from_gfn v4 #07 Roger: add FIXME to ring_map_page for vmap contiguous ring mapping v3 #07 Jan: comment: minimum ring size is based on minimum-sized message v3 #04 Andrew: reference CONFIG_ARGO in the command line documentation v3 #07 Jan: register_ring: fold else, if into else-if to drop indent v3 #07 Jan: remove no longer used guest_handle_is_aligned macros v3 #07 Jan: remove dead code from find_ring_mfns v3 #07 Jan: fix format string indention in printks v3 #07 Jan: remove redundant bounds check on npage in find_ring_mfns v3 #08 self/Roger: improve dprintk output in find_ring_info like find_send_info v3 #07 Jan: rename ring_find_info to find_ring_info v3 #07 Jan: use array_index_nospec in ring_map_page v3 #07 Jan: fix numeric entries in printk format strings v3 #7 Jan: drop unneeded parentheses from ROUNDUP_MESSAGE defn v3 #10 Roger: move find functions to top of file and drop prototypes v3 #03 meld compat check for hypercall arg register struct v3 #04 Roger/Jan: make lock names clearer and assert their state v3 #04 Jan: port -> aport with type; distinguish argo port from evtchn v3 feedback #07 Eric: fix header max ring size comment units v3 feedback #04 Roger: mfn_mapping: void* instead of uint8_t* v3 use %u for printing unsigned ints in find_ring_mfns v3 feedback #04 Jan: uint32_t -> unsigned int for npage in register_ring v3 feedback #04 Roger: drop npages struct member, calculate from len v3 : register_ring: uint32_t -> unsigned int for private_tx_ptr v3 feedback Roger/Jan: ASSERT currd is current->domain or use 'd' variable name v3 feedback #07 Roger: use opt_argo_mac_permissive : a boolean opt v3 feedback #04 Roger: reorder #includes to alphabetical order v3 feedback #07 Roger: drop comment re: Intel EPT/AMD NPT for write-only mapping v3 feedback #07 Roger: drop ptr arithmetic in update_tx_ptr, use ring struct cast v3 feedback #07 Roger: drop newline in ring_map_page v3 feedback #07 Roger: drop unneeded null check before xfree v3 feedback #07 Roger: use return and drop out label in register_ring v3 Stefano: add 4K page constraint to header file comment & commit msg v3 Julien/Stefano: 4K granularity ok: use 64-bit gfns in register interface v2 self: disallow ring resize via reregister v2 feedback Jan: drop cookie, implement teardown v2 feedback Jan: drop message from argo_message_op v2 self: move hash_index function below locking comment v2 self: OVERHAUL v2 self/Jan: remove use of magic verification field and tidy up v2 self: merge max and min ring size check clauses v2 feedback v1#13 Roger: use OS-supplied roundup; drop from public header v2 feedback #9, Jan: use the argo-mac bootparam at point of introduction v2 feedback #9, Jan: rename boot opt
[Xen-devel] [PATCH v7 10/15] argo: implement the notify op
Queries for data about space availability in registered rings and
causes notification to be sent when space has become available.
The hypercall op populates a supplied data structure with information about
ring state and if insufficient space is currently available in a given ring,
the hypervisor will record the domain's expressed interest and notify it
when it observes that space has become available.
Checks for free space occur when this notify op is invoked, so it may be
intentionally invoked with no data structure to populate
(ie. a NULL argument) to trigger such a check and consequent notifications.
Limit the maximum number of notify requests in a single operation to a
simple fixed limit of 256.
Signed-off-by: Christopher Clark
Tested-by: Chris Patterson
---
v6 #09 Jan: add compat ABI
v6 #04 Jan: xlat.lst: move argo struct entries to alphabetical position
v6: rewrap comment to fix line length
v6 #10 Roger: use list_for_each_entry{_safe} for looping
v5: add EBUSY ent flag when too many domains are already on pending list
v5: reorder notify flags: error flags last, fixed state first
v5: add compat validation macros to primary source file: common/argo.c
v5 : convert hypercall arg structs to struct form for compat checking
v5: dropped external file for compat macros: common/compat/argo.c
v4 #10 Roger: consolidate notify flags; infer pending notify if needed
v4 bugfix: take L3 before accessing ring_info in fill_ring_data
v4 #10 Roger: shorten notify flag names: drop _DATA_F
v4 #10 self/Roger: fill_ring_data: check pending_requeue error code
v4 : use standard data structures as per common code
v4 #10 Roger: lower indentation in fill_ring_data by using goto
v4 #10 Roger: reword the XEN_ARGO_RING_DATA_F_SUFFICIENT comment
v4 fix location of a FIXME that was incorrectly moved by this later commit
v3 #07 Jan: fix format string indention in printks
v3 (general) Jan: drop fixed width types for ringbuf_payload_space
v3 #07 Jan: rename ring_find_info_by_match to find_ring_info_by_match
v3 #07 Jan: fix numeric entries in printk format strings
v3: ringbuf_payload_space: simpler return 0 if get_sanitized_ring fails
v3 #10 Roger: simplify ringbuf_payload_space for empty rings
v3 #10 Roger: ringbuf_payload_space: add comment to explain how ret < INT32_MAX
v3 #10 Roger: drop out label, use return -EFAULT in fill_ring_data
v3 #10 Roger: add newline in signal_domid
v3 #10 Roger: move find functions to top of file and drop prototypes
v3 #04 Jan: meld the compat hypercall arg checking
v3 #04 Roger/Jan: make lock names clearer and assert their state
v3 #04 Jan: port -> aport with type; distinguish argo port from evtchn
v3 self: drop braces in foreach of notify_check_pending
v3 feedback Roger/Jan: ASSERT currd is current->domain or use 'd' variable name
v2 feedback Jan: drop cookie, implement teardown
v2 notify: add flag to indicate ring is shared
v2 argument name for fill_ring_data arg is now currd
v2 self: check ring size vs request and flag error rather than queue signal
v2 feedback Jan: drop 'message' from 'argo_message_op'
v2 self: simplify signal_domid, drop unnecessary label + goto
v2 self: skip the cookie check in pending_cancel
v2 self: implement npending limit on number of pending entries
v1 feedback #16 Jan: sanitize_ring in ringbuf_payload_space
v2 self: inline fill_ring_data_array
v2 self: avoid retesting dst_d for put_domain
v2 self/Jan: remove use of magic verification field and tidy up
v1 feedback #16 Jan: remove testing of magic in guest-supplied structure
v2 self: s/argo_pending_ent/pending_ent/g
v2 feedback v1#13 Roger: use OS-supplied roundup; drop from public header
v1,2 feedback Jan/Roger/Paul: drop errno returning guest access functions
v1 feedback Roger, Jan: drop argo prefix on static functions
v2 self: reduce indentation via goto out if arg NULL
v1 feedback #13 Jan: resolve checking of array handle and use of __copy
v1 #5 (#16) feedback Paul: notify op: use currd in do_argo_message_op
v1 #5 (#16) feedback Paul: notify op: use currd in argo_notify
v1 #5 (#16) feedback Paul: notify op: use currd in argo_notify_check_pending
v1 #5 (#16) feedback Paul: notify op: use currd in argo_fill_ring_data_array
v1 #13 (#16) feedback Paul: notify op: do/while: reindent only
v1 #13 (#16) feedback Paul: notify op: do/while: goto
v1 : add compat xlat.lst entries
v1: add definition for copy_field_from_guest_errno
v1 #13 feedback Jan: make 'ring data' comment comply with single-line style
v1 feedback #13 Jan: use __copy; so define and use __copy_field_to_guest_errno
v1: #13 feedback Jan: public namespace: prefix with xen
v1: #13 feedback Jan: add blank line after case in do_argo_message_op
v1: self: rename ent id to domain_id
v1: self: ent id-> domain_id
v1: self: drop signal if domain_cookie mismatches
v1. feedback #15 Jan: make loop i unsigned
v1. self: drop unnecessary mb() in argo_notify_check_pending
v1. self: add blank line
v1 #16 feedback Jan: const domain arg to +argo_fill_ring_data
v1. feedback #15 Jan:
[Xen-devel] [PATCH v7 12/15] xsm, argo: XSM control for argo message send operation
Default policy: allow.
Signed-off-by: Christopher Clark
Reviewed-by: Paul Durrant
Acked-by: Daniel De Graaf
Tested-by: Chris Patterson
---
v3 Daniel/Jan: add to the default xsm policy for the send op
v3 Add Daniel's Acked-by
v2: reordered commit sequence to after sendv implementation
v1 feedback Jan #16: apply const to function signatures
v1 version was: Reviewed-by: Paul Durrant
tools/flask/policy/modules/guest_features.te | 7 ---
xen/common/argo.c| 11 +++
xen/include/xsm/dummy.h | 6 ++
xen/include/xsm/xsm.h| 6 ++
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c| 7 +++
xen/xsm/flask/policy/access_vectors | 2 ++
7 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/tools/flask/policy/modules/guest_features.te
b/tools/flask/policy/modules/guest_features.te
index d00769e..ca52257 100644
--- a/tools/flask/policy/modules/guest_features.te
+++ b/tools/flask/policy/modules/guest_features.te
@@ -6,10 +6,11 @@ allow domain_type xen_t:xen tmem_op;
allow domain_type xen_t:xen2 pmu_use;
# Allow all domains:
-# to register single-sender (unicast) rings to partner with any domain; and
-# to register any-sender (wildcard) rings that can be sent to by any domain.
+# to register single-sender (unicast) rings to partner with any domain;
+# to register any-sender (wildcard) rings that can be sent to by any domain;
+# and send messages to rings.
allow domain_type xen_t:argo { register_any_source };
-allow domain_type domain_type:argo { register_single_source };
+allow domain_type domain_type:argo { send register_single_source };
# Allow guest console output to the serial console. This is used by PV Linux
# and stub domains for early boot output, so don't audit even when we deny it.
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 5c1e711..b2a2b83 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -2014,6 +2014,17 @@ sendv(struct domain *src_d, xen_argo_addr_t *src_addr,
if ( !dst_d )
return -ESRCH;
+ret = xsm_argo_send(src_d, dst_d);
+if ( ret )
+{
+gprintk(XENLOG_ERR, "argo: XSM REJECTED %i -> %i\n",
+src_d->domain_id, dst_d->domain_id);
+
+put_domain(dst_d);
+
+return ret;
+}
+
read_lock(_global_argo_rwlock);
if ( !src_d->argo )
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 9abfd69..9ae69cc 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -732,6 +732,12 @@ static XSM_INLINE int xsm_argo_register_any_source(const
struct domain *d)
return 0;
}
+static XSM_INLINE int xsm_argo_send(const struct domain *d,
+const struct domain *t)
+{
+return 0;
+}
+
#endif /* CONFIG_ARGO */
#include
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 0b40714..4211892 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -185,6 +185,7 @@ struct xsm_operations {
int (*argo_register_single_source) (const struct domain *d,
const struct domain *t);
int (*argo_register_any_source) (const struct domain *d);
+int (*argo_send) (const struct domain *d, const struct domain *t);
#endif
};
@@ -715,6 +716,11 @@ static inline int xsm_argo_register_any_source(const
struct domain *d)
return xsm_ops->argo_register_any_source(d);
}
+static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
+{
+return xsm_ops->argo_send(d, t);
+}
+
#endif /* CONFIG_ARGO */
#endif /* XSM_NO_WRAPPERS */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index ed236b0..ffac774 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -155,5 +155,6 @@ void __init xsm_fixup_ops (struct xsm_operations *ops)
#ifdef CONFIG_ARGO
set_to_dummy_if_null(ops, argo_register_single_source);
set_to_dummy_if_null(ops, argo_register_any_source);
+set_to_dummy_if_null(ops, argo_send);
#endif
}
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index fcb7487..76c012c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1732,6 +1732,12 @@ static int flask_argo_register_any_source(const struct
domain *d)
return avc_has_perm(domain_sid(d), SECINITSID_XEN, SECCLASS_ARGO,
ARGO__REGISTER_ANY_SOURCE, NULL);
}
+
+static int flask_argo_send(const struct domain *d, const struct domain *t)
+{
+return domain_has_perm(d, t, SECCLASS_ARGO, ARGO__SEND);
+}
+
#endif
long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
@@ -1871,6 +1877,7 @@ static struct xsm_operations flask_ops = {
#ifdef CONFIG_ARGO
.argo_register_single_source = flask_argo_register_single_source,
.argo_register_any_source = flask_argo_register_any_source,
+.argo_send = flask_argo_send,
#endif
};
diff --git a/xen/xsm/flask/policy/access_vectors
[Xen-devel] [PATCH v7 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq
sendv operation is invoked to perform a synchronous send of buffers contained in iovs to a remote domain's registered ring. It takes: * A destination address (domid, port) for the ring to send to. It performs a most-specific match lookup, to allow for wildcard. * A source address, used to inform the destination of where to reply. * The address of an array of iovs containing the data to send * .. and the length of that array of iovs * and a 32-bit message type, available to communicate message context data (eg. kernel-to-kernel, separate from the application data). If insufficient space exists in the destination ring, it will return -EAGAIN and Xen will notify the caller when sufficient space becomes available. Accesses to the ring indices are appropriately atomic. The rings are mapped into Xen's private address space to write as needed and the mappings are retained for later use. Notifications are sent to guests via VIRQ and send_guest_global_virq is exposed in the change to enable argo to call it. VIRQ_ARGO is claimed from the VIRQ previously reserved for this purpose (#11). The VIRQ notification method is used rather than sending events using evtchn functions directly because: * no current event channel type is an exact fit for the intended behaviour. ECS_IPI is closest, but it disallows migration to other VCPUs which is not necessarily a requirement for Argo. * at the point of argo_init, allocation of an event channel is complicated by none of the guest VCPUs being initialized yet and the event channel logic expects that a valid event channel has a present VCPU. * at the point of signalling a notification, the VIRQ logic is already defensive: if d->vcpu[0] is NULL, the notification is just silently dropped, whereas the evtchn_send logic is not so defensive: vcpu[0] must not be NULL, otherwise a null pointer dereference occurs. Using a VIRQ removes the need for the guest to query to determine which event channel notifications will be delivered on. This is also likely to simplify establishing future L0/L1 nested hypervisor argo communication. Signed-off-by: Christopher Clark Tested-by: Chris Patterson --- v6 #09 Jan: introduce compat ABI v6 : hoist read of iovs from guest from ringbuf_insert to do_argo_op v6 : simplify init of the NULL_hnd in ringbuf_insert v6 #09 Jan: xlat.lst remove argo_iov as generated macro not in use v6 #04 Jan: xlat.lst: move argo struct entries to alphabetical position v6 #09 Roger: fix reference to VIRQ_ARGO in commit message v6 #09 Roger: use list_for_each_entry for looping v5 #09 Roger: add comment explaining post-iovs tx_ptr round up + wrap v5 #09 Roger: remove redundant len bounds check vs MAX_ARGO_MESSAGE_SIZE v5 #09 Roger: ringbuf_insert: WARN not ERR on empty iovs v5 #09 Roger: bugfix: set rc = -EFAULT if !guest_handle_okay v5 use EBUSY when cannot add to the pending ent queue: many domains active v5: add compat validation macros to primary source file: common/argo.c v5: dropped external file for compat macros: common/compat/argo.c v5 : convert hypercall arg structs to struct form for compat checking v5 : switch argo_iov to needs translation in xlat.lst v4 Jan: remove use of fixed-width types from iov_count, ringbuf_insert v4 #07 Jan: shrink critical sections in sendv v3 #07 Jan: header: note 32-bitness of hypercall message tuype arg v4 : use standard data structures as per common code v4 self: bugfix memcpy_to_guest_ring: head_len must check (offset + len) v4 #09 Roger: drop MESSAGE from VIRQ_ARGO_MESSAGE v3 #07 Jan: rename ring_find_info* to find_ring_info* v3 #07 Jan: fix numeric entries in printk format strings v3 #10 Roger: move find functions to top of file and drop prototypes v3 #04 Jan: meld compat struct checking for hypercall args v3 #04 Roger/Jan: make lock names clearer and assert their state v3 #04 Jan: port -> aport with type; distinguish argo port from evtchn v3 feedback #09 Eric: fix len & offset sanity check in memcpy_to_guest_ring v3 feedback #04 Roger: newline fix in wildcard_pending_list_insert v3 feedback #04 Roger: drop npages struct member, calculate from len v3 #09 Roger: simplify EFAULT return in memcpy_to_guest_ring v3 #09 Roger: add newline before return in get_sanitized_ring v3 #09 Roger: replace while with for loop in iov_count v3 #09 Roger: drop 0 in struct init in ringbuf_insert v3 #09 Roger: comment for XEN_ARGO_MAXIOV: warn of stack overflow risk v3 #09 Roger: simplify while loop: for instead in ringbuf_insert v3 #09 Roger: drop out label for returns in ringbuf_insert v3 #09 Roger: drop newline in pending_queue v3 #09 Roger: replace second goto label with error path unlock in sendv v3 #09 Jason: check iov_len vs MAX_ARGO_MESSAGE_SIZE in iov_count v3 #09 Jason: check padding is zeroed in sendv op v3 #09 Jason: memcpy_to_guest_ring: simpler code with better loop v2 self: use ring_info backpointer in pending_ent to maintain npending v2 feedback Jan: drop cookie, implement teardown v2 self: pending_queue:
[Xen-devel] [PATCH v7 04/15] argo: init, destroy and soft-reset, with enable command line opt
Initialises basic data structures and performs teardown of argo state
for domain shutdown.
Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
Introduces a new Xen command line parameter 'argo': bool to enable/disable
the argo hypercall. Defaults to disabled.
New headers:
public/argo.h: with definions of addresses and ring structure, including
indexes for atomic update for communication between domain and hypervisor.
xen/argo.h: to expose the hooks for integration into domain lifecycle:
argo_init: per-domain init of argo data structures for domain_create.
argo_destroy: teardown for domain_destroy and the error exit
path of domain_create.
argo_soft_reset: reset of domain state for domain_soft_reset.
Adds a new field to struct domain: struct argo_domain *argo;
In accordance with recent work on _domain_destroy, argo_destroy is
idempotent. It will tear down: all rings registered by this domain, all
rings where this domain is the single sender (ie. specified partner,
non-wildcard rings), and all pending notifications where this domain is
awaiting signal about available space in the rings of other domains.
A count will be maintained of the number of rings that a domain has
registered in order to limit it below the fixed maximum limit defined here.
Macros are defined to verify the internal locking state within the argo
implementation. The macros are ASSERTed on entry to functions to validate
and document the required lock state prior to calling.
The hash function for the hashtables that hold ring state is derived from
the string hashing function djb2 (http://www.cse.yorku.ca/~oz/hash.html)
by Daniel J. Bernstein. Basic testing with a limited number of domains and
ports has shown reasonable distribution for the table size.
The software license on the public header is the BSD license, standard
procedure for the public Xen headers. The public header was originally
posted under a GPL license at: [1]:
https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02710.html
The following ACK by Lars Kurth is to confirm that only people being
employees of Citrix contributed to the header files in the series posted at
[1] and that thus the copyright of the files in question is fully owned by
Citrix. The ACK also confirms that Citrix is happy for the header files to
be published under a BSD license in this series (which is based on [1]).
Signed-off-by: Christopher Clark
Acked-by: Lars Kurth
Reviewed-by: Ross Philipson
Tested-by: Chris Patterson
---
v6 #09 Jan: introduce compat ABI
v6 #04 Jan: xlat.lst: move argo struct entries to alphabetical position
v6 #04 Roger: use list_for_each_entry{_safe} for looping
v5 #04 Roger: tweak command line doc: remove statement about top level bool
v5: add compat validation macros to primary source file: common/argo.c
v5: dropped external file for compat macros: common/compat/argo.c
v4: removed FIXME for removing argo_destroy from domain_kill
v4 Jan: amend the command line doc text referring to build configuration
v4 : use standard data structures as per common code
v4 Jan: replace hash_index with djb2-derived hash algorithm
v4 Andrew: switch argo command line option to list argo=
v4 #04 Roger: drop unneeded init of ring_count in argo_domain_init
v4 #04 Roger: replace if (ring_info->mfns) with ASSERTs in ring_unmap
v4 #04 Roger: rewrite the locking verification macros
v4 #04 Roger: make L1 lock description comment clearer about R(L1) and W(L1)
v4 Andrew: fix split of dprintk in ring_map_info across v4 commits
v3 #04 Andrew: use xzalloc for struct argo_domain in argo_init
v3 #04 Andrew: reference CONFIG_ARGO in the command line documentation
v3 #07 Jan: rename ring_find_info to find_ring_info
v3 #04 Andrew: don't truncate args do_argo_op printk
v3 #07 Jan: fix numeric entries in printk format strings
v3 #10 Roger: move find functions to top of file and drop prototypes
v3 #04 Jan: meld compat check for hypercall arg types
v3 #04 Roger/Jan: make lock names clearer and assert their state
v3 #04 Jan: port -> aport with type; distinguish argo port from evtchn
v3 #04 Jan: reorder call to argo_init_domain in argo_init
v3 #04 Jan: ring_remove_mfns: zero count before freeing arrays
v3 #04 Jason/Roger: soft_reset: can assume reinit is ok if d->argo set
v3 #04 Roger: remove unused and confusing d->argo_lock
v3 #04 Roger: add simple inlines in xen/argo.h, drop ifdef CONFIG_ARGO
v3 #04 Roger: simpler return -EOPNOTSUPP in do_argo_op
v3 #04 Roger: add const to domain arg to ring_remove_info
v3 #04 Roger: use XFREE
v3 #04 Roger: newline fix in wildcard_pending_list_remove
v3 #04 Roger: mfn_mapping: void* instead of uint8_t*
v3 #04 Roger: drop npages struct member in argo_ring_info; use len
v3 #04 Roger/Jan: drop many fixed width types in internal structs
v3 #04 Jason/Jan: drop pad and fixed width type in pending_ent struct
v3 #04 Eric: moved ring_find_info from register op into this commit
v3 moved hash_index function, nospec include
[Xen-devel] [PATCH v7 14/15] xsm, argo: notify: don't describe rings that cannot be sent to
Signed-off-by: Christopher Clark
Acked-by: Daniel De Graaf
Tested-by: Chris Patterson
---
v3 #10 Roger: drop out label, use return -EFAULT in fill_ring_data
v3: Add Daniel's Acked-by
xen/common/argo.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 44228d5..17ad667 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -1335,6 +1335,17 @@ fill_ring_data(const struct domain *currd,
if ( !dst_d || !dst_d->argo )
goto out;
+/*
+ * Don't supply information about rings that a guest is not
+ * allowed to send to.
+ */
+ret = xsm_argo_send(currd, dst_d);
+if ( ret )
+{
+put_domain(dst_d);
+return ret;
+}
+
read_lock(_d->argo->rings_L2_rwlock);
ring_info = find_ring_info_by_match(dst_d, ent.ring.aport,
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 01/15] argo: Introduce the Kconfig option to govern inclusion of Argo
Defines CONFIG_ARGO when enabled. Default: disabled. When the Kconfig option is enabled, the Argo hypercall implementation will be included, allowing use of the hypervisor-mediated interdomain communication mechanism. Argo is implemented for x86 and ARM hardware platforms. Availability of the option depends on EXPERT and Argo is currently an experimental feature. Signed-off-by: Christopher Clark Acked-by: Jan Beulich --- v3 added Jan's Ack v2 #01 feedback, Jan: replace def_bool/prompt with bool v1 #02 feedback, Jan: default Kconfig off, use EXPERT, fix whitespace xen/common/Kconfig | 19 +++ 1 file changed, 19 insertions(+) diff --git a/xen/common/Kconfig b/xen/common/Kconfig index a79cd40..0438462 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -202,6 +202,25 @@ config LATE_HWDOM If unsure, say N. +config ARGO + bool "Argo: hypervisor-mediated interdomain communication" if EXPERT = "y" + ---help--- + Enables a hypercall for domains to ask the hypervisor to perform + data transfer of messages between domains. + + This allows communication channels to be established that do not + require any shared memory between domains; the hypervisor is the + entity that each domain interacts with. The hypervisor is able to + enforce Mandatory Access Control policy over the communication. + + If XSM_FLASK is enabled, XSM policy can govern which domains may + communicate via the Argo system. + + This feature does nothing if the "argo" boot parameter is not present. + Argo is disabled at runtime by default. + + If unsure, say N. + menu "Schedulers" visible if EXPERT = "y" -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 05/15] errno: add POSIX error codes EMSGSIZE, ECONNREFUSED to the ABI
EMSGSIZE: Argo's sendv operation will return EMSGSIZE when an excess amount of data, across all iovs, has been supplied, exceeding either the statically configured maximum size of a transmittable message, or the (variable) size of the ring registered by the destination domain. ECONNREFUSED: Argo's register operation will return ECONNREFUSED if a ring is being registered to communicate with a specific remote domain that does exist but is not argo-enabled. These codes are described by POSIX here: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html EMSGSIZE : "Message too large" ECONNREFUSED : "Connection refused". The numeric values assigned to each are taken from Linux, as is the case for the existing error codes. EMSGSIZE : 90 ECONNREFUSED : 111 Signed-off-by: Christopher Clark Acked-by: Jan Beulich --- xen/include/public/errno.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/public/errno.h b/xen/include/public/errno.h index 305c112..e1d02fc 100644 --- a/xen/include/public/errno.h +++ b/xen/include/public/errno.h @@ -102,6 +102,7 @@ XEN_ERRNO(EILSEQ, 84) /* Illegal byte sequence */ XEN_ERRNO(ERESTART,85) /* Interrupted system call should be restarted */ #endif XEN_ERRNO(ENOTSOCK,88) /* Socket operation on non-socket */ +XEN_ERRNO(EMSGSIZE,90) /* Message too large. */ XEN_ERRNO(EOPNOTSUPP, 95) /* Operation not supported on transport endpoint */ XEN_ERRNO(EADDRINUSE, 98) /* Address already in use */ XEN_ERRNO(EADDRNOTAVAIL, 99) /* Cannot assign requested address */ @@ -109,6 +110,7 @@ XEN_ERRNO(ENOBUFS, 105)/* No buffer space available */ XEN_ERRNO(EISCONN, 106)/* Transport endpoint is already connected */ XEN_ERRNO(ENOTCONN,107)/* Transport endpoint is not connected */ XEN_ERRNO(ETIMEDOUT, 110)/* Connection timed out */ +XEN_ERRNO(ECONNREFUSED,111)/* Connection refused */ #undef XEN_ERRNO #endif /* XEN_ERRNO */ -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 11/15] xsm, argo: XSM control for argo register
XSM controls for argo ring registration with two distinct cases, where
the ring being registered is:
1) Single source: registering a ring for communication to receive messages
from a specified single other domain.
Default policy: allow.
2) Any source: registering a ring for communication to receive messages
from any, or all, other domains (ie. wildcard).
Default policy: deny, with runtime policy configuration via bootparam.
This commit modifies the signature of core XSM hook functions in order to
apply 'const' to arguments, needed in order for 'const' to be accepted in
signature of functions that invoke them.
Signed-off-by: Christopher Clark
Acked-by: Daniel De Graaf
Tested-by: Chris Patterson
---
v6 Chris: apply const to avc_audit_data sdom and tdom struct members
v6 Chris: apply const to args in dummy.h function signatures
v6 Chris: fix missing return type in xsm.h inline functions
v3 Daniel/Jan: add to the default xsm policy for the register op
v3 hoist opt_argo_mac_permissive check to allow default policy to match non-XSM
v3 was: Acked-by: Daniel De Graaf
v3 Add Daniel's Acked-by ; note minor changes required for v4
v3 feedback #07 Roger: use opt_argo_mac_permissive : a boolean opt
v2 feedback #9 Jan: refactor to use argo-mac bootparam at point of introduction
v1 feedback Paul: replace use of strncmp with strcmp
v1 feedback #16 Jan: apply const to function signatures
v1 feedback #14 Jan: add blank line before return in parse_argo_mac_param
tools/flask/policy/modules/guest_features.te | 6 ++
xen/common/argo.c| 11 +--
xen/include/xsm/dummy.h | 14 ++
xen/include/xsm/xsm.h| 19 +++
xen/xsm/dummy.c | 4
xen/xsm/flask/hooks.c| 27 ---
xen/xsm/flask/include/avc.h | 4 ++--
xen/xsm/flask/policy/access_vectors | 11 +++
xen/xsm/flask/policy/security_classes| 1 +
9 files changed, 90 insertions(+), 7 deletions(-)
diff --git a/tools/flask/policy/modules/guest_features.te
b/tools/flask/policy/modules/guest_features.te
index 9ac9780..d00769e 100644
--- a/tools/flask/policy/modules/guest_features.te
+++ b/tools/flask/policy/modules/guest_features.te
@@ -5,6 +5,12 @@ allow domain_type xen_t:xen tmem_op;
# pmu_ctrl is for)
allow domain_type xen_t:xen2 pmu_use;
+# Allow all domains:
+# to register single-sender (unicast) rings to partner with any domain; and
+# to register any-sender (wildcard) rings that can be sent to by any domain.
+allow domain_type xen_t:argo { register_any_source };
+allow domain_type domain_type:argo { register_single_source };
+
# Allow guest console output to the serial console. This is used by PV Linux
# and stub domains for early boot output, so don't audit even when we deny it.
# Without XSM, this is enabled only if the Xen was compiled in debug mode.
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 78d6f00..5c1e711 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
@@ -1676,8 +1677,10 @@ register_ring(struct domain *currd,
if ( reg.partner_id == XEN_ARGO_DOMID_ANY )
{
-if ( !opt_argo_mac_permissive )
-return -EPERM;
+ret = opt_argo_mac_permissive ? xsm_argo_register_any_source(currd) :
+-EPERM;
+if ( ret )
+return ret;
}
else
{
@@ -1688,6 +1691,10 @@ register_ring(struct domain *currd,
return -ESRCH;
}
+ret = xsm_argo_register_single_source(currd, dst_d);
+if ( ret )
+goto out;
+
send_info = xzalloc(struct argo_send_info);
if ( !send_info )
{
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index a29d1ef..9abfd69 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -720,6 +720,20 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFAULT_ARG struct
domain *d)
#endif /* CONFIG_X86 */
+#ifdef CONFIG_ARGO
+static XSM_INLINE int xsm_argo_register_single_source(const struct domain *d,
+ const struct domain *t)
+{
+return 0;
+}
+
+static XSM_INLINE int xsm_argo_register_any_source(const struct domain *d)
+{
+return 0;
+}
+
+#endif /* CONFIG_ARGO */
+
#include
static XSM_INLINE int xsm_xen_version (XSM_DEFAULT_ARG uint32_t op)
{
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3b192b5..0b40714 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -181,6 +181,11 @@ struct xsm_operations {
#endif
int (*xen_version) (uint32_t cmd);
int (*domain_resource_map) (struct domain *d);
+#ifdef CONFIG_ARGO
+int (*argo_register_single_source) (const struct domain *d,
+
[Xen-devel] [PATCH v7 13/15] xsm, argo: XSM control for any access to argo by a domain
Will inhibit initialization of the domain's argo data structure to
prevent receiving any messages or notifications and access to any of
the argo hypercall operations.
Signed-off-by: Christopher Clark
Acked-by: Daniel De Graaf
Tested-by: Chris Patterson
---
v6 #09 Jan: add compat ABI
v6 Chris: apply const to args in dummy.h function signatures
v6 Chris: fix missing return type in xsm.h inline functions
v3 Daniel/Jan: add to the default xsm policy for enable
v3 Add Daniel's Acked-by
v3 #04 Jason/Roger: soft_reset: can assume reinit is ok if d->argo set
v2 self: fix xsm use in soft-reset prior to introduction
v1 #5 (#17) feedback Paul: XSM control for any access: use currd
v1 #16 feedback Jan: apply const to function signatures
tools/flask/policy/modules/guest_features.te | 4 ++--
xen/common/argo.c| 12 ++--
xen/include/xsm/dummy.h | 5 +
xen/include/xsm/xsm.h| 6 ++
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c| 7 +++
xen/xsm/flask/policy/access_vectors | 3 +++
7 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/tools/flask/policy/modules/guest_features.te
b/tools/flask/policy/modules/guest_features.te
index ca52257..fe4835d 100644
--- a/tools/flask/policy/modules/guest_features.te
+++ b/tools/flask/policy/modules/guest_features.te
@@ -5,11 +5,11 @@ allow domain_type xen_t:xen tmem_op;
# pmu_ctrl is for)
allow domain_type xen_t:xen2 pmu_use;
-# Allow all domains:
+# Allow all domains to enable the Argo interdomain communication hypercall;
# to register single-sender (unicast) rings to partner with any domain;
# to register any-sender (wildcard) rings that can be sent to by any domain;
# and send messages to rings.
-allow domain_type xen_t:argo { register_any_source };
+allow domain_type xen_t:argo { enable register_any_source };
allow domain_type domain_type:argo { send register_single_source };
# Allow guest console output to the serial console. This is used by PV Linux
diff --git a/xen/common/argo.c b/xen/common/argo.c
index b2a2b83..44228d5 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -2094,7 +2094,7 @@ do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void)
arg1,
argo_dprintk("->do_argo_op(%u,%p,%p,%lu,0x%lx)\n", cmd,
(void *)arg1.p, (void *)arg2.p, arg3, arg4);
-if ( unlikely(!opt_argo) )
+if ( unlikely(!opt_argo || xsm_argo_enable(currd)) )
return -EOPNOTSUPP;
switch (cmd)
@@ -2212,7 +2212,7 @@ compat_argo_op(unsigned int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg1,
argo_dprintk("->compat_argo_op(%u,%p,%p,%lu,0x%lx)\n", cmd,
(void *)arg1.p, (void *)arg2.p, arg3, arg4);
-if ( unlikely(!opt_argo) )
+if ( unlikely(!opt_argo || xsm_argo_enable(currd)) )
return -EOPNOTSUPP;
switch (cmd)
@@ -2348,7 +2348,7 @@ argo_init(struct domain *d)
{
struct argo_domain *argo;
-if ( !opt_argo )
+if ( !opt_argo || xsm_argo_enable(d) )
{
argo_dprintk("argo disabled, domid: %u\n", d->domain_id);
return 0;
@@ -2405,9 +2405,9 @@ argo_soft_reset(struct domain *d)
wildcard_rings_pending_remove(d);
/*
- * Since opt_argo cannot change at runtime, if d->argo is true then
- * opt_argo must be true, and we can assume that init is allowed to
- * proceed again here.
+ * Since neither opt_argo or xsm_argo_enable(d) can change at runtime,
+ * if d->argo is true then both opt_argo and xsm_argo_enable(d) must be
+ * true, and we can assume that init is allowed to proceed again here.
*/
argo_domain_init(d->argo);
}
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 9ae69cc..e628b1c 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -721,6 +721,11 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFAULT_ARG struct
domain *d)
#endif /* CONFIG_X86 */
#ifdef CONFIG_ARGO
+static XSM_INLINE int xsm_argo_enable(const struct domain *d)
+{
+return 0;
+}
+
static XSM_INLINE int xsm_argo_register_single_source(const struct domain *d,
const struct domain *t)
{
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4211892..8a78d8a 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -182,6 +182,7 @@ struct xsm_operations {
int (*xen_version) (uint32_t cmd);
int (*domain_resource_map) (struct domain *d);
#ifdef CONFIG_ARGO
+int (*argo_enable) (const struct domain *d);
int (*argo_register_single_source) (const struct domain *d,
const struct domain *t);
int (*argo_register_any_source) (const struct domain *d);
@@ -705,6 +706,11 @@ static inline int xsm_domain_resource_map(xsm_default_t
def, struct domain *d)
}
#ifdef CONFIG_ARGO
+static inline
[Xen-devel] [PATCH v7 03/15] argo: define argo_dprintk for subsystem debugging
A convenience for working on development of the argo subsystem:
setting a #define variable enables additional debug messages.
Signed-off-by: Christopher Clark
Acked-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v3 added Roger's Reviewed-by
v3 added Jan's Ack
v2 #03 feedback, Jan: fix ifdef/define confusion error
v1 #04 feedback, Jan: fix dprintk implementation
xen/common/argo.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index ddc48f1..e91ade5 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -19,6 +19,15 @@
#include
#include
+/* Change this to #define ARGO_DEBUG here to enable more debug messages */
+#undef ARGO_DEBUG
+
+#ifdef ARGO_DEBUG
+#define argo_dprintk(format, args...) printk("argo: " format, ## args )
+#else
+#define argo_dprintk(format, ... ) ((void)0)
+#endif
+
long
do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
XEN_GUEST_HANDLE_PARAM(void) arg2, unsigned long arg3,
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 00/15] Argo: hypervisor-mediated interdomain communication
Version seven of this series: * Adds compat ABI in support of using handles - hypercall table entries now use COMPAT_CALL - affects boilerplate patch, so dropped the prior Ack there - ARM hypercall table entry is actually added this time - since using compat now, dropped use of always-64-bit pfn type (note: this is first time adding such compat logic: feedback appreciated) * Applied list iteration macros to replace for loops * Fixes for XSM patches identified in testing * Reorder and reposition compat entries in xlat.lst - added missing xen_argo_message_header entry Christopher Clark (15): argo: Introduce the Kconfig option to govern inclusion of Argo argo: introduce the argo_op hypercall boilerplate argo: define argo_dprintk for subsystem debugging argo: init, destroy and soft-reset, with enable command line opt errno: add POSIX error codes EMSGSIZE, ECONNREFUSED to the ABI xen/arm: introduce guest_handle_for_field() argo: implement the register op argo: implement the unregister op argo: implement the sendv op; evtchn: expose send_guest_global_virq argo: implement the notify op xsm, argo: XSM control for argo register xsm, argo: XSM control for argo message send operation xsm, argo: XSM control for any access to argo by a domain xsm, argo: notify: don't describe rings that cannot be sent to MAINTAINERS: add new section for Argo and self as maintainer MAINTAINERS |7 + docs/misc/xen-command-line.pandoc| 20 + tools/flask/policy/modules/guest_features.te |7 + xen/arch/arm/traps.c |3 + xen/arch/x86/guest/hypercall_page.S |2 +- xen/arch/x86/hvm/hypercall.c |3 + xen/arch/x86/hypercall.c |3 + xen/arch/x86/pv/hypercall.c |3 + xen/common/Kconfig | 19 + xen/common/Makefile |1 + xen/common/argo.c| 2427 ++ xen/common/domain.c |9 + xen/common/event_channel.c |2 +- xen/include/Makefile |1 + xen/include/asm-arm/guest_access.h |3 + xen/include/public/argo.h| 274 +++ xen/include/public/errno.h |2 + xen/include/public/xen.h |4 +- xen/include/xen/argo.h | 44 + xen/include/xen/event.h |7 + xen/include/xen/hypercall.h | 18 + xen/include/xen/sched.h |5 + xen/include/xlat.lst |9 + xen/include/xsm/dummy.h | 25 + xen/include/xsm/xsm.h| 31 + xen/xsm/dummy.c |6 + xen/xsm/flask/hooks.c| 41 +- xen/xsm/flask/include/avc.h |4 +- xen/xsm/flask/policy/access_vectors | 16 + xen/xsm/flask/policy/security_classes|1 + 30 files changed, 2988 insertions(+), 9 deletions(-) create mode 100644 xen/common/argo.c create mode 100644 xen/include/public/argo.h create mode 100644 xen/include/xen/argo.h -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 08/15] argo: implement the unregister op
Takes a single argument: a handle to the ring unregistration struct,
which specifies the port and partner domain id or wildcard.
The ring's entry is removed from the hashtable of registered rings;
any entries for pending notifications are removed; and the ring is
unmapped from Xen's address space.
If the ring had been registered to communicate with a single specified
domain (ie. a non-wildcard ring) then the partner domain state is removed
from the partner domain's argo send_info hash table.
Signed-off-by: Christopher Clark
Reviewed-by: Roger Pau Monné
Tested-by: Chris Patterson
---
v6 #09 Jan: add compat ABI
v6 Chris: add Tested-by
v6 Roger: add Reviewed-by
v6 #04 Jan: xlat.lst: move argo struct entries to alphabetical position
v6 #04 Roger: use list_for_each_entry for looping
v5: add compat validation macros to primary source file: common/argo.c
v5: dropped external file for compat macros: common/compat/argo.c
v4 # Jan: shrink the critical sections in unregister
v4 : use standard data structures as per common code
v4 #08 Roger: skip send_info lookup for wildcard rings
v4: add ASSERT_UNREACHABLE for missing sender domain or send_info
v4: reduce indentation by using goto
v4: add unlikely to currd->argo check
v4 #08 Jan: move put_domain outside L2 critical section
v4: include ring data in debug output when ring not found
v3 #08 Jan: pull xfree out of exclusive critical sections in unregister_ring
v3 #08 Jan: rename send_find_info to find_send_info
v3 #07 Jan: rename ring_find_info to find_ring_info
v3 #08 Roger: use return and remove the out label in unregister_ring
v3 #08 Roger: better debug output in send_find_info
v3 #10 Roger: move find functions to top of file and drop prototypes
v3 #04 Jan: meld compat check for unregister_ring struct
v3 #04 Roger/Jan: make lock names clearer and assert their state
v3 #04 Jan: port -> aport with type; distinguish argo port from evtchn
v3 feedback Roger/Jan: ASSERT currd is current->domain or use 'd' variable name
v3 feedback #07 Roger: const the argo_ring_id structs in send_find_info
v2 feedback Jan: drop cookie, implement teardown
v2 feedback Jan: drop message from argo_message_op
v2 self: OVERHAUL
v2 self: reorder logic to shorten critical section
v1 #13 feedback Jan: revise use of guest_handle_okay vs __copy ops
v1 feedback Roger, Jan: drop argo prefix on static functions
v1,2 feedback Jan/Roger/Paul: drop errno returning guest access functions
v1 #5 (#14) feedback Paul: use currd in do_argo_message_op
v1 #5 (#14) feedback Paul: full use currd in argo_unregister_ring
v1 #13 (#14) feedback Paul: replace do/while with goto; reindent
v1 self: add blank lines in unregister case in do_argo_message_op
v1: #13 feedback Jan: public namespace: prefix with xen
v1: #13 feedback Jan: blank line after op case in do_argo_message_op
v1: #14 feedback Jan: replace domain id override with validation
v1: #18 feedback Jan: meld the ring count limit into the series
v1: feedback #15 Jan: verify zero in unused hypercall args
xen/common/argo.c | 140 ++
xen/include/public/argo.h | 19 +++
xen/include/xlat.lst | 1 +
3 files changed, 160 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 54256ae..e724fc7 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -37,6 +37,7 @@ CHECK_argo_addr;
CHECK_argo_register_ring;
CHECK_argo_ring;
CHECK_argo_ring_message_header;
+CHECK_argo_unregister_ring;
#endif
#define MAX_RINGS_PER_DOMAIN128U
@@ -52,6 +53,7 @@ CHECK_argo_ring_message_header;
DEFINE_XEN_GUEST_HANDLE(xen_argo_addr_t);
DEFINE_XEN_GUEST_HANDLE(xen_argo_register_ring_t);
DEFINE_XEN_GUEST_HANDLE(xen_argo_ring_t);
+DEFINE_XEN_GUEST_HANDLE(xen_argo_unregister_ring_t);
#ifdef CONFIG_COMPAT
DEFINE_XEN_GUEST_HANDLE(compat_pfn_t);
#endif
@@ -362,6 +364,36 @@ find_ring_info(const struct domain *d, const struct
argo_ring_id *id)
return NULL;
}
+static struct argo_send_info *
+find_send_info(const struct domain *d, const struct argo_ring_id *id)
+{
+struct argo_send_info *send_info;
+const struct list_head *bucket;
+
+ASSERT(LOCKING_send_L2(d));
+
+/* List is not modified here. Search and return the match if found. */
+bucket = >argo->send_hash[hash_index(id)];
+
+list_for_each_entry(send_info, bucket, node)
+{
+const struct argo_ring_id *cmpid = _info->id;
+
+if ( cmpid->aport == id->aport &&
+ cmpid->domain_id == id->domain_id &&
+ cmpid->partner_id == id->partner_id )
+{
+argo_dprintk("found send_info for ring(%u:%x %u)\n",
+ id->domain_id, id->aport, id->partner_id);
+return send_info;
+}
+}
+argo_dprintk("no send_info for ring(%u:%x %u)\n",
+ id->domain_id, id->aport, id->partner_id);
+
+return NULL;
+}
+
static void
ring_unmap(const struct domain *d, struct argo_ring_info *ring_info)
{
@@ -765,6 +797,85
[Xen-devel] [PATCH v7 02/15] argo: introduce the argo_op hypercall boilerplate
Presence is gated upon CONFIG_ARGO.
Registers the hypercall previously reserved for this.
Takes 5 arguments, does nothing and returns -ENOSYS.
Implementation will provide a compat ABI so COMPAT_CALL is the
macro used in the hypercall tables.
Signed-off-by: Christopher Clark
---
v6 dropped Jan Acked-by due to change of implementation and commit msg
v6 switched to COMPAT_CALL and provides compat_argo_op
v6 feedback #3 Julien: add argo_op to the ARM hypercall table
v2 Copyright line: add 2019
v2 feedback #3 Jan: drop "message" from argo_message_op
v2 feedback #3 Jan: add Acked-by
v1 feedback #15 Jan: handle upper-halves of hypercall args
v1 feedback #15 Jan: use unsigned where negative values impossible
xen/arch/arm/traps.c| 3 +++
xen/arch/x86/guest/hypercall_page.S | 2 +-
xen/arch/x86/hvm/hypercall.c| 3 +++
xen/arch/x86/hypercall.c| 3 +++
xen/arch/x86/pv/hypercall.c | 3 +++
xen/common/Makefile | 1 +
xen/common/argo.c | 38 +
xen/include/public/xen.h| 2 +-
xen/include/xen/hypercall.h | 18 ++
9 files changed, 71 insertions(+), 2 deletions(-)
create mode 100644 xen/common/argo.c
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 221c762..e1e8ac9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1397,6 +1397,9 @@ static arm_hypercall_t arm_hypercall_table[] = {
HYPERCALL(platform_op, 1),
HYPERCALL_ARM(vcpu_op, 3),
HYPERCALL(vm_assist, 2),
+#ifdef CONFIG_ARGO
+HYPERCALL(argo_op, 5),
+#endif
};
#ifndef NDEBUG
diff --git a/xen/arch/x86/guest/hypercall_page.S
b/xen/arch/x86/guest/hypercall_page.S
index fdd2e72..26afabf 100644
--- a/xen/arch/x86/guest/hypercall_page.S
+++ b/xen/arch/x86/guest/hypercall_page.S
@@ -59,7 +59,7 @@ DECLARE_HYPERCALL(sysctl)
DECLARE_HYPERCALL(domctl)
DECLARE_HYPERCALL(kexec_op)
DECLARE_HYPERCALL(tmem_op)
-DECLARE_HYPERCALL(xc_reserved_op)
+DECLARE_HYPERCALL(argo_op)
DECLARE_HYPERCALL(xenpmu_op)
DECLARE_HYPERCALL(arch_0)
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 19d1263..5bb1750 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -134,6 +134,9 @@ static const hypercall_table_t hvm_hypercall_table[] = {
#ifdef CONFIG_TMEM
HYPERCALL(tmem_op),
#endif
+#ifdef CONFIG_ARGO
+COMPAT_CALL(argo_op),
+#endif
COMPAT_CALL(platform_op),
#ifdef CONFIG_PV
COMPAT_CALL(mmuext_op),
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 032de8f..93e7860 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -64,6 +64,9 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
ARGS(domctl, 1),
ARGS(kexec_op, 2),
ARGS(tmem_op, 1),
+#ifdef CONFIG_ARGO
+ARGS(argo_op, 5),
+#endif
ARGS(xenpmu_op, 2),
#ifdef CONFIG_HVM
ARGS(hvm_op, 2),
diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index 5d11911..f452dd5 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -77,6 +77,9 @@ const hypercall_table_t pv_hypercall_table[] = {
#ifdef CONFIG_TMEM
HYPERCALL(tmem_op),
#endif
+#ifdef CONFIG_ARGO
+COMPAT_CALL(argo_op),
+#endif
HYPERCALL(xenpmu_op),
#ifdef CONFIG_HVM
HYPERCALL(hvm_op),
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 56fc201..59ac7de 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_ARGO) += argo.o
obj-y += bitmap.o
obj-y += bsearch.o
obj-$(CONFIG_CORE_PARKING) += core_parking.o
diff --git a/xen/common/argo.c b/xen/common/argo.c
new file mode 100644
index 000..ddc48f1
--- /dev/null
+++ b/xen/common/argo.c
@@ -0,0 +1,38 @@
+/**
+ * Argo : Hypervisor-Mediated data eXchange
+ *
+ * Derived from v4v, the version 2 of v2v.
+ *
+ * Copyright (c) 2010, Citrix Systems
+ * Copyright (c) 2018-2019 BAE Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+
+long
+do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
+ XEN_GUEST_HANDLE_PARAM(void) arg2, unsigned long arg3,
+ unsigned long arg4)
+{
+return -ENOSYS;
+}
+
+#ifdef CONFIG_COMPAT
+long
+compat_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
+ XEN_GUEST_HANDLE_PARAM(void) arg2, unsigned long arg3,
+ unsigned long arg4)
+{
+return -ENOSYS;
+}
+#endif
diff --git
Re: [Xen-devel] [PATCH v6 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq
On Mon, Jan 28, 2019 at 3:29 AM Jan Beulich wrote:
>
> >>> On 24.01.19 at 03:04, wrote:
> > --- a/xen/include/public/argo.h
> > +++ b/xen/include/public/argo.h
> > @@ -46,6 +46,34 @@ typedef uint32_t xen_argo_port_t;
> > /* gfn type: 64-bit on all architectures to aid avoiding a compat ABI */
> > typedef uint64_t xen_argo_gfn_t;
> >
> > +/*
> > + * XEN_ARGO_MAXIOV : maximum number of iovs accepted in a single sendv.
> > + * Caution is required if this value is increased: this determines the
> > size of
> > + * an array of xen_argo_iov_t structs on the hypervisor stack, so could
> > cause
> > + * stack overflow if the value is too large.
> > + * The Linux Argo driver never passes more than two iovs.
> > + *
> > + * This value should also not exceed 128 to ensure that the total amount
> > of data
> > + * posted in a single Argo sendv operation cannot exceed 2^31 bytes, to
> > reduce
> > + * risk of integer overflow defects:
> > + * Each argo iov can hold ~ 2^24 bytes, so XEN_ARGO_MAXIOV <= 2^(31-24),
> > + * ie. keep XEN_ARGO_MAXIOV <= 128.
> > +*/
> > +#define XEN_ARGO_MAXIOV 8U
> > +
> > +DEFINE_XEN_GUEST_HANDLE(uint8_t);
>
> There's no need for this, you can simply use ...
>
> > +typedef struct xen_argo_iov
> > +{
> > +#ifdef XEN_GUEST_HANDLE_64
>
> Note that this is defined only when __XEN__ or __XEN_TOOLS__ are
> defined, i.e. not for an "ordinary" consumer. I'm afraid that - as
> said before - you won't get around some translation as long as you
> use any form of handles.
ack.
I've retained use of the handle, so have added compat handling in v7.
>
> > +XEN_GUEST_HANDLE_64(uint8_t) iov_hnd;
>
> ... XEN_GUEST_HANDLE(uint8) here.
>
> > +#else
> > +uint64_t iov_hnd;
>
> Clearly this is not a suitable alternative for a handle.
>
> > --- a/xen/include/xlat.lst
> > +++ b/xen/include/xlat.lst
> > @@ -152,3 +152,5 @@
> > ?argo_ring argo.h
> > ?argo_register_ring argo.h
> > ?argo_unregister_ringargo.h
> > +!argo_iovargo.h
>
> I wasn't able to spot where what this line produces is actually used.
> As per above I think you will need to use it, but if in the end there's
> a different solution, then this should not be added without need.
ack, v7 uses the generated XLAT item for translation.
Christopher
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 07/15] argo: implement the register op
On Mon, Jan 28, 2019 at 3:19 AM Jan Beulich wrote: > > >>> On 24.01.19 at 03:04, wrote: > > @@ -31,13 +32,27 @@ > > #ifdef CONFIG_COMPAT > > #include > > CHECK_argo_addr; > > +CHECK_argo_register_ring; > > CHECK_argo_ring; > > #endif > > What about struct xen_argo_ring_message_header? ack - fixed > > > --- a/xen/include/xlat.lst > > +++ b/xen/include/xlat.lst > > @@ -150,3 +150,4 @@ > > ?flask_transitionxsm/flask_op.h > > ?argo_addr argo.h > > ?argo_ring argo.h > > +?argo_register_ring argo.h > > This insertion wants to move up a line (relative to the argo > ones which are already there) as well, to fit the secondary > sorting by structure name. ack Christopher ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 02/15] argo: introduce the argo_op hypercall boilerplate
On Fri, Jan 25, 2019 at 10:55 AM Christopher Clark wrote: > > On Thu, Jan 24, 2019 at 2:08 AM Julien Grall wrote: > > > > Hi, > > > > On 24/01/2019 02:04, Christopher Clark wrote: > > > Presence is gated upon CONFIG_ARGO. > > > > > > Registers the hypercall previously reserved for this. > > > Takes 5 arguments, does nothing and returns -ENOSYS. > > > > > > Will be avoiding a compat ABI by using fixed-size types in hypercall ops > > > so > > > HYPERCALL, rather than COMPAT_CALL, is the correct macro for the hypercall > > > tables. > > > > > > Even though handles will be used for (up to) two of the arguments to the > > > hypercall, there will be no need for any XLAT_* translation functions > > > because the referenced data structures have been constructed to be exactly > > > the same size and bit pattern on both 32-bit and 64-bit guests, and padded > > > to be integer multiples of 32 bits in size. This means that the same > > > copy_to_guest and copy_from_guest logic can be relied upon to perform as > > > required without any further intervention. Testing communication with 32 > > > and 64 bit guests has confirmed this works as intended. > > > > > > Signed-off-by: Christopher Clark > > > Acked-by: Jan Beulich > > > > > > v2 Copyright line: add 2019 > > > v2 feedback #3 Jan: drop "message" from argo_message_op > > > v2 feedback #3 Jan: add Acked-by > > > v1 feedback #15 Jan: handle upper-halves of hypercall args > > > v1 feedback #15 Jan: use unsigned where negative values impossible > > > --- > > > xen/arch/x86/guest/hypercall_page.S | 2 +- > > > xen/arch/x86/hvm/hypercall.c| 3 +++ > > > xen/arch/x86/hypercall.c| 3 +++ > > > xen/arch/x86/pv/hypercall.c | 3 +++ > > > > Sorry for noticing quite late in the process. Don't you need to add the > > hypercall in xen/arch/arm/traps.c? > Adding this looked fine, so I've added the ARM hypercall table entry to this patch. Christopher ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 04/15] argo: init, destroy and soft-reset, with enable command line opt
On Mon, Jan 28, 2019 at 3:16 AM Jan Beulich wrote: > > >>> On 24.01.19 at 03:04, wrote: > > --- a/xen/include/xlat.lst > > +++ b/xen/include/xlat.lst > > @@ -148,3 +148,5 @@ > > ?flask_setenforcexsm/flask_op.h > > !flask_sid_context xsm/flask_op.h > > ?flask_transitionxsm/flask_op.h > > +?argo_addr argo.h > > +?argo_ring argo.h > > The entries in this file are sorted alphabetically by header name > first, with the exception of the main xen.h which is at the top of > this file. Please move your additions up immediately past the > arch-specific ones. ack, done. thanks Christopher ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 10/15] argo: implement the notify op
On Tue, Jan 22, 2019 at 6:14 AM Roger Pau Monné wrote:
>
> On Mon, Jan 21, 2019 at 01:59:50AM -0800, Christopher Clark wrote:
> > Queries for data about space availability in registered rings and
> > causes notification to be sent when space has become available.
> >
> > The hypercall op populates a supplied data structure with information about
> > ring state and if insufficient space is currently available in a given ring,
> > the hypervisor will record the domain's expressed interest and notify it
> > when it observes that space has become available.
> >
> > Checks for free space occur when this notify op is invoked, so it may be
> > intentionally invoked with no data structure to populate
> > (ie. a NULL argument) to trigger such a check and consequent notifications.
> >
> > Limit the maximum number of notify requests in a single operation to a
> > simple fixed limit of 256.
> >
> > Signed-off-by: Christopher Clark
>
> LGTM, but I would like to see the open-coded versions of the list_
> macros fixed:
>
> Reviewed-by: Roger Pau Monné
>
> > diff --git a/xen/common/argo.c b/xen/common/argo.c
> > index 518aff7..4b43bdd 100644
> > --- a/xen/common/argo.c
> > +++ b/xen/common/argo.c
> [...]
> > +static void
> > +pending_notify(struct list_head *to_notify)
> > +{
> > +ASSERT(LOCKING_Read_L1);
> > +
> > +/* Sending signals for all ents in this list, draining until it is
> > empty. */
> > +while ( !list_empty(to_notify) )
> > +{
> > +struct pending_ent *ent =
> > +list_entry(to_notify->next, struct pending_ent, node);
>
> list_first_entry_or_null
(same as earlier message: list_first_entry_or_null is not used by Xen)
list_for_each_entry_safe
>
> > +
> > +list_del(>node);
> > +signal_domid(ent->domain_id);
> > +xfree(ent);
> > +}
> > +}
> > +
> > +static void
> > +pending_find(const struct domain *d, struct argo_ring_info *ring_info,
> > + unsigned int payload_space, struct list_head *to_notify)
> > +{
> > +struct list_head *cursor, *pending_head;
> > +
> > +ASSERT(LOCKING_Read_rings_L2(d));
> > +
> > +/*
> > + * TODO: Current policy here is to signal _all_ of the waiting domains
> > + * interested in sending a message of size less than
> > payload_space.
> > + *
> > + * This is likely to be suboptimal, since once one of them has added
> > + * their message to the ring, there may well be insufficient room
> > + * available for any of the others to transmit, meaning that they were
> > + * woken in vain, which created extra work just to requeue their wait.
> > + *
> > + * Retain this simple policy for now since it at least avoids starving
> > a
> > + * domain of available space notifications because of a policy that
> > only
> > + * notified other domains instead. Improvement may be possible;
> > + * investigation required.
> > + */
> > +spin_lock(_info->L3_lock);
> > +
> > +/* Remove matching ents from the ring list, and add them to
> > "to_notify" */
> > +pending_head = _info->pending;
> > +cursor = pending_head->next;
> > +
> > +while ( cursor != pending_head )
> > +{
> > +struct pending_ent *ent = list_entry(cursor, struct pending_ent,
> > node);
> > +
> > +cursor = cursor->next;
>
> list_for_each_entry_safe?
ack
>
> > +
> > +if ( payload_space >= ent->len )
> > +{
> > +if ( ring_info->id.partner_id == XEN_ARGO_DOMID_ANY )
> > +wildcard_pending_list_remove(ent->domain_id, ent);
> > +
> > +list_del(>node);
> > +ring_info->npending--;
> > +list_add(>node, to_notify);
> > +}
> > +}
> > +
> > +spin_unlock(_info->L3_lock);
> > +}
> > +
> > static int
> > pending_queue(const struct domain *d, struct argo_ring_info *ring_info,
> >domid_t src_id, unsigned int len)
> > @@ -1023,6 +1163,36 @@ pending_requeue(const struct domain *d, struct
> > argo_ring_info *ring_info,
> > }
> >
> > static void
> > +pending_cancel(const struct domain *d, struct argo_ring_info *ring_info,
> > + domid_t src_id)
> > +{
> > +struct list_head *cursor, *pending_head;
> > +
> > +ASSERT(LOCKING_L3(d, ring_info));
> > +
> > +/* Remove all ents where domain_id matches src_id from the ring's
> > list. */
> > +pending_head = _info->pending;
> > +cursor = pending_head->next;
> > +
> > +while ( cursor != pending_head )
> > +{
> > +struct pending_ent *ent = list_entry(cursor, struct pending_ent,
> > node);
> > +
> > +cursor = cursor->next;
>
> list_for_each_entry_safe
ack
>
> > +
> > +if ( ent->domain_id == src_id )
> > +{
> > +/* For wildcard rings, remove each from their wildcard list
> > too. */
> > +if ( ring_info->id.partner_id == XEN_ARGO_DOMID_ANY )
> > +wildcard_pending_list_remove(ent->domain_id, ent);
> > +
Re: [Xen-devel] [PATCH v5 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq
On Tue, Jan 22, 2019 at 4:08 AM Roger Pau Monné wrote:
>
> On Mon, Jan 21, 2019 at 01:59:49AM -0800, Christopher Clark wrote:
> > sendv operation is invoked to perform a synchronous send of buffers
> > contained in iovs to a remote domain's registered ring.
> >
> > It takes:
> > * A destination address (domid, port) for the ring to send to.
> >It performs a most-specific match lookup, to allow for wildcard.
> > * A source address, used to inform the destination of where to reply.
> > * The address of an array of iovs containing the data to send
> > * .. and the length of that array of iovs
> > * and a 32-bit message type, available to communicate message context
> >data (eg. kernel-to-kernel, separate from the application data).
> >
> > If insufficient space exists in the destination ring, it will return
> > -EAGAIN and Xen will notify the caller when sufficient space becomes
> > available.
> >
> > Accesses to the ring indices are appropriately atomic. The rings are
> > mapped into Xen's private address space to write as needed and the
> > mappings are retained for later use.
> >
> > Notifications are sent to guests via VIRQ and send_guest_global_virq is
> > exposed in the change to enable argo to call it. VIRQ_ARGO_MESSAGE is
>^ VIRQ_ARGO
> > claimed from the VIRQ previously reserved for this purpose (#11).
> >
> > The VIRQ notification method is used rather than sending events using
> > evtchn functions directly because:
> >
> > * no current event channel type is an exact fit for the intended
> > behaviour. ECS_IPI is closest, but it disallows migration to
> > other VCPUs which is not necessarily a requirement for Argo.
> >
> > * at the point of argo_init, allocation of an event channel is
> > complicated by none of the guest VCPUs being initialized yet
> > and the event channel logic expects that a valid event channel
> > has a present VCPU.
>
> IMO iff you wanted to use event channels those _must_ be setup by the
> guest, ie: the guest argo driver would load, allocate an event channel
> and then tell the hypervisor about the event channel that should be
> used for argo notifications.
>
> > +static int
> > +memcpy_to_guest_ring(const struct domain *d, struct argo_ring_info
> > *ring_info,
> > + unsigned int offset,
> > + const void *src, XEN_GUEST_HANDLE(uint8_t) src_hnd,
> > + unsigned int len)
> > +{
> > +unsigned int mfns_index = offset >> PAGE_SHIFT;
> > +void *dst;
> > +int ret;
> > +unsigned int src_offset = 0;
> > +
> > +ASSERT(LOCKING_L3(d, ring_info));
> > +
> > +offset &= ~PAGE_MASK;
> > +
> > +if ( len + offset > XEN_ARGO_MAX_RING_SIZE )
> > +return -EFAULT;
> > +
> > +while ( len )
> > +{
> > +unsigned int head_len = (offset + len) > PAGE_SIZE ? PAGE_SIZE -
> > offset
> > + : len;
>
> IMO that would be clearer as:
>
> head_len = min(PAGE_SIZE - offset, len);
You're right that the calculated result should be the same, but I've left
this unchanged because I think the reason for using that value (ie. intent)
is clearer in the form it has:
it's not about trying to find the smallest amount of data to write,
it's about only writing up to the PAGE_SIZE boundary, starting at offset.
>
> But anyway, this should go away when you move to using vmap.
>
> [...]
> > +static int
> > +ringbuf_insert(const struct domain *d, struct argo_ring_info *ring_info,
> > + const struct argo_ring_id *src_id,
> > + XEN_GUEST_HANDLE_PARAM(xen_argo_iov_t) iovs_hnd,
> > + unsigned long niov, uint32_t message_type,
> > + unsigned long *out_len)
> > +{
> > +xen_argo_ring_t ring;
> > +struct xen_argo_ring_message_header mh = { };
> > +int sp, ret;
> > +unsigned int len = 0;
> > +xen_argo_iov_t iovs[XEN_ARGO_MAXIOV];
> > +xen_argo_iov_t *piov;
> > +XEN_GUEST_HANDLE(uint8_t) NULL_hnd =
> > + guest_handle_from_param(guest_handle_from_ptr(NULL, uint8_t),
> > uint8_t);
> > +
> > +ASSERT(LOCKING_L3(d, ring_info));
> > +
> > +ret = __copy_from_guest(iovs, iovs_hnd, niov) ? -EFAULT : 0;
> > +if ( ret )
> > +return ret;
> > +
> > +/*
> > + * Obtain the total size of data to transmit -- sets the 'len' variable
> > + * -- and sanity check that the iovs conform to size and number limits.
> > + * Enforced below: no more than 'len' bytes of guest data
> > + * (plus the message header) will be sent in this operation.
> > + */
> > +ret = iov_count(iovs, niov, );
> > +if ( ret )
> > +return ret;
> > +
> > +/*
> > + * Size bounds check against ring size and static maximum message
> > limit.
> > + * The message must not fill the ring; there must be at least one slot
> > + * remaining so we can distinguish a full ring from an empty
Re: [Xen-devel] [PATCH v5 07/15] argo: implement the register op
On Tue, Jan 22, 2019 at 1:59 AM Roger Pau Monné wrote:
>
> On Mon, Jan 21, 2019 at 01:59:47AM -0800, Christopher Clark wrote:
> > The register op is used by a domain to register a region of memory for
> > receiving messages from either a specified other domain, or, if specifying a
> > wildcard, any domain.
> >
> > This operation creates a mapping within Xen's private address space that
> > will remain resident for the lifetime of the ring. In subsequent commits,
> > the hypervisor will use this mapping to copy data from a sending domain into
> > this registered ring, making it accessible to the domain that registered the
> > ring to receive data.
> >
> > Wildcard any-sender rings are default disabled and registration will be
> > refused with EPERM unless they have been specifically enabled with the
> > new mac-permissive flag that is added to the argo boot option here. The
> > reason why the default for wildcard rings is 'deny' is that there is
> > currently no means to protect the ring from DoS by a noisy domain
> > spamming the ring, affecting other domains ability to send to it. This
> > will be addressed with XSM policy controls in subsequent work.
> >
> > Since denying access to any-sender rings is a significant functional
> > constraint, the new option "mac-permissive" for the argo bootparam
> > enables overriding this. eg: "argo=1,mac-permissive=1"
> >
> > The p2m type of the memory supplied by the guest for the ring must be
> > p2m_ram_rw and the memory will be pinned as PGT_writable_page while the ring
> > is registered.
> >
> > xen_argo_gfn_t type is defined and is 64-bit on all architectures which
> > assists with avoiding the need for compat code to translate hypercall args.
> > This hypercall op and its interface currently only supports 4K-sized pages.
> >
> > Signed-off-by: Christopher Clark
>
> Reviewed-by: Roger Pau Mooné
>
> Just some nits that can be taken care of later.
>
> > +static int
> > +find_ring_mfns(struct domain *d, struct argo_ring_info *ring_info,
> > + const unsigned int npage,
> > + XEN_GUEST_HANDLE_PARAM(xen_argo_gfn_t) gfn_hnd,
> > + const unsigned int len)
> > +{
> > +unsigned int i;
> > +int ret = 0;
> > +mfn_t *mfns;
> > +void **mfn_mapping;
> > +
> > +ASSERT(LOCKING_Write_rings_L2(d));
> > +
> > +if ( ring_info->mfns )
> > +{
> > +/* Ring already existed: drop the previous mapping. */
> > +gprintk(XENLOG_INFO, "argo: vm%u re-register existing ring "
> > +"(vm%u:%x vm%u) clears mapping\n",
> > +d->domain_id, ring_info->id.domain_id,
> > +ring_info->id.aport, ring_info->id.partner_id);
> > +
> > +ring_remove_mfns(d, ring_info);
> > +ASSERT(!ring_info->mfns);
> > +}
> > +
> > +mfns = xmalloc_array(mfn_t, npage);
> > +if ( !mfns )
> > +return -ENOMEM;
> > +
> > +for ( i = 0; i < npage; i++ )
> > +mfns[i] = INVALID_MFN;
> > +
> > +mfn_mapping = xzalloc_array(void *, npage);
> > +if ( !mfn_mapping )
> > +{
> > +xfree(mfns);
> > +return -ENOMEM;
> > +}
> > +
> > +ring_info->mfns = mfns;
> > +ring_info->mfn_mapping = mfn_mapping;
> > +
> > +for ( i = 0; i < npage; i++ )
> > +{
> > +xen_argo_gfn_t argo_gfn;
> > +mfn_t mfn;
> > +
> > +ret = __copy_from_guest_offset(_gfn, gfn_hnd, i, 1) ? -EFAULT
> > : 0;
> > +if ( ret )
> > +break;
> > +
> > +ret = find_ring_mfn(d, _gfn(argo_gfn), );
> > +if ( ret )
> > +{
> > +gprintk(XENLOG_ERR, "argo: vm%u: invalid gfn %"PRI_gfn" "
> > +"r:(vm%u:%x vm%u) %p %u/%u\n",
> > +d->domain_id, gfn_x(_gfn(argo_gfn)),
> > +ring_info->id.domain_id, ring_info->id.aport,
> > +ring_info->id.partner_id, ring_info, i, npage);
> > +break;
> > +}
> > +
> > +ring_info->mfns[i] = mfn;
> > +
> > +argo_dprintk("%u: %"PRI_gfn" -> %"PRI_mfn"\n",
> > + i, gfn_x(_gfn(argo_gfn)), mfn_x(ring_info->mfns[i]));
> > +}
> > +
> > +ring_info->nmfns = i;
> > +
> > +if ( ret )
> > +ring_remove_mfns(d, ring_info);
> > +else
> > +{
> > +ASSERT(ring_info->nmfns == NPAGES_RING(len));
> > +
> > +gprintk(XENLOG_DEBUG, "argo: vm%u ring (vm%u:%x vm%u) %p "
>
> Nit: this likely wants to be an argo_dprintk?
There are not many instances in the Argo code where gprintk(XENLOG_DEBUG
is used, but it's intentional here, because argo_dprintk needs a
recompile to enable it, whereas gprintk does not.
Ring registration is non-datapath and the message is potentially useful
when diagnosing a deployed system.
>
> > +"mfn_mapping %p len %u nmfns %u\n",
> > +d->domain_id, ring_info->id.domain_id,
> > +ring_info->id.aport, ring_info->id.partner_id, ring_info,
> > +
Re: [Xen-devel] [PATCH v5 04/15] argo: init, destroy and soft-reset, with enable command line opt
On Mon, Jan 21, 2019 at 9:55 AM Roger Pau Monné wrote:
>
> On Mon, Jan 21, 2019 at 01:59:44AM -0800, Christopher Clark wrote:
> > Initialises basic data structures and performs teardown of argo state
> > for domain shutdown.
> >
> > Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
> >
> > Introduces a new Xen command line parameter 'argo': bool to enable/disable
> > the argo hypercall. Defaults to disabled.
> >
> > New headers:
> > public/argo.h: with definions of addresses and ring structure, including
> > indexes for atomic update for communication between domain and hypervisor.
> >
> > xen/argo.h: to expose the hooks for integration into domain lifecycle:
> > argo_init: per-domain init of argo data structures for domain_create.
> > argo_destroy: teardown for domain_destroy and the error exit
> > path of domain_create.
> > argo_soft_reset: reset of domain state for domain_soft_reset.
> >
> > Adds a new field to struct domain: struct argo_domain *argo;
> >
> > In accordance with recent work on _domain_destroy, argo_destroy is
> > idempotent. It will tear down: all rings registered by this domain, all
> > rings where this domain is the single sender (ie. specified partner,
> > non-wildcard rings), and all pending notifications where this domain is
> > awaiting signal about available space in the rings of other domains.
> >
> > A count will be maintained of the number of rings that a domain has
> > registered in order to limit it below the fixed maximum limit defined here.
> >
> > Macros are defined to verify the internal locking state within the argo
> > implementation. The macros are ASSERTed on entry to functions to validate
> > and document the required lock state prior to calling.
> >
> > The hash function for the hashtables that hold ring state is derived from
> > the string hashing function djb2 (http://www.cse.yorku.ca/~oz/hash.html)
> > by Daniel J. Bernstein. Basic testing with a limited number of domains and
> > ports has shown reasonable distribution for the table size.
> >
> > The software license on the public header is the BSD license, standard
> > procedure for the public Xen headers. The public header was originally
> > posted under a GPL license at: [1]:
> > https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02710.html
> >
> > The following ACK by Lars Kurth is to confirm that only people being
> > employees of Citrix contributed to the header files in the series posted at
> > [1] and that thus the copyright of the files in question is fully owned by
> > Citrix. The ACK also confirms that Citrix is happy for the header files to
> > be published under a BSD license in this series (which is based on [1]).
> >
> > Signed-off-by: Christopher Clark
> > Acked-by: Lars Kurth
> > Reviewed-by: Ross Philipson
>
> Thanks.
>
> Reviewed-by: Roger Pau Monné
>
> I've got some nits below, but it's purely cosmetic changes to make the
> code cleaner.
>
> > ---
> >
> > diff --git a/docs/misc/xen-command-line.pandoc
> > b/docs/misc/xen-command-line.pandoc
> > index d39bcee..93f41bc 100644
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -182,6 +182,21 @@ Permit Xen to use "Always Running APIC Timer" support
> > on compatible hardware
> > in combination with cpuidle. This option is only expected to be useful for
> > developers wishing Xen to fall back to older timing methods on newer
> > hardware.
> >
> > +### argo
> > += List of [ ]
> > +
> > +Controls for the Argo hypervisor-mediated interdomain communication
> > service.
> > +
> > +The functionality that this option controls is only available when Xen has
> > been
> > +compiled with the build setting for Argo enabled in the build
> > configuration.
> > +
> > +Argo is a interdomain communication mechanism, where Xen acts as the
> > central
> > +point of authority. Guests may register memory rings to recieve messages,
> > +query the status of other domains, and send messages by hypercall, all
> > subject
> > +to appropriate auditing by Xen.
> > +
> > +* An overall boolean acts as a global control. Argo is disabled by
> > default.
>
> I'm not sure it's worth adding a list item for the boolean, I would
> just add the "Argo is disabled by default" to the first paragraph.
ack, thanks, done.
>
> [...]
> > +static struct argo_ring_info *
> > +find_ring_info(const struct domain *d, const struct argo_ring_id *id)
> > +{
> > +struct list_head *cursor, *bucket;
> > +
> > +ASSERT(LOCKING_Read_rings_L2(d));
> > +
> > +/* List is not modified here. Search and return the match if found. */
> > +bucket = >argo->ring_hash[hash_index(id)];
> > +
> > +for ( cursor = bucket->next; cursor != bucket; cursor = cursor->next )
>
> Why are you open-coding list_for_each here?
see response to cover letter
> You might also consider using list_for_each_entry, so that you can
> avoid the list_entry call below.
Ack, have done
Re: [Xen-devel] [PATCH v5 00/15] Argo: hypervisor-mediated interdomain communication
On Tue, Jan 22, 2019 at 6:19 AM Roger Pau Monné wrote: > > On Mon, Jan 21, 2019 at 01:59:40AM -0800, Christopher Clark wrote: > > Version five of this patch series: > > > > * Changes are primarily addressing feedback from the v4 series reviews. > > Many points noted on the invididual commit posts. > > > > * Critical sections have been shrunk, with allocations and frees > > pulled outside where possible, reordering logic within hypercall ops. > > > > * A new ring hash function implemented, derived from the djb2 string > > hash function. > > > > * Flags returned by the notify op have been simplified. > > > > * Now uses a single argo boot parameter, taking a list: > > - top level boolean to enable/disable Argo > > - mac-permissive option to enable/disable wildcard rings > > - command line doc edit: no "CONFIG_ARGO" but refers to build config > > > > * Switched to use the standard list data structures used by Xen's > > common code. > > AFAIK this was not requested by any reviewer, so I wonder why you made > such change. The more that you open coded some of the list_ macros > instead of just doing a s/hlist_/list_/ replacement. > I'm fine with using list instead of hlist, At your request, v7 replaces open coding with Xen's list macros. The hlist macros were not used by any of the common code in Xen. > but I don't understand why > you decided to open code list_for_each and list_for_each_safe instead > of using the macros provided by Xen. Is there an issue with such > macros? As discussed offline: - Using Xen's list macros will expedite Argo's merge for Xen 4.12 - List macros in Xen list.h originated in Linux list.h and have diverged - OpenXT has use cases for measured launch and nested virtualization, which influence downstream performance and security requirements for Argo and Xen - OpenXT can temporarily patch Xen 4.12 for downstream use > I've made a couple of minor comments, but I think the current status > is good, and fixing those minor comments is going to be trivial. Ack, thanks. Hopefully v7 looks good. Christopher ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing test] 132588: regressions - FAIL
flight 132588 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/132588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130860 test-xtf-amd64-amd64-3 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130860 test-xtf-amd64-amd64-2 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130860 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 130860 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-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-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail 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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop 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-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen df1debf494ac38c95abb602b2b3057613de06b47 baseline version: xen 96cbd0893f783997caaf117e897d5fa8f2dc7b5f Last test of basis 130860 2018-11-29 14:06:50 Z 62 days Failing since132486 2019-01-26 01:36:53 Z5 days2 attempts Testing same since 132588 2019-01-29 20:27:18 Z1 days1 attempts People who touched revisions under test: Julien Grall Marc Zyngier Shameer Kolothum Stefano Stabellini Stefano Stabellini jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64
[Xen-devel] [PATCHv2 9/9] xen/privcmd-buf.c: Convert to use vm_insert_range_buggy
Convert to use vm_insert_range_buggy() to map range of kernel
memory to user vma.
This driver has ignored vm_pgoff. We could later "fix" these drivers
to behave according to the normal vm_pgoff offsetting simply by
removing the _buggy suffix on the function name and if that causes
regressions, it gives us an easy way to revert.
Signed-off-by: Souptick Joarder
Reviewed-by: Boris Ostrovsky
---
drivers/xen/privcmd-buf.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/xen/privcmd-buf.c b/drivers/xen/privcmd-buf.c
index de01a6d..a9d7e97 100644
--- a/drivers/xen/privcmd-buf.c
+++ b/drivers/xen/privcmd-buf.c
@@ -166,12 +166,8 @@ static int privcmd_buf_mmap(struct file *file, struct
vm_area_struct *vma)
if (vma_priv->n_pages != count)
ret = -ENOMEM;
else
- for (i = 0; i < vma_priv->n_pages; i++) {
- ret = vm_insert_page(vma, vma->vm_start + i * PAGE_SIZE,
-vma_priv->pages[i]);
- if (ret)
- break;
- }
+ ret = vm_insert_range_buggy(vma, vma_priv->pages,
+ vma_priv->n_pages);
if (ret)
privcmd_buf_vmapriv_free(vma_priv);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCHv2 8/9] xen/gntdev.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
map->count is passed to vm_insert_range and internal API
verify map->count against count ( count = vma_pages(vma))
for page array boundary overrun. With this count is not
needed inside gntdev_mmap() and it could be replaced with
vma_pages(vma).
Signed-off-by: Souptick Joarder
Reviewed-by: Boris Ostrovsky
---
drivers/xen/gntdev.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 5efc5ee..a930309 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1082,18 +1082,17 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
{
struct gntdev_priv *priv = flip->private_data;
int index = vma->vm_pgoff;
- int count = vma_pages(vma);
struct gntdev_grant_map *map;
- int i, err = -EINVAL;
+ int err = -EINVAL;
if ((vma->vm_flags & VM_WRITE) && !(vma->vm_flags & VM_SHARED))
return -EINVAL;
pr_debug("map %d+%d at %lx (pgoff %lx)\n",
- index, count, vma->vm_start, vma->vm_pgoff);
+ index, vma_pages(vma), vma->vm_start, vma->vm_pgoff);
mutex_lock(>lock);
- map = gntdev_find_map_index(priv, index, count);
+ map = gntdev_find_map_index(priv, index, vma_pages(vma));
if (!map)
goto unlock_out;
if (use_ptemod && map->vma)
@@ -1145,12 +1144,9 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
goto out_put_map;
if (!use_ptemod) {
- for (i = 0; i < count; i++) {
- err = vm_insert_page(vma, vma->vm_start + i*PAGE_SIZE,
- map->pages[i]);
- if (err)
- goto out_put_map;
- }
+ err = vm_insert_range(vma, map->pages, map->count);
+ if (err)
+ goto out_put_map;
} else {
#ifdef CONFIG_X86
/*
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCHv2 5/9] drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 28bc501..b72cf11 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -224,8 +224,7 @@ struct drm_gem_object *
static int gem_mmap_obj(struct xen_gem_object *xen_obj,
struct vm_area_struct *vma)
{
- unsigned long addr = vma->vm_start;
- int i;
+ int ret;
/*
* clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
@@ -246,18 +245,11 @@ static int gem_mmap_obj(struct xen_gem_object *xen_obj,
* FIXME: as we insert all the pages now then no .fault handler must
* be called, so don't provide one
*/
- for (i = 0; i < xen_obj->num_pages; i++) {
- int ret;
-
- ret = vm_insert_page(vma, addr, xen_obj->pages[i]);
- if (ret < 0) {
- DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
- return ret;
- }
+ ret = vm_insert_range(vma, xen_obj->pages, xen_obj->num_pages);
+ if (ret < 0)
+ DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
- addr += PAGE_SIZE;
- }
- return 0;
+ return ret;
}
int xen_drm_front_gem_mmap(struct file *filp, struct vm_area_struct *vma)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_insert_range() is the API which could be used to mapped
kernel memory/pages in drivers which has considered vm_pgoff
vm_insert_range_buggy() is the API which could be used to map
range of kernel memory/pages in drivers which has not considered
vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
We _could_ then at a later "fix" these drivers which are using
vm_insert_range_buggy() to behave according to the normal vm_pgoff
offsetting simply by removing the _buggy suffix on the function
name and if that causes regressions, it gives us an easy way to revert.
Signed-off-by: Souptick Joarder
Suggested-by: Russell King
Suggested-by: Matthew Wilcox
---
include/linux/mm.h | 4 +++
mm/memory.c| 81 ++
mm/nommu.c | 14 ++
3 files changed, 99 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 80bb640..25752b0 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2565,6 +2565,10 @@ unsigned long change_prot_numa(struct vm_area_struct
*vma,
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
+int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num);
+int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num);
vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn);
vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index e11ca9d..0a4bf57 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1520,6 +1520,87 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned
long addr,
}
EXPORT_SYMBOL(vm_insert_page);
+/**
+ * __vm_insert_range - insert range of kernel pages into user vma
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ * @offset: user's requested vm_pgoff
+ *
+ * This allows drivers to insert range of kernel pages they've allocated
+ * into a user vma.
+ *
+ * If we fail to insert any page into the vma, the function will return
+ * immediately leaving any previously inserted pages present. Callers
+ * from the mmap handler may immediately return the error as their caller
+ * will destroy the vma, removing any successfully inserted pages. Other
+ * callers should make their own arrangements for calling unmap_region().
+ *
+ * Context: Process context.
+ * Return: 0 on success and error code otherwise.
+ */
+static int __vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num, unsigned long offset)
+{
+ unsigned long count = vma_pages(vma);
+ unsigned long uaddr = vma->vm_start;
+ int ret, i;
+
+ /* Fail if the user requested offset is beyond the end of the object */
+ if (offset > num)
+ return -ENXIO;
+
+ /* Fail if the user requested size exceeds available object size */
+ if (count > num - offset)
+ return -ENXIO;
+
+ for (i = 0; i < count; i++) {
+ ret = vm_insert_page(vma, uaddr, pages[offset + i]);
+ if (ret < 0)
+ return ret;
+ uaddr += PAGE_SIZE;
+ }
+
+ return 0;
+}
+
+/**
+ * vm_insert_range - insert range of kernel pages starts with non zero offset
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ *
+ * Maps an object consisting of `num' `pages', catering for the user's
+ * requested vm_pgoff
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise.
+ */
+int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num)
+{
+ return __vm_insert_range(vma, pages, num, vma->vm_pgoff);
+}
+EXPORT_SYMBOL(vm_insert_range);
+
+/**
+ * vm_insert_range_buggy - insert range of kernel pages starts with zero offset
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ *
+ * Maps a set of pages, always starting at page[0]
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise.
+ */
+int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num)
[Xen-devel] [PATCHv2 0/9] Use vm_insert_range and vm_insert_range_buggy
Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_insert_range() is the API which could be used to mapped kernel memory/pages in drivers which has considered vm_pgoff vm_insert_range_buggy() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_insert_range_buggy() to behave according to the normal vm_pgoff offsetting simply by removing the _buggy suffix on the function name and if that causes regressions, it gives us an easy way to revert. v1 -> v2: Few Reviewed-by. Updated the change log in [8/9] In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer, not as a in-buffer offset by design and it always want to mmap a whole buffer from its beginning. Added additional changes after discussing with Marek and vm_insert_range could be used instead of vm_insert_range_buggy. Souptick Joarder (9): mm: Introduce new vm_insert_range and vm_insert_range_buggy API arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range drivers/firewire/core-iso.c: Convert to use vm_insert_range_buggy drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range iommu/dma-iommu.c: Convert to use vm_insert_range videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range xen/gntdev.c: Convert to use vm_insert_range xen/privcmd-buf.c: Convert to use vm_insert_range_buggy arch/arm/mm/dma-mapping.c | 22 ++ drivers/firewire/core-iso.c| 15 +--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 17 + drivers/gpu/drm/xen/xen_drm_front_gem.c| 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-core.c| 7 ++ .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++ drivers/xen/gntdev.c | 16 ++--- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h | 4 ++ mm/memory.c| 81 ++ mm/nommu.c | 14 13 files changed, 136 insertions(+), 106 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 132578: regressions - FAIL
flight 132578 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/132578/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 129313 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 129313 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 129313 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 129313 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 129313 test-amd64-i386-examine 8 reboot fail REGR. vs. 129313 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 129313 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 129313 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 129313 test-amd64-i386-xl7 xen-boot fail REGR. vs. 129313 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 129313 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 129313 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 129313 test-amd64-amd64-examine 8 reboot fail REGR. vs. 129313 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 129313 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 129313 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 129313 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-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-check
[Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-xl-xsm
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-xsm testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git 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: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Bug introduced: 9b5eed105a45ac0557af113b4096132ae7e3e47f Bug not present: ac35b66883e8330ffde609152e13c225b12de6a4 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132637/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-amd64-xl-xsm.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-amd64-xl-xsm.xen-boot --summary-out=tmp/132637.bisection-summary --basis-template=128858 --blessings=real,real-bisect linux-3.18 test-amd64-amd64-xl-xsm xen-boot Searching for failure / basis pass: 132456 fail [host=debina1] / 128858 [host=elbling1] 128841 [host=huxelrebe0] 128807 [host=baroque1] 128691 [host=godello1] 128258 [host=elbling0] 128232 [host=godello0] 128177 [host=albana1] 128096 [host=baroque1] 127486 [host=godello1] 127472 [host=albana1] 127455 [host=rimava1] 127296 [host=pinot0] 127001 [host=chardonnay1] 126926 [host=chardonnay1] 126813 [host=chardonnay1] 126711 [host=chardonnay1] 126583 [host=chardonnay1] 126472 [host=chardonnay1] 126362 [host=chardonnay1] 126270 [host=ch\ ardonnay1] 126189 [host=chardonnay1] 126042 [host=pinot0] 125899 [host=joubertin1] 125658 [host=baroque1] 125649 [host=albana1] 125641 [host=rimava1] 125525 [host=rimava0] 125505 [host=rimava0] 125138 ok. Failure / basis pass flights: 132456 / 125138 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 9b5eed105a45ac0557af113b4096132ae7e3e47f c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 de5b678ca4dcdfa83e322491d478d66df56c1986 08b908ba63dee8bc313983c5e412852cbcbcda85 Basis pass ac35b66883e8330ffde609152e13c225b12de6a4 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a b4ac4bc410222d221dc46a74ac71efaa7b32d57c Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#ac35b66883e8330ffde609152e13c225b12de6a4-9b5eed105a45ac0557af113b4096132ae7e3e47f git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git\ #43139135a8938de44f66333831d3a8655d07663a-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#b4ac4bc410222d221dc46a74ac71efaa7b32d57c-08b908ba63dee8bc313983c5e412852cbcbcda85 adhoc-revtuple-generator: tree discontiguous: linux-stable adhoc-revtuple-generator: tree discontiguous: qemu-xen adhoc-revtuple-generator: tree discontiguous: xen Loaded 1007 nodes in revision graph Searching for test results: 113503 [host=merlot1] 113856 [host=italia0] 113869 [host=elbling0] 114034 [host=godello1] 114133 [host=godello0] 114180 [host=pinot1] 114225 [host=merlot1] 114446 [host=nocera0] 114677 [host=fiano1] 114843 [host=huxelrebe0] 115289 [host=chardonnay1] 115479 [host=italia0] 115495 [host=pinot1] 115688 [host=elbling0] 115673 [host=godello0] 115698 [host=baroque0] 115714 [host=baroque1] 115729 [host=nobling0] 116106 [host=rimava0] 116121 [host=huxelrebe0] 116140 [host=chardonnay1] 116193 [host=godello1] 116308 [host=chardonnay0] 116475 [host=merlot1] 116501 [host=godello0] 116728 [host=baroque0] 116760 [host=fiano0] 116862 [host=baroque1] 116890 [host=chardonnay1] 116920 [host=nobling0] 117131 [host=huxelrebe0] 117211 [host=baroque0] 117375 [host=godello1] 117641 [host=pinot1] 117702 [host=huxelrebe1] 118149 [host=chardonnay1] 118186 [host=fiano0] 118488 [host=pinot0] 118666 [host=baroque1] 118730 [host=godello1] 119432 [host=italia0] 120010 [host=pinot0] 120043 [host=godello1] 120090 [host=fiano1] 120132 [host=godello0] 120235 [host=huxelrebe0] 120276 [host=baroque1] 120486 [host=pinot1] 120665
[Xen-devel] Xen Project Developer and Design Summit 2019: Cfp and Registration Open Now
Dear Community Members, starting today, registration officially opens for The Xen Project Developer & Design Summit. This year’s Summit, taking place from July 9 through 11 in Chicago, will bring together the Xen Project community of developers and power users to share ideas, latest developments, and experiences, as well as offer opportunities to plan and collaborate on all things Xen Project. You can find more information at https://events.linuxfoundation.org/events/xensummit-2019/ If you’d like to present at the Summit and have a topic that you’d like to submit, the Call For Proposals is open now and will close April 12, 2019. Last but not least, we have many opportunities to support the Summit via sponsorships. For information regarding registration, speaking opportunities and sponsorships, head over the event website and learn more! Best Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: correct dependencies of post-SSE ISA extensions
On 14/01/2019 12:48, Jan Beulich wrote:
On 14.01.19 at 13:00, wrote:
>> On 14/01/2019 11:39, Jan Beulich wrote:
>>> First of all a PCLMULQDQ dependency was missing entirely. Add it as well
>>> as AESNI and SHA to SSE2, as all of them act on vectors of integers,
>>> whereas plain SSE supports vectors of single precision floats only. This
>>> is in line with how e.g. binutils and gcc treat them.
>>>
>>> Signed-off-by: Jan Beulich
>>> ---
>>> TBD: On the same basis, SSE3, SSSE3 and SSE4A should probably also
>>> depend on SSE2 rather than SSE. In fact making this a chain SSE -> SSE2
>>> -> SSE3 -> { SSSE3, SSE4A } would probably be best, and get us in line
>>> with both binutils and gcc. But I think I did suggest so when the
>>> dependencies were introduced, and this wasn't liked for a reason I
>>> forgot.
>> While all of this is true, there is a comment in context which explains
>> why the dependences are they way they are.
>>
>> Providing a guest with SSE, no SSE2, and PCLMULDQ/AESNI/SHA will allow
>> these latter instruction groups to function correctly.
> You mean "Several futher instruction sets are built on core %XMM
> support, without specific inter-dependencies"? This explains it at
> best partly, the more that there then are exceptions to this rule
> ({,S}SSE3 -> SSE4.1 and SSE4.1 -> SSE4.2). Do we really have to
> take a different view here than binutils and gcc (and perhaps many
> others) do?
>
> Some of Linux'es x86-specific crypto drivers make even more
> interesting implications, several of which I mean to fix. But they
> (imo) validly imply e.g. SSE2 when there is SSSE3, which would
> mean such a driver would only work because we can't hide the
> SSE2 insns when a guest config file masks off SSE2 but not
> SSSE3 - until such an insn hits the emulator, where the
> vcpu_has_sse2() check would make it raise #UD, just because
> of our non-standard feature dependencies.
The dependences described here are primarily to prevent malfunctions in
Xen, rather than to provide a historically-accurate view of which
features appeared when. Software which doesn't follow the rules cannot
be helped - its already buggy.
The question which matters here is whether the Intel/AMD SDM's allow for
any such implications.
Vol1 12.13.4 states that software wishing to use AES-NI or PCMULDQ must
first check for SSE2, and then for the individual feature bit. I
suppose this is better evidence of a logical connection than we've used
in other bits of the dependency tree, but I see absolutely nothing
discussing the SHA instruction set.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 132633: tolerable all pass - PUSHED
flight 132633 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/132633/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 68cda62e50c34f938747c1558117ee2c37134b30 baseline version: xen f15ff4d50011d6860e0e577b147b9f8b6670661d Last test of basis 132627 2019-01-30 15:00:29 Z0 days Testing same since 132633 2019-01-30 18:00:48 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f15ff4d500..68cda62e50 68cda62e50c34f938747c1558117ee2c37134b30 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 14/14] xen/gnttab: Minor improvements to arch header files
On 30/01/2019 20:04, Julien Grall wrote: > Hi Andrew, > > On 11/22/18 5:56 PM, Andrew Cooper wrote: >> On 21/11/2018 13:21, Andrew Cooper wrote: >>> * Use XFREE() when appropriate >>> * Drop stale comments and unnecessary brackets >>> * Fold asm constraints >>> >>> No functional change. >>> >>> Signed-off-by: Andrew Cooper >>> --- >>> CC: Jan Beulich >>> CC: Wei Liu >>> CC: Roger Pau Monné >>> --- >>> xen/include/asm-arm/grant_table.h | 6 ++ >>> xen/include/asm-x86/grant_table.h | 10 +++--- >> >> CC'ing ARM maintainers. I'm sorry for missing you out originally - I >> folded two separate patches and forgot to adjust the CC list. > > Sorry it fell through the cracks. > > Acked-by: Julien Grall No problem. Thanks. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 14/14] xen/gnttab: Minor improvements to arch header files
Hi Andrew, On 11/22/18 5:56 PM, Andrew Cooper wrote: On 21/11/2018 13:21, Andrew Cooper wrote: * Use XFREE() when appropriate * Drop stale comments and unnecessary brackets * Fold asm constraints No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/include/asm-arm/grant_table.h | 6 ++ xen/include/asm-x86/grant_table.h | 10 +++--- CC'ing ARM maintainers. I'm sorry for missing you out originally - I folded two separate patches and forgot to adjust the CC list. Sorry it fell through the cracks. Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86emul: correct AVX512BW write masking checks
On 14/01/2019 11:40, Jan Beulich wrote:
> For VPSADBW this likely was a result of bad copy-and-paste.
>
> For VPS{L,R}LDQ comment and code were not in line, but then again the
> comment also wasn't fully updated from the AVX2 original it got cloned
> from.
>
> Signed-off-by: Jan Beulich
I'm guessing that these are covered by the first row of table 2-40, and
the absense of {k1} in the instruction specifications?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.10.1 Xen crash and reboot
Hi, On Tue, Jan 01, 2019 at 07:46:57PM +, Andy Smith wrote: > The test host is slightly different hardware to the others: Xeon > E5-1680v4 on there as opposed to Xeon D-1540 previously. > > Test host is now running with pcid=0 to see if that helps. The > longest this guest has been able to run so far without crashing the > host is 14 days. Just to note, it has so far been 28 days and this host using pcid=0 on the command line has not crashed again yet. I still have no way to reproduce the problem on demand but if anyone wants me me to do any further debugging with pcid=1 I can do that. Thanks, Andy ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.12] xen/cmdline: Work around some specific command line warnings
On Wed, Jan 30, 2019 at 05:16:47PM +, Andrew Cooper wrote:
> On 30/01/2019 17:07, Andrew Cooper wrote:
> > On 30/01/2019 16:31, Juergen Gross wrote:
> >> On 30/01/2019 16:55, Andrew Cooper wrote:
> >>> Xen will warn when an unknown parameter is found in the command line.
> >>> e.g.
> >>>
> >>> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
> >>>
> >>> One case where this goes wrong is a workaround for an old grub bug, which
> >>> resulted in "placeholder" being prepended to the command line.
> >>>
> >>> Another case is when booting a CONFIG_PV_SHIM_EXCLUSIVE build, in which
> >>> the
> >>> parsing for the "pv-shim" parameter is discarded.
> >>>
> >>> Introduce ignore_param() and OPT_IGNORE to cope with known cases, where
> >>> warning the user is the wrong course of action to take.
> >>>
> >>> Signed-off-by: Andrew Cooper
> >>> ---
> >>> CC: Jan Beulich
> >>> CC: Wei Liu
> >>> CC: Roger Pau Monné
> >>> CC: Juergen Gross
> >>>
> >>> v2:
> >>> * Rewrite from scratch, following Juergen's suggestion
> >>>
> >>> An implementation detail of ignore_param() is that it can only be used
> >>> once
> >>> per translation unit, which is fine for now. Two options to fix this are
> >>> to
> >>> tokenise __LINE__ in (requires some extreme preprocessor magic to make
> >>> work,
> >>> as ## inhibits expansion, and may cause livepatching issues), or to
> >>> retain the
> >>> _val parameter and require callers to just pass in a unique string.
> >> Or make the unique string an optional parameter via:
> >>
> >> #define ignore_param(_name, uniq...)\
> >> __setup_str __setup_str_ign ## uniq[] = _name; \
> >> __kparam __setup_ign ## uniq = \
> >> { .name = __setup_str_ign ## uniq, \
> >> .type = OPT_IGNORE }
> >>
> >> With or without that change:
> >>
> >> Reviewed-by: Juergen Gross
> >> Release-acked-by: Juergen Gross
> > Actually I like this as an option.
>
> Sadly, it doesn't work, as you end up with:
>
> __setup_str setup_str_ign_ ## [] = "pv-shim";
>
> and ## is a binary operator.
>
> I'll leave it as-was and we can figure this out in the future if necessary.
Sigh. This means you can't have two ignore_param in the same CU.
I was trying to use this for "flask" and "silo" and (re)discovered this
issue in the hard way.
Wei.
>
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Pings for 4.12 [PATCH 00/14] XSA-277 followup
On 21/11/2018 13:21, Andrew Cooper wrote:
> This covers various fixes related to XSA-277 which weren't in security
> supported areas, and associated cleanup.
>
> The biggest issue noticed here is that altp2m's use of hardware #VE support
> will cause general memory corruption if the guest ever balloons out the VEINFO
> page. The only safe way I think of doing this is for Xen to alloc annonymous
> domheap pages for the VEINFO, and for the guest to map them in a similar way
> to the shared info and grant table frames.
>
> Andrew Cooper (14):
> x86/soft-reset: Drop gfn reference after calling get_gfn_query()
> x86/mem-sharing: Don't leave the altp2m lock held when nominating a page
> AMD/IOMMU: Fix multiple reference counting errors
> x86/p2m: Fix locking in p2m_altp2m_lazy_copy()
> x86/p2m: Don't overwrite p2m_altp2m_lazy_copy()'s callers p2m pointer
> x86/hvm: Make the altp2m locking easier to follow
> x86/p2m: Coding style cleanup
> xen/memory: Drop ARM put_gfn() stub
> x86/p2m: Switch the two_gfns infrastructure to using gfn_t
> x86/mm: Switch {get,put}_gfn() infrastructure to using gfn_t
> xen/mm: Switch mfn_to_virt()/virt_to_mfn() to using mfn_t
> xen/gnttab: Drop gnttab_create_{shared,status}_page()
> xen/gnttab: Simplify gnttab_map_frame()
> xen/gnttab: Minor improvements to arch header files
A number of these patches are still pending maintainer review.
The p2m patches all need George as the MM maintainer. The AMD/IOMMU
patch is all unreachable code, but needs AMD input. The final patch
needs ARM input.
Given that these are mostly reviewed and non-controversial, it would be
nice to get them into 4.12, so I guess at this point I could also do
with a release ack.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 132627: tolerable all pass - PUSHED
flight 132627 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/132627/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen f15ff4d50011d6860e0e577b147b9f8b6670661d baseline version: xen 863549158129d326b2e5850f722bfda643264f2b Last test of basis 132618 2019-01-30 11:00:46 Z0 days Testing same since 132627 2019-01-30 15:00:29 Z0 days1 attempts People who touched revisions under test: Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 8635491581..f15ff4d500 f15ff4d50011d6860e0e577b147b9f8b6670661d -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.12] xen/cmdline: Work around some specific command line warnings
On 30/01/2019 16:38, Jan Beulich wrote:
On 30.01.19 at 16:55, wrote:
>> Xen will warn when an unknown parameter is found in the command line. e.g.
>>
>> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>>
>> One case where this goes wrong is a workaround for an old grub bug, which
>> resulted in "placeholder" being prepended to the command line.
>>
>> Another case is when booting a CONFIG_PV_SHIM_EXCLUSIVE build, in which the
>> parsing for the "pv-shim" parameter is discarded.
>>
>> Introduce ignore_param() and OPT_IGNORE to cope with known cases, where
>> warning the user is the wrong course of action to take.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
>> An implementation detail of ignore_param() is that it can only be used once
>> per translation unit, which is fine for now. Two options to fix this are to
>> tokenise __LINE__ in (requires some extreme preprocessor magic to make work,
>> as ## inhibits expansion, and may cause livepatching issues), or to retain
>> the
>> _val parameter and require callers to just pass in a unique string.
> How about requiring the quotes to be omitted from the argument
> passed to the macro and using that string to paste onto the
> variable names? This would require following an earlier suggestion
> of mine in that we (a) treat '-' and '_' equally when parsing
> command line options (cmdline_strcmp()) and (b) the main parser
> to use that function. But as you say, nothing that needs solving
> right away.
>
>> @@ -136,6 +137,11 @@ extern const struct kernel_param __param_start[],
>> __param_end[];
>>.type = OPT_STR, \
>>.len = sizeof(_var), \
>>.par.var = &_var }
>> +#define ignore_param(_name) \
>> +__setup_str __setup_str_ign[] = _name; \
>> +__kparam __setup_ign = \
>> +{ .name = __setup_str_ign, \
>> + .type = OPT_IGNORE }
> I don't suppose that I could talk you into dropping the leading
> underscore from the macro parameter name,
No. That results in a failure to compile because of ".name" when
initialising the structure.
I've left it as is for consistency with the other macros.
> and into
> reducing the double leading underscores of the variables to
> single ones?
Done.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.12] xen/cmdline: Work around some specific command line warnings
On 30/01/2019 17:07, Andrew Cooper wrote:
> On 30/01/2019 16:31, Juergen Gross wrote:
>> On 30/01/2019 16:55, Andrew Cooper wrote:
>>> Xen will warn when an unknown parameter is found in the command line. e.g.
>>>
>>> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>>>
>>> One case where this goes wrong is a workaround for an old grub bug, which
>>> resulted in "placeholder" being prepended to the command line.
>>>
>>> Another case is when booting a CONFIG_PV_SHIM_EXCLUSIVE build, in which the
>>> parsing for the "pv-shim" parameter is discarded.
>>>
>>> Introduce ignore_param() and OPT_IGNORE to cope with known cases, where
>>> warning the user is the wrong course of action to take.
>>>
>>> Signed-off-by: Andrew Cooper
>>> ---
>>> CC: Jan Beulich
>>> CC: Wei Liu
>>> CC: Roger Pau Monné
>>> CC: Juergen Gross
>>>
>>> v2:
>>> * Rewrite from scratch, following Juergen's suggestion
>>>
>>> An implementation detail of ignore_param() is that it can only be used once
>>> per translation unit, which is fine for now. Two options to fix this are to
>>> tokenise __LINE__ in (requires some extreme preprocessor magic to make work,
>>> as ## inhibits expansion, and may cause livepatching issues), or to retain
>>> the
>>> _val parameter and require callers to just pass in a unique string.
>> Or make the unique string an optional parameter via:
>>
>> #define ignore_param(_name, uniq...)\
>> __setup_str __setup_str_ign ## uniq[] = _name; \
>> __kparam __setup_ign ## uniq = \
>> { .name = __setup_str_ign ## uniq, \
>> .type = OPT_IGNORE }
>>
>> With or without that change:
>>
>> Reviewed-by: Juergen Gross
>> Release-acked-by: Juergen Gross
> Actually I like this as an option.
Sadly, it doesn't work, as you end up with:
__setup_str setup_str_ign_ ## [] = "pv-shim";
and ## is a binary operator.
I'll leave it as-was and we can figure this out in the future if necessary.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.12] xen/cmdline: Work around some specific command line warnings
On 30/01/2019 16:31, Juergen Gross wrote:
> On 30/01/2019 16:55, Andrew Cooper wrote:
>> Xen will warn when an unknown parameter is found in the command line. e.g.
>>
>> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>>
>> One case where this goes wrong is a workaround for an old grub bug, which
>> resulted in "placeholder" being prepended to the command line.
>>
>> Another case is when booting a CONFIG_PV_SHIM_EXCLUSIVE build, in which the
>> parsing for the "pv-shim" parameter is discarded.
>>
>> Introduce ignore_param() and OPT_IGNORE to cope with known cases, where
>> warning the user is the wrong course of action to take.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Wei Liu
>> CC: Roger Pau Monné
>> CC: Juergen Gross
>>
>> v2:
>> * Rewrite from scratch, following Juergen's suggestion
>>
>> An implementation detail of ignore_param() is that it can only be used once
>> per translation unit, which is fine for now. Two options to fix this are to
>> tokenise __LINE__ in (requires some extreme preprocessor magic to make work,
>> as ## inhibits expansion, and may cause livepatching issues), or to retain
>> the
>> _val parameter and require callers to just pass in a unique string.
> Or make the unique string an optional parameter via:
>
> #define ignore_param(_name, uniq...)\
> __setup_str __setup_str_ign ## uniq[] = _name; \
> __kparam __setup_ign ## uniq = \
> { .name = __setup_str_ign ## uniq, \
> .type = OPT_IGNORE }
>
> With or without that change:
>
> Reviewed-by: Juergen Gross
> Release-acked-by: Juergen Gross
Actually I like this as an option. I'll fold this in, along with Jan's
namespacing request.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing test] 132577: regressions - FAIL
flight 132577 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/132577/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 132485 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-5 69 xtf/test-hvm64-xsa-278 fail like 132485 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 132485 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 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-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail 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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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-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 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen 316e4426a185efefa078dd087c89a694b2149be8 baseline version: xen 278e9f511e97de734668a7190138eebe05834ffe Last test of basis 132485 2019-01-26 01:36:52 Z4 days Testing same since 132577 2019-01-29 17:41:43 Z0 days1 attempts People who touched revisions under test: Julien Grall Shameer Kolothum jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev
Re: [Xen-devel] [PATCH v2 for-4.12] xen/cmdline: Work around some specific command line warnings
>>> On 30.01.19 at 16:55, wrote:
> Xen will warn when an unknown parameter is found in the command line. e.g.
>
> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>
> One case where this goes wrong is a workaround for an old grub bug, which
> resulted in "placeholder" being prepended to the command line.
>
> Another case is when booting a CONFIG_PV_SHIM_EXCLUSIVE build, in which the
> parsing for the "pv-shim" parameter is discarded.
>
> Introduce ignore_param() and OPT_IGNORE to cope with known cases, where
> warning the user is the wrong course of action to take.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> An implementation detail of ignore_param() is that it can only be used once
> per translation unit, which is fine for now. Two options to fix this are to
> tokenise __LINE__ in (requires some extreme preprocessor magic to make work,
> as ## inhibits expansion, and may cause livepatching issues), or to retain the
> _val parameter and require callers to just pass in a unique string.
How about requiring the quotes to be omitted from the argument
passed to the macro and using that string to paste onto the
variable names? This would require following an earlier suggestion
of mine in that we (a) treat '-' and '_' equally when parsing
command line options (cmdline_strcmp()) and (b) the main parser
to use that function. But as you say, nothing that needs solving
right away.
> @@ -136,6 +137,11 @@ extern const struct kernel_param __param_start[],
> __param_end[];
>.type = OPT_STR, \
>.len = sizeof(_var), \
>.par.var = &_var }
> +#define ignore_param(_name) \
> +__setup_str __setup_str_ign[] = _name; \
> +__kparam __setup_ign = \
> +{ .name = __setup_str_ign, \
> + .type = OPT_IGNORE }
I don't suppose that I could talk you into dropping the leading
underscore from the macro parameter name, and into
reducing the double leading underscores of the variables to
single ones? I realize this won't fit the other macros, but
eventually we will want to get rid of all those name space
violations.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.12] xen/cmdline: Work around some specific command line warnings
On 30/01/2019 16:55, Andrew Cooper wrote:
> Xen will warn when an unknown parameter is found in the command line. e.g.
>
> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>
> One case where this goes wrong is a workaround for an old grub bug, which
> resulted in "placeholder" being prepended to the command line.
>
> Another case is when booting a CONFIG_PV_SHIM_EXCLUSIVE build, in which the
> parsing for the "pv-shim" parameter is discarded.
>
> Introduce ignore_param() and OPT_IGNORE to cope with known cases, where
> warning the user is the wrong course of action to take.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Juergen Gross
>
> v2:
> * Rewrite from scratch, following Juergen's suggestion
>
> An implementation detail of ignore_param() is that it can only be used once
> per translation unit, which is fine for now. Two options to fix this are to
> tokenise __LINE__ in (requires some extreme preprocessor magic to make work,
> as ## inhibits expansion, and may cause livepatching issues), or to retain the
> _val parameter and require callers to just pass in a unique string.
Or make the unique string an optional parameter via:
#define ignore_param(_name, uniq...)\
__setup_str __setup_str_ign ## uniq[] = _name; \
__kparam __setup_ign ## uniq = \
{ .name = __setup_str_ign ## uniq, \
.type = OPT_IGNORE }
With or without that change:
Reviewed-by: Juergen Gross
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] Ping: [PATCH] x86emul: correct AVX512BW write masking checks
>>> On 24.01.19 at 11:54, wrote:
On 16.01.19 at 12:40, wrote:
>> On 14/01/2019 12:40, Jan Beulich wrote:
>>> For VPSADBW this likely was a result of bad copy-and-paste.
>>>
>>> For VPS{L,R}LDQ comment and code were not in line, but then again the
>>> comment also wasn't fully updated from the AVX2 original it got cloned
>>> from.
>>>
>>> Signed-off-by: Jan Beulich
>>
>> Release-acked-by: Juergen Gross
>
> Andrew?
I guess I'll commit this without any ordinary ack early next week
unless I hear back.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] libxl: When restricted, start QEMU paused
Anthony PERARD writes ("Re: [PATCH for-4.12] libxl: When restricted, start QEMU
paused"):
> On Wed, Jan 30, 2019 at 03:09:45PM +, Ian Jackson wrote:
> > - libxl connects and hand-checks [xxx???] with QEMU, then sends the
> > cmd "query-status".
> > - QEMU prepares and maybe tries to send the response,
> > while also writing "running" into xenstore.
> > - libxl sees via xenstore that QEMU is running and disconnects from the
> > QMP socket before receiving the response from the cmd.
> > => The QMP socket (monitor) is thereby blocked and will never reply
> > to commands on new connections.
> >
> > This is due to QEMU only responding to one command at a time, and
> > suspending its monitor (QMP) until the command as been processed and
> > sent. Disconnecting from the socket doesn't unsuspend the monitor. The
> > race described here is very likely to happen with QEMU 3.1.50 (during
> > 3.2 development), but can be reproduced with QEMU 3.1.
> >
> > [xxx??? So, require, therefore, that when we get the QMP readiness
> > notification, the qemu state is xenstore.]
>
> Sorry for this been vague. I'm not 100% sure of what QEMU do and when.
> The listing of QEMU's action are probably not accurate.
Hrm. Maybe you want to write `roughly' or `I think' or something,
then. I think the description of the QEMU behaviour is useful even if
not 100% accurate.
> Or maybe the issue here is: s/hand-checks/handshake/, I was trying to
> describe the context with as little words as possible before
> getting to the point where things fails.
Yes, `handshake' makes much more sense. `Hand-check' would mean
`check by hand'.
https://en.wiktionary.org/wiki/handshake
https://en.wiktionary.org/wiki/by_hand
> Is that better to understand the context? How much of this would
> actally be useful for the patch description?
Probably what you wrote originally and I edited, with the xxx's fixed.
Assuming it's actually true...
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] xen-block: handle resize callback
Some frontend drivers will handle dynamic resizing of PV disks, so set up
the BlockDevOps resize_cb() method during xen_block_realize() to allow
this to be done.
Signed-off-by: Paul Durrant
---
Cc: Stefan Hajnoczi
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Kevin Wolf
Cc: Max Reitz
v2:
- re-write backend state after updating sectors
---
hw/block/dataplane/xen-block.c | 4 +---
hw/block/trace-events | 1 +
hw/block/xen-block.c | 40 ++
3 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index d0d8905a33..c6a15da024 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -50,7 +50,6 @@ struct XenBlockDataPlane {
unsigned int nr_ring_ref;
void *sring;
int64_t file_blk;
-int64_t file_size;
int protocol;
blkif_back_rings_t rings;
int more_work;
@@ -189,7 +188,7 @@ static int xen_block_parse_request(XenBlockRequest *request)
request->req.seg[i].first_sect + 1) * dataplane->file_blk;
request->size += len;
}
-if (request->start + request->size > dataplane->file_size) {
+if (request->start + request->size > blk_getlength(dataplane->blk)) {
error_report("error: access beyond end of file");
goto err;
}
@@ -638,7 +637,6 @@ XenBlockDataPlane *xen_block_dataplane_create(XenDevice
*xendev,
dataplane->xendev = xendev;
dataplane->file_blk = conf->logical_block_size;
dataplane->blk = conf->blk;
-dataplane->file_size = blk_getlength(dataplane->blk);
QLIST_INIT(>inflight);
QLIST_INIT(>freelist);
diff --git a/hw/block/trace-events b/hw/block/trace-events
index d0851953c5..8020f9226a 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -126,6 +126,7 @@ xen_block_realize(const char *type, uint32_t disk, uint32_t
partition) "%s d%up%
xen_block_connect(const char *type, uint32_t disk, uint32_t partition) "%s
d%up%u"
xen_block_disconnect(const char *type, uint32_t disk, uint32_t partition) "%s
d%up%u"
xen_block_unrealize(const char *type, uint32_t disk, uint32_t partition) "%s
d%up%u"
+xen_block_size(const char *type, uint32_t disk, uint32_t partition, int64_t
sectors) "%s d%up%u %"PRIi64
xen_disk_realize(void) ""
xen_disk_unrealize(void) ""
xen_cdrom_realize(void) ""
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index a636487b3e..0f0799e861 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -144,6 +144,38 @@ static void xen_block_unrealize(XenDevice *xendev, Error
**errp)
}
}
+static void xen_block_set_size(XenBlockDevice *blockdev)
+{
+const char *type = object_get_typename(OBJECT(blockdev));
+XenBlockVdev *vdev = >props.vdev;
+BlockConf *conf = >props.conf;
+int64_t sectors = blk_getlength(conf->blk) / conf->logical_block_size;
+XenDevice *xendev = XEN_DEVICE(blockdev);
+
+trace_xen_block_size(type, vdev->disk, vdev->partition, sectors);
+
+xen_device_backend_printf(xendev, "sectors", "%"PRIi64, sectors);
+}
+
+static void xen_block_resize_cb(void *opaque)
+{
+XenBlockDevice *blockdev = opaque;
+XenDevice *xendev = XEN_DEVICE(blockdev);
+enum xenbus_state backend_state = xen_device_backend_get_state(xendev);
+
+xen_block_set_size(blockdev);
+
+/*
+ * Mimic the behaviour of Linux xen-blkback and re-write the state
+ * to trigger the frontend watch.
+ */
+xen_device_backend_set_state(xendev, backend_state);
+}
+
+static const BlockDevOps xen_block_dev_ops = {
+.resize_cb = xen_block_resize_cb,
+};
+
static void xen_block_realize(XenDevice *xendev, Error **errp)
{
XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
@@ -180,7 +212,7 @@ static void xen_block_realize(XenDevice *xendev, Error
**errp)
}
if (!blkconf_apply_backend_options(conf, blockdev->info & VDISK_READONLY,
- false, errp)) {
+ true, errp)) {
return;
}
@@ -197,6 +229,7 @@ static void xen_block_realize(XenDevice *xendev, Error
**errp)
return;
}
+blk_set_dev_ops(conf->blk, _block_dev_ops, blockdev);
blk_set_guest_block_size(conf->blk, conf->logical_block_size);
if (conf->discard_granularity > 0) {
@@ -215,9 +248,8 @@ static void xen_block_realize(XenDevice *xendev, Error
**errp)
xen_device_backend_printf(xendev, "sector-size", "%u",
conf->logical_block_size);
-xen_device_backend_printf(xendev, "sectors", "%"PRIi64,
- blk_getlength(conf->blk) /
- conf->logical_block_size);
+
+xen_block_set_size(blockdev);
blockdev->dataplane =
xen_block_dataplane_create(xendev, conf, blockdev->props.iothread);
--
2.20.1.2.gb21ebb6
___
Xen-devel mailing list
Re: [Xen-devel] [PATCH for-4.12] libxl: When restricted, start QEMU paused
On Wed, Jan 30, 2019 at 03:09:45PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH for-4.12] libxl: When restricted, start QEMU
> paused"):
> > [stuff]
>
> Thanks for this. I think the code looks right but to make it easier
> to understand what was going on I have taken the liberty of trying to
> reword your commit message for English grammar.
>
> Can you please check that this is true ?
>
> libxl runs the command "cont" later during guest creation; i.e. it
> is expecting that QEMU would not do any emulation. Use the "-S"
> command option to achieve this.
>
> Unfortunately, when QEMU is started with "-S", it won't write QEMU's
> readiness into xenstore. So only activate this option when we have a
> QEMU startup notification via QMP available, i.e. when dm_restrict
> is activated.
>
> The -S option has the side-effect of suppressing the startup
> notification via xenstore: libxl will only get the notification via
> QMP.
>
> It is important to rely only on QMP for notification when we have
> QMP available, as (due to a qemu bug) not waiting for that QMP
> notification may result in the QMP socket becoming blocked, so that
> QEMU stops responding to new connections even if no existing ones
> are active.
>
> The QEMU bug that this patch works around is as follows:
> - libxl connects and hand-checks [xxx???] with QEMU, then sends the
> cmd "query-status".
> - QEMU prepares and maybe tries to send the response,
> while also writing "running" into xenstore.
> - libxl sees via xenstore that QEMU is running and disconnects from the
> QMP socket before receiving the response from the cmd.
> => The QMP socket (monitor) is thereby blocked and will never reply
> to commands on new connections.
>
> This is due to QEMU only responding to one command at a time, and
> suspending its monitor (QMP) until the command as been processed and
> sent. Disconnecting from the socket doesn't unsuspend the monitor. The
> race described here is very likely to happen with QEMU 3.1.50 (during
> 3.2 development), but can be reproduced with QEMU 3.1.
>
> [xxx??? So, require, therefore, that when we get the QMP readiness
> notification, the qemu state is xenstore.]
Sorry for this been vague. I'm not 100% sure of what QEMU do and when.
The listing of QEMU's action are probably not accurate.
QEMU probably write the "running" state to xenstore before starting to
handle the QMP connection (respond to command). I'm unsure of when QEMU
does handle QMP, but that's probably in the main_loop(), which is
started after the piece of code that write to xenstore.
Or maybe the issue here is: s/hand-checks/handshake/, I was trying to
describe the context with as little words as possible before
getting to the point where things fails.
But here is a little more detail of libxl's action, when the bug happen
(and before that patch is applied):
- connect(qmp_socket)
. wait (for event, like something to read or xenstore updates)
- receive QMP greeting, then send 'qmp_capabilities' command
. wait
- receive response to qmp_capability, then send 'query-status'
. wait
- receive update from xenstore: qemu's state=runnning
then close connection to qmp_socket and keep going with domain
creation
Is that better to understand the context? How much of this would
actally be useful for the patch description?
> I added a couple of xxx where I was particularly unsure.
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 for-4.12] xen/cmdline: Work around some specific command line warnings
Xen will warn when an unknown parameter is found in the command line. e.g.
(d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
One case where this goes wrong is a workaround for an old grub bug, which
resulted in "placeholder" being prepended to the command line.
Another case is when booting a CONFIG_PV_SHIM_EXCLUSIVE build, in which the
parsing for the "pv-shim" parameter is discarded.
Introduce ignore_param() and OPT_IGNORE to cope with known cases, where
warning the user is the wrong course of action to take.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
v2:
* Rewrite from scratch, following Juergen's suggestion
An implementation detail of ignore_param() is that it can only be used once
per translation unit, which is fine for now. Two options to fix this are to
tokenise __LINE__ in (requires some extreme preprocessor magic to make work,
as ## inhibits expansion, and may cause livepatching issues), or to retain the
_val parameter and require callers to just pass in a unique string.
Thoughts welcome.
---
xen/arch/x86/pv/shim.c | 5 -
xen/arch/x86/setup.c | 6 ++
xen/common/kernel.c| 2 ++
xen/include/xen/init.h | 8 +++-
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 636a9d6..324ca27 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -40,7 +40,10 @@
#undef virt_to_mfn
#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_PV_SHIM_EXCLUSIVE
+/* Tolerate "pv-shim" being passed to a CONFIG_PV_SHIM_EXCLUSIVE hypervisor. */
+ignore_param("pv-shim");
+#else
bool pv_shim;
boolean_param("pv-shim", pv_shim);
#endif
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 06eb483..92da060 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -639,6 +639,12 @@ static void __init noreturn reinit_bsp_stack(void)
reset_stack_and_jump(init_done);
}
+/*
+ * Some scripts add "placeholder" to work around a grub error where it ate the
+ * first parameter.
+ */
+ignore_param("placeholder");
+
static bool __init loader_is_grub2(const char *loader_name)
{
/* GRUB1="GNU GRUB 0.xx"; GRUB2="GRUB 1.xx" */
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 053c31d..6125754 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -162,6 +162,8 @@ static int parse_params(const char *cmdline, const struct
kernel_param *start,
}
rctmp = param->par.func(optval);
break;
+case OPT_IGNORE:
+break;
default:
BUG();
break;
diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
index c6b453a..9384914 100644
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -81,7 +81,8 @@ struct kernel_param {
OPT_UINT,
OPT_BOOL,
OPT_SIZE,
-OPT_CUSTOM
+OPT_CUSTOM,
+OPT_IGNORE,
} type;
unsigned int len;
union {
@@ -136,6 +137,11 @@ extern const struct kernel_param __param_start[],
__param_end[];
.type = OPT_STR, \
.len = sizeof(_var), \
.par.var = &_var }
+#define ignore_param(_name) \
+__setup_str __setup_str_ign[] = _name; \
+__kparam __setup_ign = \
+{ .name = __setup_str_ign, \
+ .type = OPT_IGNORE }
#define __rtparam __param(__dataparam)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [linux-4.19 test] 132468: regressions - FAIL
On Tue, Jan 29, 2019 at 05:46:55PM +, osstest service owner wrote: > flight 132468 linux-4.19 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/132468/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. > 129313 > test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. > vs. 129313 > test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. > 129313 > test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. > vs. 129313 > test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. > 129313 > test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-examine 8 reboot fail REGR. vs. > 129313 > test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. > 129313 > test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. > 129313 > test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. > 129313 > test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. > 129313 > test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-xl7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. > 129313 > test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. > 129313 > test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. > 129313 > test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. > 129313 > test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. > 129313 > test-amd64-amd64-examine 8 reboot fail REGR. vs. > 129313 > test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. > vs. 129313 > test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. > vs. 129313 Hello, I've been watching the 4.19 branch for some time since I would like to switch osstest to use it so we can start testing pvh dom0 in osstest. The most worrying issue, and that affects quite a lot of the jobs, is the failure to boot on the chardonnay boxes. The following page fault is always triggered when booting as dom0 on this specific hardware: Jan 26 10:54:04.598513 [2.985424] input: Avocent Keyboard/Mouse Function as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/0003:0624:0249.0001/input/input5 Jan 26 10:54:04.610288 [3.037982] hid-generic 0003:0624:0249.0001: input,hidraw0: USB HID v1.00 Keyboard [Avocent Keyboard/Mouse Function] on usb-:00:1a.0-1.1.1/input0 Jan 26 10:54:04.622578 [3.039965] input: Avocent Keyboard/Mouse Function as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.1/0003:0624:0249.0002/input/input6 Jan 26 10:54:04.634343 [3.040639] hid-generic 0003:0624:0249.0002: input,hidraw1: USB HID v1.00 Mouse [Avocent Keyboard/Mouse Function] on usb-:00:1a.0-1.1.1/input1 Jan 26 10:54:04.646335 [3.042337] input: Avocent Keyboard/Mouse Function as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.2/0003:0624:0249.0003/input/input7 Jan 26 10:54:04.658656 [3.043023] hid-generic 0003:0624:0249.0003: input,hidraw2: USB HID v1.00 Mouse [Avocent Keyboard/Mouse Function] on usb-:00:1a.0-1.1.1/input2 Jan 26 10:54:04.682582 [3.248135] ata7.00: ATA-8: WDC WD1003FBYZ-010FB0, 01.01V03, max UDMA/133 Jan 26 10:54:04.682620 [3.248404] ata7.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 32) Jan 26 10:54:04.694636 [3.250183] ata7.00: configured for UDMA/133 Jan 26 10:54:04.694700 [3.261071] scsi 6:0:0:0: Direct-Access ATA WDC WD1003FBYZ-0 1V03 PQ: 0 ANSI: 5 Jan 26 10:54:04.706642 [3.261718] sd 6:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jan 26 10:54:04.706715 [3.261725] sd 6:0:0:0: Attached scsi generic sg0 type 0 Jan 26 10:54:04.718585 [3.262118] sd 6:0:0:0: [sda] Write Protect is off Jan 26 10:54:04.718621 [3.262667] sd 6:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jan 26 10:54:04.730644 [3.285447] sda: sda1 sda2 < sda5 > Jan 26 10:54:04.730705 [3.286292] sd 6:0:0:0: [sda] Attached SCSI disk Jan 26 10:54:04.742638 Begin: Loading essential drivers ... done. Jan 26 10:54:04.742700 Begin:
Re: [Xen-devel] [BUG]
Ater some years. I am figure out that on these machime was hardware deffect. Hardware is not stable. > > >"IRQ problem dom0 xen4.5-amd64" >i have mothrboard geforce 6100pm-m2(v3.0) latest bios and athtlon 64 x2 5000+ >cpu >Mothrboard based on nforce 430 chipset >if in bios enabled apic mode. Xen boot stops on trying to load dom0 kernel >(gentoo kernel v4.5 or ubuntu kernel v 4.2) and just showing black screen, >but kernel without xen loads normally. > >if in bios disable apic mode Xen boot dom0 but not see any disk (of cource >scsi libata and nforce deivers enabled in kernel by "Y") and keyboard does not >work. >logs on screen that i can see: >genirq: flags mismatch irq12 0080 (i8042) vs (mce) >genirq: flags mismatch irq1 0080 (i8042) vs 0002cc00 (spinlock0) >genirq: flags mismatch irq1 0080 (rtc0) vs 0002cc00 (xen-pcpu) >genirq: flags mismatch irq5 0080 (sata_nv) vs 0002cc00 (callfunction0) > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 132544: regressions - FAIL
On Wed, Jan 30, 2019 at 09:15:58AM +0100, Juergen Gross wrote: > On 29/01/2019 18:08, osstest service owner wrote: > > flight 132544 xen-unstable real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/132544/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 > > guest-localmigrate/x10 fail REGR. vs. 132422 > > Does the host have the hypercall buffer device patch (Linux kernel > upstream commit c51b3c639e01f20559531eef3c5919feae23c55a)? According to http://logs.test-lab.xenproject.org/osstest/logs/132544/build-amd64-pvops/info.html The Linux tree under test is e6608e1f2fbd5827df9fa0da9ab1ad64f68be8d7 . commit e6608e1f2fbd5827df9fa0da9ab1ad64f68be8d7 Author: Greg Kroah-Hartman AuthorDate: Sat Jan 26 09:37:07 2019 +0100 Commit: Greg Kroah-Hartman CommitDate: Sat Jan 26 09:37:07 2019 +0100 Linux 4.14.96 $ git checkout e6608e1f2fbd5827df9fa0da9ab1ad64f68be8d7 $ git log drivers/xen It doesn't appear to have the patch you want. Wei. > > > Juergen > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12] libxl: When restricted, start QEMU paused
Anthony PERARD writes ("[PATCH for-4.12] libxl: When restricted, start QEMU
paused"):
> [stuff]
Thanks for this. I think the code looks right but to make it easier
to understand what was going on I have taken the liberty of trying to
reword your commit message for English grammar.
Can you please check that this is true ?
libxl runs the command "cont" later during guest creation; i.e. it
is expecting that QEMU would not do any emulation. Use the "-S"
command option to achieve this.
Unfortunately, when QEMU is started with "-S", it won't write QEMU's
readiness into xenstore. So only activate this option when we have a
QEMU startup notification via QMP available, i.e. when dm_restrict
is activated.
The -S option has the side-effect of suppressing the startup
notification via xenstore: libxl will only get the notification via
QMP.
It is important to rely only on QMP for notification when we have
QMP available, as (due to a qemu bug) not waiting for that QMP
notification may result in the QMP socket becoming blocked, so that
QEMU stops responding to new connections even if no existing ones
are active.
The QEMU bug that this patch works around is as follows:
- libxl connects and hand-checks [xxx???] with QEMU, then sends the
cmd "query-status".
- QEMU prepares and maybe tries to send the response,
while also writing "running" into xenstore.
- libxl sees via xenstore that QEMU is running and disconnects from the
QMP socket before receiving the response from the cmd.
=> The QMP socket (monitor) is thereby blocked and will never reply
to commands on new connections.
This is due to QEMU only responding to one command at a time, and
suspending its monitor (QMP) until the command as been processed and
sent. Disconnecting from the socket doesn't unsuspend the monitor. The
race described here is very likely to happen with QEMU 3.1.50 (during
3.2 development), but can be reproduced with QEMU 3.1.
[xxx??? So, require, therefore, that when we get the QMP readiness
notification, the qemu state is xenstore.]
I added a couple of xxx where I was particularly unsure.
Regards,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/6] xen/x86: add PHYSDEVOP_msi_msix_set_enable
>>> On 30.01.19 at 14:51, wrote:
> On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -1474,6 +1474,22 @@ int pci_restore_msi_state(struct pci_dev *pdev)
>> return 0;
>> }
>>
>> +int msi_msix_set_enable(struct pci_dev *pdev, int flag, int enable)
>> +{
>> +if ( !current->domain->target || pdev->domain !=
>> current->domain->target )
>> +return -EPERM;
>> +
>> +switch ( flag ) {
>> +case PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSI:
>> +msi_set_enable(pdev, enable);
>> +break;
>
> Please add a newline here.
And also please correct indentation. The misplaced { was
already pointed out iirc.
>> +case PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSIX:
>> +msix_set_enable(pdev, enable);
>> +break;
>> +}
>> +return 0;
There's another blank line missing above here.
>> --- a/xen/include/public/physdev.h
>> +++ b/xen/include/public/physdev.h
>> @@ -344,6 +344,19 @@ struct physdev_dbgp_op {
>> typedef struct physdev_dbgp_op physdev_dbgp_op_t;
>> DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
>>
>> +#define PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSI 0
>> +#define PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSIX 1
>> +
>> +#define PHYSDEVOP_msi_msix_set_enable 32
>
> There's no need for the 'msi_msix' name, there are already other
> hypercalls that deal with both msi and msix and just have msi in the
> name: PHYSDEVOP_msi_set_enable.
And FAOD the same then also for the other two defines,
or alternatively
#define PHYSDEVOP_MSI_SET_ENABLE 0
#define PHYSDEVOP_MSIX_SET_ENABLE 1
>> +struct physdev_msi_msix_set_enable {
>> +/* IN */
>> +struct physdev_pci_device pci;
>> +uint8_t flag;
>
> But this is not really a flags field, I would rather rename this
> to 'mode' maybe.
>
>> +uint8_t enable;
>> +};
>> +typedef struct physdev_msi_msix_set_enable physdev_msi_msix_set_enable_t;
>> +DEFINE_XEN_GUEST_HANDLE(physdev_msi_msix_set_enable_t);
>
> I think you need to add the new hypercall to include/xlat.lst, AFAICT
> it requires no translation, so you should add it as '?'.
Plus add invocation of the resulting macro.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/pv-shim: Avoid a command line parameter warning for CONFIG_PV_SHIM_EXCLUSIVE builds
On 30/01/2019 15:09, Juergen Gross wrote:
> On 30/01/2019 11:06, Jan Beulich wrote:
> On 30.01.19 at 11:01, wrote:
>>> On 30/01/2019 09:57, Jan Beulich wrote:
>>> On 29.01.19 at 20:07, wrote:
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -40,7 +40,11 @@
> #undef virt_to_mfn
> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
>
> -#ifndef CONFIG_PV_SHIM_EXCLUSIVE
> +#ifdef CONFIG_PV_SHIM_EXCLUSIVE
> +/* Tolerate "pv-shim" being passed to a CONFIG_PV_SHIM_EXCLUSIVE
> hypervisor. */
> +static bool _discard;
> +boolean_param("pv-shim", _discard);
> +#else
> bool pv_shim;
> boolean_param("pv-shim", pv_shim);
> #endif
It would end up being less extra code if you did
#ifdef CONFIG_PV_SHIM_EXCLUSIVE
/* Tolerate "pv-shim" being passed to a CONFIG_PV_SHIM_EXCLUSIVE
hypervisor. */
static bool __initdata pv_shim;
#else
bool pv_shim;
#endif
boolean_param("pv-shim", pv_shim);
>>>
>>> Sadly not. In the EXCLUSIVE case, pv_shim is defined to be 1, and then
>>> you've got an object named with just a number. (I tried this approach
>>> first.)
>>
>> Oh, that's unfortunate in this particular case. In which case I
>> don't have any better suggestion either. One that you and others
>> perhaps wouldn't like would be
>>
>> custom_param("pv-shim", NULL);
>>
>> with parse_params() suitably adjusted to avoid the call in that
>> case.
>
> I'd rather add something like ignore_param("pv-shim") instead (with the
> new type OPT_IGNORE).
BTW, in case this is the selected solution we might want to add
ignore_param("placeholder");
as well. Some old grub scripts seem to add "placeholder" as the first
boot parameter to mitigate a grub error (eating first parameter).
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/pv-shim: Avoid a command line parameter warning for CONFIG_PV_SHIM_EXCLUSIVE builds
On 30/01/2019 11:06, Jan Beulich wrote:
On 30.01.19 at 11:01, wrote:
>> On 30/01/2019 09:57, Jan Beulich wrote:
>> On 29.01.19 at 20:07, wrote:
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -40,7 +40,11 @@
#undef virt_to_mfn
#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_PV_SHIM_EXCLUSIVE
+/* Tolerate "pv-shim" being passed to a CONFIG_PV_SHIM_EXCLUSIVE
hypervisor. */
+static bool _discard;
+boolean_param("pv-shim", _discard);
+#else
bool pv_shim;
boolean_param("pv-shim", pv_shim);
#endif
>>> It would end up being less extra code if you did
>>>
>>> #ifdef CONFIG_PV_SHIM_EXCLUSIVE
>>> /* Tolerate "pv-shim" being passed to a CONFIG_PV_SHIM_EXCLUSIVE
>>> hypervisor. */
>>> static bool __initdata pv_shim;
>>> #else
>>> bool pv_shim;
>>> #endif
>>> boolean_param("pv-shim", pv_shim);
>>
>> Sadly not. In the EXCLUSIVE case, pv_shim is defined to be 1, and then
>> you've got an object named with just a number. (I tried this approach
>> first.)
>
> Oh, that's unfortunate in this particular case. In which case I
> don't have any better suggestion either. One that you and others
> perhaps wouldn't like would be
>
> custom_param("pv-shim", NULL);
>
> with parse_params() suitably adjusted to avoid the call in that
> case.
I'd rather add something like ignore_param("pv-shim") instead (with the
new type OPT_IGNORE).
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.12] x86/pvh-boot: don't mandate validity of RSDP pointer
On 30/01/2019 14:55, Wei Liu wrote: > RSDP is not mandatory according to PVH spec. Remove the BUG_ON. The > guest (xen) will fall back to scanning if necessary. > > Reported-by: Andrew Cooper > Signed-off-by: Wei Liu 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 for-4.12 1/8] dom0/pvh: align allocation and mapping order to start address
On Wed, Jan 30, 2019 at 12:37:28PM +, Wei Liu wrote: > On Wed, Jan 30, 2019 at 11:36:39AM +0100, Roger Pau Monne wrote: > > Due to the recent changes in the iommu mapping logic, the start > > addresses provided need to be aligned to the order intended to be > > mapped. > > > > Can you reference some commits here? What would happen if the address is > not aligned? See: https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01030.html and https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01503.html > > dom0 PVH domain builder didn't take this into account when populating > > the p2m, fix this by making sure the order is chosen so that the start > > address is aligned to it. > > > > Signed-off-by: Roger Pau Monné > > --- > > Cc: Jan Beulich > > Cc: Andrew Cooper > > Cc: Wei Liu > > --- > > Without this patch trying to create a PVH dom0 will trigger an assert > > on certain hardware depending on the memory map. > > --- > > xen/arch/x86/hvm/dom0_build.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c > > index 51cf490811..a571d15c13 100644 > > --- a/xen/arch/x86/hvm/dom0_build.c > > +++ b/xen/arch/x86/hvm/dom0_build.c > > @@ -152,6 +152,8 @@ static int __init pvh_populate_memory_range(struct > > domain *d, > > > > order = get_order_from_pages(end - start + 1); > > order = min(order ? order - 1 : 0, max_order); > > +/* The order allocated and populated must be aligned to the > > address. */ > > +order = min(order, start ? find_first_set_bit(start) : MAX_ORDER); > > Isn't max_order better here? It will yield the same result because order has already been limited by max_order. I've used MAX_ORDER directly because it's a constant and could be faster than loading the value in max_order. You could also use 'order' instead of MAX_ORDER and will also yield the same result. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.12 v2] arm: gic-v3: deactivate SGI/PPI during initialization
On i.MX8, we implemented partition reboot which means Cortex-A reboot will not impact M4 cores and System control Unit core. However GICv3 is not reset because we also need to support A72 Cluster reboot without affecting A53 Cluster. The gic-v3 controller is configured with EOImode to 1, so during xen reboot, there is a function call "smp_call_function(halt_this_cpu, NULL, 0);" , but halt_this_cpu never return, that means other CPUs have no chance to deactivate the SGI interrupt, because the deactivate_irq operation is at the end of do_sgi. During the next boot of Xen, CPU0 will issue GIC_SGI_CALL_FUNCTION to other CPUs. As the Active state for SGI is left untouched during the reboot, the GIC_SGI_CALL_FUNCTION will still be active on the non-boot CPUs. This means the interrupt cannot be triggered again until it get deactivated. And according to IHI0069D_gic_architecture_specification, chapter "8.11.3 GICR_ICACTIVER0, Interrupt Clear-Active Register 0", the RW field of GICR_ICACTIVER0 resets to a value that is architecturally UNKNOWN. So set a fixed value during gic-v3 initialization to make sure interrupts are in deactivated state. Signed-off-by: Peng Fan --- V2: refine commit log deactivate SGI/PPI. No need for SPI, because Some or all RW fields of this GICD_ICACTIVER have defined reset values xen/arch/arm/gic-v3.c | 5 + 1 file changed, 5 insertions(+) diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 6fbc106757..1c1d2604f3 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -833,6 +833,11 @@ static int gicv3_cpu_init(void) writel_relaxed(priority, GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + (i / 4) * 4); +/* + * The activate state is unknown at boot, so make sure all + * SGIs and PPIs are de-activated. + */ +writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0); /* * Disable all PPI interrupts, ensure all SGI interrupts are * enabled. -- 2.14.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.12] x86/pvh-boot: don't mandate validity of RSDP pointer
On 30/01/2019 13:55, Wei Liu wrote: > RSDP is not mandatory according to PVH spec. Remove the BUG_ON. The > guest (xen) will fall back to scanning if necessary. > > Reported-by: Andrew Cooper > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 for-4.12] x86/pvh-boot: don't mandate validity of RSDP pointer
RSDP is not mandatory according to PVH spec. Remove the BUG_ON. The guest (xen) will fall back to scanning if necessary. Reported-by: Andrew Cooper Signed-off-by: Wei Liu --- xen/arch/x86/guest/pvh-boot.c | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arch/x86/guest/pvh-boot.c index 544775eeb4..ca8e156f7d 100644 --- a/xen/arch/x86/guest/pvh-boot.c +++ b/xen/arch/x86/guest/pvh-boot.c @@ -79,7 +79,6 @@ static void __init convert_pvh_info(multiboot_info_t **mbi, pvh_mbi_mods[i].string= entry[i].cmdline_paddr; } -BUG_ON(!pvh_info->rsdp_paddr); rsdp_hint = pvh_info->rsdp_paddr; *mbi = _mbi; -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 132618: tolerable all pass - PUSHED
flight 132618 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/132618/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 863549158129d326b2e5850f722bfda643264f2b baseline version: xen f50dd67950ca9d5a517501af10de7c8d88d1a188 Last test of basis 132569 2019-01-29 15:00:44 Z0 days Testing same since 132618 2019-01-30 11:00:46 Z0 days1 attempts People who touched revisions under test: Andrii Anisov Julien Grall jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f50dd67950..8635491581 863549158129d326b2e5850f722bfda643264f2b -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/6] xen/x86: add PHYSDEVOP_msi_msix_set_enable
On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
> PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE in non-permissive mode. Which
> is the right thing to do for PV domain (the main use case for pciback),
> as PV domain should use XEN_PCI_OP_* commands for that. Unfortunately
> those commands are not good for stubdomain use, as they configure MSI in
> dom0's kernel too, which should not happen for HVM domain.
>
> This new physdevop is allowed only for stubdomain controlling the domain
> which own the device.
>
> Signed-off-by: Marek Marczykowski-Górecki
Thanks!
> ---
> Changes in v3:
> - new patch
>
> This is rather RFC. Any suggestions for shorter name? Also, I'm not sure
> if physdev_msi_msix_set_enable.flag is the best name/idea.
I've made some comments below.
> Should it be plugged into XSM? Any suggestions how exactly? New
> function with XSM_DM_PRIV default action? Should it get target domain
> only, or also machine_bdf?
You should Cc the XSM maintainer I think, which I've done now.
> ---
> xen/arch/x86/msi.c | 16
> xen/arch/x86/physdev.c | 24
> xen/include/asm-x86/msi.h| 1 +
> xen/include/public/physdev.h | 13 +
> 4 files changed, 54 insertions(+)
>
> diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
> index babc414..9ba934c 100644
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -1474,6 +1474,22 @@ int pci_restore_msi_state(struct pci_dev *pdev)
> return 0;
> }
>
> +int msi_msix_set_enable(struct pci_dev *pdev, int flag, int enable)
> +{
> +if ( !current->domain->target || pdev->domain != current->domain->target
> )
> +return -EPERM;
> +
> +switch ( flag ) {
> +case PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSI:
> +msi_set_enable(pdev, enable);
> +break;
Please add a newline here.
> +case PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSIX:
> +msix_set_enable(pdev, enable);
> +break;
> +}
> +return 0;
> +}
> +
> void __init early_msi_init(void)
> {
> if ( use_msi < 0 )
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index de59e39..822846a 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -671,6 +671,30 @@ ret_t do_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> break;
> }
>
> +case PHYSDEVOP_msi_msix_set_enable: {
> +struct physdev_msi_msix_set_enable op;
> +struct pci_dev *pdev;
> +
> +ret = -EFAULT;
> +if ( copy_from_guest(, arg, 1) )
> +break;
> +
> +ret = -EINVAL;
> +if ( op.flag != PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSI &&
> +op.flag != PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSIX )
Align.
> +break;
> +
> +pcidevs_lock();
> +pdev = pci_get_pdev(op.pci.seg, op.pci.bus, op.pci.devfn);
> +if ( pdev )
> +ret = msi_msix_set_enable(pdev, op.flag, !!op.enable);
> +else
> +ret = -ENODEV;
> +pcidevs_unlock();
> +break;
> +
> +}
> +
> default:
> ret = -ENOSYS;
> break;
> diff --git a/xen/include/asm-x86/msi.h b/xen/include/asm-x86/msi.h
> index 10387dc..080bf24 100644
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -252,5 +252,6 @@ void guest_mask_msi_irq(struct irq_desc *, bool mask);
> void ack_nonmaskable_msi_irq(struct irq_desc *);
> void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
> void set_msi_affinity(struct irq_desc *, const cpumask_t *);
> +int msi_msix_set_enable(struct pci_dev *pdev, int flag, int enable);
>
> #endif /* __ASM_MSI_H */
> diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
> index b6faf83..fd797c6 100644
> --- a/xen/include/public/physdev.h
> +++ b/xen/include/public/physdev.h
> @@ -344,6 +344,19 @@ struct physdev_dbgp_op {
> typedef struct physdev_dbgp_op physdev_dbgp_op_t;
> DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
>
> +#define PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSI 0
> +#define PHYSDEVOP_MSI_MSIX_SET_ENABLE_MSIX 1
> +
> +#define PHYSDEVOP_msi_msix_set_enable 32
There's no need for the 'msi_msix' name, there are already other
hypercalls that deal with both msi and msix and just have msi in the
name: PHYSDEVOP_msi_set_enable.
> +struct physdev_msi_msix_set_enable {
> +/* IN */
> +struct physdev_pci_device pci;
> +uint8_t flag;
But this is not really a flags field, I would rather rename this
to 'mode' maybe.
> +uint8_t enable;
> +};
> +typedef struct physdev_msi_msix_set_enable physdev_msi_msix_set_enable_t;
> +DEFINE_XEN_GUEST_HANDLE(physdev_msi_msix_set_enable_t);
I think you need to add the new hypercall to include/xlat.lst, AFAICT
it requires no translation,
Re: [Xen-devel] [PATCH] arm: gic-v3: clear GICR active interrupts
> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 2019年1月30日 21:49 > To: Peng Fan ; sstabell...@kernel.org > Cc: xen-devel@lists.xenproject.org; Andre Przywara > > Subject: Re: [PATCH] arm: gic-v3: clear GICR active interrupts > > Hi, > > On 30/01/2019 13:36, Peng Fan wrote: > >>> Each ICACTIVER0 registers hold the active bit for 32 interrupts. > >>> However, this code assumes the register only hold 4 interrupts. So > >>> this will write to unwanted area. > >>> > >>> There are only 16 SGIs, so it fits in one write to ICACTIVER0. As > >>> wrote above, you also need to deactivate the PPIs. So the following > >>> should > >> be enough: > >>> > >>> /* > >>>* The activate state is unknown at boot, so make sure all SGIs > >>> and PPIs > >> are > >>>* de-activated. > >>>*/ > >>> writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0); > > > > Just have a following up question, according to > > IHI0069D_gic_architecture_specification > > "8.11.3 GICR_ICACTIVER0, Interrupt Clear-Active Register 0" > > This field resets to a value that is architecturally UNKNOWN, Do we > > need to take SPI into consideration as the following in gic_cpu_init? > > for (i = 0; i < nr_lines; i +=32) > > writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0 + (i > > / 32) * 4); > > > > and move nr_lines out from gic_dist_init to a static global varaiable. > > You can't clear SPIs through GICD_RDIST_SGI_BASE. You have to use the > GICD. Oops. I got wrong. > > Furthermore, gic_cpu_init is called for every CPU so this is not a good place > for clearing shared interrupts. Shared interrupts should be cleared in > gic_dist_init as this is called only once. Yes. Thanks, Peng. > > Cheers, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen 4.12 bug] HVM/PVH boot confusion
On Wed, Jan 30, 2019 at 02:49:52PM +0100, Juergen Gross wrote: > On 30/01/2019 14:38, Wei Liu wrote: > > On Wed, Jan 30, 2019 at 12:46:45PM +, Wei Liu wrote: > >> On Wed, Jan 30, 2019 at 12:30:44PM +, Andrew Cooper wrote: > > There are at least two bugs here. > > > > 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH > > entrypoint must not mandate its existence, because there are releases of > > the domain builder which don't provide it. > The inner Xen, in this case, can fall back to scanning low 1MB memory > for RSDP. > >>> > >>> Agreed. > > > > ---8<--- > > From 46e3686355da177955ca63ce3e8cf6a80cdb897d Mon Sep 17 00:00:00 2001 > > From: Wei Liu > > Date: Wed, 30 Jan 2019 13:31:32 + > > Subject: [PATCH] x86/pvh: don't mandate presence of RSDP pointer > > > > RSDP hint is not mandatory according to PVH spec. Only set the hint if > > pvh_info contains a valid pointer. The guest (xen) will fall back to > > scanning for RSDP in lower 1MB of memory. > > > > Reported-by: Andrew Cooper > > Signed-off-by: Wei Liu > > --- > > xen/arch/x86/guest/pvh-boot.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arch/x86/guest/pvh-boot.c > > index 544775eeb4..c6e21fa83b 100644 > > --- a/xen/arch/x86/guest/pvh-boot.c > > +++ b/xen/arch/x86/guest/pvh-boot.c > > @@ -79,8 +79,8 @@ static void __init convert_pvh_info(multiboot_info_t > > **mbi, > > pvh_mbi_mods[i].string= entry[i].cmdline_paddr; > > } > > > > -BUG_ON(!pvh_info->rsdp_paddr); > > -rsdp_hint = pvh_info->rsdp_paddr; > > +if ( pvh_info->rsdp_paddr ) > > Why do you need the if here? rsdp_hint is NULL initially. > > So just removing the BUG_ON() seems to be required. Good point. Wei. > > > Juergen > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen 4.12 bug] HVM/PVH boot confusion
On 30/01/2019 14:38, Wei Liu wrote: > On Wed, Jan 30, 2019 at 12:46:45PM +, Wei Liu wrote: >> On Wed, Jan 30, 2019 at 12:30:44PM +, Andrew Cooper wrote: > There are at least two bugs here. > > 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH > entrypoint must not mandate its existence, because there are releases of > the domain builder which don't provide it. The inner Xen, in this case, can fall back to scanning low 1MB memory for RSDP. >>> >>> Agreed. > > ---8<--- > From 46e3686355da177955ca63ce3e8cf6a80cdb897d Mon Sep 17 00:00:00 2001 > From: Wei Liu > Date: Wed, 30 Jan 2019 13:31:32 + > Subject: [PATCH] x86/pvh: don't mandate presence of RSDP pointer > > RSDP hint is not mandatory according to PVH spec. Only set the hint if > pvh_info contains a valid pointer. The guest (xen) will fall back to > scanning for RSDP in lower 1MB of memory. > > Reported-by: Andrew Cooper > Signed-off-by: Wei Liu > --- > xen/arch/x86/guest/pvh-boot.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arch/x86/guest/pvh-boot.c > index 544775eeb4..c6e21fa83b 100644 > --- a/xen/arch/x86/guest/pvh-boot.c > +++ b/xen/arch/x86/guest/pvh-boot.c > @@ -79,8 +79,8 @@ static void __init convert_pvh_info(multiboot_info_t **mbi, > pvh_mbi_mods[i].string= entry[i].cmdline_paddr; > } > > -BUG_ON(!pvh_info->rsdp_paddr); > -rsdp_hint = pvh_info->rsdp_paddr; > +if ( pvh_info->rsdp_paddr ) Why do you need the if here? rsdp_hint is NULL initially. So just removing the BUG_ON() seems to be required. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 7/8] x86/microcode: Synchronize late microcode loading
On Tue, Jan 29, 2019 at 11:37:12AM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:49PM +0800, Chao Gao wrote:
>> This patch ports microcode improvement patches from linux kernel.
>>
>> 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.
>>
>> Signed-off-by: Chao Gao
>> Tested-by: Chao Gao
>> [linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
>> [linux commit: bb8c13d61a629276a162c1d2b1a20a815cbcfbb7]
>> Cc: Kevin Tian
>> Cc: Jun Nakajima
>> Cc: Ashok Raj
>> Cc: Borislav Petkov
>> Cc: Thomas Gleixner
>> Cc: Andrew Cooper
>> Cc: Jan Beulich
>> ---
>> xen/arch/x86/microcode.c | 125
>> +--
>> 1 file changed, 98 insertions(+), 27 deletions(-)
>>
>> diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
>> index 3c2274f..b7b20cf 100644
>> --- a/xen/arch/x86/microcode.c
>> +++ b/xen/arch/x86/microcode.c
>> @@ -22,6 +22,7 @@
>> */
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -30,18 +31,25 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> +#include
>>
>> +#include
>> #include
>> #include
>> #include
>> #include
>>
>> +/* By default, wait for 3us */
>> +#define MICROCODE_DEFAULT_TIMEOUT_US 3
>> +
>> static module_t __initdata ucode_mod;
>> static signed int __initdata ucode_mod_idx;
>> static bool_t __initdata ucode_mod_forced;
>> +static unsigned int nr_cores;
>>
>> /*
>> * If we scan the initramfs.cpio for the early microcode code
>> @@ -188,10 +196,11 @@ static DEFINE_SPINLOCK(microcode_mutex);
>>
>> DEFINE_PER_CPU(struct ucode_cpu_info, ucode_cpu_info);
>>
>> -struct microcode_info {
>> -unsigned int cpu;
>> -int error;
>> -};
>> +/*
>> + * Count the CPUs that have entered and exited the rendezvous
>> + * during late microcode update.
>> + */
>> +static atomic_t cpu_in, cpu_out;
>>
>> static void microcode_fini_cpu(unsigned int cpu)
>> {
>> @@ -290,30 +299,60 @@ int microcode_resume_cpu(unsigned int cpu)
>> return microcode_ops ? microcode_update_cpu() : 0;
>> }
>>
>> -static long do_microcode_update(void *_info)
>> +/* Wait for all CPUs to rendezvous with a timeout (us) */
>> +static int wait_for_cpus(atomic_t *cnt, unsigned int timeout)
>> {
>> -struct microcode_info *info = _info;
>> -int error;
>> +unsigned int cpus = num_online_cpus();
>>
>> -BUG_ON(info->cpu != smp_processor_id());
>> +atomic_inc(cnt);
>> +
>> +while ( atomic_read(cnt) != cpus )
>> +{
>> +if ( timeout <= 0 )
>> +{
>> +printk("CPU%d: Timeout when waiting for CPUs calling in\n",
>> + smp_processor_id());
>> +return -EBUSY;
>> +}
>> +udelay(1);
>
>udelay will call the rdtsc instruction, is it fine to use it on a
>sibling thread while there's a microcode update in process on the same
>core?
I think it is ok. I just checked the kernel code. It uses the ndelay,
which in turn calls the rdtsc instruction in some cases.
Ashok, what's your opinion?
>
>> +timeout--;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int do_microcode_update(void *unused)
>> +{
>> +unsigned int cpu = smp_processor_id();
>> +int ret;
>>
>> -error = microcode_update_cpu();
>> -if ( error )
>> -info->error = error;
>> +ret = wait_for_cpus(_in, MICROCODE_DEFAULT_TIMEOUT_US);
>> +if ( ret )
>> +return ret;
>>
>> -info->cpu = cpumask_next(info->cpu, _online_map);
>> -if ( info->cpu < nr_cpu_ids )
>> -return continue_hypercall_on_cpu(info->cpu, do_microcode_update,
>> info);
>> +/*
>> + * Initiate an update on all processors which don't have an online
>> sibling
>> + * thread with a lower thread id. Other sibling threads just await the
>> + * completion of microcode update.
>> + */
>> +if ( cpu == cpumask_first(per_cpu(cpu_sibling_mask, cpu)) )
>> +ret = microcode_update_cpu();
>
>The description says "Gather all cores and serialize the microcode
>update on them by doing it one-by-one" but it looks like you are doing
>the update in parallel actually?
>
>> +/*
>> + * 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
>> + */
>> +if ( wait_for_cpus(_out, MICROCODE_DEFAULT_TIMEOUT_US * nr_cores) )
>> +
Re: [Xen-devel] [PATCH v2 21/21] memblock: drop memblock_alloc_*_nopanic() variants
On Mon 2019-01-21 10:04:08, Mike Rapoport wrote: > As all the memblock allocation functions return NULL in case of error > rather than panic(), the duplicates with _nopanic suffix can be removed. > > Signed-off-by: Mike Rapoport > Acked-by: Greg Kroah-Hartman > --- > arch/arc/kernel/unwind.c | 3 +-- > arch/sh/mm/init.c | 2 +- > arch/x86/kernel/setup_percpu.c | 10 +- > arch/x86/mm/kasan_init_64.c| 14 -- > drivers/firmware/memmap.c | 2 +- > drivers/usb/early/xhci-dbc.c | 2 +- > include/linux/memblock.h | 35 --- > kernel/dma/swiotlb.c | 2 +- > kernel/printk/printk.c | 9 + For printk: Reviewed-by: Petr Mladek Acked-by: Petr Mladek Best Regards, Petr > mm/memblock.c | 35 --- > mm/page_alloc.c| 10 +- > mm/page_ext.c | 2 +- > mm/percpu.c| 11 --- > mm/sparse.c| 6 ++ > 14 files changed, 31 insertions(+), 112 deletions(-) > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 8/8] microcode: update microcode on cores in parallel
On Tue, Jan 29, 2019 at 12:27:30PM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:50PM +0800, Chao Gao wrote:
>> Currently, microcode_update_lock and microcode_mutex prevent cores
>> from updating microcode in parallel. Below changes are made to support
>> parallel microcode update on cores.
>
>Oh, that's what I missed from the previous patch then, and what
>serialises the applying of the microcode update.
>
>>
>> microcode_update_lock is removed. The purpose of this lock is to
>> prevent logic threads of a same core from updating microcode at the
>> same time. But due to using a global lock, it also prevents parallel
>> microcode updating on different cores. The original purpose of
>> microcode_update_lock is already enforced at the level of
>> apply_microcode()'s caller:
>> 1. For late microcode update, only one sibiling thread of a core will
>> call the apply_microcode().
>> 2. For microcode update during system startup or CPU-hotplug, each
>> logical thread is woken up one-by-one.
>> 3. get/put_cpu_bitmaps() prevents the concurrency of CPU-hotplug and
>> late microcode update.
>>
>> microcode_mutex is replaced by a rwlock. microcode_mutex was used to
>> prevent concurrent accesses to 'uci' and microcode_cache. Now the
>> per-cpu variable, 'uci', won't be accessed by remote cpus after most
>> fields in 'uci' have been removed; The only shared resource which
>> needs to be protected is the microcode_cache. A rwlock allows multiple
>> readers (one thread of each core) to access the global cache and
>> update microcode simultaneously. Because the rwlock may be held in
>> stop_machine context, where interrupt is disabled, irq{save, restore}
>> variants are used to get/release the rwlock.
>>
>> Note that printk in apply_microcode() and svm_host_osvm_init() (for AMD
>> only) are still processed sequentially.
>>
>> Signed-off-by: Chao Gao
>
>Thanks, this LGTM, just one question below.
>
>> @@ -285,10 +307,11 @@ static int parse_microcode_blob(const void *buffer,
>> size_t len)
>> static int microcode_update_cpu(void)
>> {
>> int ret;
>> +unsigned long flag;
>>
>> -spin_lock(_mutex);
>> +read_lock_irqsave(_rwlock, flag);
>> ret = microcode_ops->apply_microcode(smp_processor_id());
>> -spin_unlock(_mutex);
>> +read_unlock_irqrestore(_rwlock, flag);
>
>Why do you take the lock here, wouldn't it be better to just take it
>for find_patch? (ie: like you do for save_patch)
Because find_patch() is expected to return a pointer to a ucode patch.
If a thread is to load this ucode patch, we should hold the lock to
avoid it being freed by another thread.
Thanks
Chao
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] arm: gic-v3: clear GICR active interrupts
Hi Julien
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2019年1月30日 20:06
> To: Peng Fan ; sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; Andre Przywara
>
> Subject: Re: [PATCH] arm: gic-v3: clear GICR active interrupts
>
> Hi
>
> Replying to this thread again.
>
> On 22/01/2019 10:54, Julien Grall wrote:
> > Hi Peng,
> >
> > The commit title is a bit confusing. It suggests that all interrupts
> > should be deactivated at boot, however you are only deactivating the SGIs.
> >
> > On 1/22/19 2:35 AM, Peng Fan wrote:
> >> On i.MX8, we implemented partition reboot which means Cortex-A reboot
> >> will not impact M4 cores and System control Unit core. However GICv3
> >> is not reset because hardware design.
> >
> > What do you mean by hardware design? Is it a defect?
> >
> >>
> >> The gic-v3 controller is configured with EOImode to 1, so during xen
> >> reboot, GIC_SGI_CALL_FUNCTION interrupt from CPU0 to other CPUs, but
> >> stop_cpu never return, that means other CPUs have no chance to
> >> deactive the interrupt. During xen booting again, CPU0 will issue
> >> GIC_SGI_CALL_FUNCTION to other CPUs. Because
> GIC_SGI_CALL_FUNCTION of
> >> other CPUs are active during the last reboot, interrupts could not be
> >> triggered unless we deactive the interrupt first.
> >
> > From the description here, I think it not very sane to go to sleep
> > with an interrupt activate.
>
> It looks like I was wrong here. There are case where you can't avoid that (see
> my answer to your other patch) and the boot code cannot rely on the activate
> state of interrupt. So they have to be cleaned at boot.
>
> This also have to be done for PPI and SPIs. Peng, would you mind to do that
> patch?
I'll send out v2 patch soon.
>
> >
> > A better solution would be to move the deactivation earlier on in
> > do_sgi (maybe after eoi_irq) so we call stop_cpu() with all interrupts
> disabled.
> >
> >>
> >> So let's deactive the interrupts during GICv3 initialization to fix
> >
> > s/deactivate/
> >
> >> this issue.
> >
> > Similarly to the commit title, you wrote the commit message very
> generically.
> >
> >
> >>
> >> Signed-off-by: Peng Fan
> >> ---
> >> xen/arch/arm/gic-v3.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index
> >> 6fbc106757..643d4a33f0 100644
> >> --- a/xen/arch/arm/gic-v3.c
> >> +++ b/xen/arch/arm/gic-v3.c
> >> @@ -824,8 +824,12 @@ static int gicv3_cpu_init(void)
> >> priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI
> >> << 8 |
> >> GIC_PRI_IPI);
> >> for (i = 0; i < NR_GIC_SGI; i += 4)
> >> + {
> >> writel_relaxed(priority,
> >> GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 +
> (i / 4) *
> >> 4);
> >> + writel_relaxed(0x,
> >> + GICD_RDIST_SGI_BASE + GICR_ICACTIVER0 + (i /
> 4) *
> >> +4);
>
> Each ICACTIVER0 registers hold the active bit for 32 interrupts. However, this
> code assumes the register only hold 4 interrupts. So this will write to
> unwanted area.
>
> There are only 16 SGIs, so it fits in one write to ICACTIVER0. As wrote above,
> you also need to deactivate the PPIs. So the following should be enough:
>
> /*
> * The activate state is unknown at boot, so make sure all SGIs and PPIs are
> * de-activated.
> */
> writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0);
Thanks,
Peng.
>
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 01/28] linkage: new macros for assembler symbols
Introduce new C macros for annotations of functions and data in assembly. There is a long-standing mess in macros like ENTRY, END, ENDPROC and similar. They are used in different manners and sometimes incorrectly. So introduce macros with clear use to annotate assembly as follows: a) Support macros for the ones below SYM_T_FUNC -- type used by assembler to mark functions SYM_T_OBJECT -- type used by assembler to mark data SYM_T_NONE -- type used by assembler to mark entries of unknown type They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE respectively. According to the gas manual, this is the most portable way. I am not sure about other assemblers, so we can switch this back to %function and %object if this turns into a problem. Architectures can also override them by something like ", @function" if they need. SYM_A_ALIGN, SYM_A_NONE -- align the symbol? SYM_L_GLOBAL, SYM_L_WEAK, SYM_L_LOCAL -- linkage of symbols b) Mostly internal annotations, used by the ones below SYM_ENTRY -- use only if you have to (for non-paired symbols) SYM_START -- use only if you have to (for paired symbols) SYM_END -- use only if you have to (for paired symbols) c) Annotations for code SYM_INNER_LABEL_ALIGN -- only for labels in the middle of code SYM_INNER_LABEL -- only for labels in the middle of code SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for one function SYM_FUNC_START_ALIAS -- use where there are two global names for one function SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function SYM_FUNC_START -- use for global functions SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment SYM_FUNC_START_LOCAL -- use for local functions SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o alignment SYM_FUNC_START_WEAK -- use for weak functions SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START, SYM_FUNC_START_WEAK, ... For functions with special (non-C) calling conventions: SYM_CODE_START -- use for non-C (special) functions SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o alignment SYM_CODE_START_LOCAL -- use for local non-C (special) functions SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special) functions, w/o alignment SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START d) For data SYM_DATA_START -- global data symbol SYM_DATA_START_LOCAL -- local data symbol SYM_DATA_END -- the end of the SYM_DATA_START symbol SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol SYM_DATA -- start+end wrapper around simple global data SYM_DATA_LOCAL -- start+end wrapper around simple local data == The macros allow to pair starts and ends of functions and mark functions correctly in the output ELF objects. All users of the old macros in x86 are converted to use these in further patches. [v2] * use SYM_ prefix and sane names * add SYM_START and SYM_END and parametrize all the macros [v3] * add SYM_DATA, SYM_DATA_LOCAL, and SYM_DATA_END_LABEL [v4] * add _NOALIGN versions of some macros * add _CODE_ derivates of _FUNC_ macros [v5] * drop "SIMPLE" from data annotations * switch NOALIGN and ALIGN variants of inner labels * s/visibility/linkage/; s@SYM_V_@SYM_L_@ * add Documentation [v6] * fixed typos found by Randy Dunlap * remove doubled INNER_LABEL macros, one pair was unused [v7] * rebased on the top of current code Signed-off-by: Jiri Slaby Cc: Andrew Morton Cc: Boris Ostrovsky Cc: h...@zytor.com Cc: Ingo Molnar Cc: jpoim...@redhat.com Cc: Juergen Gross Cc: Len Brown Cc: Linus Torvalds Cc: linux-ker...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: mi...@redhat.com Cc: Pavel Machek Cc: Peter Zijlstra Cc: "Rafael J. Wysocki" Cc: Thomas Gleixner Cc: xen-devel@lists.xenproject.org Cc: x...@kernel.org --- Documentation/asm-annotations.rst | 217 ++ arch/x86/include/asm/linkage.h| 10 +- include/linux/linkage.h | 245 +- 3 files changed, 461 insertions(+), 11 deletions(-) create mode 100644 Documentation/asm-annotations.rst diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst new file mode 100644 index ..265d64a1fc0b --- /dev/null +++ b/Documentation/asm-annotations.rst @@ -0,0 +1,217 @@ +Assembler Annotations += + +Copyright (c) 2017 Jiri Slaby + +This document describes the new macros for annotation of data and code in +assembler. In particular, it contains information about ``SYM_FUNC_START``, +``SYM_FUNC_END``, ``SYM_CODE_START``, and similar. + +Rationale +- +Some code like entries, trampolines, or boot code needs to be written in +assembly. The same as in C, we group such code into functions and accompany +them with
[Xen-devel] [PATCH v7 14/28] xen/pvh: annotate data appropriatelly
Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros to have: 8 OBJECT LOCAL DEFAULT6 gdt 000832 OBJECT LOCAL DEFAULT6 gdt_start 0028 0 OBJECT LOCAL DEFAULT6 gdt_end 0028 256 OBJECT LOCAL DEFAULT6 early_stack 0128 0 OBJECT LOCAL DEFAULT6 early_stack Signed-off-by: Jiri Slaby Reviewed-by: Boris Ostrovsky Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: xen-devel@lists.xenproject.org --- arch/x86/platform/pvh/head.S | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S index 1f8825bbaffb..4e63480bb223 100644 --- a/arch/x86/platform/pvh/head.S +++ b/arch/x86/platform/pvh/head.S @@ -150,11 +150,12 @@ END(pvh_start_xen) .section ".init.data","aw" .balign 8 -gdt: +SYM_DATA_START_LOCAL(gdt) .word gdt_end - gdt_start .long _pa(gdt_start) .word 0 -gdt_start: +SYM_DATA_END(gdt) +SYM_DATA_START_LOCAL(gdt_start) .quad 0x/* NULL descriptor */ #ifdef CONFIG_X86_64 .quad GDT_ENTRY(0xa09a, 0, 0xf) /* PVH_CS_SEL */ @@ -163,15 +164,14 @@ gdt_start: #endif .quad GDT_ENTRY(0xc092, 0, 0xf) /* PVH_DS_SEL */ .quad GDT_ENTRY(0x4090, 0, 0x18)/* PVH_CANARY_SEL */ -gdt_end: +SYM_DATA_END_LABEL(gdt_start, SYM_L_LOCAL, gdt_end) .balign 16 -canary: - .fill 48, 1, 0 +SYM_DATA_LOCAL(canary, .fill 48, 1, 0) -early_stack: +SYM_DATA_START_LOCAL(early_stack) .fill BOOT_STACK_SIZE, 1, 0 -early_stack_end: +SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end) ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, _ASM_PTR (pvh_start_xen - __START_KERNEL_map)) -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 25/28] x86_32/asm: add ENDs to some functions and relabel with SYM_CODE_*
All these are functions which are invoked from elsewhere, but they are not typical C functions. So we annotate them using the new SYM_CODE_START. All these were not balanced with any END, so mark their ends by SYM_CODE_END, appropriatelly. Signed-off-by: Jiri Slaby Reviewed-by: Boris Ostrovsky [xen bits] Reviewed-by: Rafael J. Wysocki [hibernate] Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Pavel Machek Cc: Boris Ostrovsky Cc: Juergen Gross Cc: linux...@vger.kernel.org Cc: xen-devel@lists.xenproject.org --- arch/x86/entry/entry_32.S| 3 ++- arch/x86/kernel/acpi/wakeup_32.S | 7 --- arch/x86/kernel/ftrace_32.S | 3 ++- arch/x86/kernel/head_32.S| 3 ++- arch/x86/power/hibernate_asm_32.S| 6 -- arch/x86/realmode/rm/trampoline_32.S | 6 -- arch/x86/xen/xen-asm_32.S| 7 --- 7 files changed, 22 insertions(+), 13 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 07029b98111d..f7190d5da9f1 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -790,9 +790,10 @@ SYM_ENTRY(__begin_SYSENTER_singlestep_region, SYM_L_GLOBAL, SYM_A_NONE) * Xen doesn't set %esp to be precisely what the normal SYSENTER * entry point expects, so fix it up before using the normal path. */ -ENTRY(xen_sysenter_target) +SYM_CODE_START(xen_sysenter_target) addl$5*4, %esp /* remove xen-provided frame */ jmp .Lsysenter_past_esp +SYM_CODE_END(xen_sysenter_target) #endif /* diff --git a/arch/x86/kernel/acpi/wakeup_32.S b/arch/x86/kernel/acpi/wakeup_32.S index feac1e5ecba0..71a05a6cc36a 100644 --- a/arch/x86/kernel/acpi/wakeup_32.S +++ b/arch/x86/kernel/acpi/wakeup_32.S @@ -8,8 +8,7 @@ .code32 ALIGN -ENTRY(wakeup_pmode_return) -wakeup_pmode_return: +SYM_CODE_START(wakeup_pmode_return) movw$__KERNEL_DS, %ax movw%ax, %ss movw%ax, %fs @@ -38,6 +37,7 @@ wakeup_pmode_return: # jump to place where we left off movlsaved_eip, %eax jmp *%eax +SYM_CODE_END(wakeup_pmode_return) bogus_magic: jmp bogus_magic @@ -71,7 +71,7 @@ restore_registers: popfl ret -ENTRY(do_suspend_lowlevel) +SYM_CODE_START(do_suspend_lowlevel) callsave_processor_state callsave_registers pushl $3 @@ -86,6 +86,7 @@ ret_point: callrestore_registers callrestore_processor_state ret +SYM_CODE_END(do_suspend_lowlevel) .data ALIGN diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S index b855dc10daeb..f4dca7df8ad6 100644 --- a/arch/x86/kernel/ftrace_32.S +++ b/arch/x86/kernel/ftrace_32.S @@ -102,7 +102,7 @@ WEAK(ftrace_stub) ret END(ftrace_caller) -ENTRY(ftrace_regs_caller) +SYM_CODE_START(ftrace_regs_caller) /* * i386 does not save SS and ESP when coming from kernel. * Instead, to get sp, >sp is used (see ptrace.h). @@ -170,6 +170,7 @@ SYM_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL) lea 3*4(%esp), %esp /* Skip orig_ax, ip and cs */ jmp .Lftrace_ret +SYM_CODE_END(ftrace_regs_caller) #else /* ! CONFIG_DYNAMIC_FTRACE */ ENTRY(function_hook) diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index 2d5390d84467..bfd713034e9b 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -64,7 +64,7 @@ RESERVE_BRK(pagetables, INIT_MAP_SIZE) * can. */ __HEAD -ENTRY(startup_32) +SYM_CODE_START(startup_32) movl pa(initial_stack),%ecx /* test KEEP_SEGMENTS flag to see if the bootloader is asking @@ -172,6 +172,7 @@ num_subarch_entries = (. - subarch_entries) / 4 #else jmp .Ldefault_entry #endif /* CONFIG_PARAVIRT */ +SYM_CODE_END(startup_32) #ifdef CONFIG_HOTPLUG_CPU /* diff --git a/arch/x86/power/hibernate_asm_32.S b/arch/x86/power/hibernate_asm_32.S index 6fe383002125..a19ed3d23185 100644 --- a/arch/x86/power/hibernate_asm_32.S +++ b/arch/x86/power/hibernate_asm_32.S @@ -35,7 +35,7 @@ ENTRY(swsusp_arch_suspend) ret ENDPROC(swsusp_arch_suspend) -ENTRY(restore_image) +SYM_CODE_START(restore_image) /* prepare to jump to the image kernel */ movlrestore_jump_address, %ebx movlrestore_cr3, %ebp @@ -45,9 +45,10 @@ ENTRY(restore_image) /* jump to relocated restore code */ movlrelocated_restore_code, %eax jmpl*%eax +SYM_CODE_END(restore_image) /* code below has been relocated to a safe page */ -ENTRY(core_restore_code) +SYM_CODE_START(core_restore_code) movltemp_pgt, %eax movl%eax, %cr3 @@ -77,6 +78,7 @@ copy_loop: done: jmpl*%ebx +SYM_CODE_END(core_restore_code) /* code below belongs to the image kernel */ .align PAGE_SIZE diff --git
[Xen-devel] [PATCH v7 09/28] x86/asm: annotate aliases
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS, and SYM_FUNC_END_ALIAS. This will make the tools generating the debuginfo happy. Signed-off-by: Jiri Slaby Cc: Herbert Xu Cc: "David S. Miller" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Cc: Boris Ostrovsky Cc: Juergen Gross Reviewed-by: Juergen Gross [xen parts] Cc: Cc: --- arch/x86/crypto/aesni-intel_asm.S | 5 ++--- arch/x86/lib/memcpy_64.S | 4 ++-- arch/x86/lib/memmove_64.S | 4 ++-- arch/x86/lib/memset_64.S | 4 ++-- arch/x86/xen/xen-asm_64.S | 4 ++-- 5 files changed, 10 insertions(+), 11 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 6c349e844581..19effbf9ce35 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -1761,8 +1761,7 @@ ENDPROC(aesni_gcm_finalize) #endif -.align 4 -_key_expansion_128: +SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128) SYM_FUNC_START_LOCAL(_key_expansion_256a) pshufd $0b, %xmm1, %xmm1 shufps $0b0001, %xmm0, %xmm4 @@ -1773,8 +1772,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a) movaps %xmm0, (TKEYP) add $0x10, TKEYP ret -ENDPROC(_key_expansion_128) SYM_FUNC_END(_key_expansion_256a) +SYM_FUNC_END_ALIAS(_key_expansion_128) SYM_FUNC_START_LOCAL(_key_expansion_192a) pshufd $0b01010101, %xmm1, %xmm1 diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S index 3b24dc05251c..68fcd8f9a48b 100644 --- a/arch/x86/lib/memcpy_64.S +++ b/arch/x86/lib/memcpy_64.S @@ -27,7 +27,7 @@ * Output: * rax original destination */ -ENTRY(__memcpy) +SYM_FUNC_START_ALIAS(__memcpy) ENTRY(memcpy) ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \ "jmp memcpy_erms", X86_FEATURE_ERMS @@ -41,7 +41,7 @@ ENTRY(memcpy) rep movsb ret ENDPROC(memcpy) -ENDPROC(__memcpy) +SYM_FUNC_END_ALIAS(__memcpy) EXPORT_SYMBOL(memcpy) EXPORT_SYMBOL(__memcpy) diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S index bbec69d8223b..50c1648311b3 100644 --- a/arch/x86/lib/memmove_64.S +++ b/arch/x86/lib/memmove_64.S @@ -26,7 +26,7 @@ */ .weak memmove -ENTRY(memmove) +SYM_FUNC_START_ALIAS(memmove) ENTRY(__memmove) /* Handle more 32 bytes in loop */ @@ -208,6 +208,6 @@ ENTRY(__memmove) 13: retq ENDPROC(__memmove) -ENDPROC(memmove) +SYM_FUNC_END_ALIAS(memmove) EXPORT_SYMBOL(__memmove) EXPORT_SYMBOL(memmove) diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S index 9bc861c71e75..927ac44d34aa 100644 --- a/arch/x86/lib/memset_64.S +++ b/arch/x86/lib/memset_64.S @@ -19,7 +19,7 @@ * * rax original destination */ -ENTRY(memset) +SYM_FUNC_START_ALIAS(memset) ENTRY(__memset) /* * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended @@ -43,8 +43,8 @@ ENTRY(__memset) rep stosb movq %r9,%rax ret -ENDPROC(memset) ENDPROC(__memset) +SYM_FUNC_END_ALIAS(memset) EXPORT_SYMBOL(memset) EXPORT_SYMBOL(__memset) diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S index 1e9ef0ba30a5..30dcc311f566 100644 --- a/arch/x86/xen/xen-asm_64.S +++ b/arch/x86/xen/xen-asm_64.S @@ -168,13 +168,13 @@ ENDPROC(xen_sysenter_target) #else /* !CONFIG_IA32_EMULATION */ -ENTRY(xen_syscall32_target) +SYM_FUNC_START_ALIAS(xen_syscall32_target) ENTRY(xen_sysenter_target) lea 16(%rsp), %rsp /* strip %rcx, %r11 */ mov $-ENOSYS, %rax pushq $0 jmp hypercall_iret -ENDPROC(xen_syscall32_target) ENDPROC(xen_sysenter_target) +SYM_FUNC_END_ALIAS(xen_syscall32_target) #endif /* CONFIG_IA32_EMULATION */ -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 23/28] x86_64/asm: change all ENTRY+END to SYM_CODE_*
Here, we change all assembly code which is marked using END (and not ENDPROC). We switch all these to appropriate new markings SYM_CODE_START and SYM_CODE_END. Signed-off-by: Jiri Slaby Reviewed-by: Boris Ostrovsky [xen bits] Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Boris Ostrovsky Cc: Juergen Gross Cc: xen-devel@lists.xenproject.org --- arch/x86/entry/entry_64.S| 48 arch/x86/entry/entry_64_compat.S | 8 +++--- arch/x86/kernel/ftrace_64.S | 4 +-- arch/x86/xen/xen-asm_64.S| 8 +++--- arch/x86/xen/xen-head.S | 8 +++--- 5 files changed, 38 insertions(+), 38 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 2fe59c693732..88e865ec9695 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -46,11 +46,11 @@ .section .entry.text, "ax" #ifdef CONFIG_PARAVIRT -ENTRY(native_usergs_sysret64) +SYM_CODE_START(native_usergs_sysret64) UNWIND_HINT_EMPTY swapgs sysretq -END(native_usergs_sysret64) +SYM_CODE_END(native_usergs_sysret64) #endif /* CONFIG_PARAVIRT */ .macro TRACE_IRQS_FLAGS flags:req @@ -142,7 +142,7 @@ END(native_usergs_sysret64) * with them due to bugs in both AMD and Intel CPUs. */ -ENTRY(entry_SYSCALL_64) +SYM_CODE_START(entry_SYSCALL_64) UNWIND_HINT_EMPTY /* * Interrupts are off on entry. @@ -273,13 +273,13 @@ syscall_return_via_sysret: popq%rdi popq%rsp USERGS_SYSRET64 -END(entry_SYSCALL_64) +SYM_CODE_END(entry_SYSCALL_64) /* * %rdi: prev task * %rsi: next task */ -ENTRY(__switch_to_asm) +SYM_CODE_START(__switch_to_asm) UNWIND_HINT_FUNC /* * Save callee-saved registers @@ -321,7 +321,7 @@ ENTRY(__switch_to_asm) popq%rbp jmp __switch_to -END(__switch_to_asm) +SYM_CODE_END(__switch_to_asm) /* * A newly forked process directly context switches into this address. @@ -330,7 +330,7 @@ END(__switch_to_asm) * rbx: kernel thread func (NULL for user thread) * r12: kernel thread arg */ -ENTRY(ret_from_fork) +SYM_CODE_START(ret_from_fork) UNWIND_HINT_EMPTY movq%rax, %rdi callschedule_tail /* rdi: 'prev' task parameter */ @@ -357,14 +357,14 @@ ENTRY(ret_from_fork) */ movq$0, RAX(%rsp) jmp 2b -END(ret_from_fork) +SYM_CODE_END(ret_from_fork) /* * Build the entry stubs with some assembler magic. * We pack 1 stub into every 8-byte block. */ .align 8 -ENTRY(irq_entries_start) +SYM_CODE_START(irq_entries_start) vector=FIRST_EXTERNAL_VECTOR .rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR) UNWIND_HINT_IRET_REGS @@ -373,7 +373,7 @@ ENTRY(irq_entries_start) .align 8 vector=vector+1 .endr -END(irq_entries_start) +SYM_CODE_END(irq_entries_start) .macro DEBUG_ENTRY_ASSERT_IRQS_OFF #ifdef CONFIG_DEBUG_ENTRY @@ -499,7 +499,7 @@ END(irq_entries_start) * | return address| * ++ */ -ENTRY(interrupt_entry) +SYM_CODE_START(interrupt_entry) UNWIND_HINT_FUNC ASM_CLAC cld @@ -565,7 +565,7 @@ ENTRY(interrupt_entry) TRACE_IRQS_OFF ret -END(interrupt_entry) +SYM_CODE_END(interrupt_entry) _ASM_NOKPROBE(interrupt_entry) @@ -772,7 +772,7 @@ _ASM_NOKPROBE(common_interrupt) * APIC interrupts. */ .macro apicinterrupt3 num sym do_sym -ENTRY(\sym) +SYM_CODE_START(\sym) UNWIND_HINT_IRET_REGS pushq $~(\num) .Lcommon_\sym: @@ -780,7 +780,7 @@ ENTRY(\sym) UNWIND_HINT_REGS indirect=1 call\do_sym /* rdi points to pt_regs */ jmp ret_from_intr -END(\sym) +SYM_CODE_END(\sym) _ASM_NOKPROBE(\sym) .endm @@ -879,7 +879,7 @@ apicinterrupt IRQ_WORK_VECTOR irq_work_interrupt smp_irq_work_interrupt * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS. */ .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 -ENTRY(\sym) +SYM_CODE_START(\sym) UNWIND_HINT_IRET_REGS offset=\has_error_code*8 /* Sanity check */ @@ -963,7 +963,7 @@ ENTRY(\sym) jmp error_exit .endif _ASM_NOKPROBE(\sym) -END(\sym) +SYM_CODE_END(\sym) .endm idtentry divide_error do_divide_error has_error_code=0 @@ -1080,7 +1080,7 @@ SYM_CODE_END(xen_do_hypervisor_callback) * We distinguish between categories by comparing each saved segment register * with its current contents: any discrepancy means we in category 1. */ -ENTRY(xen_failsafe_callback) +SYM_CODE_START(xen_failsafe_callback) UNWIND_HINT_EMPTY movl%ds, %ecx cmpw%cx, 0x10(%rsp) @@ -1110,7 +1110,7 @@ ENTRY(xen_failsafe_callback) PUSH_AND_CLEAR_REGS
[Xen-devel] [PATCH v7 20/28] x86/asm: make some functions local
There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, we mark them "static". In assembly,
annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
ENDPROC to SYM_{FUNC,CODE}_END too). Whether we use FUNC or CODE,
depends on whether ENDPROC or END was used for a particular function
before.
Signed-off-by: Jiri Slaby
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: x...@kernel.org
Cc: Matt Fleming
Cc: Ard Biesheuvel
Cc: linux-...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
arch/x86/boot/compressed/efi_thunk_64.S | 8
arch/x86/entry/entry_64.S | 21 +++--
arch/x86/lib/copy_page_64.S | 4 ++--
arch/x86/lib/memcpy_64.S| 12 ++--
arch/x86/lib/memset_64.S| 8
arch/x86/platform/efi/efi_thunk_64.S| 12 ++--
arch/x86/platform/pvh/head.S| 4 ++--
7 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/arch/x86/boot/compressed/efi_thunk_64.S
b/arch/x86/boot/compressed/efi_thunk_64.S
index d66000d23921..31312070db22 100644
--- a/arch/x86/boot/compressed/efi_thunk_64.S
+++ b/arch/x86/boot/compressed/efi_thunk_64.S
@@ -99,12 +99,12 @@ ENTRY(efi64_thunk)
ret
ENDPROC(efi64_thunk)
-ENTRY(efi_exit32)
+SYM_FUNC_START_LOCAL(efi_exit32)
movqfunc_rt_ptr(%rip), %rax
push%rax
mov %rdi, %rax
ret
-ENDPROC(efi_exit32)
+SYM_FUNC_END(efi_exit32)
.code32
/*
@@ -112,7 +112,7 @@ ENDPROC(efi_exit32)
*
* The stack should represent the 32-bit calling convention.
*/
-ENTRY(efi_enter32)
+SYM_FUNC_START_LOCAL(efi_enter32)
movl$__KERNEL_DS, %eax
movl%eax, %ds
movl%eax, %es
@@ -172,7 +172,7 @@ ENTRY(efi_enter32)
btsl$X86_CR0_PG_BIT, %eax
movl%eax, %cr0
lret
-ENDPROC(efi_enter32)
+SYM_FUNC_END(efi_enter32)
.data
.balign 8
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 6b60e5e6531c..2fe59c693732 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1046,7 +1046,8 @@ idtentry hypervisor_callback xen_do_hypervisor_callback
has_error_code=0
* existing activation in its critical region -- if so, we pop the current
* activation and restart the handler using the previous one.
*/
-ENTRY(xen_do_hypervisor_callback) /*
do_hypervisor_callback(struct *pt_regs) */
+/* do_hypervisor_callback(struct *pt_regs) */
+SYM_CODE_START_LOCAL(xen_do_hypervisor_callback)
/*
* Since we don't modify %rdi, evtchn_do_upall(struct *pt_regs) will
@@ -1064,7 +1065,7 @@ ENTRY(xen_do_hypervisor_callback) /*
do_hypervisor_callback(struct *pt_regs) */
callxen_maybe_preempt_hcall
#endif
jmp error_exit
-END(xen_do_hypervisor_callback)
+SYM_CODE_END(xen_do_hypervisor_callback)
/*
* Hypervisor uses this for application faults while it executes.
@@ -1155,7 +1156,7 @@ idtentry machine_checkdo_mce
has_error_code=0paranoid=1
* Use slow, but surefire "are we in kernel?" check.
* Return: ebx=0: need swapgs on exit, ebx=1: otherwise
*/
-ENTRY(paranoid_entry)
+SYM_CODE_START_LOCAL(paranoid_entry)
UNWIND_HINT_FUNC
cld
PUSH_AND_CLEAR_REGS save_ret=1
@@ -1182,7 +1183,7 @@ ENTRY(paranoid_entry)
SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%rax save_reg=%r14
ret
-END(paranoid_entry)
+SYM_CODE_END(paranoid_entry)
/*
* "Paranoid" exit path from exception stack. This is invoked
@@ -1196,7 +1197,7 @@ END(paranoid_entry)
*
* On entry, ebx is "no swapgs" flag (1: don't need swapgs, 0: need it)
*/
-ENTRY(paranoid_exit)
+SYM_CODE_START_LOCAL(paranoid_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF_DEBUG
@@ -1213,12 +1214,12 @@ ENTRY(paranoid_exit)
RESTORE_CR3 scratch_reg=%rbx save_reg=%r14
.Lparanoid_exit_restore:
jmp restore_regs_and_return_to_kernel
-END(paranoid_exit)
+SYM_CODE_END(paranoid_exit)
/*
* Save all registers in pt_regs, and switch GS if needed.
*/
-ENTRY(error_entry)
+SYM_CODE_START_LOCAL(error_entry)
UNWIND_HINT_FUNC
cld
PUSH_AND_CLEAR_REGS save_ret=1
@@ -1302,16 +1303,16 @@ ENTRY(error_entry)
callfixup_bad_iret
mov %rax, %rsp
jmp .Lerror_entry_from_usermode_after_swapgs
-END(error_entry)
+SYM_CODE_END(error_entry)
-ENTRY(error_exit)
+SYM_CODE_START_LOCAL(error_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
testb $3, CS(%rsp)
jz retint_kernel
jmp retint_user
-END(error_exit)
+SYM_CODE_END(error_exit)
/*
* Runs on exception stack. Xen PV does not go through this path at all,
diff --git a/arch/x86/lib/copy_page_64.S b/arch/x86/lib/copy_page_64.S
index fd2d09afa097..f505870bd93b 100644
---
Re: [Xen-devel] [Xen 4.12 bug] HVM/PVH boot confusion
On Wed, Jan 30, 2019 at 12:30:44PM +, Andrew Cooper wrote: > >> There are at least two bugs here. > >> > >> 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH > >> entrypoint must not mandate its existence, because there are releases of > >> the domain builder which don't provide it. > > The inner Xen, in this case, can fall back to scanning low 1MB memory > > for RSDP. > > Agreed. > > > > >> 2) The HVM/PVH boot confusion. This think this is a still-outstanding > >> bug around the broken assumption that the hvmloader binary speaks the > >> PVH protocol without advertising itself appropriately (I really regret > >> not objecting to those patches before they went in). At the least, that > >> needs fixing by putting a proper ELF note in hvmloader, and the domain > >> builder needs to be updated to build all PVH-boot-ABI images consistently. > > Do you expect users to drop an arbitrary hvmloader into an arbitrary > > version of Xen and they continue to work? > > This is hard to answer. HVMLoader specifically, perhaps not. After > all, it does link unstable libraries from tools/ That's my thought as well. To me it would be nice to make hvmloader a proper PVH binary, but this task's priority is rather low, because I consider it internal to Xen. > > That said, how we boot guests is an ABI, and this should be kept in mind > when making changes. Sure. I agree. I think we've been mindful in that regard. Domain builder code isn't perfect, but it doesn't remove or add to the ABI willy-nilly. Long term I agree with Roger -- things can be streamlined. Your use case is rather special. At this moment I think if we fix issue bug #1 you should be good to go? Wei. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.9-testing test] 132484: regressions - FAIL
>>> On 29.01.19 at 19:55, wrote: > On 29/01/2019 18:49, osstest service owner wrote: >> flight 132484 xen-4.9-testing real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/132484/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-xtf-amd64-amd64-1 69 xtf/test-hvm64-xsa-278 fail REGR. vs. >> 130954 > > This is the XSA-278 PoC noticing that c/s > 75ce36eb72cb93e8a3c9f60fd5e697067921d712 hasn't been backported. I've just added this to the pending set, but I have to admit that it wasn't clear to me at all that this would be needed on the stable trees. There was a remark about backportability in the submission, but this didn't mean to me that it's kind of imperative to have. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.12 1/8] dom0/pvh: align allocation and mapping order to start address
On Wed, Jan 30, 2019 at 11:36:39AM +0100, Roger Pau Monne wrote:
> Due to the recent changes in the iommu mapping logic, the start
> addresses provided need to be aligned to the order intended to be
> mapped.
>
Can you reference some commits here? What would happen if the address is
not aligned?
> dom0 PVH domain builder didn't take this into account when populating
> the p2m, fix this by making sure the order is chosen so that the start
> address is aligned to it.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
> ---
> Without this patch trying to create a PVH dom0 will trigger an assert
> on certain hardware depending on the memory map.
> ---
> xen/arch/x86/hvm/dom0_build.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index 51cf490811..a571d15c13 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -152,6 +152,8 @@ static int __init pvh_populate_memory_range(struct domain
> *d,
>
> order = get_order_from_pages(end - start + 1);
> order = min(order ? order - 1 : 0, max_order);
> +/* The order allocated and populated must be aligned to the address.
> */
> +order = min(order, start ? find_first_set_bit(start) : MAX_ORDER);
Isn't max_order better here?
> page = alloc_domheap_pages(d, order, dom0_memflags | MEMF_no_scrub);
> if ( page == NULL )
> {
> --
> 2.20.1
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen 4.12 bug] HVM/PVH boot confusion
On 30/01/2019 11:59, Wei Liu wrote: > On Tue, Jan 29, 2019 at 07:49:51PM +, Andrew Cooper wrote: >> Hello, >> >> Given the following vm.cfg file: >> >> name="vm" >> type="hvm" >> >> vcpus=4 >> memory=1024 >> >> firmware_override="/root/xen-syms" >> >> kernel="/boot/vmlinuz-4.4-xen" >> ramdisk="/boot/initrd-4.4.0+10.img" >> >> cmdline="console=xen,pv dom0=pv --- earlyprintk=xen" >> > What is your use case here? If you want to use the shim, why don't you > put pvshim=1 directly? I'm testing a corner case. > >> Xen crashes with the following trace: >> >> (d15) (XEN) Xen BUG at pvh-boot.c:82 >> (d15) (XEN) [ Xen-4.12.0-rc x86_64 debug=y Not tainted ] >> (d15) (XEN) CPU:0 >> (d15) (XEN) RIP:e008:[] pvh_init+0x27d/0x2fe >> >> (d15) (XEN) Xen call trace: >> (d15) (XEN)[] pvh_init+0x27d/0x2fe >> (d15) (XEN)[] __start_xen+0x14c/0x28f6 >> (d15) (XEN)[] __high_start+0x53/0x55 >> (d15) (XEN) >> (d15) (XEN) >> (d15) (XEN) >> (d15) (XEN) Panic on CPU 0: >> (d15) (XEN) Xen BUG at pvh-boot.c:82 >> (d15) (XEN) >> >> The problem is that Xen is started at its PVH entrypoint (contrary to >> the instructions in the vm config file), and Xen unconditionally expects >> RSDP to be passed. >> >> There are at least two bugs here. >> >> 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH >> entrypoint must not mandate its existence, because there are releases of >> the domain builder which don't provide it. > The inner Xen, in this case, can fall back to scanning low 1MB memory > for RSDP. Agreed. > >> 2) The HVM/PVH boot confusion. This think this is a still-outstanding >> bug around the broken assumption that the hvmloader binary speaks the >> PVH protocol without advertising itself appropriately (I really regret >> not objecting to those patches before they went in). At the least, that >> needs fixing by putting a proper ELF note in hvmloader, and the domain >> builder needs to be updated to build all PVH-boot-ABI images consistently. > Do you expect users to drop an arbitrary hvmloader into an arbitrary > version of Xen and they continue to work? This is hard to answer. HVMLoader specifically, perhaps not. After all, it does link unstable libraries from tools/ That said, how we boot guests is an ABI, and this should be kept in mind when making changes. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RT Xen on ARM - R-Car series
Hi, On 30/01/2019 20:23, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote: My e-mail client thinks the e-mail was sent from the future. Can you make sure your timezone is set correctly? [ 0.682996] CPU features: detected feature: Kernel page table isolation (KPTI) (XEN) p2m.c:1844: d0v1: Failed to walk page-table va 0x800013f59c57 (XEN) p2m.c:1844: d0v2: Failed to walk page-table va 0x800013f70c57 (XEN) p2m.c:1844: d0v1: Failed to walk page-table va 0x800013f59c48 (XEN) p2m.c:1844: d0v2: Failed to walk page-table va 0x800013f70c48 Is this normal. Could the error have anything to do with me using the dom0_max_vpcus=4 bootarg for Xen? No this is a unknown benign issue when using KPTI kernel on Xen (see [1]). I still haven't found time to fix it and would appreciate help to solve the issue. Cheers, [1] https://lists.xen.org/archives/html/xen-devel/2018-03/msg00223.html -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen 4.12 bug] HVM/PVH boot confusion
On Wed, Jan 30, 2019 at 12:25:20PM +0100, Roger Pau Monné wrote: > Adding Anthony who likely knows more about all this since it's closely > related to QEMU. > > On Tue, Jan 29, 2019 at 07:49:51PM +, Andrew Cooper wrote: > > Hello, > > > > Given the following vm.cfg file: > > > > name="vm" > > type="hvm" > > > > vcpus=4 > > memory=1024 > > > > firmware_override="/root/xen-syms" > > > > kernel="/boot/vmlinuz-4.4-xen" > > ramdisk="/boot/initrd-4.4.0+10.img" > > I know very little about direct kernel booting with HVM, but I assume > using firmware_override gets rid of hvmloader and the BIOS/UEFI > payload plus the option rom to direct boot into a Linux kernel? In HVM direct boot case, SeaBIOS takes care of loading the kernel and booting it. QEMU communicate with SeaBIOS via the firmware config interface (fw_cfg). Setting firmware_override only replace hvmloader by that other elf. > So basically the module list is `mod[0] = kernel` and `mod[1] = > ramdisk`? No, the module list isn't magically change, I don't think. The toolstack is still going to but seabios as one of the module (probably only, I forgot), but there isn't a reason to put the kernel/ramdisk in there. In the config above, xen can be a kernel at most (I think), but certainly not a firmware. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] arm: gic-v3: clear GICR active interrupts
Hi
Replying to this thread again.
On 22/01/2019 10:54, Julien Grall wrote:
Hi Peng,
The commit title is a bit confusing. It suggests that all interrupts should be
deactivated at boot, however you are only deactivating the SGIs.
On 1/22/19 2:35 AM, Peng Fan wrote:
On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because hardware design.
What do you mean by hardware design? Is it a defect?
The gic-v3 controller is configured with EOImode to 1, so during xen
reboot, GIC_SGI_CALL_FUNCTION interrupt from CPU0 to other CPUs, but
stop_cpu never return, that means other CPUs have no chance to
deactive the interrupt. During xen booting again, CPU0 will issue
GIC_SGI_CALL_FUNCTION to other CPUs. Because GIC_SGI_CALL_FUNCTION of
other CPUs are active during the last reboot, interrupts could not be
triggered unless we deactive the interrupt first.
From the description here, I think it not very sane to go to sleep with an
interrupt activate.
It looks like I was wrong here. There are case where you can't avoid that (see
my answer to your other patch) and the boot code cannot rely on the activate
state of interrupt. So they have to be cleaned at boot.
This also have to be done for PPI and SPIs. Peng, would you mind to do that
patch?
A better solution would be to move the deactivation earlier on in do_sgi (maybe
after eoi_irq) so we call stop_cpu() with all interrupts disabled.
So let's deactive the interrupts during GICv3 initialization to fix
s/deactivate/
this issue.
Similarly to the commit title, you wrote the commit message very generically.
Signed-off-by: Peng Fan
---
xen/arch/arm/gic-v3.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 6fbc106757..643d4a33f0 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -824,8 +824,12 @@ static int gicv3_cpu_init(void)
priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI << 8 |
GIC_PRI_IPI);
for (i = 0; i < NR_GIC_SGI; i += 4)
+ {
writel_relaxed(priority,
GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + (i / 4) * 4);
+ writel_relaxed(0x,
+ GICD_RDIST_SGI_BASE + GICR_ICACTIVER0 + (i / 4) * 4);
Each ICACTIVER0 registers hold the active bit for 32 interrupts. However, this
code assumes the register only hold 4 interrupts. So this will write to unwanted
area.
There are only 16 SGIs, so it fits in one write to ICACTIVER0. As wrote above,
you also need to deactivate the PPIs. So the following should be enough:
/*
* The activate state is unknown at boot, so make sure all SGIs and PPIs are
* de-activated.
*/
writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0);
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen 4.12 bug] HVM/PVH boot confusion
On Tue, Jan 29, 2019 at 07:49:51PM +, Andrew Cooper wrote: > Hello, > > Given the following vm.cfg file: > > name="vm" > type="hvm" > > vcpus=4 > memory=1024 > > firmware_override="/root/xen-syms" > > kernel="/boot/vmlinuz-4.4-xen" > ramdisk="/boot/initrd-4.4.0+10.img" > > cmdline="console=xen,pv dom0=pv --- earlyprintk=xen" > What is your use case here? If you want to use the shim, why don't you put pvshim=1 directly? > Xen crashes with the following trace: > > (d15) (XEN) Xen BUG at pvh-boot.c:82 > (d15) (XEN) [ Xen-4.12.0-rc x86_64 debug=y Not tainted ] > (d15) (XEN) CPU:0 > (d15) (XEN) RIP:e008:[] pvh_init+0x27d/0x2fe > > (d15) (XEN) Xen call trace: > (d15) (XEN)[] pvh_init+0x27d/0x2fe > (d15) (XEN)[] __start_xen+0x14c/0x28f6 > (d15) (XEN)[] __high_start+0x53/0x55 > (d15) (XEN) > (d15) (XEN) > (d15) (XEN) > (d15) (XEN) Panic on CPU 0: > (d15) (XEN) Xen BUG at pvh-boot.c:82 > (d15) (XEN) > > The problem is that Xen is started at its PVH entrypoint (contrary to > the instructions in the vm config file), and Xen unconditionally expects > RSDP to be passed. > > There are at least two bugs here. > > 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH > entrypoint must not mandate its existence, because there are releases of > the domain builder which don't provide it. The inner Xen, in this case, can fall back to scanning low 1MB memory for RSDP. > > 2) The HVM/PVH boot confusion. This think this is a still-outstanding > bug around the broken assumption that the hvmloader binary speaks the > PVH protocol without advertising itself appropriately (I really regret > not objecting to those patches before they went in). At the least, that > needs fixing by putting a proper ELF note in hvmloader, and the domain > builder needs to be updated to build all PVH-boot-ABI images consistently. Do you expect users to drop an arbitrary hvmloader into an arbitrary version of Xen and they continue to work? Wei. > > I don't have time to look into this at the moment, if anyone fancies > trying to fix these issues. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 132575: regressions - FAIL
flight 132575 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/132575/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 132422 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 132422 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 132422 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132422 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 132422 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 132422 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 132422 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 132422 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 132422 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 132422 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 132422 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 132422 test-amd64-i386-xl-pvshim12 guest-start fail 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-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-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-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 9d8c1d1814b744d0fb41085463db5d8ae025607e baseline version: xen 08b908ba63dee8bc313983c5e412852cbcbcda85 Last test of basis 132422 2019-01-23 08:09:34 Z7 days Failing since132457 2019-01-24 14:59:50 Z5 days5 attempts Testing same since 132575 2019-01-29 17:09:29 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Andrii Anisov George Dunlap Jan Beulich Julien Grall Norbert Manthey Roger Pau Monne Roger Pau Monné Wei Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt
Re: [Xen-devel] [PATCH for-4.12] arm: gic: deactivate sgi immediately after eoi
On 30/01/2019 01:21, Peng Fan wrote: Hi Julien Hi Peng, -Original Message- From: Julien Grall [mailto:julien.gr...@arm.com] Sent: 2019年1月29日 23:57 To: Peng Fan ; sstabell...@kernel.org; jgr...@suse.com Cc: xen-devel@lists.xenproject.org; Andre Przywara Subject: Re: [PATCH for-4.12] arm: gic: deactivate sgi immediately after eoi (+ Andre) Hi Peng, On 24/01/2019 12:43, Peng Fan wrote: On i.MX8, we implemented partition reboot which means Cortex-A reboot will not impact M4 cores and System control Unit core. However GICv3 is not reset because we also need to support A72 Cluster reboot without affecting A53 Cluster. How about the other interrupts? For instance, it would be theoretically possible to have a PPI/SPI active and receive the order to turn it off. Is this going to be an issue? Currently we only met this issue when doing Xen reboot, because halt_this_cpu never return. For other interrupts, I think they are deactivated properly. I don't think so, IPIs has an higher priority than all the other interrupt. So you may receive the IPI while handling another interrupts. This will leave the interrupts activated while turning off the processor. I spoke with Marc Z. (GIC expert) today regarding rebooting/kexecing with interrupts activated. He said this is a valid case and the boot code should take care of de-activating all interrupts. So your first patch might be more suitable here. Sorry for the inconvenience. I will comment back on the first one again. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
