Re: [Xen-devel] [PATCH 20/34] xen: convert put_page() to put_user_page*()

On 8/1/19 9:36 PM, Juergen Gross wrote: On 02.08.19 04:19, john.hubb...@gmail.com wrote: From: John Hubbard ... diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 2f5ce7230a43..29e461dbee2d 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -611,15 +611,10 @@

[Xen-devel] [linux-4.19 test] 139592: regressions - FAIL

flight 139592 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/139592/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail REGR. vs. 129313

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

flight 139614 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/139614/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 83d6207f99021ac9b2990fc9d66bab3cb3ae5f26 baseline version: ovmf

Re: [Xen-devel] "CPU N still not dead..." messages during microcode update stage of boot when smt=0

On 02.08.19 04:15, Andy Smith wrote: Hi, On Mon, Jul 22, 2019 at 01:06:03PM +0100, Andrew Cooper wrote: On 22/07/2019 10:16, Jan Beulich wrote: On 21.07.2019 22:06, Andy Smith wrote: (XEN) Adding cpu 1 to runqueue 0 (XEN) CPU 1 still not dead... (XEN) CPU 1 still not dead... (XEN) CPU 1

Re: [Xen-devel] [PATCH 20/34] xen: convert put_page() to put_user_page*()

On 02.08.19 04:19, john.hubb...@gmail.com wrote: From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit

Re: [Xen-devel] [PATCH 00/34] put_user_pages(): miscellaneous call sites

On 8/1/19 7:16 PM, john.hubb...@gmail.com wrote: > From: John Hubbard > > Hi, > > These are best characterized as miscellaneous conversions: many (not all) > call sites that don't involve biovec or iov_iter, nor mm/. It also leaves > out a few call sites that require some more work. These are

[Xen-devel] [PATCH 00/34] put_user_pages(): miscellaneous call sites

From: John Hubbard Hi, These are best characterized as miscellaneous conversions: many (not all) call sites that don't involve biovec or iov_iter, nor mm/. It also leaves out a few call sites that require some more work. These are mostly pretty simple ones. It's probably best to send all of

[Xen-devel] [PATCH 28/34] mm/madvise.c: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 32/34] goldfish_pipe: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 31/34] nfs: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 23/34] uprobes: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 25/34] mm/frame_vector.c: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 14/34] oradax: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 02/34] net/rds: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 01/34] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()

From: John Hubbard Provide more capable variation of put_user_pages_dirty_lock(), and delete put_user_pages_dirty(). This is based on the following: 1. Lots of call sites become simpler if a bool is passed into put_user_page*(), instead of making the call site choose which put_user_page*()

[Xen-devel] [PATCH 22/34] orangefs: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 27/34] mm/memory.c: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 33/34] kernel/events/core.c: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 06/34] drm/i915: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 26/34] mm/gup_benchmark.c: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 16/34] drivers/tee: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 10/34] genwqe: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 11/34] scif: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 01/34] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()

From: John Hubbard Provide more capable variation of put_user_pages_dirty_lock(), and delete put_user_pages_dirty(). This is based on the following: 1. Lots of call sites become simpler if a bool is passed into put_user_page*(), instead of making the call site choose which put_user_page*()

[Xen-devel] [PATCH 18/34] fbdev/pvr2fb: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 08/34] media/ivtv: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 19/34] fsl_hypervisor: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 03/34] net/ceph: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 29/34] mm/process_vm_access.c: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 13/34] rapidio: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 15/34] staging/vc04_services: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 24/34] futex: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 21/34] fs/exec.c: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 12/34] vmci: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 05/34] drm/etnaviv: convert release_pages() to put_user_pages()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 09/34] media/v4l2-core/mm: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 07/34] drm/radeon: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 30/34] crypt: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 04/34] x86/kvm: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder versions"). Cc:

[Xen-devel] [PATCH 02/34] net/rds: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 34/34] fs/binfmt_elf: convert put_page() to put_user_page*()

From: Ira Weiny For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 20/34] xen: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 17/34] vfio: convert put_page() to put_user_page*()

From: John Hubbard For pages that were retained via get_user_pages*(), release those pages via the new put_user_page*() routines, instead of via put_page() or release_pages(). This is part a tree-wide conversion, as described in commit fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder

[Xen-devel] [PATCH 00/34] put_user_pages(): miscellaneous call sites

From: John Hubbard Hi, These are best characterized as miscellaneous conversions: many (not all) call sites that don't involve biovec or iov_iter, nor mm/. It also leaves out a few call sites that require some more work. These are mostly pretty simple ones. It's probably best to send all of

