Re: [Xen-devel] [PATCH] read grubenv and set default from saved_entry or next_entry

On 2019-08-16 15:25, Steven Haigh wrote: On 2019-08-16 05:05, YOUNG, MICHAEL A. wrote: On Thu, 15 Aug 2019, Steven Haigh wrote: Having a bit of a look here My test system grubenv file has: # GRUB Environment Block saved_entry=0 kernelopts=root=UUID=5346b4d9-885f-4673-8aff-04a16bf1971a ro

Re: [Xen-devel] [PATCH] read grubenv and set default from saved_entry or next_entry

On 2019-08-16 05:05, YOUNG, MICHAEL A. wrote: On Thu, 15 Aug 2019, Steven Haigh wrote: Having a bit of a look here My test system grubenv file has: # GRUB Environment Block saved_entry=0 kernelopts=root=UUID=5346b4d9-885f-4673-8aff-04a16bf1971a ro rootflags=subvol=root selinux=0 rhgb

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

flight 140163 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/140163/ 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. 133580

[Xen-devel] [PATCH v6 8/8] xen/arm: add reserved-memory regions to the dom0 memory node

Reserved memory regions are automatically remapped to dom0. Their device tree nodes are also added to dom0 device tree. However, the dom0 memory node is not currently extended to cover the reserved memory regions ranges as required by the spec. This commit fixes it. Change make_memory_node to

[Xen-devel] [PATCH v6 6/8] xen/arm: handle reserved-memory in consider_modules and dt_unreserved_regions

reserved-memory regions overlap with memory nodes. The overlapping memory is reserved-memory and should be handled accordingly: consider_modules and dt_unreserved_regions should skip these regions the same way they are already skipping mem-reserve regions. Signed-off-by: Stefano Stabellini

[Xen-devel] [PATCH v6 1/8] xen/arm: pass node to device_tree_for_each_node

Add a new parameter to device_tree_for_each_node: node, the node to start the search from. Passing 0 triggers the old behavior. Set min_depth to depth of the current node + 1 to avoid scanning siblings of the initial node passed as an argument. Don't call func() on the parent node passed as an

[Xen-devel] [PATCH v6 4/8] xen/arm: fix indentation in early_print_info

No functional changes. Signed-off-by: Stefano Stabellini --- xen/arch/arm/bootfdt.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c index f23ebaa188..a70a739bb0 100644 --- a/xen/arch/arm/bootfdt.c +++

[Xen-devel] [PATCH v6 0/8] reserved-memory in dom0

Hi all, This patch series introduces partial reserved-memory support for dom0 only (no domU support for reserved-memory yet.) The following changes since commit 762b9a2d990bba1f3aefe660cff0c37ad2e375bc: xen/page_alloc: Keep away MFN 0 from the buddy allocator (2019-08-09 11:12:55 -0700)

[Xen-devel] [PATCH v6 3/8] xen/arm: keep track of reserved-memory regions

As we parse the device tree in Xen, keep track of the reserved-memory regions as they need special treatment (follow-up patches will make use of the stored information.) Reuse process_memory_node to add reserved-memory regions to the bootinfo.reserved_mem array. Refuse to continue once we reach

[Xen-devel] [PATCH v6 5/8] xen/arm: early_print_info print reserved_mem

Improve early_print_info to also print the banks saved in bootinfo.reserved_mem. Print them right after RESVD, increasing the same index. Since we are at it, also switch the existing RESVD print to use unsigned int. Signed-off-by: Stefano Stabellini Reviewed-by: Volodymyr Babchuk Acked-by:

[Xen-devel] [PATCH v6 7/8] xen/arm: don't iomem_permit_access for reserved-memory regions

Don't allow reserved-memory regions to be remapped into any unprivileged guests, until reserved-memory regions are properly supported in Xen. For now, do not call iomem_permit_access on them, because giving iomem_permit_access to dom0 means that the toolstack will be able to assign the region to a

