[linux-linus test] 165510: tolerable FAIL - PUSHED

flight 165510 linux-linus real [real] flight 165517 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165510/ http://logs.test-lab.xenproject.org/osstest/logs/165517/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

[PATCH] xen/pvcalls-back: Remove redundant 'flush_workqueue()' calls

'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by:

[PATCH v2 4/6] xen/arm: if direct-map domain use native addresses for GICv3

From: Stefano Stabellini Today we use native addresses to map the GICv3 for Dom0 and fixed addresses for DomUs. This patch changes the behavior so that native addresses are used for all direct-map domains(including Dom0). Considering that dom0 may not always be directly mapped in the future,

[PATCH v2 6/6] xen/docs: add a document to explain how to do passthrough without IOMMU

From: Stefano Stabellini Make sure to start with a WARNING about security. Signed-off-by: Stefano Stabellini Signed-off-by: Penny Zheng --- docs/misc/arm/passthrough-noiommu.txt | 54 +++ 1 file changed, 54 insertions(+) create mode 100644

[PATCH v2 5/6] xen/arm: if direct-map domain use native UART address and IRQ number for vPL011

From: Stefano Stabellini We always use a fix address to map the vPL011 to domains. The address could be a problem for direct-map domains. So, for domains that are directly mapped, reuse the address of the physical UART on the platform to avoid potential clashes. Do the same for the virtual IRQ

[PATCH v2 3/6] xen/arm: if direct-map domain use native addresses for GICv2

From: Stefano Stabellini Today we use native addresses to map the GICv2 for Dom0 and fixed addresses for DomUs. This patch changes the behavior so that native addresses are used for all domains that are direct-map memory map. NEW VGIC has different naming schemes, like referring distributor

[PATCH v2 2/6] xen/arm: introduce direct-map for domUs

From: Stefano Stabellini Cases where domU needs direct-map memory map: * IOMMU not present in the system. * IOMMU disabled if it doesn't cover a specific device and all the guests are trusted. Thinking a mixed scenario, where a few devices with IOMMU and a few without, then guest DMA

[PATCH v2 1/6] xen: introduce XEN_DOMCTL_CDF_directmap

From: Stefano Stabellini This commit introduces a new arm-specific flag XEN_DOMCTL_CDF_directmap to specify that this domain should have its memory directly mapped (guest physical address == physical address) at domain creation. Refine is_domain_direct_mapped to check whether the flag

[PATCH v2 0/6] direct-map memory map

Cases where domU needs direct-map memory map: * IOMMU not present in the system. * IOMMU disabled if it doesn't cover a specific device and all the guests are trusted. Thinking a mixed scenario, where a few devices with IOMMU and a few without, then guest DMA security still could not be

[xen-unstable test] 165509: tolerable FAIL - PUSHED

flight 165509 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/165509/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 165503

Re: [PATCH v6 3/3] arm/libxl: Emulated PCI device tree node in libxl [and 1 more messages]

On Thu, 14 Oct 2021, Ian Jackson wrote: > (Replying to both the earlier subthread on v5 and to the new v6 > patch.) > > Bertrand Marquis writes ("Re: [PATCH v5 10/11] arm/libxl: Emulated PCI device > tree node in libxl"): > > Now you suggest to add a new field arm_vpci in

Re: [PATCH v6 2/3] xen/arm: Enable the existing x86 virtual PCI support for ARM.

On Thu, 14 Oct 2021, Bertrand Marquis wrote: > From: Rahul Singh > > The existing VPCI support available for X86 is adapted for Arm. > When the device is added to XEN via the hyper call > “PHYSDEVOP_pci_device_add”, VPCI handler for the config space > access is added to the Xen to emulate the

Re: [PATCH v6 1/3] xen/vpci: Move ecam access functions to common code

On Thu, 14 Oct 2021, Bertrand Marquis wrote: > PCI standard is using ECAM and not MCFG which is coming from ACPI[1]. > Use ECAM/ecam instead of MCFG in common code and in new functions added > in common vpci code by this patch. > > Rename vpci_access_allowed to vpci_ecam_access_allowed and move