Re: [Xen-devel] "CPU N still not dead..." messages during microcode update stage of boot when smt=0

Hi, On Mon, Jul 22, 2019 at 01:06:03PM +0100, Andrew Cooper wrote: > On 22/07/2019 10:16, Jan Beulich wrote: > > On 21.07.2019 22:06, Andy Smith wrote: > >> (XEN) Adding cpu 1 to runqueue 0 > >> (XEN) CPU 1 still not dead... > >> (XEN) CPU 1 still not dead... > >> (XEN) CPU 1 still not dead... >

[Xen-devel] [xen-unstable test] 139589: regressions - FAIL

flight 139589 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/139589/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 139563 Tests which did

[Xen-devel] [xen-unstable-smoke test] 139607: tolerable all pass - PUSHED

flight 139607 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/139607/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] [linux-linus test] 139584: regressions - FAIL

flight 139584 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/139584/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580

[Xen-devel] [ovmf test] 139600: regressions - FAIL

flight 139600 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/139600/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 139571 build-i386-xsm

Re: [Xen-devel] Criteria / validation proposal: drop Xen

> On 1. Aug 2019, at 18:27, Ben Cotton wrote: > > On Thu, Aug 1, 2019 at 3:27 AM Elnikety, Eslam wrote: >> >> But t3 is not Xen. >> > That's a good reason to not use it. :-) I picked it to be a small, > cheap instance that would represent a potential use case. Is the t2 > family Xen? Or the

Re: [Xen-devel] [RFC] Generating Go bindings for libxl

> With that said, what are your expectations for the generated Go code at this > point? > Do you think we should try to generate the pieces that call into libxl? Or, > do you think > the code generation should be limited to the structs and boiler-plate C <-> > Go "type > marshaling?" [...] >

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.19 18:46, Jan Beulich wrote: On 01.08.2019 16:54, Oleksandr wrote: On 01.08.19 17:34, Jan Beulich wrote: On 01.08.2019 16:31, Oleksandr wrote:    This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may request    deferred probing (returns -EPROBE_DEFER)

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

On Thu, Aug 1, 2019 at 1:16 AM Roger Pau Monné wrote: > > On Wed, Jul 31, 2019 at 02:03:24PM -0700, Roman Shaposhnik wrote: > > On Wed, Jul 31, 2019 at 12:46 PM Andrew Cooper > > wrote: > > > > > > On 31/07/2019 20:35, Roman Shaposhnik wrote: > > > > On Wed, Jul 31, 2019 at 1:43 AM Roger Pau

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

On Thu, Aug 1, 2019 at 1:45 AM Roger Pau Monné wrote: > > On Wed, Jul 31, 2019 at 12:30:04PM -0700, Roman Shaposhnik wrote: > > On Wed, Jul 31, 2019 at 1:36 AM Roger Pau Monné > > wrote: > > > > > > On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote: > > > > Sorry -- got a bit

Re: [Xen-devel] [PATCH v8 00/16] improve late microcode loading

On 01/08/2019 11:22, Chao Gao wrote: > This series includes below changes: > 1. Patch 1: always read microcode revision at boot time > 2. Patch 2: an userspace tool for late microcode update To get things started, I've committed these two changes.  I'm afraid I don't have time immediately to

