[Xen-devel] [PATCH v4] xen/doc: Improve Dom0-less documentation

- Changed unprintable characters with %s/\%xA0/ /g So all the spaces are 0x20 now. - Added address-cells and size-cells to configuration example. This resolves the dom0less boot issue in case of arm64. - Added some notes about xl tools usage in case of dom0less. Signed-off-by: Viktor Mitin

Re: [Xen-devel] [PATCH] tests/cpu-policy: fix format-overflow warning by null terminating strings

On 31.07.2019 02:22, Dario Faggioli wrote: > Jan's example above, seem to compile **without any warnings** for me as > well. If I add a main(), I can even get the code above to print the > content of the array. > > And yet, building the tools without a patch like Christoper's one > (which was also

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

On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote: > Sorry -- got a bit distracted yesterday. Attached is the log with only > your latest patch attached. Interestingly enough the box booted fine > without screen artifacts. So I guess we're getting closer... > > Thanks for all the he

Re: [Xen-devel] [PATCH v3 01/10] page-alloc: Clamp get_free_buddy() to online nodes

On 30.07.2019 19:32, Andrew Cooper wrote: > On 30/07/2019 09:09, Jan Beulich wrote: >> On 29.07.2019 19:26, Andrew Cooper wrote: >>> On 29/07/2019 16:48, Jan Beulich wrote: On 29.07.2019 14:11, Andrew Cooper wrote: > +if ( d ) > +nodes_and(nodemask, nodemask, d->node_affini

Re: [Xen-devel] [PATCH v4] xen/doc: Improve Dom0-less documentation

Hi, On 7/31/19 9:10 AM, Viktor Mitin wrote: - Changed unprintable characters with %s/\%xA0/ /g So all the spaces are 0x20 now. - Added address-cells and size-cells to configuration example. This resolves the dom0less boot issue in case of arm64. - Added some notes about xl tools usage in

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

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

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

On Wed, Jul 31, 2019 at 10:36:31AM +0200, Roger Pau Monné wrote: > On Tue, Jul 30, 2019 at 10:55:24AM -0700, Roman Shaposhnik wrote: > > Sorry -- got a bit distracted yesterday. Attached is the log with only > > your latest patch attached. Interestingly enough the box booted fine > > without screen

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

On 30.07.2019 19:55, Roman Shaposhnik wrote: > Sorry -- got a bit distracted yesterday. Attached is the log with only > your latest patch attached. Interestingly enough the box booted fine > without screen artifacts. So I guess we're getting closer... I'm afraid I can't make sense of this and the

Re: [Xen-devel] [PATCH] x86/boot: Fix build dependenices for reloc.c

On Tue, Jul 30, 2019 at 06:07:54PM +0100, Andrew Cooper wrote: > c/s 201f852eaf added start_info.h and kconfig.h to reloc.c, but only updated > start_info.h in RELOC_DEPS. > > This causes reloc.c to not be regenerated when Kconfig changes. It is most > noticeable when enabling CONFIG_PVH and find

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

On 30.07.2019 19:56, Roman Shaposhnik wrote: > On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote: >> >> On 23.07.2019 20:25, Roman Shaposhnik wrote: >>> Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug >>> booted the system just fine. >> >> Btw (I've noticed this only now) -

Re: [Xen-devel] [PATCH v3 08/10] xen/nodemask: Introduce unlocked __nodemask_{set, clear}() helpers

On 30.07.2019 19:48, Andrew Cooper wrote: > On 30/07/2019 12:26, Jan Beulich wrote: >> On 29.07.2019 14:12, Andrew Cooper wrote: >>> --- a/xen/include/xen/nodemask.h >>> +++ b/xen/include/xen/nodemask.h >>> @@ -11,7 +11,9 @@ >>>* The available nodemask operations are: >>>* >>>* void nod

Re: [Xen-devel] [PATCH v4] xen/doc: Improve Dom0-less documentation

On Wed, Jul 31, 2019 at 11:40 AM Julien Grall wrote: > > Hi, > Hi Julien, > On 7/31/19 9:10 AM, Viktor Mitin wrote: > > - Changed unprintable characters with %s/\%xA0/ /g > >So all the spaces are 0x20 now. > > > > - Added address-cells and size-cells to configuration example. > >This res

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

On 31/07/2019 09:34, Jan Beulich wrote: > On 30.07.2019 19:56, Roman Shaposhnik wrote: >> On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote: >>> On 23.07.2019 20:25, Roman Shaposhnik wrote: Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug booted the system just fine

Re: [Xen-devel] [PATCH v3 01/10] page-alloc: Clamp get_free_buddy() to online nodes

On 31/07/2019 09:22, Jan Beulich wrote: > On 30.07.2019 19:32, Andrew Cooper wrote: >> On 30/07/2019 09:09, Jan Beulich wrote: >>> On 29.07.2019 19:26, Andrew Cooper wrote: On 29/07/2019 16:48, Jan Beulich wrote: > On 29.07.2019 14:11, Andrew Cooper wrote: >> +if ( d ) >> +

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

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. This is a preparatory for the patch "xen/arm: merge make_timer_node and make_timer_domU_node". Original goal is to

[Xen-devel] [PATCH v3 2/2] xen/arm: merge 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 merge them to avoid discrepancy. The main difference between the functions is the timer interrupts used. Kept the domU version for the compatible as it is simpler. Kept the hw version for the clock as it is re

Re: [Xen-devel] [PATCH v3 1/2] xen/link: Introduce .bss.percpu.page_aligned

On 30.07.2019 18:36, Andrew Cooper wrote: > On 30/07/2019 10:49, Jan Beulich wrote: >> On 30.07.2019 11:35, Andrew Cooper wrote: >>> On 30/07/2019 09:42, Jan Beulich wrote: On 29.07.2019 19:38, Andrew Cooper wrote: > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@

Re: [Xen-devel] [PATCH] Speculative mitigation facilities report wrong status

On 31/07/2019 10:30, Jin Nan Wang wrote: > Diff with 'spec-ctrl=no' and without. > > --- xen.dmesg.5.log 2019-07-31 14:55:38.138173874 +0800 > +++ xen.dmesg.6.log 2019-07-31 14:59:50.223516313 +0800 > @@ -7,7 +7,7 @@ > (XEN) Xen versio

[Xen-devel] [PATCH] Speculative mitigation facilities report wrong status

Diff with 'spec-ctrl=no' and without. --- xen.dmesg.5.log 2019-07-31 14:55:38.138173874 +0800 +++ xen.dmesg.6.log 2019-07-31 14:59:50.223516313 +0800 @@ -7,7 +7,7 @@ (XEN) Xen version 4.12.0_14-1 (abu...@suse.de) (gcc (SUSE Linux) 4.8.

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

On 31.07.2019 10:58, Andrew Cooper wrote: > On 31/07/2019 09:34, Jan Beulich wrote: >> On 30.07.2019 19:56, Roman Shaposhnik wrote: >>> On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote: On 23.07.2019 20:25, Roman Shaposhnik wrote: > Interestingly enough, adding iommu_inclusive_mapping=1

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

flight 139557 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/139557/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 1585ed3c702e680ae492d852c8cff62cf300df99 baseline version: xen 22ec

Re: [Xen-devel] [PATCH] x86/boot: Fix build dependenices for reloc.c

On 31/07/2019 09:47, Roger Pau Monné wrote: > On Tue, Jul 30, 2019 at 06:07:54PM +0100, Andrew Cooper wrote: >> c/s 201f852eaf added start_info.h and kconfig.h to reloc.c, but only updated >> start_info.h in RELOC_DEPS. >> >> This causes reloc.c to not be regenerated when Kconfig changes. It is mo

Re: [Xen-devel] [PATCH] Speculative mitigation facilities report wrong status

I will improve it soon. thanks James From: Andrew Cooper Sent: Wednesday, July 31, 2019 5:44:50 PM To: xen-devel@lists.xenproject.org ; Jin Nan Wang Cc: roger@citrix.com ; Jan Beulich ; w...@xen.org Subject: Re: [PATCH] Speculative mitigation facilities

[Xen-devel] [PATCH v4 2/2] xen/arm: merge make_timer_node and make_timer_domU_node

Merged make_timer_node and make_timer_domU_node into one function make_timer_node. Kept the domU version for the compatible as it is simpler. Kept the hw version for the clock as it is relevant for the both cases. Suggested-by: Julien Grall Signed-off-by: Viktor Mitin --- v4 updates: updated

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

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. This is a preparatory for the patch "xen/arm: merge make_timer_node and make_timer_domU_node". Original goal is to

Re: [Xen-devel] [PATCH] x86/boot: Fix build dependenices for reloc.c

On Tue, 30 Jul 2019 at 18:08, Andrew Cooper wrote: > > c/s 201f852eaf added start_info.h and kconfig.h to reloc.c, but only updated > start_info.h in RELOC_DEPS. > > This causes reloc.c to not be regenerated when Kconfig changes. It is most > noticeable when enabling CONFIG_PVH and finding the re

Re: [Xen-devel] [PATCH] x86/boot: Fix build dependenices for reloc.c

On 31/07/2019 11:38, Wei Liu wrote: > On Tue, 30 Jul 2019 at 18:08, Andrew Cooper wrote: >> c/s 201f852eaf added start_info.h and kconfig.h to reloc.c, but only updated >> start_info.h in RELOC_DEPS. >> >> This causes reloc.c to not be regenerated when Kconfig changes. It is most >> noticeable wh

Re: [Xen-devel] [PATCH] Speculative mitigation facilities report wrong status

Hi folks, On 7/31/19 5:44 PM, Andrew Cooper wrote: > The check for reporting MD_CLEAR must stay as X86_FEATURE_MD_CLEAR, > because this is a property in microcode which no controls, and nothing > further to virtualise at Xen's level. There are two solution, which one would you like? solution1: m

Re: [Xen-devel] [PATCH] x86/boot: Fix build dependenices for reloc.c

On Wed, Jul 31, 2019 at 10:57:36AM +0100, Andrew Cooper wrote: > On 31/07/2019 09:47, Roger Pau Monné wrote: > > On Tue, Jul 30, 2019 at 06:07:54PM +0100, Andrew Cooper wrote: > >> c/s 201f852eaf added start_info.h and kconfig.h to reloc.c, but only > >> updated > >> start_info.h in RELOC_DEPS. >

Re: [Xen-devel] [RFC 5/6] arm64: call enter_hypervisor_head only when it is needed

Hi Andrii, On 30/07/2019 18:35, Andrii Anisov wrote: On 26.07.19 13:59, Julien Grall wrote: Hi, On 26/07/2019 11:37, Andrii Anisov wrote: From: Andrii Anisov On ARM64 we know exactly if trap happened from hypervisor or guest, so we do not need to take that decision. This reduces a conditio

Re: [Xen-devel] [PATCH] Speculative mitigation facilities report wrong status

On 31/07/2019 11:45, Jin Nan Wang wrote: > Hi folks, > > On 7/31/19 5:44 PM, Andrew Cooper wrote: >> The check for reporting MD_CLEAR must stay as X86_FEATURE_MD_CLEAR, >> because this is a property in microcode which no controls, and nothing >> further to virtualise at Xen's level. > There are two

Re: [Xen-devel] [PATCH] x86/boot: Fix build dependenices for reloc.c

On 30.07.2019 19:07, Andrew Cooper wrote: > c/s 201f852eaf added start_info.h and kconfig.h to reloc.c, but only updated > start_info.h in RELOC_DEPS. > > This causes reloc.c to not be regenerated when Kconfig changes. It is most > noticeable when enabling CONFIG_PVH and finding the resulting bin

[Xen-devel] XEN is not bringing

Hi team, Could you please suggest me why kernel gets stuck at [..] " (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) Freed 336kB init memory. " [..] Please find the below log :- U-Boot 2015.04 (Jul 23 2019 - 12:58:16) CPU: Renesas Electronics R8A7795 rev 2.0

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

Hi Julien, On Mon, Jul 29, 2019 at 3:35 PM Julien Grall wrote: > > Hi Viktor, > > On 7/29/19 1:21 PM, Viktor Mitin wrote: > > On Mon, Jul 29, 2019 at 1:49 PM Julien Grall wrote: > >> On 7/29/19 10:13 AM, Viktor Mitin wrote: > >>> On Fri, Jul 26, 2019 at 3:50 PM Julien Grall wrote: > >> > >>> It

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

On 31/07/2019 12:16, Viktor Mitin wrote: On Mon, Jul 29, 2019 at 3:35 PM Julien Grall wrote: On 7/29/19 1:21 PM, Viktor Mitin wrote: On Mon, Jul 29, 2019 at 1:49 PM Julien Grall wrote: On 7/29/19 10:13 AM, Viktor Mitin wrote: On Fri, Jul 26, 2019 at 3:50 PM Julien Grall wrote: * -

Re: [Xen-devel] [PATCH v2] x86/HVM: correct hvmemul_map_linear_addr() for multi-page case

On 13.09.2018 13:12, Jan Beulich wrote: > The function does two translations in one go for a single guest access. > Any failure of the first translation step (guest linear -> guest > physical), resulting in #PF, ought to take precedence over any failure > of the second step (guest physical -> hos

Re: [Xen-devel] [RFC 5/6] arm64: call enter_hypervisor_head only when it is needed

On Wed, 31 Jul 2019 12:02:20 +0100 Julien Grall wrote: Hi, > On 30/07/2019 18:35, Andrii Anisov wrote: > > > > On 26.07.19 13:59, Julien Grall wrote: > >> Hi, > >> > >> On 26/07/2019 11:37, Andrii Anisov wrote: > >>> From: Andrii Anisov > >>> > >>> On ARM64 we know exactly if trap happened

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

On Wed, Jul 31, 2019 at 2:25 PM Julien Grall wrote: > > > > On 31/07/2019 12:16, Viktor Mitin wrote: > > On Mon, Jul 29, 2019 at 3:35 PM Julien Grall wrote: > >> On 7/29/19 1:21 PM, Viktor Mitin wrote: > >>> On Mon, Jul 29, 2019 at 1:49 PM Julien Grall wrote: > On 7/29/19 10:13 AM, Viktor M

Re: [Xen-devel] [RFC] XCP-ng subproject proposal

+1 from me. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Intel TXT: add reviewer, move to Odd Fixes state

Hi Lars, On 30/07/2019 12:22, Lars Kurth wrote: On 30 Jul 2019, at 11:08, George Dunlap > wrote: On 7/30/19 10:54 AM, Julien Grall wrote: Hi Jan, On 30/07/2019 10:05, Jan Beulich wrote: On 30.07.2019 10:54, Julien Grall wrote: On 7/30/19 9:29 AM, Jan Beul

Re: [Xen-devel] [PATCH v2 1/2] ns16550: Add compatible string for Raspberry Pi 4

Hi, On 29/07/2019 17:06, Andre Przywara wrote: On Mon, 29 Jul 2019 09:19:19 -0400 Stewart Hildebrand wrote: Hi, Per the BCM2835 peripherals datasheet [1] page 10: "The UART core is build to emulate 16550 behaviour ... The implemented UART is not a 16650 compatible UART However as far as poss

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: platform: Add Raspberry Pi platform

Hi Stewart, On 29/07/2019 14:19, Stewart Hildebrand wrote: The aux peripherals (uart1, spi1, and spi2) share an IRQ and a page of memory. For debugging, it is helpful to use the aux UART in Xen. In this case, Xen would try to assign spi1 and spi2 to dom0, but this results in an error since the s

Re: [Xen-devel] [PATCH v2 0/2] Raspberry Pi 4 support

Hi Stewart, On 29/07/2019 14:19, Stewart Hildebrand wrote: This is a series to enable UART console for Raspberry Pi 4. Note that I'm relying on the firmware to initialize the UART (i.e. enable_uart=1 in config.txt), since full UART initialization on this platform requires accessing some regis

Re: [Xen-devel] [PATCH v4] xen/doc: Improve Dom0-less documentation

Hi Viktor, On 31/07/2019 09:57, Viktor Mitin wrote: On Wed, Jul 31, 2019 at 11:40 AM Julien Grall wrote: I can switch the memory property back to hexadecimal on commit. But I would like to understand why the value has changed before doing that. Ok, let's keep hexadecimal. 128Mb is ok in this

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

Hi Viktor, 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, because reviewer will know what to expect in the series. Viktor Mitin writes: > Extend fdt_

Re: [Xen-devel] [PATCH 3/7] xen/arm: Rework psr_mode_is_32bit()

Hi Stefano, On 29/07/2019 22:52, Stefano Stabellini wrote: On Fri, 26 Jul 2019, Volodymyr Babchuk wrote: Julien Grall writes: Hi, On 26/07/2019 13:31, Volodymyr Babchuk wrote: Julien Grall writes: psr_mode_is_32bit() prototype does not match the rest of the helpers for the process state.

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

flight 139539 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/139539/ 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. 139484 Tests which did no

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

Hi Volodymyr, On Wed, Jul 31, 2019 at 3:11 PM Volodymyr Babchuk wrote: > > > Hi Viktor, > > 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, because

Re: [Xen-devel] [PATCH v2 0/2] Raspberry Pi 4 support

On Mon, 29 Jul 2019 09:19:18 -0400 Stewart Hildebrand wrote: Hi, > This is a series to enable UART console for Raspberry Pi 4. Note that I'm > relying on the firmware to initialize the UART (i.e. enable_uart=1 in > config.txt), since full UART initialization on this platform requires > access

Re: [Xen-devel] [PATCH v4 2/2] xen/arm: merge make_timer_node and make_timer_domU_node

Viktor Mitin writes: > Merged make_timer_node and make_timer_domU_node into one function > make_timer_node. It is widely accepted to write commit messages in imperative mood, e.g. "merge" instead of "merged" > Kept the domU version for the compatible as it is simpler. > Kept the hw version for

Re: [Xen-devel] [PATCH v3 07/10] xen/nodemask: Drop nodes_{setall, clear}() and improve the initialisers

On 30/07/2019 10:44, Jan Beulich wrote: > On 29.07.2019 14:12, Andrew Cooper wrote: >> There is no need to use runtime variable-length clearing when MAX_NUMNODES is >> known to the compiler. Drop these functions and use the initialisers >> instead. > The only slight concern I have with this is t

Re: [Xen-devel] [PATCH v4 2/2] xen/arm: merge make_timer_node and make_timer_domU_node

On Wed, Jul 31, 2019 at 3:33 PM Volodymyr Babchuk wrote: > > > > Viktor Mitin writes: > > > Merged make_timer_node and make_timer_domU_node into one function > > make_timer_node. > It is widely accepted to write commit messages in imperative mood, > e.g. "merge" instead of "merged" > > > Kept the

Re: [Xen-devel] [PATCH] Intel TXT: add reviewer, move to Odd Fixes state

I am waiting for another mail address dedicated for mailing lists that has the disclaimer disabled. This is an official way in Intel to do that. I don't know when it will be ready, but I expect that this process can take few days. From my perspective we can wait until I will have that mail address

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

Hi, I am only going to comment on process. I will look at the rest later on. On 31/07/2019 13:28, Viktor Mitin wrote: Hi Volodymyr, On Wed, Jul 31, 2019 at 3:11 PM Volodymyr Babchuk wrote: Hi Viktor, It is recommended (and probably required, but I can't find exact place in the rules) to i

Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface

On Thu, 2019-07-18 at 14:44 +, Jan Beulich wrote: > On 18.07.2019 15:59, Petre Ovidiu PIRCALABU wrote: > > Before using xenforeignmemory_map_resource I investigated several > > different approaches: > > - Allocate the memory in hypervisor and xc_map_foreign_pages > > (doesn't > > work because y

[Xen-devel] [PATCH] Speculative mitigation facilities report wrong status v2

Add a check about X86_FEATURE_MD_CLEAR to avoid to print "None". --- xen/arch/x86/spec_ctrl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index cada9a058e..468a847598 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c

Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface

On 31.07.2019 14:53, Petre Ovidiu PIRCALABU wrote: > On Thu, 2019-07-18 at 14:44 +, Jan Beulich wrote: >> On 18.07.2019 15:59, Petre Ovidiu PIRCALABU wrote: >>> Before using xenforeignmemory_map_resource I investigated several >>> different approaches: >>> - Allocate the memory in hypervisor an

Re: [Xen-devel] [PATCH] Speculative mitigation facilities report wrong status v2

On 31/07/2019 14:09, Jin Nan Wang wrote: This wants at least a minimal aspect of description from your first patch, i.e. that booting with spec-ctrl=0 results in Xen printing "None MD_CLEAR". > Add a check about X86_FEATURE_MD_CLEAR to avoid to print "None". Needs a SoB tag. The actual code cha

Re: [Xen-devel] [PATCH v3 07/10] xen/nodemask: Drop nodes_{setall, clear}() and improve the initialisers

On 31.07.2019 14:49, Andrew Cooper wrote: > I don't see a way to avoid expanding node twice, but given that its wrapper > is in ALL_CAPS and obviously a macro. > > Furthermore, experimenting with a deliberate attempt to provoke this, I got > > numa.c: In function ‘numa_initmem_init’: > > /local

Re: [Xen-devel] [PATCH v3 07/10] xen/nodemask: Drop nodes_{setall, clear}() and improve the initialisers

On 31/07/2019 14:12, Jan Beulich wrote: > On 31.07.2019 14:49, Andrew Cooper wrote: >> I don't see a way to avoid expanding node twice, but given that its wrapper >> is in ALL_CAPS and obviously a macro. >> >> Furthermore, experimenting with a deliberate attempt to provoke this, I got >> >> numa.c

[Xen-devel] [PATCH] Speculative mitigation facilities report wrong status v3

Add a check about X86_FEATURE_MD_CLEAR to avoid to print "None". Signed-off-by: James Wang --- xen/arch/x86/spec_ctrl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index cada9a058e..468a847598 100644 --- a/xen/arch/x86/spec_ctrl.c +++

Re: [Xen-devel] [PATCH v3 1/2] x86/ubsan: Don't perform alignment checking on supporting compilers

On 26/07/2019 08:33, Jan Beulich wrote: On 27.06.19 at 20:56, wrote: >> GCC 5 introduced -fsanitize=alignment which is enabled by default by >> CONFIG_UBSAN. This trips a load of wont-fix cases in the ACPI tables and the >> hypercall page and stubs writing logic. >> >> It also causes the nat

Re: [Xen-devel] [PATCH v4 2/2] xen/arm: merge make_timer_node and make_timer_domU_node

Viktor Mitin writes: > On Wed, Jul 31, 2019 at 3:33 PM Volodymyr Babchuk > wrote: >> >> >> >> Viktor Mitin writes: >> >> > Merged make_timer_node and make_timer_domU_node into one function >> > make_timer_node. >> It is widely accepted to write commit messages in imperative mood, >> e.g. "merge"

[Xen-devel] [PATCH] Speculative mitigation facilities report wrong status V4

Booting with spec-ctrl=0 results in Xen printing "None MD_CLEAR". (XEN) Support for HVM VMs: None MD_CLEAR (XEN) Support for PV VMs: None MD_CLEAR Add a check about X86_FEATURE_MD_CLEAR to avoid to print "None". Signed-off-by: James Wang --- xen/arch/x86/spec_ctrl.c | 2 ++ 1 file changed,

[Xen-devel] [PATCH v5] Speculative mitigation facilities report wrong status

Booting with spec-ctrl=0 results in Xen printing "None MD_CLEAR". (XEN) Support for HVM VMs: None MD_CLEAR (XEN) Support for PV VMs: None MD_CLEAR Add a check about X86_FEATURE_MD_CLEAR to avoid to print "None". Signed-off-by: James Wang --- xen/arch/x86/spec_ctrl.c | 2 ++ 1 file changed,

Re: [Xen-devel] [PATCH v5] Speculative mitigation facilities report wrong status

On 31/07/2019 14:33, Jin Nan Wang wrote: > Booting with spec-ctrl=0 results in Xen printing "None MD_CLEAR". > > (XEN) Support for HVM VMs: None MD_CLEAR > (XEN) Support for PV VMs: None MD_CLEAR > > Add a check about X86_FEATURE_MD_CLEAR to avoid to print "None". > > Signed-off-by: James Wang

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: platform: Add Raspberry Pi platform

On Wednesday, July 31, 2019 8:04 AM, Julien Grall wrote: >Hi Stewart, Hi Julien >On 29/07/2019 14:19, Stewart Hildebrand wrote: >> The aux peripherals (uart1, spi1, and spi2) share an IRQ and a page of >> memory. For debugging, it is helpful to use the aux UART in Xen. In >> this case, Xen would

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

Hi, You should have enough characters in the title to explain what you are extending. Something like: xen/arm: Extend fdt_property_interrupts to support domU On 31/07/2019 11:28, Viktor Mitin wrote: Extend fdt_property_interrupts to deal with other domain than the hwdom. The prototype of fd

Re: [Xen-devel] [PATCH] Intel TXT: add reviewer, move to Odd Fixes state

> On 31 Jul 2019, at 12:52, Julien Grall wrote: > >> To move forward: >> * There should be a policy discussion > > How should I raise it? Do you want a patch again contribution-guidelines? I think we should start with an e-mail thread with an appropriate title on xen-devel@ (CCing committers

Re: [Xen-devel] [PATCH v4 2/2] xen/arm: merge make_timer_node and make_timer_domU_node

Hi, NIT: s/merge/consolidate/ On 31/07/2019 11:28, Viktor Mitin wrote: Merged make_timer_node and make_timer_domU_node into one function make_timer_node. Kept the domU version for the compatible as it is simpler. Kept the hw version for the clock as it is relevant for the both cases. The com

Re: [Xen-devel] [PATCH v4 2/2] xen/arm: merge make_timer_node and make_timer_domU_node

Hi Viktor, I am going to exceptionally top-post. There are rules that are widely accepted for the coding style yet they are not written in CODING_STYLE. Rather than keeping reminding us how everything is unwritten, it would be more beneficial if you try to help us making better. Meanwhile, I

Re: [Xen-devel] [PATCH v4 2/2] xen/arm: merge make_timer_node and make_timer_domU_node

Hi Volodymyr, On 31/07/2019 14:41, Volodymyr Babchuk wrote: Viktor Mitin writes: On Wed, Jul 31, 2019 at 3:33 PM Volodymyr Babchuk wrote: So, previously this code copied "compatible" property from platform device tree. Please note, that theoretically it would be neither "arm,armv8-timer" not

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

flight 139561 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/139561/ 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 1

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: platform: Add Raspberry Pi platform

Hi, On 31/07/2019 14:55, Stewart Hildebrand wrote: On Wednesday, July 31, 2019 8:04 AM, Julien Grall wrote: Hi Stewart, Hi Julien On 29/07/2019 14:19, Stewart Hildebrand wrote: The aux peripherals (uart1, spi1, and spi2) share an IRQ and a page of memory. For debugging, it is helpful to u

Re: [Xen-devel] [PATCH 5/7] xen/arm: traps: Avoid BUG_ON() in do_trap_brk()

On 30/07/2019 18:00, Stefano Stabellini wrote: > On Tue, 30 Jul 2019, Julien Grall wrote: >> Hi Stefano, >> >> On 7/29/19 11:02 PM, Stefano Stabellini wrote: >>> On Tue, 23 Jul 2019, Julien Grall wrote: At the moment, do_trap_brk() is using a BUG_ON() to check the hardware has been correc

Re: [Xen-devel] [PATCH v2 0/2] Raspberry Pi 4 support

On Wednesday, July 31, 2019 8:32 AM, Andre Przywara wrote: >On Mon, 29 Jul 2019 09:19:18 -0400 >Stewart Hildebrand wrote: > >Hi, > >> This is a series to enable UART console for Raspberry Pi 4. Note that I'm >> relying on the firmware to initialize the UART (i.e. enable_uart=1 in >> config.txt

[Xen-devel] Fedora 30 and BLSCFG changes equals non-booting DomUs.

Fedora 30 implemented Boot Loader Specification (BLS) by default for all newly installed, and any upgraded systems. This causes hell booting a DomU that is *not* configured as HVM - thus fails when not using the bootloader from within the guest. pygrub will always fail to boot these VMs. Lin

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

On 7/30/19 10:52 PM, Nicholas Rosbrook wrote: >> All that said, the first question I think is, what the generated code >> needs to look like. Then, if c-for-go can be configured to do that, >> then we can consider it; otherwise, making our own generator from the >> IDL will be the only option. >

[Xen-devel] Fedora 30 DomU - pygrub always boots the second menu option

There's a ton of changes to grub in Fedora 30 Most of them causing pain. When booting using pygrub, the presented menu always has the second option selected. The contents of /etc/default/grub is as follows: GRUB_TIMEOUT=1 GRUB_DEFAULT=0 GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="cons

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

On 7/30/19 7:39 PM, Tamas K Lengyel wrote: > On Tue, Jul 30, 2019 at 9:49 AM George Dunlap > wrote: >> >> On 7/30/19 2:48 PM, Tamas K Lengyel wrote: >>> On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook >>> wrote: Hello, As a follow up to the presentation that Brendan Kerriga

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

flight 139544 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/139544/ 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 Tests which did not

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

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

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

Hi Jan, On Mon, Jul 29, 2019 at 4:21 PM Jan Beulich wrote: > - Line 67: I believe Jan request the space before label > >>> Seems agreed not to add the spaces before label. Right? > >> > >> Certainly not, afaia. I will object to any written down rule disallowing > >> leading blank(s) al

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

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

[Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

There are coding style rules that are widely accepted by community, but newer were formalized in the document. Notable example is the question on how function arguments and parameters should be indented when they do not fit into one line. This question was raised multiple times lately, mostly beca

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

> On 31 Jul 2019, at 12:43, Viktor Mitin wrote: > > On Wed, Jul 31, 2019 at 2:25 PM Julien Grall > wrote: >> >> >> >> On 31/07/2019 12:16, Viktor Mitin wrote: >>> On Mon, Jul 29, 2019 at 3:35 PM Julien Grall wrote: On 7/29/19 1:21 PM, Viktor Mitin wrote: >

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

On 31/07/2019 17:24, Volodymyr Babchuk wrote: > There are coding style rules that are widely accepted by community, > but newer were formalized in the document. Notable example is the > question on how function arguments and parameters should be indented > when they do not fit into one line. > > Th

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

Hi All, On Wed, Jul 31, 2019 at 7:45 PM Andrew Cooper wrote: > > On 31/07/2019 17:24, Volodymyr Babchuk wrote: > > There are coding style rules that are widely accepted by community, > > but newer were formalized in the document. Notable example is the > > question on how function arguments and p

[Xen-devel] [PATCH 0/3] automation: build Xen in openSUSE Tumbleweed

The openSUSE distribution comes in two flavours: Leap, which is non-rolling, and released annualy, and Tumbleweed, which is rolling. In general, they are quite similar, but the versions of the software they ship can be significantly different. As it is easy to imagine, Tumbleweed, being rolling, h

[Xen-devel] [PATCH 2/3] automation: add openSUSE Tumbleweed CI image

openSUSE comes in two flavours: Leap, which is non-rolling, and released annualy, and Tumbleweed, which is rolling. Reasons why it makes sense to have both (despite both being openSUSE, package lists in dockerfiles being quite similar, etc) are: - Leap share a lot with SUSE Linux Enterprise. So, r

[Xen-devel] [PATCH 3/3] automation: build in openSUSE Tumbleweed

Signed-off-by: Dario Faggioli --- Cc: Doug Goldstein Cc: Wei Liu --- automation/gitlab-ci/build.yaml | 20 1 file changed, 20 insertions(+) diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index 1e61d30c85..94877f9d01 100644 --- a/automation

[Xen-devel] [PATCH 1/3] automation: try to keep openSUSE Leap image a little smaller

Using `--no-recommends` when updating or installing commands should prevent non strictly necessary packages to be installed. doing a `clean -a` after installing all the packages, should, in theory, free more space (as opposed to using just `clean`). Signed-off-by: Dario Faggioli --- Cc: Doug Gol

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

> On 31 Jul 2019, at 17:54, Viktor Mitin wrote: > > Hi All, > > On Wed, Jul 31, 2019 at 7:45 PM Andrew Cooper > wrote: >> >> On 31/07/2019 17:24, Volodymyr Babchuk wrote: >>> There are coding style rules that are widely accepted by community, >>> but newer were formalized in the document. N

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

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 the invite. So I > think what we need to do is figure out a way on how to make the coding > standard enforceable by a coding standard c

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

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

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

flight 139568 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/139568/ 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 1

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

Hi Andrew, Andrew Cooper writes: > On 31/07/2019 17:24, Volodymyr Babchuk wrote: >> There are coding style rules that are widely accepted by community, >> but newer were formalized in the document. Notable example is the >> question on how function arguments and parameters should be indented >>

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

Hi Lars, Lars Kurth writes: >> On 31 Jul 2019, at 17:54, Viktor Mitin wrote: >> >> Hi All, >> >> On Wed, Jul 31, 2019 at 7:45 PM Andrew Cooper >> wrote: >>> >>> On 31/07/2019 17:24, Volodymyr Babchuk wrote: [...] > Ultimately we have to make some trade-offs as to what is more important:

Re: [Xen-devel] [PATCH] CODING_STYLE: clarify function argument indentation

On 31/07/2019 18:49, Volodymyr Babchuk wrote: > Hi Andrew, > > Andrew Cooper writes: > >> On 31/07/2019 17:24, Volodymyr Babchuk wrote: >>> There are coding style rules that are widely accepted by community, >>> but newer were formalized in the document. Notable example is the >>> question on how f

Re: [Xen-devel] [PATCH v2 0/2] Raspberry Pi 4 support

Hi, On 7/31/19 1:05 PM, Julien Grall wrote: On 29/07/2019 14:19, Stewart Hildebrand wrote: This is a series to enable UART console for Raspberry Pi 4. Note that I'm relying on the firmware to initialize the UART (i.e. enable_uart=1 in config.txt), since full UART initialization on this platfor

  1   2   >