[xen-unstable-smoke test] 165512: tolerable all pass - PUSHED

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

Re: Xen Booting Problem on ARM Machine

On Thu, 14 Oct 2021, Sai Kiran Kumar Reddy Y wrote: > On Thu, Oct 14, 2021 at 5:45 AM Stefano Stabellini > wrote: > On Wed, 13 Oct 2021, Sai Kiran Kumar Reddy Y wrote: > > On Fri, Oct 1, 2021 at 8:17 AM Stefano Stabellini > wrote: > >       Yes there are other ways but

[qemu-mainline test] 165506: tolerable FAIL - PUSHED

flight 165506 qemu-mainline real [real] flight 165513 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165506/ http://logs.test-lab.xenproject.org/osstest/logs/165513/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [PATCH] xen/pvcalls-back: Remove redundant 'flush_workqueue()' calls

On Thu, 14 Oct 2021, Christophe JAILLET wrote: > 'destroy_workqueue()' already drains the queue before destroying it, so > there is no need to flush it explicitly. > > Remove the redundant 'flush_workqueue()' calls. > > This was generated with coccinelle: > > @@ > expression E; > @@ > -

[xen-unstable-smoke test] 165511: tolerable all pass - PUSHED

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

Re: [PATCH v6 3/3] arm/libxl: Emulated PCI device tree node in libxl [and 1 more messages]

(Replying to both the earlier subthread on v5 and to the new v6 patch.) Bertrand Marquis writes ("Re: [PATCH v5 10/11] arm/libxl: Emulated PCI device tree node in libxl"): > Now you suggest to add a new field arm_vpci in libxl__domain_create_state. Hi. I was handwaving, hence "probably" :-).

Re: [PATCH V7 0/2] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

Hello all On 14.10.21 14:40, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko You can find an initial discussion at [1]-[7]. The extended region (safe range) is a region of guest physical address space which is unused and could be safely used to create grant/foreign mappings

Re: [PATCH v5 10/11] arm/libxl: Emulated PCI device tree node in libxl

Hi Ian, > On 7 Oct 2021, at 17:11, Ian Jackson wrote: > > Rahul Singh writes ("Re: [PATCH v5 10/11] arm/libxl: Emulated PCI device tree > node in libxl"): >> As Stefano suggested in another email that we can remove the vpci >> option, if we reach to conclusion that we need vpci option I will

Re: [PATCH v6 1/3] xen/vpci: Move ecam access functions to common code

