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

flight 139555 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/139555/ 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] [xen-unstable-smoke test] 139576: tolerable all pass - PUSHED

flight 139576 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/139576/ 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] [freebsd-master test] 139559: all pass - PUSHED

flight 139559 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/139559/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 58ae190bd3c0e785e5895867257c9926915fb818 baseline version: freebsd

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

> I return to the question I stated before.  At the moment, your bindings > have the following call chain: > > * DomainInfo(), hand-crafted.  Calls domainInfo(). > * domainInfo(), automaticall generated.  Calls C.libxl_domain_info(). > > The in-tree bindings have the following call chain: > > *

[Xen-devel] [linux-4.14 test] 139553: tolerable FAIL - PUSHED

flight 139553 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/139553/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13

Re: [Xen-devel] [PATCH 14/17] xen/arm64: head: Remove ID map as soon as it is not used

Hi Stefano, On 7/31/19 9:40 PM, Stefano Stabellini wrote: On Tue, 30 Jul 2019, Julien Grall wrote: Hi Stefano, On 7/30/19 6:33 PM, Stefano Stabellini wrote: On Thu, 27 Jun 2019, Julien Grall wrote: On 6/27/19 7:55 PM, Stefano Stabellini wrote: On Mon, 10 Jun 2019, Julien Grall wrote: +1:

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

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 Monné > > wrote: > >> 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

Re: [Xen-devel] [PATCH v2 34/35] xen/arm32: head: Setup HTTBR in enable_mmu() and add missing isb

Hi Stefano, On 7/30/19 10:26 PM, Stefano Stabellini wrote: On Mon, 22 Jul 2019, Julien Grall wrote: At the moment, HTTBR is setup in create_page_tables(). This is fine as it is called by every CPUs. However, such assumption may not hold in the future. To make change easier, the HTTBR is not

Re: [Xen-devel] [PATCH v2 32/35] xen/arm32: head: Rework and document setup_fixmap()

Hi Stefano, On 7/30/19 10:14 PM, Stefano Stabellini wrote: On Mon, 22 Jul 2019, Julien Grall wrote: At the moment, the fixmap table is only hooked when earlyprintk is used. This is fine today because in C land, the fixmap is not used by anyone until the the boot CPU is switching to the runtime

Re: [Xen-devel] [PATCH 14/17] xen/arm64: head: Remove ID map as soon as it is not used

On Tue, 30 Jul 2019, Julien Grall wrote: > Hi Stefano, > > On 7/30/19 6:33 PM, Stefano Stabellini wrote: > > On Thu, 27 Jun 2019, Julien Grall wrote: > > > On 6/27/19 7:55 PM, Stefano Stabellini wrote: > > > > On Mon, 10 Jun 2019, Julien Grall wrote: > > > > > +1: > > > > > +/* > > > > >

Re: [Xen-devel] [PATCH v2 24/35] xen/arm32: head: Introduce distinct paths for the boot CPU and secondary CPUs

Hi Stefano, On 7/30/19 9:07 PM, Stefano Stabellini wrote: On Mon, 22 Jul 2019, Julien Grall wrote: The boot code is currently quite difficult to go through because of the lack of documentation and a number of indirection to avoid executing some path in either the boot CPU or secondary CPUs.

Re: [Xen-devel] [PATCH v2 33/35] xen/arm32: head: Rework and document launch()

On Tue, 30 Jul 2019, Julien Grall wrote: > On 30/07/2019 22:21, Stefano Stabellini wrote: > > On Mon, 22 Jul 2019, Julien Grall wrote: > >> Boot CPU and secondary CPUs will use different entry point to C code. At > >> the moment, the decision on which entry to use is taken within launch(). > >> >

Re: [Xen-devel] [PATCH v2 22/35] xen/arm32: head: Rework UART initialization on boot CPU

Hi Stefano, On 7/30/19 8:40 PM, Stefano Stabellini wrote: On Mon, 22 Jul 2019, Julien Grall wrote: @@ -497,11 +497,15 @@ ENTRY(switch_ttbr) #ifdef CONFIG_EARLY_PRINTK /* - * Bring up the UART. - * r11: Early UART base address - * Clobbers r0-r2 + * Initialize the UART. Should only be

Re: [Xen-devel] [PATCH v2 16/35] xen/arm64: head: Rework and document launch()

Hi Stefano, On 7/30/19 6:45 PM, Stefano Stabellini wrote: On Mon, 22 Jul 2019, Julien Grall wrote: Boot CPU and secondary CPUs will use different entry point to C code. At the moment, the decision on which entry to use is taken within launch(). In order to avoid a branch for the decision and

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

Hi! Andrew reminded me that EVE has a weird in-tree patch for Xen's qemu to deal with an issue we can't quite explain: https://github.com/lf-edge/eve/blob/master/pkg/xen-tools/patches-4.12.0/01-remove-assert.patch The way this problem manifests itself is *sometime after* an HVM domain with

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

On 31/07/2019 20:35, Roman Shaposhnik wrote: > On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monné wrote: >> 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

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

On Wed, Jul 31, 2019 at 2:46 AM Jan Beulich wrote: > > 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

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

On Wed, Jul 31, 2019 at 1:43 AM Roger Pau Monné wrote: > > 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

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

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 distracted yesterday. Attached is the log with only > > your latest patch attached. Interestingly enough the box booted fine > > without screen

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

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

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

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 >>

[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

[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

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.

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

[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

[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,

[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 ---

[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,

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

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. > >

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:

[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

[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

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)

[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

[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

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

[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

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 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.

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 >>

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

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

[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

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

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,

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

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

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

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

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

[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

[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

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.

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

[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 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 >> >>

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’: > >

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

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

[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 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

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

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

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

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 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 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 >

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

[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

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

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

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

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

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

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

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

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] 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

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

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 ->

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] 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: > >> > >>>

[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

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

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

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

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] [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:

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

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

[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

[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:

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

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

[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

[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)

  1   2   >