[Xen-devel] [PATCH v6 2/8] xen/arm: make process_memory_node a device_tree_node_func

Change the signature of process_memory_node to match device_tree_node_func. Thanks to this change, the next patch will be able to use device_tree_for_each_node to call process_memory_node on all the children of a provided node. Return error if there is no reg property or if nr_banks is reached.

[Xen-devel] [linux-4.4 test] 140161: regressions - FAIL

flight 140161 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140161/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit2 broken in 140131 test-amd64-amd64-xl-pvshim 20

[Xen-devel] [PATCH] MAINTAINERS: remove myself from SVM and AMD IOMMU

From: Brian Woods I will no longer be working at AMD and am removing myself. Signed-off-by: Brian Woods --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 77413e0..251bfe2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -146,14 +146,12 @@ F:

Re: [Xen-devel] [PATCH v5 00/10] AMD IOMMU: further improvements

On Tue, Aug 06, 2019 at 03:05:36PM +0200, Jan Beulich wrote: > Only the first patch here is left from v4, everything else is new, > yet still related. The main goal is to reduce the huge memory > overhead that we've noticed. On the way there a number of other > things were once again noticed.

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

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

[Xen-devel] [PATCH] xen/arm: domain_build: Remove redundant check in make_vpl011_uart_node()

None of the code since the last check of res modify the value. So the check can be removed. Coverity-ID: 1476824 Signed-off-by: Julien Grall --- xen/arch/arm/domain_build.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/arch/arm/domain_build.c

Re: [Xen-devel] [RFC] Code of Conduct

> On 15 Aug 2019, at 20:08, Rich Persaud wrote: > > Following the discussion we had at the Developer Summit (see > https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc > >

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

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

Re: [Xen-devel] [win-pv-devel] [RFC] Code of Conduct

> On Aug 15, 2019, at 14:46, Lars Kurth wrote: >> On 15 Aug 2019, at 19:27, Rich Persaud wrote: >> On Aug 15, 2019, at 14:01, Lars Kurth wrote: >> >>> Hi Rich, >>> >>> thanks for the feedback. I am going to >>> >>> On 15/08/2019, 18:23, "Rich Persaud" wrote: >>> On Aug 9, 2019, at

Re: [Xen-devel] [PATCH] read grubenv and set default from saved_entry or next_entry

On Thu, 15 Aug 2019, Steven Haigh wrote: > Having a bit of a look here > > My test system grubenv file has: > # GRUB Environment Block > saved_entry=0 > kernelopts=root=UUID=5346b4d9-885f-4673-8aff-04a16bf1971a ro > rootflags=subvol=root selinux=0 rhgb quiet > boot_success=1 >

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

> On 15 Aug 2019, at 17:29, Andrew Cooper wrote: > > On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote: >> Thanks Julien. I will do that next time (unless you guys want me to >> re-send all this ;-)). >> >> BTW, I also pushed my changes onto the xenbits server: >>

Re: [Xen-devel] [win-pv-devel] [RFC] Code of Conduct

> On 15 Aug 2019, at 19:27, Rich Persaud wrote: > > On Aug 15, 2019, at 14:01, Lars Kurth wrote: > >> Hi Rich, >> >> thanks for the feedback. I am going to >> >> On 15/08/2019, 18:23, "Rich Persaud" wrote: >> >> > On Aug 9, 2019, at 13:48, Lars Kurth wrote: >> > >> >

[Xen-devel] [qemu-mainline test] 140148: tolerable FAIL - PUSHED

flight 140148 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/140148/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 140012 test-armhf-armhf-libvirt 14

Re: [Xen-devel] [RFC] Code of Conduct

On Aug 15, 2019, at 14:01, Lars Kurth wrote: > > Hi Rich, > > thanks for the feedback. I am going to > > On 15/08/2019, 18:23, "Rich Persaud" wrote: > > > On Aug 9, 2019, at 13:48, Lars Kurth wrote: > > > > Hi all, > > Hi Lars, > > > > > Following the

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