Hi Jan, > On 14 Oct 2021, at 17:06, Jan Beulich wrote: > > On 14.10.2021 16:49, Bertrand Marquis wrote: >> @@ -305,7 +291,7 @@ static int vpci_portio_read(const struct hvm_io_handler >> *handler, >> >> reg = hvm_pci_decode_addr(cf8, addr, ); >> >> -if ( !vpci_access_allowed(reg,

Re: [future abi] [RFC PATCH V3] xen/gnttab: Store frame GFN in struct page_info on Arm

Hello, all. The potential issue on Arm (which might happen when remapping grant-table frame) is still present, it hasn't disappeared. Some effort was put in trying to fix that by current patch. Although I have addressed (I hope) all review comments received for this patch, I realize this

Re: [PATCH v6 1/3] xen/vpci: Move ecam access functions to common code

On 14.10.2021 16:49, Bertrand Marquis wrote: > @@ -305,7 +291,7 @@ static int vpci_portio_read(const struct hvm_io_handler > *handler, > > reg = hvm_pci_decode_addr(cf8, addr, ); > > -if ( !vpci_access_allowed(reg, size) ) > +if ( !vpci_ecam_access_allowed(reg, size) ) >

[ovmf test] 165508: all pass - PUSHED

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

Re: [PATCH V7 0/2] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

On 14.10.21 17:28, Ian Jackson wrote: Hi Ian Oleksandr Tyshchenko writes ("[PATCH V7 0/2] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")"): You can find an initial discussion at [1]-[7]. The extended region

Re: [PING] Re: [PATCH] xen/arm: optee: Allocate anonymous domheap pages

Hi Stefano, On 08/10/2021 22:49, Stefano Stabellini wrote: On Fri, 8 Oct 2021, Julien Grall wrote: On 07/10/2021 23:14, Stefano Stabellini wrote: On Thu, 7 Oct 2021, Volodymyr Babchuk wrote: Hi Stefano, Stefano Stabellini writes: On Wed, 6 Oct 2021, Oleksandr wrote: Hello all Gentle

Re: [XEN PATCH v7 30/51] build: hook kconfig into xen build system

On Mon, Oct 11, 2021 at 05:38:47PM +0200, Jan Beulich wrote: > On 24.08.2021 12:50, Anthony PERARD wrote: > > Now that xen's build system is very close to Linux's ones, we can hook > > "Makefile.host" into Xen's build system, and we can build Kconfig with > > that. > > > > Signed-off-by: Anthony

[PATCH v6 2/3] xen/arm: Enable the existing x86 virtual PCI support for ARM.

From: Rahul Singh The existing VPCI support available for X86 is adapted for Arm. When the device is added to XEN via the hyper call “PHYSDEVOP_pci_device_add”, VPCI handler for the config space access is added to the Xen to emulate the PCI devices config space. A MMIO trap handler for the PCI

[PATCH v6 3/3] arm/libxl: Emulated PCI device tree node in libxl

From: Rahul Singh libxl will create an emulated PCI device tree node in the device tree to enable the guest OS to discover the virtual PCI during guest boot. Emulated PCI device tree node will only be created when there is any device assigned to guest. A new area has been reserved in the arm

[PATCH v6 1/3] xen/vpci: Move ecam access functions to common code

PCI standard is using ECAM and not MCFG which is coming from ACPI[1]. Use ECAM/ecam instead of MCFG in common code and in new functions added in common vpci code by this patch. Rename vpci_access_allowed to vpci_ecam_access_allowed and move it from arch/x86/hvm/io.c to drivers/vpci/vpci.c.

[PATCH v6 0/3] PCI devices passthrough on Arm

Hello All, This serie is a follow up on Rahul serie where we included various fixes required after review on the mailing list and a new patch to move some of the x86 ecam related code to the common vpci code. Most of the patches of the original serie have been merged and this serie includes only

Re: [PATCH V7 0/2] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

Oleksandr Tyshchenko writes ("[PATCH V7 0/2] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")"): > You can find an initial discussion at [1]-[7]. > > The extended region (safe range) is a region of guest physical

Re: [XEN PATCH v7 38/51] build: use main rune to build host binary x86's mkelf32 and mkreloc

On Mon, Oct 11, 2021 at 05:56:06PM +0200, Jan Beulich wrote: > On 24.08.2021 12:50, Anthony PERARD wrote: > > Signed-off-by: Anthony PERARD > > Acked-by: Jan Beulich > > > --- a/xen/arch/x86/Makefile > > +++ b/xen/arch/x86/Makefile > > @@ -81,6 +81,10 @@ endif > > extra-y += asm-macros.i > >

Re: [XEN PATCH v7 32/51] build: Remove KBUILD_ specific from Makefile.host

On Mon, Oct 11, 2021 at 05:47:29PM +0200, Jan Beulich wrote: > On 24.08.2021 12:50, Anthony PERARD wrote: > > This will allow $(HOSTCFLAGS) to actually be used when building > > programmes for the build-host. > > > > The other variable don't exist in our build system. > > > > Also remove

Re: [PATCH 2/2] memory: XENMEM_add_to_physmap (almost) wrapping checks

On 14.10.2021 13:29, Julien Grall wrote: > On 13/09/2021 07:42, Jan Beulich wrote: >> Determining that behavior is correct (i.e. results in failure) for a >> passed in GFN equaling INVALID_GFN is non-trivial. Make this quite a >> bit more obvious by checking input in generic code - both for

[xen-unstable-smoke test] 165507: tolerable all pass - PUSHED

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

Re: [XEN PATCH v7 27/51] build: introduce if_changed_deps

On Mon, Oct 11, 2021 at 04:20:36PM +0200, Jan Beulich wrote: > On 24.08.2021 12:50, Anthony PERARD wrote: > > @@ -400,7 +407,7 @@ $(TARGET).gz: $(TARGET) > > gzip -n -f -9 < $< > $@.new > > mv $@.new $@ > > > > -$(TARGET): FORCE > > +$(TARGET): tools_fixdep FORCE > > $(MAKE) -C tools

Re: [XEN PATCH v7 26/51] build: build everything from the root dir, use obj=$subdir

On 14.10.2021 15:33, Anthony PERARD wrote: > On Wed, Oct 13, 2021 at 03:24:31PM +0100, Anthony PERARD wrote: >> On Mon, Oct 11, 2021 at 04:02:22PM +0200, Jan Beulich wrote: >>> On 24.08.2021 12:50, Anthony PERARD wrote: ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y) cmd_cc_o_c = $(CC)

Re: [PATCH V7 2/2] libxl/arm: Add handling of extended regions for DomU

Julien Grall writes ("Re: [PATCH V7 2/2] libxl/arm: Add handling of extended regions for DomU"): > On 14/10/2021 12:40, Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko ... > > Suggested-by: Julien Grall > > Signed-off-by: Oleksandr Tyshchenko > > Reviewed-by: Julien Grall Again,

Re: [XEN PATCH v7 26/51] build: build everything from the root dir, use obj=$subdir

On Wed, Oct 13, 2021 at 03:24:31PM +0100, Anthony PERARD wrote: > On Mon, Oct 11, 2021 at 04:02:22PM +0200, Jan Beulich wrote: > > On 24.08.2021 12:50, Anthony PERARD wrote: > > > ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y) > > > cmd_cc_o_c = $(CC) $(c_flags) -c $< -o $(dot-target).tmp -MQ $@

[libvirt test] 165504: regressions - FAIL

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

[xen-unstable test] 165503: tolerable FAIL - PUSHED

flight 165503 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/165503/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 165491

Re: [PATCH V7 2/2] libxl/arm: Add handling of extended regions for DomU

Hi Oleksandr, On 14/10/2021 12:40, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko The extended region (safe range) is a region of guest physical address space which is unused and could be safely used to create grant/foreign mappings instead of wasting real RAM pages from the domain

[ovmf test] 165505: all pass - PUSHED

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

Re: [PATCH V6 2/2] libxl/arm: Add handling of extended regions for DomU

Hi Stefano On 13.10.21 23:24, Stefano Stabellini wrote: On Wed, 13 Oct 2021, Oleksandr wrote: On 13.10.21 21:26, Oleksandr wrote: On 13.10.21 20:07, Julien Grall wrote: Hi Julien Hi, On 13/10/2021 17:44, Oleksandr wrote: On 13.10.21 19:24, Julien Grall wrote: On 13/10/2021 16:49,

[PATCH V7 2/2] libxl/arm: Add handling of extended regions for DomU

From: Oleksandr Tyshchenko The extended region (safe range) is a region of guest physical address space which is unused and could be safely used to create grant/foreign mappings instead of wasting real RAM pages from the domain memory for establishing these mappings. The extended regions are

[PATCH V7 1/2] xen/arm: Introduce gpaddr_bits field to struct xen_domctl_getdomaininfo

From: Oleksandr Tyshchenko We need to pass info about maximum supported guest physical address space size to the toolstack on Arm in order to properly calculate the base and size of the extended region (safe range) for the guest. The extended region is unused address space which could be safely

[PATCH V7 0/2] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

From: Oleksandr Tyshchenko You can find an initial discussion at [1]-[7]. The extended region (safe range) is a region of guest physical address space which is unused and could be safely used to create grant/foreign mappings instead of wasting real RAM pages from the domain memory for

Re: [PATCH] Revert "xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag"

Michal Orzel writes ("[PATCH] Revert "xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag""): > This reverts commit 2075b410ee8087662c880213c3aca196fb7ade22. > > During the discussion [1] that took place after > the patch was merged it was agreed that it should > be reverted to avoid introducing a

Re: [PATCH 2/2] memory: XENMEM_add_to_physmap (almost) wrapping checks

Hi Jan, On 13/09/2021 07:42, Jan Beulich wrote: Determining that behavior is correct (i.e. results in failure) for a passed in GFN equaling INVALID_GFN is non-trivial. Make this quite a bit more obvious by checking input in generic code - both for singular requests to not match the value and

Re: [XEN PATCH v7 50/51] build: specify source tree in include/ for prerequisite

On 24.08.2021 12:50, Anthony PERARD wrote: > When doing an out-of-tree build, and thus setting VPATH, > GNU Make 0.81 on Ubuntu Trusty complains about Circular dependency of > include/Makefile and include/xlat.lst and drop them. The build fails > later due to headers malformed. Doesn't this

Re: [PATCH] Revert "xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag"

On 14/10/2021 10:42, Christian Lindig wrote: On 14 Oct 2021, at 10:33, Julien Grall > wrote: Looking at the thread, we are only missing an ack for... ---  tools/ocaml/libs/xc/xenctrl.ml  | 1 - >   tools/ocaml/libs/xc/xenctrl.mli | 1 - Acked-by: Christian Lindig

Re: [XEN PATCH v7 49/51] build: adding out-of-tree support to the xen build

On 24.08.2021 12:50, Anthony PERARD wrote: > This implement out-of-tree support, there's two ways to create an > out-of-tree build tree (after that, `make` in that new directory > works): > make O=build > mkdir build; cd build; make -f ../Makefile > also works with an absolute path for

Re: [XEN PATCH v7 48/51] build: Rework "headers*.chk" prerequisite in include/

On 24.08.2021 12:50, Anthony PERARD wrote: > Listing public headers when out-of-tree build are involved becomes > more annoying where every path to every headers needs to start with > "$(srctree)/$(src)", or $(wildcard ) will not work. This means more > repetition. > > This patch attempt to

Re: [XEN PATCH v7 47/51] build: Rework "clean" to clean from the root dir

On 24.08.2021 12:50, Anthony PERARD wrote: > This will allow "clean" to work from an out-of-tree build when > it will be available. > > Some of the file been removed in current "clean" target aren't added > to $(clean-files) because they are already listed in $(extra-) or > $(extra-y). > > Also

Re: [PATCH] Revert "xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag"

On 14 Oct 2021, at 10:33, Julien Grall mailto:jul...@xen.org>> wrote: Looking at the thread, we are only missing an ack for... --- tools/ocaml/libs/xc/xenctrl.ml | 1 - > tools/ocaml/libs/xc/xenctrl.mli | 1 - Acked-by: Christian Lindig mailto:christian.lin...@citrix.com>>

Re: [XEN PATCH v7 46/51] build: replace $(BASEDIR) by $(srctree)

On 24.08.2021 12:50, Anthony PERARD wrote: > $(srctree) is a better description for the source directory than > $(BASEDIR) that has been used for both source and build directory > (which where the same). > > "clean" is still changing directory, so we need to use absolute path > for it. > >

[qemu-mainline test] 165498: tolerable FAIL - PUSHED

flight 165498 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/165498/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 165488 test-amd64-amd64-qemuu-nested-amd

Re: [PATCH] Revert "xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag"

Hi Michal, On 14/10/2021 09:47, Michal Orzel wrote: This reverts commit 2075b410ee8087662c880213c3aca196fb7ade22. During the discussion [1] that took place after the patch was merged it was agreed that it should be reverted to avoid introducing a bad interface. Furthermore, the patch rejected

Re: [XEN PATCH v7 45/51] build: rework cloc recipe

On 24.08.2021 12:50, Anthony PERARD wrote: > After folowing patches, the recipe doesn't work anymore. > - build: build everything from the root dir, use obj=$subdir > - build: introduce if_changed_deps That was some 20 patches ago - shouldn't all make goals continue to work at every step?

Re: [PATCH v2] xen/arm: vgic to ignore GICD ICPENRn registers access

On 14/10/2021 07:55, Hongda Deng wrote: Hi, Hi, -Original Message- From: Julien Grall Sent: 2021年10月13日 5:58 To: Hongda Deng ; xen-devel@lists.xenproject.org; sstabell...@kernel.org Cc: Bertrand Marquis ; Wei Chen Subject: Re: [PATCH v2] xen/arm: vgic to ignore GICD ICPENRn

Re: [XEN PATCH v7 44/51] build: add $(srctree) in few key places

On 24.08.2021 12:50, Anthony PERARD wrote: > This adds $(srctree) to a few path where make's VPATH=$(srctree) won't > apply. > > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich

Re: [PATCH v5 08/11] xen/arm: Enable the existing x86 virtual PCI support for ARM.

On 14.10.2021 11:03, Bertrand Marquis wrote: > Hi Jan, > >> On 14 Oct 2021, at 07:33, Jan Beulich wrote: >> >> On 13.10.2021 21:27, Stefano Stabellini wrote: >>> On Wed, 13 Oct 2021, Jan Beulich wrote: On 13.10.2021 16:51, Oleksandr Andrushchenko wrote: > On 13.10.21 16:00, Jan Beulich

Re: [XEN PATCH v7 43/51] build: replace $(BASEDIR) by $(objtree)

On 24.08.2021 12:50, Anthony PERARD wrote: > We need to differentiate between source files and generated/built > files. We will be replacing $(BASEDIR) by $(objtree) for files that > are generated, and $(abs_objtree) in cases where an absolute path is > necessary. > > The "clean" target is still

Re: [PATCH v5 08/11] xen/arm: Enable the existing x86 virtual PCI support for ARM.

Hi Jan, > On 14 Oct 2021, at 07:33, Jan Beulich wrote: > > On 13.10.2021 21:27, Stefano Stabellini wrote: >> On Wed, 13 Oct 2021, Jan Beulich wrote: >>> On 13.10.2021 16:51, Oleksandr Andrushchenko wrote: On 13.10.21 16:00, Jan Beulich wrote: > On 13.10.2021 10:45, Roger Pau Monné

Re: [PATCH] Revert "xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag"

Hi Michal, > On 14 Oct 2021, at 09:47, Michal Orzel wrote: > > This reverts commit 2075b410ee8087662c880213c3aca196fb7ade22. > > During the discussion [1] that took place after > the patch was merged it was agreed that it should > be reverted to avoid introducing a bad interface. > >

Re: [PATCH] Revert "xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag"

On 14.10.2021 10:47, Michal Orzel wrote: > This reverts commit 2075b410ee8087662c880213c3aca196fb7ade22. > > During the discussion [1] that took place after > the patch was merged it was agreed that it should > be reverted to avoid introducing a bad interface. > > Furthermore, the patch rejected

Re: [XEN PATCH v7 42/51] build: grab common EFI source files in arch specific dir

On 24.08.2021 12:50, Anthony PERARD wrote: > Rather than preparing the efi source file, we will copy them as needed > from the build location. > > Avoid the links as they seems fragile in out-of-tree builds. Also by > making a copy, we don't need to figure out the relative path or we > don't need

[PATCH] Revert "xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag"

This reverts commit 2075b410ee8087662c880213c3aca196fb7ade22. During the discussion [1] that took place after the patch was merged it was agreed that it should be reverted to avoid introducing a bad interface. Furthermore, the patch rejected usage of flag XEN_DOMCTL_CDF_vpci for x86 which is not

Re: Xen Booting Problem on ARM Machine

On Thu, Oct 14, 2021 at 5:45 AM Stefano Stabellini wrote: > On Wed, 13 Oct 2021, Sai Kiran Kumar Reddy Y wrote: > > On Fri, Oct 1, 2021 at 8:17 AM Stefano Stabellini < > sstabell...@kernel.org> wrote: > > Yes there are other ways but without serial is going to be > difficult > >

Re: [XEN PATCH v7 41/51] build,x86: remove the need for build32.mk

On 24.08.2021 12:50, Anthony PERARD wrote: > --- a/xen/arch/x86/boot/Makefile > +++ b/xen/arch/x86/boot/Makefile > @@ -1,23 +1,51 @@ > obj-bin-y += head.o > +head-objs := cmdline.S reloc.S > > -DEFS_H_DEPS = $(BASEDIR)/$(src)/defs.h $(BASEDIR)/include/xen/stdbool.h > +nocov-y +=

Re: [XEN PATCH v7 40/51] build: fix dependencies in arch/x86/boot

On 24.08.2021 12:50, Anthony PERARD wrote: > Temporary fix the list of headers that cmdline.c and reloc.c depends > on, until the next time the list is out of sync again. > > Also, add the linker script to the list. > > Signed-off-by: Anthony PERARD Reviewed-by: Jan Beulich Afaict this is

Re: [PATCH v5 08/11] xen/arm: Enable the existing x86 virtual PCI support for ARM.

Hi, > On 14 Oct 2021, at 07:33, Jan Beulich wrote: > > On 13.10.2021 21:27, Stefano Stabellini wrote: >> On Wed, 13 Oct 2021, Jan Beulich wrote: >>> On 13.10.2021 16:51, Oleksandr Andrushchenko wrote: On 13.10.21 16:00, Jan Beulich wrote: > On 13.10.2021 10:45, Roger Pau Monné wrote:

Re: [PATCH v5 07/11] xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag

Hi, > On 14 Oct 2021, at 07:23, Jan Beulich wrote: > > On 13.10.2021 22:41, Stefano Stabellini wrote: >> On Wed, 13 Oct 2021, Jan Beulich wrote: >>> On 13.10.2021 14:11, Bertrand Marquis wrote: > On 13 Oct 2021, at 11:56, Roger Pau Monné wrote: > If vPCI for Arm on 4.16 is not going to

[ovmf test] 165502: all pass - PUSHED

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

RE: [PATCH v2] xen/arm: vgic to ignore GICD ICPENRn registers access

Hi, > -Original Message- > From: Julien Grall > Sent: 2021年10月13日 5:58 > To: Hongda Deng ; xen-devel@lists.xenproject.org; > sstabell...@kernel.org > Cc: Bertrand Marquis ; Wei Chen > > Subject: Re: [PATCH v2] xen/arm: vgic to ignore GICD ICPENRn registers access > > Hi, > > On

Re: [XEN PATCH v7 51/51] build: add %.E targets

On 13.10.2021 17:48, Jan Beulich wrote: > On 24.08.2021 12:50, Anthony PERARD wrote: >> I guess it's easier to remember that %.E does "$(CC) -E" or "$(CPP)". > > I've never seen any *.E. I'm puzzled (and hence have reservations, but > then again don't care enough to object). Actually I've

Re: [PATCH v5 08/11] xen/arm: Enable the existing x86 virtual PCI support for ARM.

On 13.10.2021 21:27, Stefano Stabellini wrote: > On Wed, 13 Oct 2021, Jan Beulich wrote: >> On 13.10.2021 16:51, Oleksandr Andrushchenko wrote: >>> On 13.10.21 16:00, Jan Beulich wrote: On 13.10.2021 10:45, Roger Pau Monné wrote: > On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh

Re: [PATCH v5 07/11] xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag

On 13.10.2021 22:41, Stefano Stabellini wrote: > On Wed, 13 Oct 2021, Jan Beulich wrote: >> On 13.10.2021 14:11, Bertrand Marquis wrote: On 13 Oct 2021, at 11:56, Roger Pau Monné wrote: If vPCI for Arm on 4.16 is not going to be functional, why so much pressure in pushing those