Re: [Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

On Thu, Aug 1, 2019 at 9:01 AM Juergen Gross wrote: > > This email only tracks big items for xen.git tree. Please reply for items you > would like to see in 4.13 so that people have an idea what is going on and > prioritise accordingly. > > You're welcome to provide description and use cases of

Re: [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev

On Thu, Aug 1, 2019 at 10:44 AM Andrew Cooper wrote: > > On 01/08/2019 18:35, Roman Shaposhnik wrote: > > On Thu, Aug 1, 2019 at 3:30 AM Anthony PERARD > > wrote: > >> On Wed, Jul 31, 2019 at 01:11:22PM -0700, Roman Shaposhnik wrote: > >>> Hi! > >> Hi Roman, > >> > >> Thanks for the bug report!

Re: [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev

On 01/08/2019 18:35, Roman Shaposhnik wrote: > On Thu, Aug 1, 2019 at 3:30 AM Anthony PERARD > wrote: >> On Wed, Jul 31, 2019 at 01:11:22PM -0700, Roman Shaposhnik wrote: >>> Hi! >> Hi Roman, >> >> Thanks for the bug report! >> >> That bug (technical debt really) was fixed in QEMU 4.0 (so will

Re: [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev

On Thu, Aug 1, 2019 at 3:30 AM Anthony PERARD wrote: > > On Wed, Jul 31, 2019 at 01:11:22PM -0700, Roman Shaposhnik wrote: > > Hi! > > Hi Roman, > > Thanks for the bug report! > > That bug (technical debt really) was fixed in QEMU 4.0 (so will be fixed > in Xen 4.13). It's a series of patch with

[Xen-devel] [libvirt test] 139585: tolerable all pass - PUSHED

flight 139585 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/139585/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139551 test-armhf-armhf-libvirt-raw 13

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

On Thu, Aug 1, 2019 at 5:50 PM Volodymyr Babchuk wrote: > >> In this case we also can declare and use intrs[] in the same way. > > > > There is no guarantee the index in irq will match intrs[...]. So you > > need to keep them hardcoded in the latter case. > Oh, right. I don't like the idea of

Re: [Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

On 01/08/2019 17:00, Juergen Gross wrote: > == Hypervisor == > > * Improvements to domain creation (v2) > - Andrew Cooper This should probably be dropped.  Its not going to get a look in in the forseeable future, and is in the position of gaining incremental improvements anyway. > * Switch

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

On Thu, Aug 1, 2019 at 4:58 PM Julien Grall wrote: > > > > On 01/08/2019 14:57, Julien Grall wrote: > >>> +unsigned int irq[MAX_TIMER_PPI]; > >> As I said in the previous version, you are wasting stack space > >> there. Also, this is misleading. When I see array of 4 items, I expect > >>

Re: [Xen-devel] Xen Coding style and clang-format

Hi Tamas, On Thu, Aug 1, 2019 at 6:58 PM Tamas K Lengyel wrote: > > On Thu, Aug 1, 2019 at 4:06 AM Viktor Mitin wrote: > > > > On Wed, Jul 31, 2019 at 8:05 PM Viktor Mitin > > wrote: > > > > > > On Wed, Jul 31, 2019 at 7:27 PM Lars Kurth > > > wrote: > > > > > > > Viktor: thank you for

Re: [Xen-devel] Criteria / validation proposal: drop Xen

On Thu, Aug 1, 2019 at 3:27 AM Elnikety, Eslam wrote: > > But t3 is not Xen. > That's a good reason to not use it. :-) I picked it to be a small, cheap instance that would represent a potential use case. Is the t2 family Xen? Or the m5? I think it makes sense to write the requirement as "the

[Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

This email only tracks big items for xen.git tree. Please reply for items you would like to see in 4.13 so that people have an idea what is going on and prioritise accordingly. You're welcome to provide description and use cases of the feature you're working on. = Timeline = We now adopt a

Re: [Xen-devel] Xen Coding style and clang-format

On Thu, Aug 1, 2019 at 4:06 AM Viktor Mitin wrote: > > On Wed, Jul 31, 2019 at 8:05 PM Viktor Mitin > wrote: > > > > On Wed, Jul 31, 2019 at 7:27 PM Lars Kurth wrote: > > > > > Viktor: thank you for spending time on this > > > > > > I added an item to community call tomorrow and CC'ed you in

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.2019 16:54, Oleksandr wrote: > On 01.08.19 17:34, Jan Beulich wrote: >> On 01.08.2019 16:31, Oleksandr wrote: >>>    This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which >>> may request >>>    deferred probing (returns -EPROBE_DEFER) depending on what device will >>>

[Xen-devel] [ovmf test] 139588: regressions - FAIL

flight 139588 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/139588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 139571 build-i386-xsm

Re: [Xen-devel] [PATCH] Adding Intel TXT maintainter

> On Jul 29, 2019, at 10:45, Jan Beulich wrote: > >> On 29.07.2019 16:39, Lukasz Hawrylko wrote: >> Support for Intel TXT has orphaned status right now because >> no active maintainter is listed. Adding myself as active maintainter, >> so it could be reverted to supported state. > > Which you

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.19 17:34, Jan Beulich wrote: Hi Jan On 01.08.2019 16:31, Oleksandr wrote:  This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may request  deferred probing (returns -EPROBE_DEFER) depending on what device will be probed the first  (Root device must be

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

> > It is not explicitly written in the wiki page. But it is implied in a few > > places such as in the section "Providing a git branch", "Using git > > send-email alone". > > You are right. That should be made explicit. I think you are the only person > in years that sent a series without

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Julien Grall writes: > Hi Volodymyr, > > On 01/08/2019 15:07, Volodymyr Babchuk wrote: >> >> Hi Julien, >> >> Julien Grall writes: >> >>> Hi, >>> >>> On 01/08/2019 14:49, Volodymyr Babchuk wrote: Viktor Mitin writes: > Functions make_timer_node and make_timer_domU_node are

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.2019 16:31, Oleksandr wrote: >  This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may > request >  deferred probing (returns -EPROBE_DEFER) depending on what device will be > probed the first >  (Root device must be registered before Cache devices. If not the

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On 01.08.19 17:31, Oleksandr wrote: Hello, Hi, Roger I think it would help if you describe why such error code is needed by Xen and how it would be used.  This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may request  deferred probing (returns -EPROBE_DEFER)

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

Hello, Hi, Roger I think it would help if you describe why such error code is needed by Xen and how it would be used.  This is needed for the upcoming V2 of the IPMMU driver (ARM) [1] which may request  deferred probing (returns -EPROBE_DEFER) depending on what device will be probed

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Hi Volodymyr, On 01/08/2019 15:07, Volodymyr Babchuk wrote: Hi Julien, Julien Grall writes: Hi, On 01/08/2019 14:49, Volodymyr Babchuk wrote: Viktor Mitin writes: Functions make_timer_node and make_timer_domU_node are quite similar. So it is better to consolidate them to avoid

Re: [Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

On Thu, Aug 01, 2019 at 05:10:08PM +0300, Oleksandr wrote: > Hello all. > > What is the proper location to place Linux error code (-EPROBE_DEFER) in > Xen? > https://elixir.bootlin.com/linux/v5.3-rc2/source/include/linux/errno.h#L19 > > ... > Although that error is going to be used by Arm code

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

> On 1 Aug 2019, at 15:02, Julien Grall wrote: > > Hi Lars, > > On 01/08/2019 14:59, Lars Kurth wrote: >>> On 1 Aug 2019, at 13:41, Julien Grall >> > wrote: >>> >>> Hi Viktor, >>> >>> On 01/08/2019 13:26, Viktor Mitin wrote: Hi Julien and Volodymyr, On

[Xen-devel] [Question] Proper location for Linux error code (-EPROBE_DEFER) in Xen

Hello all. What is the proper location to place Linux error code (-EPROBE_DEFER) in Xen? https://elixir.bootlin.com/linux/v5.3-rc2/source/include/linux/errno.h#L19 ... Although that error is going to be used by Arm code the first, I feel it should be somewhere in common place as it is not

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Hi Julien, Julien Grall writes: > Hi, > > On 01/08/2019 14:49, Volodymyr Babchuk wrote: >> >> Viktor Mitin writes: >> >>> Functions make_timer_node and make_timer_domU_node are quite similar. >>> So it is better to consolidate them to avoid discrepancy. >>> The main difference between the

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

Hi Lars, On 01/08/2019 14:59, Lars Kurth wrote: On 1 Aug 2019, at 13:41, Julien Grall > wrote: Hi Viktor, On 01/08/2019 13:26, Viktor Mitin wrote: Hi Julien and Volodymyr, On Wed, Jul 31, 2019 at 3:52 PM Julien Grall > wrote: Hi,

[Xen-devel] [qemu-mainline test] 139573: regressions - FAIL

flight 139573 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/139573/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 139300

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

> On 1 Aug 2019, at 13:41, Julien Grall wrote: > > Hi Viktor, > > On 01/08/2019 13:26, Viktor Mitin wrote: >> Hi Julien and Volodymyr, >> On Wed, Jul 31, 2019 at 3:52 PM Julien Grall wrote: >>> >>> Hi, >>> > It is recommended (and probably required, but I can't find exact place >

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

On 01/08/2019 14:57, Julien Grall wrote: Hi, On 01/08/2019 14:49, Volodymyr Babchuk wrote: Viktor Mitin writes: Functions make_timer_node and make_timer_domU_node are quite similar. So it is better to consolidate them to avoid discrepancy. The main difference between the functions is the

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Hi, On 01/08/2019 14:49, Volodymyr Babchuk wrote: Viktor Mitin writes: Functions make_timer_node and make_timer_domU_node are quite similar. So it is better to consolidate them to avoid discrepancy. The main difference between the functions is the timer interrupts used. Keep the domU

Re: [Xen-devel] [PATCH v5 1/2] xen/arm: extend fdt_property_interrupts to support DomU

On 01/08/2019 14:33, Volodymyr Babchuk wrote: >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 4c8404155a..bc7d17dd2c 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -621,17 +621,20 @@ static void __init

Re: [Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Viktor Mitin writes: > Functions make_timer_node and make_timer_domU_node are quite similar. > So it is better to consolidate them to avoid discrepancy. > The main difference between the functions is the timer interrupts used. > > Keep the domU version for the compatible as it is simpler. > Mean

Re: [Xen-devel] [PATCH v5 1/2] xen/arm: extend fdt_property_interrupts to support DomU

Hi Viktor, Viktor Mitin writes: > Extend fdt_property_interrupts to deal with other domain than the hwdom. > > The prototype of fdt_property_interrupts() has been modified > to support both hwdom and domU in one function. > > The new prototype of make_timer_node function is required > since

[Xen-devel] [linux-4.19 test] 139569: regressions - FAIL

flight 139569 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/139569/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313

Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

On 01.08.19 14:16, Viktor Mitin wrote: On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich wrote: On 31.07.2019 18:20, Viktor Mitin wrote: How all those projects live without this issue? Perhaps they don't care? I do. What is the reason not to fix 'diff -p'? Is it not possible at all? I have

Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

On 01.08.2019 14:16, Viktor Mitin wrote: > I expected you to have some arguments why it cannot be fixed in the > diff or other tools. I don't follow: How does it matter here whether I have arguments towards (not) fixing diff etc? That's their maintainers' arguments, if any, not mine. All I know

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

Hi Viktor, On 01/08/2019 13:26, Viktor Mitin wrote: Hi Julien and Volodymyr, On Wed, Jul 31, 2019 at 3:52 PM Julien Grall wrote: Hi, It is recommended (and probably required, but I can't find exact place in the rules) to include cover letter if you are sending more that one patch in

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: extend fdt_property_interrupts

Hi Julien and Volodymyr, On Wed, Jul 31, 2019 at 3:52 PM Julien Grall wrote: > > Hi, > > >> It is recommended (and probably required, but I can't find exact place > >> in the rules) to include cover letter if you are sending more that one > >> patch in series. This will ease up review process,

Re: [Xen-devel] [RFC] xen: Add .astylerc for automated style-formatting

On Thu, Aug 1, 2019 at 10:40 AM Jan Beulich wrote: > > On 31.07.2019 18:20, Viktor Mitin wrote: > > How all those projects live without this issue? > > Perhaps they don't care? I do. > > > What is the reason not to fix 'diff -p'? Is it not possible at all? > > I have no idea, but I guess there's

[Xen-devel] [PATCH v5 2/2] xen/arm: consolidate make_timer_node and make_timer_domU_node

Functions make_timer_node and make_timer_domU_node are quite similar. So it is better to consolidate them to avoid discrepancy. The main difference between the functions is the timer interrupts used. Keep the domU version for the compatible as it is simpler. Mean do not copy platform's

[Xen-devel] [PATCH v5 0/2] xen/arm: Consolidate make_timer_node and make_timer_domU_node

Functions make_timer_node and make_timer_domU_node are quite similar, so it is better to consolidate them to avoid discrepancy. This patch series achives this goal in two steps: - Extend fdt_property_interrupts to deal with other domain than the hwdom. - Consolidate make_timer_node and

[Xen-devel] [PATCH v5 1/2] xen/arm: extend fdt_property_interrupts to support DomU

Extend fdt_property_interrupts to deal with other domain than the hwdom. The prototype of fdt_property_interrupts() has been modified to support both hwdom and domU in one function. The new prototype of make_timer_node function is required since make_timer_node calls fdt_property_interrupts

Re: [Xen-devel] [RFC 1/6] xen/arm: Re-enable interrupt later in the trap path

On Thu, 2019-08-01 at 09:45 +0300, Andrii Anisov wrote: > Hello Julien, > > On 30.07.19 23:10, Julien Grall wrote: > > > > In this series I think I need interrupts locked until I start > > > time accounting for hypervisor. Time accounting is started by > > > `tacc_head()` function. I prefer to

Re: [Xen-devel] [PATCH v8 02/16] x86/microcode: always collect_cpu_info() during boot

On 01/08/2019 11:22, Chao Gao wrote: > From: Sergey Dyasli > > Currently cpu_sig struct is not updated during boot if no microcode blob > is specified by "ucode=[| scan]". > > It will result in cpu_sig.rev being 0 which affects APIC's > check_deadline_errata() and retpoline_safe() functions. > >

  1   2   >