Hello Dario, On 13.08.19 17:45, Dario Faggioli wrote: What do you mean with "Yet its scheduling is very implementation dependant"? The freertos provides an interface to its scheduling internals like `vTaskSwitchContext` and `xTaskIncrementTick()`, which should be called by the

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS] Introduce a MAINTAINERS file

Rationale: this will allow us to use get_maintainer.pl / add_maintainers.pl scripts from xen.git Signed-off-by: Lars Kurth --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 MAINTAINERS diff --git a/MAINTAINERS b/MAINTAINERS new file mode 100644 index

Re: [Xen-devel] [RFC] Code of Conduct

Hi Rich, thanks for the feedback. I am going to On 15/08/2019, 18:23, "Rich Persaud" wrote: > On Aug 9, 2019, at 13:48, Lars Kurth wrote: > > Hi all, Hi Lars, > > Following the discussion we had at the Developer Summit (see

[Xen-devel] [PATCH] xen/arm: domain_build: Print the correct domain in construct_domain()

construct_domain() can be called by other domain than dom0. To avoid confusion in the log, print the correct domain. Signed-off-by: Julien Grall --- xen/arch/arm/domain_build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/domain_build.c

[Xen-devel] [PATCH] xen/arm: domain_build: Print the correct domain in initrd_load()

initrd_load() can be called by other domain than dom0. To avoid confusion in the log, print the correct domain. Signed-off-by: Julien Grall --- xen/arch/arm/domain_build.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/domain_build.c

[Xen-devel] [PATCH v2] xen/arm: domain_build: Print the correct domain in dtb_load()

dtb_load() can be called by other domain than dom0. To avoid confusion in the log, print the correct domain. Signed-off-by: Julien Grall --- Changes in v2: - Fix the second print in the function as well. --- xen/arch/arm/domain_build.c | 8 +--- 1 file changed, 5 insertions(+),

Re: [Xen-devel] [RFC] Code of Conduct

> On Aug 9, 2019, at 13:48, Lars Kurth wrote: > > Hi all, Hi Lars, > > Following the discussion we had at the Developer Summit (see > https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc. > for notes) I put

[Xen-devel] [PATCH v2] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

Use-case: Allow using both scripts on xen repositories such as mini-os.git, osstest.git, Tool changes: * add_maintainers.pl: $get_maintainer inherits path from $0 * get_maintainer.pl: warn (instead fo die) when called from a different tree Assumptions: the repository contains a MAINTAINERS

Re: [Xen-devel] [PATCH] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

On 15/08/2019, 18:12, "Lars Kurth" wrote: Use-case: Allow using both scripts on xen repositories such as mini-os.git, osstest.git, Tool changes: * add_maintainers.pl: $get_maintainer inherits path from $0 * get_maintainer.pl: warn (instead fo die) when called

[Xen-devel] [PATCH] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

Use-case: Allow using both scripts on xen repositories such as mini-os.git, osstest.git, Tool changes: * add_maintainers.pl: $get_maintainer inherits path from $0 * get_maintainer.pl: warn (instead fo die) when called from a different tree Assumptions: the repository contains a MAINTAINERS

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

flight 140145 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/140145/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139876 Tests which did

Re: [Xen-devel] [PATCH V2 2/6] iommu/arm: Add ability to handle deferred probing request

Hi, Julien I noticed there was already a panic() in iommu_setup() just in case the user force the use of IOMMU but they were not initialized. I was half-tempted to set iommu_force to true for Arm, but I think this is a different issue. So here my take (not tested nor compiled). Thank

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote: > Thanks Julien. I will do that next time (unless you guys want me to > re-send all this ;-)). > > BTW, I also pushed my changes onto the xenbits server: > http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary >

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

On 8/15/19 5:00 PM, Julien Grall wrote: > Hi George, > > On 15/08/2019 16:48, George Dunlap wrote: >> On 8/15/19 4:36 PM, Julien Grall wrote: >>> Hi George, >>> >>> On 15/08/2019 16:32, George Dunlap wrote: On 8/15/19 4:29 PM, Julien Grall wrote: > > > On 15/08/2019 16:19,

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

> On 15 Aug 2019, at 16:58, Julien Grall wrote: > > Hi Lars, > > On 15/08/2019 16:46, Lars Kurth wrote: >>> On 15 Aug 2019, at 16:33, Lars Kurth >> > wrote: >>> >>> >>> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel >>> >

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

Hi George, On 15/08/2019 16:48, George Dunlap wrote: On 8/15/19 4:36 PM, Julien Grall wrote: Hi George, On 15/08/2019 16:32, George Dunlap wrote: On 8/15/19 4:29 PM, Julien Grall wrote: On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: Hi Lars, Julien, Hi, Thanks for the pointers, I

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

Hi Lars, On 15/08/2019 16:46, Lars Kurth wrote: On 15 Aug 2019, at 16:33, Lars Kurth > wrote: On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel > wrote: Hi Lars, Julien, Thanks for the pointers, I will read them up and follow the

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

On 8/15/19 4:36 PM, Julien Grall wrote: > Hi George, > > On 15/08/2019 16:32, George Dunlap wrote: >> On 8/15/19 4:29 PM, Julien Grall wrote: >>> >>> >>> On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: Hi Lars, Julien, >>> >>> Hi, >>> Thanks for the pointers, I will read them up and

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

> On 15 Aug 2019, at 16:33, Lars Kurth wrote: > > > >> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel > > wrote: >> >> Hi Lars, Julien, >> >> Thanks for the pointers, I will read them up and follow the recommendations >> with my future contributions. >> Sorry

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

Thanks Julien. I will do that next time (unless you guys want me to re-send all this ;-)). BTW, I also pushed my changes onto the xenbits server: http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

Hi George, On 15/08/2019 16:32, George Dunlap wrote: On 8/15/19 4:29 PM, Julien Grall wrote: On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: Hi Lars, Julien, Hi, Thanks for the pointers, I will read them up and follow the recommendations with my future contributions. Sorry for the

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel wrote: > > Hi Lars, Julien, > > Thanks for the pointers, I will read them up and follow the recommendations > with my future contributions. > Sorry for the mess… It's not really a mess: it must have been quite a pain to put the mails

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

On 8/15/19 4:29 PM, Julien Grall wrote: > > > On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: >> Hi Lars, Julien, > > Hi, > >> Thanks for the pointers, I will read them up and follow the >> recommendations with my future contributions. >> Sorry for the mess… >> >> But, let me ask first

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: Hi Lars, Julien, Hi, Thanks for the pointers, I will read them up and follow the recommendations with my future contributions. Sorry for the mess… But, let me ask first before reading the wikis, how do you prefer submitting series that

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

Hi Lars, Julien, Thanks for the pointers, I will read them up and follow the recommendations with my future contributions. Sorry for the mess… But, let me ask first before reading the wikis, how do you prefer submitting series that contain patches belonging to 2 distinct repos (e.g. xen and

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

> On 15 Aug 2019, at 12:38, Julien Grall wrote: > > Hi, > > I am not going to answer on the patch itself but the process. > > Any series (i.e more than one patch) should contain a cover letter with a > rough summary of the goal of the series. > > Furthermore, this 3 patches series has been

Re: [Xen-devel] [PATCH 0/6] x86emul: further work

On 01/07/2019 12:47, Jan Beulich wrote: > On top of the AVX512 series I'd like to put out for review/discussion > > 1: generalize wbinvd() hook > 2: support WBNOINVD > 3: generalize invlpg() hook > 4: move INVPCID_TYPE_* to x86-defns.h > 5: support INVPCID > 6: support MOVDIR{I,64B} insns Do you

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

flight 140128 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/140128/ 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. 133580

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

On 15/08/2019 14:51, Volodymyr Babchuk wrote: Julien Grall writes: Hi Volodymyr, On 15/08/2019 13:14, Volodymyr Babchuk wrote: Julien Grall writes: On 15/08/2019 12:24, Julien Grall wrote: Hi Volodymyr, On 15/08/2019 12:20, Volodymyr Babchuk wrote: Hi Stefano, Stefano Stabellini

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

Julien Grall writes: > Hi Volodymyr, > > On 15/08/2019 13:14, Volodymyr Babchuk wrote: >> Julien Grall writes: >> >>> On 15/08/2019 12:24, Julien Grall wrote: Hi Volodymyr, On 15/08/2019 12:20, Volodymyr Babchuk wrote: > > Hi Stefano, > > Stefano Stabellini writes:

Re: [Xen-devel] [PATCH V2 2/6] iommu/arm: Add ability to handle deferred probing request

On 15.08.19 15:54, Julien Grall wrote: Hi, Hi Julien I noticed there was already a panic() in iommu_setup() just in case the user force the use of IOMMU but they were not initialized. I was half-tempted to set iommu_force to true for Arm, but I think this is a different issue. So here my

Re: [Xen-devel] [PATCH V2 2/6] iommu/arm: Add ability to handle deferred probing request

Hi, On 15/08/2019 10:29, Julien Grall wrote: > On 14/08/2019 20:25, Stefano Stabellini wrote: >> On Wed, 14 Aug 2019, Julien Grall wrote: >> I agree that we should enable all IOMMUs or none. I don't think we want >> to deal with partially initialized IOMMUs systems. >> >> Failure to enable all

Re: [Xen-devel] [xen-unstable-coverity test] 140105: all pass - PUSHED

On Wed, Aug 14, 2019 at 09:52:31AM +, osstest service owner wrote: > flight 140105 xen-unstable-coverity real [real] > http://logs.test-lab.xenproject.org/osstest/logs/140105/ > > Perfect :-) > All tests in this flight passed as required > version targeted for testing: > xen

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

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

[Xen-devel] [linux-4.4 test] 140131: regressions - trouble: blocked/broken/fail/pass

flight 140131 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140131/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit2 broken build-amd64-xsm 6 xen-build

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

Hi Volodymyr, On 15/08/2019 13:14, Volodymyr Babchuk wrote: Julien Grall writes: On 15/08/2019 12:24, Julien Grall wrote: Hi Volodymyr, On 15/08/2019 12:20, Volodymyr Babchuk wrote: Hi Stefano, Stefano Stabellini writes: On Tue, 13 Aug 2019, Volodymyr Babchuk wrote: @@ -162,6 +156,10

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

Hi Julien, Julien Grall writes: > On 15/08/2019 12:24, Julien Grall wrote: >> Hi Volodymyr, >> >> On 15/08/2019 12:20, Volodymyr Babchuk wrote: >>> >>> Hi Stefano, >>> >>> Stefano Stabellini writes: >>> On Tue, 13 Aug 2019, Volodymyr Babchuk wrote: >> @@ -162,6 +156,10 @@ static void

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

Hi, I am not going to answer on the patch itself but the process. Any series (i.e more than one patch) should contain a cover letter with a rough summary of the goal of the series. Furthermore, this 3 patches series has been received as 3 separate threads (i.e in-reply-to is missing). This

[Xen-devel] [PATCH livepatch-python 1/1] livepatch: Add python bindings for livepatch operations

Extend the XC python bindings library to support also all common livepatch operations and actions. Add the python bindings for the following operations: - status (pyxc_livepatch_status): Requires a payload name as an input. Returns a status dict containing a state string and a return code

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

On 15/08/2019 12:24, Julien Grall wrote: Hi Volodymyr, On 15/08/2019 12:20, Volodymyr Babchuk wrote: Hi Stefano, Stefano Stabellini writes: On Tue, 13 Aug 2019, Volodymyr Babchuk wrote: @@ -162,6 +156,10 @@ static void __init process_memory_node(const void *fdt, int node,  

[Xen-devel] [PATCH lp-metadata 3/3] livepatch: Add metadata runtime retrieval mechanism

Extend the livepatch list operation to fetch also payloads' metadata. This is achieved by extending the sysctl list interface with 2 extra guest handles: * metadata - an array of arbitrary size strings * metadata_len - an array of metadata strings' lengths (uin32_t each) Payloads' metadata is

[Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

The payloads' name strings can be of arbitrary size (typically small with an upper bound of XEN_LIVEPATCH_NAME_SIZE). Current implementation of the list operation interface allows to copy names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual size and enforces space allocation

[Xen-devel] [PATCH lp-metadata 1/3] livepatch: Add support for modules .modinfo section metadata

Having detailed hotpatch metadata helps to properly identify module's origin and version. It also allows to keep track of the history of hotpatch loads in the system (at least within dmesg buffer size limits). The hotpatch metadata are embedded in a form of .modinfo section. Each such section

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

Hi Volodymyr, On 15/08/2019 12:20, Volodymyr Babchuk wrote: Hi Stefano, Stefano Stabellini writes: On Tue, 13 Aug 2019, Volodymyr Babchuk wrote: @@ -162,6 +156,10 @@ static void __init process_memory_node(const void *fdt, int node, bootinfo.mem.bank[bootinfo.mem.nr_banks].size =

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

Hi Stefano, Stefano Stabellini writes: > On Tue, 13 Aug 2019, Volodymyr Babchuk wrote: >> > @@ -162,6 +156,10 @@ static void __init process_memory_node(const void >> > *fdt, int node, >> > bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size; >> > bootinfo.mem.nr_banks++; >>

Re: [Xen-devel] [edk2-devel] [PATCH v5 00/35] Specific platform to run OVMF in Xen PVH and HVM guests

On 08/13/19 13:30, Anthony PERARD wrote: > Patch series available in this git branch: > https://xenbits.xen.org/git-http/people/aperard/ovmf.git > br.platform-xen-pvh-v5 > > Changes in v5: > - patch 23 got a rework of the lapic range skipping > - small fixups in patch 20, 22, 23, 31, 32, 33. >

[Xen-devel] [libvirt test] 140149: regressions - FAIL

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

Re: [Xen-devel] [PATCH v2 00/48] xen: add core scheduling support

Hi Juergen, The latest round of testing revealed the following 3 Xen crashes: 1. vcpu_sleep_sync() <-- vlapic_init_sipi_action() This was seen multiple times. It tends to happen on large Windows Server VMs (>= 12 vCPUs). https://paste.debian.net/1095844/ 2. vcpu_sleep_sync() <--

Re: [Xen-devel] [edk2-devel] [PATCH v5 32/35] OvmfPkg: Introduce PcdXenGrantFrames

On 08/15/19 11:40, Laszlo Ersek wrote: > On 08/13/19 13:31, Anthony PERARD wrote: >> Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow >> the same value to be used in a different module. >> >> The reason for the number of page to be 4 doesn't exist anymore, so >> simply remove

[Xen-devel] [livepatch: independ. modules 3/3] python: Add XC binding for Xen build ID

Extend the list of xc() object methods with additional one to display Xen's buildid. The implementation follows the libxl implementation (e.g. max buildid size assumption being XC_PAGE_SIZE). Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Martin Mazein Reviewed-by: Andra-Irina Paraschiv

Re: [Xen-devel] [edk2-devel] [PATCH v5 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

On 08/13/19 13:31, Anthony PERARD wrote: > XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the > Grant Tables. > > The call is only done if it is necessary, we simply detect if the > guest is PVH, as in this case there is currently no PCI bus, and no > PCI Xen platform device

Re: [Xen-devel] [edk2-devel] [PATCH v5 32/35] OvmfPkg: Introduce PcdXenGrantFrames

On 08/13/19 13:31, Anthony PERARD wrote: > Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow > the same value to be used in a different module. > > The reason for the number of page to be 4 doesn't exist anymore, so > simply remove the comment. > > Signed-off-by: Anthony

Re: [Xen-devel] [edk2-devel] [PATCH v5 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

On 08/13/19 13:31, Anthony PERARD wrote: > On a Xen PVH guest, none of the existing serial or console interface > works, so we add a new one, based on XenConsoleSerialPortLib, and > implemented via SerialDxe. > > That is a simple console implementation that can work on both PVH > guest and HVM

Re: [Xen-devel] [PATCH V2 2/6] iommu/arm: Add ability to handle deferred probing request

Hi Stefano, On 14/08/2019 20:25, Stefano Stabellini wrote: On Wed, 14 Aug 2019, Julien Grall wrote: I agree that we should enable all IOMMUs or none. I don't think we want to deal with partially initialized IOMMUs systems. Failure to enable all IOMMUs should lead to returning an error from the

Re: [Xen-devel] [edk2-devel] [PATCH v5 23/35] OvmfPkg/XenPlatformPei: Rework memory detection

On 08/13/19 13:31, Anthony PERARD wrote: > When running as a Xen PVH guest, there is no CMOS to read the memory > size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can > work without CMOS by reading the e820 table. > > Rework XenPublishRamRegions to also care for the reserved and

Re: [Xen-devel] [PATCH v5 6/7] xen/arm: don't iomem_permit_access for reserved-memory regions

Hi Stefano, On 14/08/2019 23:40, Stefano Stabellini wrote: On Tue, 13 Aug 2019, Julien Grall wrote: On 8/13/19 3:34 PM, Volodymyr Babchuk wrote: Stefano Stabellini writes: On a side note, the check is still incorrect here because you would allow /reserved-memory@... or /reserved-memory-test

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

Hi Stefano, On 14/08/2019 23:35, Stefano Stabellini wrote: On Tue, 13 Aug 2019, Volodymyr Babchuk wrote: @@ -162,6 +156,10 @@ static void __init process_memory_node(const void *fdt, int node, bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size; bootinfo.mem.nr_banks++;

Re: [Xen-devel] [edk2-devel] [PATCH v5 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall

On 08/13/19 13:31, Anthony PERARD wrote: > When the Xen PVH entry point has been used, hvmloader hasn't run and > hasn't prepared an E820 table. The only way left to get an E820 table > is to ask Xen via an hypercall. We keep the result cached to avoid > making a second hypercall which would give

Re: [Xen-devel] [edk2-devel] [PATCH v5 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected

On 08/13/19 13:31, Anthony PERARD wrote: > XenPvhDetected() can be used to figure out if OVMF has started via the > Xen PVH entry point. > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 > Signed-off-by: Anthony PERARD > Acked-by: Laszlo Ersek > --- > > Notes: > v5: > - in

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

flight 140127 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140127/ 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 build-amd64

Re: [Xen-devel] [PATCH] read grubenv and set default from saved_entry or next_entry

On Thu, 15 Aug 2019, Steven Haigh wrote: > Having a bit of a look here > > My test system grubenv file has: > # GRUB Environment Block > saved_entry=0 > kernelopts=root=UUID=5346b4d9-885f-4673-8aff-04a16bf1971a ro > rootflags=subvol=root selinux=0 rhgb quiet > boot_success=1 It looks like

Re: [Xen-devel] [PATCH] read grubenv and set default from saved_entry or next_entry

On 2019-08-15 09:56, YOUNG, MICHAEL A. wrote: On Thu, 15 Aug 2019, Michael Young wrote: This patch may help your issue with the default kernel setting on Fedora 30 as it uses the setting of saved_entry or next_entry from the grubenv file to choose the default kernel which should override any