On 24.09.2021 03:06, Igor Druzhinin wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -364,7 +364,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
> u8 bus, u8 devfn)
> switch ( pdev->type = pdev_type(pseg->nr, bus, devfn) )
> {
>
On 24.09.2021 04:30, Julien Grall wrote:
> Hi Roger,
>
> On Thu, 23 Sep 2021, 16:20 Roger Pau Monné, wrote:
>
>> On Thu, Sep 23, 2021 at 01:47:37PM +0500, Julien Grall wrote:
>>> Hi Roger,
>>>
>>> On 22/09/2021 14:39, Roger Pau Monné wrote:
On Wed, Sep 22, 2021 at 01:57:02PM +0500, Julien G
On 23.09.21 23:00, Stefano Stabellini wrote:
> On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Xen-pciback driver was designed to be built for x86 only. But it
>> can also be used by other architectures, e.g. Arm.
>> Re-structure the driver in a way that
On 23.09.21 22:47, Stefano Stabellini wrote:
> On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
>> Currently PCI backend implements multiple functionalities at a time.
>> To name a few:
>> 1. It is used as a database for assignable PCI devices, e.g. xl
>> pci-assignable-{add|remove|list} ma
On Thu, Sep 23, 2021 at 03:54:46PM +0200, Christophe Leroy wrote:
>
> Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
> > On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > > > From: Mike Rapoport
> > > >
> > >
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 11:05
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 31/37] xen/arm: introduce a helper to parse device
> tree NUMA dista
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 10:45
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 29/37] xen/arm: introduce a helper to parse device
> tree processor node
>
> On
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 10:10
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis ; jbeul...@suse.com;
> andrew.coop...@citrix.com; roger@citrix.com; w...@xen.org
> Subj
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 10:06
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 24/37] xen/arm: implement two arch helpers to get
> memory map info
>
> On Thu
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 9:47
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 23/37] xen/arm: implement node distance helpers for
> Arm
>
> On Thu
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 9:23
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 21/37] xen/arm: Keep memory nodes in dtb for NUMA when
> boot from EFI
>
> On Th
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 9:15
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 20/37] xen: introduce CONFIG_EFI to stub API for non-
> EFI architect
> -Original Message-
> From: Xen-devel On Behalf Of
> Stefano Stabellini
> Sent: 2021年9月24日 8:32
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis ; jbeul...@suse.com;
> andrew.coop...@citrix.com; roger@citrix.com; w...@x
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 8:26
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis ; jbeul...@suse.com;
> andrew.coop...@citrix.com; roger@citrix.com; w...@xen.org
> Subject: Re: [PA
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 10:34
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 28/37] xen/arm: stub memory hotplug access helpers for
> Arm
>
> On Thu, 23 Se
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 10:26
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 26/37] xen/arm: build NUMA cpu_to_node map in
> dt_smp_init_cpus
>
On 2021/9/24 8:29, Stefano Stabellini wrote:
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
x86 provides a mem_hotplug to maintain the end of memory hotplug
^ variable
end address. This variable can be accessed out of mm.c. We want
some code out of mm.c
flight 165169 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165169/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
test-amd64-amd64-do
flight 165170 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165170/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7ea7f9c07757b9445c24b23acf4c2e8e60b30b7e
baseline version:
ovmf 79019c7a42287e8591ec9
flight 165168 xen-unstable real [real]
flight 165172 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165168/
http://logs.test-lab.xenproject.org/osstest/logs/165172/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On Thu, 23 Sep 2021, Wei Chen wrote:
> Arm platforms support both ACPI and device tree. We don't
> want users to select device tree NUMA or ACPI NUMA manually.
> We hope usrs can just enable NUMA for Arm, and device tree
^ users
> NUMA and ACPI NUMA can be selected depends on device tree
On Thu, 23 Sep 2021, Wei Chen wrote:
> In this patch, we can start to create NUMA system that is
> based on device tree.
>
> Signed-off-by: Wei Chen
> ---
> xen/arch/arm/numa.c| 55 ++
> xen/arch/arm/setup.c | 7 +
> xen/include/asm-arm/numa
On Thu, 23 Sep 2021, Wei Chen wrote:
> The NUMA information provided in the host Device-Tree
> are only for Xen. For dom0, we want to hide them as they
> may be different (for now, dom0 is still not aware of NUMA)
> The CPU and memory nodes are recreated from scratch for the
> domain. So we already
On Thu, 23 Sep 2021, Wei Chen wrote:
> In this API, we scan whole device tree to parse CPU node id, memory
^ function ^ the whole
> node id and distance-map. Though early_scan_node will invoke has a
> handler to process memory nodes. If we want to parse memory node id
> in this handler
On Thu, 23 Sep 2021, Wei Chen wrote:
> Memory blocks' NUMA ID information is stored in device tree's
> memory nodes as "numa-node-id". We need a new helper to parse
> and verify this ID from memory nodes.
>
> Signed-off-by: Wei Chen
There are tabs for indentation in this patch, we use spaces.
On Thu, 23 Sep 2021, Wei Chen wrote:
> A NUMA aware device tree will provide a "distance-map" node to
> describe distance between any two nodes. This patch introduce a
> new helper to parse this distance map.
>
> Signed-off-by: Wei Chen
> ---
> xen/arch/arm/numa_device_tree.c | 106 +
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 8:14
> To: Stefano Stabellini
> Cc: Wei Chen ; xen-devel@lists.xenproject.org;
> jul...@xen.org; Bertrand Marquis ;
> jbeul...@suse.com; andrew.coop...@citrix.com; roger@citrix.com;
> w...@xen.org
> Subject: Re: [PAT
On Thu, 23 Sep 2021, Wei Chen wrote:
> Processor NUMA ID information is stored in device tree's processor
> node as "numa-node-id". We need a new helper to parse this ID from
> processor node. If we get this ID from processor node, this ID's
> validity still need to be checked. Once we got a invali
On Thu, 23 Sep 2021, Wei Chen wrote:
> Common code in NUMA need these two helpers to access/update
> memory hotplug end address. Arm has not support memory hotplug
> yet. So we stub these two helpers in this patch to make NUMA
> common code happy.
>
> Signed-off-by: Wei Chen
> ---
> xen/include/
Hi Roger,
On Thu, 23 Sep 2021, 16:20 Roger Pau Monné, wrote:
> On Thu, Sep 23, 2021 at 01:47:37PM +0500, Julien Grall wrote:
> > Hi Roger,
> >
> > On 22/09/2021 14:39, Roger Pau Monné wrote:
> > > On Wed, Sep 22, 2021 at 01:57:02PM +0500, Julien Grall wrote:
> > > >
> > > >
> > > > On 22/09/2021
On Thu, 23 Sep 2021, Wei Chen wrote:
> NUMA implementation has a cpu_to_node array to store CPU to NODE
> map. Xen is using CPU logical ID in runtime components, so we
> use CPU logical ID as CPU index in cpu_to_node.
>
> In device tree case, cpu_logical_map is created in dt_smp_init_cpus.
> So, w
On Thu, 23 Sep 2021, Wei Chen wrote:
> NUMA initialization will parse information from firmware provided
> static resource affinity table (ACPI SRAT or DTB). bad_srat if a
> function that will be used when initialization code encounters
> some unexcepted errors.
>
> In this patch, we introduce Arm
On Thu, 23 Sep 2021, Wei Chen wrote:
> These two helpers are architecture APIs that are required by
> nodes_cover_memory.
>
> Signed-off-by: Wei Chen
> ---
> xen/arch/arm/numa.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
>
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 7:56
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 04/37] xen: introduce an arch helper for default dma
> zone status
>
On Thu, 23 Sep 2021, Wei Chen wrote:
> We will parse NUMA nodes distances from device tree or ACPI
> table. So we need a matrix to record the distances between
> any two nodes we parsed. Accordingly, we provide this
> node_set_distance API for device tree or ACPI table parsers
> to set the distance
On Thu, 23 Sep 2021, Wei Chen wrote:
> As a memory range described in device tree cannot be split across
> multiple nodes. So we define NR_NODE_MEMBLKS as NR_MEM_BANKS in
> arch header.
This statement is true but what is the goal of this patch? Is it to
reduce code size and memory consumption?
I
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 7:45
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 02/37] xen: introduce a Kconfig option to configure
> NUMA nodes numb
On Thu, 23 Sep 2021, Wei Chen wrote:
> EFI can get memory map from EFI system table. But EFI system
> table doesn't contain memory NUMA information, EFI depends on
> ACPI SRAT or device tree memory node to parse memory blocks'
> NUMA mapping.
>
> But in current code, when Xen is booting from EFI,
On Thu, 23 Sep 2021, Wei Chen wrote:
> Some architectures do not support EFI, but EFI API will be used
> in some common features. Instead of spreading #ifdef ARCH, we
> introduce this Kconfig option to give Xen the ability of stubing
> EFI API for non-EFI supported architectures.
>
> Signed-off-by
Bus number 0xff is valid according to the PCI spec. Using u8 typed sub_bus
and assigning 0xff to it will result in the following loop getting stuck.
for ( ; sec_bus <= sub_bus; sec_bus++ ) {...}
Just change its type to u16 the same way that is already handled in
dmar_scope_add_buses().
Signe
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> As we have turned numa_scan_nodes to neutral function. If we
> still use CONFIG_ACPI_NUMA in numa_initmem_init to gate
> numa_scan_nodes that doesn't make sense. As CONFIG_ACPI_NUMA
> will be selected by CONFIG_NUMA for x86. So in this patch
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> srat_bad is used when NUMA initialization code scan SRAT failed.
> It will turn fw_numa to disabled status. Its implementation depends
> on NUMA implementation. We want every NUMA implementation to provide
> this function for common initiali
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> The most code in acpi_scan_nodes can be reused by other NUMA
> implementation. Rename acpi_scan_nodes to a more generic name
> numa_scan_nodes, and replace BIOS to Firmware in print message,
> as BIOS is x86 specific name.
>
> Signed-off-by
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> Xen is using acpi_numa as a switch for ACPI based NUMA. We want to
> use this switch logic for other firmware based NUMA implementation,
> like device tree based NUMA in follow-up patches. As Xen will never
> use both ACPI and device tree ba
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> Xen is using processor_nodes_parsed to record parsed processor nodes
> from ACPI table or other firmware provided resource table. This
> variable is used in ACPI numa functions directly. In follow-up
> patchs, neutral NUMA code will be abstr
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> We will reuse nodes_cover_memory for Arm to check its bootmem
> info. So we introduce two arch helpers to get memory map's
> entry number and specified entry's range:
> arch_get_memory_bank_number
> arch_get_memory_bank_range
>
> De
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> There is some code in acpi_numa_memory_affinity_init to update node
> memory range and update node_memblk_range array. This code is not
> ACPI specific, it can be shared by other NUMA implementation, like
> device tree based NUMA implementat
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> We want to abstract code from acpi_numa_memory_affinity_init.
> But mem_hotplug is coupled with x86. In this patch, we use
> helpers to repace mem_hotplug direct accessing. This will
^ replace
> allow most code can be common.
+x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> x86 provides a mem_hotplug to maintain the end of memory hotplug
^ variable
> end address. This variable can be accessed out of mm.c. We want
> some code out of mm.c can be reused by other architectures without
CC'ing x86 maintainers
On Thu, 23 Sep 2021, Wei Chen wrote:
> One NUMA node may contain several memory blocks. In current Xen
> code, Xen will maintain a node memory range for each node to cover
> all its memory blocks. But here comes the problem, in the gap of
> one node's two memory blocks, if t
You forgot to add the x86 maintainers in CC to all the patches touching
x86 code in this series. Adding them now but you should probably resend.
On Thu, 23 Sep 2021, Stefano Stabellini wrote:
> On Thu, 23 Sep 2021, Wei Chen wrote:
> > NUMA node structure "struct node" is using u64 as node memory
On Thu, 23 Sep 2021, Wei Chen wrote:
> NUMA node structure "struct node" is using u64 as node memory
> range. In order to make other architectures can reuse this
> NUMA node relative code, we replace the u64 to paddr_t. And
> use pfn_to_paddr and paddr_to_pfn to replace explicit shift
> operations.
On Thu, 23 Sep 2021, Wei Chen wrote:
> We have introduced CONFIG_NUMA in previous patch. And this
^ a
> option is enabled only on x86 in current stage. In a follow
^ at the
> up patch, we will enable this option for Arm. But we st
On Thu, 23 Sep 2021, Wei Chen wrote:
> In current code, when Xen is running in a multiple nodes NUMA
> system, it will set dma_bitsize in end_boot_allocator to reserve
> some low address memory for DMA.
>
> There are some x86 implications in current implementation. Becuase
On Thu, 23 Sep 2021, Wei Chen wrote:
> Current NUMA nodes number is a hardcode configuration. This
> configuration is difficult for an administrator to change
> unless changing the code.
>
> So in this patch, we introduce this new Kconfig option for
> administrators to change NUMA nodes number con
Hi Andrew.
On 08.09.21 00:28, Oleksandr wrote:
On 07.09.21 20:35, Andrew Cooper wrote:
Hi Andrew
On 07/09/2021 18:09, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest address
space size to the toolstack on Arm in order to properl
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 cho
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 cho
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest 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 used by do
From: Oleksandr Tyshchenko
You can find an initial discussion at [1],[2] and [3].
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 e
On 23.09.21 23:59, Andrew Cooper wrote:
Hi Andrew.
On 23/09/2021 20:32, Oleksandr Tyshchenko wrote:
Suggested-by: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
You can find the related discussions at:
https://lore.kernel.org/xen-devel/93d0df14-2c8a-c2e3-8c51-544121901...@xen.org/
ht
On 23/09/2021 20:32, Oleksandr Tyshchenko wrote:
> Suggested-by: Julien Grall
> Signed-off-by: Oleksandr Tyshchenko
> ---
> You can find the related discussions at:
> https://lore.kernel.org/xen-devel/93d0df14-2c8a-c2e3-8c51-544121901...@xen.org/
> https://lore.kernel.org/xen-devel/1628890077-125
Hi Stefano,
Stefano Stabellini writes:
> On Mon, 6 Sep 2021, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Allocate anonymous domheap pages as there is no strict need to
>> account them to a particular domain.
>>
>> Since XSA-383 "xen/arm: Restrict the amount of memory tha
flight 165165 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165165/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail REGR. vs. 164950
Tests which are
On Thu, 23 Sep 2021, Julien Grall wrote:
> Hi,
>
> On 23/09/2021 11:14, Hongda Deng wrote:
> > Currently, Xen will return IO unhandled when guests access GICD ICPENRn
> > registers. This will raise a data abort inside guest. For Linux Guest,
> > these virtual registers will not be accessed. But fo
On Wed, 22 Sep 2021, Rahul Singh wrote:
> 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
On Mon, 6 Sep 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Allocate anonymous domheap pages as there is no strict need to
> account them to a particular domain.
>
> Since XSA-383 "xen/arm: Restrict the amount of memory that dom0less
> domU and dom0 can allocate" the dom0 ca
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Xen-pciback driver was designed to be built for x86 only. But it
> can also be used by other architectures, e.g. Arm.
> Re-structure the driver in a way that it can be built for other
> platforms as well.
>
>
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> Currently PCI backend implements multiple functionalities at a time.
> To name a few:
> 1. It is used as a database for assignable PCI devices, e.g. xl
>pci-assignable-{add|remove|list} manipulates that list. So, whenever
>the toolstack
Hi Linus,
On Thu, Sep 23, 2021 at 09:01:46AM -0700, Linus Torvalds wrote:
> On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
> >
> You need to be a LOT more careful.
>
> From a trivial check - exactly because I looked at doing it with a
> script, and decided it's not so easy - I found cases
From: Oleksandr Tyshchenko
Rework Arm implementation to store grant table frame GFN
in struct page_info directly instead of keeping it in
standalone status/shared arrays.
To cover 64-bit/40-bit IPA on Arm64/Arm32 we need the space
to hold 52-bit/28-bit + extra bit value respectively. In order
to
On Thu, 23 Sep 2021, Rahul Singh wrote:
> >> +goto err_exit;
> >> +}
> >
> > This is unnecessary at the moment, right? Can we get rid of ops->init ?
>
> No this is required for N1SDP board. Please check below patch.
> https://gitlab.com/rahsingh/xen-integration/-/commit/6379ba5764
On 23.09.21 19:38, Stefano Stabellini wrote:
Hi Stefano
On Thu, 23 Sep 2021, Oleksandr wrote:
On 18.09.21 19:59, Oleksandr wrote:
+#define EXT_REGION_END 0x80003fffULL
+
+static int __init find_unallocated_memory(const struct kernel_info
*kinfo,
+
flight 165163 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
test-amd64-amd64-do
Hi Stefano,
> On 23 Sep 2021, at 3:09 am, Stefano Stabellini wrote:
>
> On Wed, 22 Sep 2021, Rahul Singh wrote:
>> XEN during boot will read the PCI device tree node “reg” property
>> and will map the PCI config space to the XEN memory.
>>
>> As of now only "pci-host-ecam-generic" compatible bo
flight 165161 xen-unstable real [real]
flight 165167 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165161/
http://logs.test-lab.xenproject.org/osstest/logs/165167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On Thu, 23 Sep 2021, Luca Fancellu wrote:
> >> +/*
> >> + * Binaries will be translated into bootmodules, the maximum number for
> >> them is
> >> + * MAX_MODULES where we should remove a unit for Xen and one for Xen DTB
> >> + */
> >> +#define MAX_DOM0LESS_MODULES (MAX_MODULES - 2)
> >> +static s
On Thu, 23 Sep 2021, Oleksandr wrote:
> On 18.09.21 19:59, Oleksandr wrote:
> > > > > +#define EXT_REGION_END 0x80003fffULL
> > > > > +
> > > > > +static int __init find_unallocated_memory(const struct kernel_info
> > > > > *kinfo,
> > > > > + struct mem
On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
>
> The core change is in the third patch that makes memblock_free() a
> counterpart of memblock_alloc() and adds memblock_phys_alloc() to be a
^^^
> counterpart of memblock_phys_alloc().
That should be 'memblock_phys_free()'
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> On 23.09.21 12:05, Juergen Gross wrote:
> > On 23.09.21 11:02, Oleksandr Andrushchenko wrote:
> >>
> >> On 23.09.21 00:10, Stefano Stabellini wrote:
> >>> On Wed, 22 Sep 2021, Oleksandr Andrushchenko wrote:
> --- a/drivers/xen/xen-pciback/x
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> Hi, Stefano!
>
> [snip]
>
>
> >> +};
> >> +
> >> +/* Default ECAM ops */
> >> +extern const struct pci_ecam_ops pci_generic_ecam_ops;
> > If we use container_of and get rid of sysdata, I wonder if we get avoid
> > exporting pci_generic_ecam_o
Hi Stefano,
> On 23 Sep 2021, at 3:41 am, Stefano Stabellini wrote:
>
> On Wed, 22 Sep 2021, Rahul Singh wrote:
>> 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 spac
On Thu, Sep 23, 2021 at 05:22:08PM +0200, Jan Beulich wrote:
> On 23.09.2021 17:15, Roger Pau Monné wrote:
> > On Thu, Sep 23, 2021 at 02:15:25PM +0200, Jan Beulich wrote:
> >> On 23.09.2021 13:54, Roger Pau Monné wrote:
> >>> On Thu, Sep 23, 2021 at 01:32:52PM +0200, Jan Beulich wrote:
> On 2
On 23.09.2021 17:25, Juergen Gross wrote:
> On 23.09.21 17:19, Jan Beulich wrote:
>> On 23.09.2021 17:15, Juergen Gross wrote:
>>> On 23.09.21 17:10, Jan Beulich wrote:
On 23.09.2021 16:59, Juergen Gross wrote:
> On 07.09.21 12:11, Jan Beulich wrote:
>> This was effectively lost while
On 23.09.21 17:19, Jan Beulich wrote:
On 23.09.2021 17:15, Juergen Gross wrote:
On 23.09.21 17:10, Jan Beulich wrote:
On 23.09.2021 16:59, Juergen Gross wrote:
On 07.09.21 12:11, Jan Beulich wrote:
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be
On 23.09.2021 17:15, Roger Pau Monné wrote:
> On Thu, Sep 23, 2021 at 02:15:25PM +0200, Jan Beulich wrote:
>> On 23.09.2021 13:54, Roger Pau Monné wrote:
>>> On Thu, Sep 23, 2021 at 01:32:52PM +0200, Jan Beulich wrote:
On 23.09.2021 13:10, Roger Pau Monné wrote:
> On Tue, Sep 21, 2021 at 0
Hi Stefano,
> On 23 Sep 2021, at 3:52 am, Stefano Stabellini wrote:
>
> On Wed, 22 Sep 2021, Rahul Singh wrote:
>> If the property is not present in the device tree node for host bridge,
>> XEN while creating the dtb for hwdom will create this property and
>> assigns the already allocated segmen
On 23.09.2021 17:15, Juergen Gross wrote:
> On 23.09.21 17:10, Jan Beulich wrote:
>> On 23.09.2021 16:59, Juergen Gross wrote:
>>> On 07.09.21 12:11, Jan Beulich wrote:
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as d
Hi Julien,
> On 23 Sep 2021, at 10:02 am, Julien Grall wrote:
>
> Hi Stefano,
>
> On 23/09/2021 07:23, Stefano Stabellini wrote:
>> Subject should have xen/arm
>> On Wed, 22 Sep 2021, Rahul Singh wrote:
>>> Implement generic pci access functions to read/write the configuration
>>> space.
>>>
>
Hi Julien,
> On 23 Sep 2021, at 9:52 am, Julien Grall wrote:
>
> Hi,
>
> On 23/09/2021 07:23, Stefano Stabellini wrote:
>>> diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
>>> index 4b32c7088a..5406daecda 100644
>>> --- a/xen/include/asm-arm/pci.h
>>> +++ b/xen/include/asm-ar
On 23.09.21 17:10, Jan Beulich wrote:
On 23.09.2021 16:59, Juergen Gross wrote:
On 07.09.21 12:11, Jan Beulich wrote:
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as done in PV mode. Clearly
this then needs re-introducing th
Hi Stefano,
> On 23 Sep 2021, at 3:23 am, Stefano Stabellini wrote:
>
> Subject should have xen/arm
>
>
> On Wed, 22 Sep 2021, Rahul Singh wrote:
>> Implement generic pci access functions to read/write the configuration
>> space.
>>
>> Signed-off-by: Rahul Singh
>> ---
>> Change in v2: Fixed
On Thu, Sep 23, 2021 at 02:15:25PM +0200, Jan Beulich wrote:
> On 23.09.2021 13:54, Roger Pau Monné wrote:
> > On Thu, Sep 23, 2021 at 01:32:52PM +0200, Jan Beulich wrote:
> >> On 23.09.2021 13:10, Roger Pau Monné wrote:
> >>> On Tue, Sep 21, 2021 at 09:21:11AM +0200, Jan Beulich wrote:
> ---
On 23.09.2021 16:59, Juergen Gross wrote:
> On 07.09.21 12:11, Jan Beulich wrote:
>> This was effectively lost while dropping PVHv1 code. Move the function
>> and arrange for it to be called the same way as done in PV mode. Clearly
>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserv
Hi Stefano,
> On 23 Sep 2021, at 3:11 am, Stefano Stabellini wrote:
>
> On Wed, 22 Sep 2021, Rahul Singh wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add support for Xilinx ZynqMP PCI host controller to map the PCI config
>> space to the XEN memory.
>>
>> Patch helps to understand how the ge
Hi Stefano,
> On 23 Sep 2021, at 1:14 am, Stefano Stabellini wrote:
>
> On Wed, 22 Sep 2021, Rahul Singh wrote:
>> Add cmdline boot option "pci-passthrough = = " to enable
>> disable the PCI passthrough support on ARM.
> ^ or disable
Ack.
>
>>
>> Signed-off-by: Rahul Singh
>> ---
>> Change in
On 07.09.21 12:13, Jan Beulich wrote:
Both xen_pvh and xen_start_flags get written just once aeryl during
init. Using the respective annotation then allows the open-coded placing
in .data to go away.
Additionally the former, like the latter, wants exporting, or else
xen_pvh_domain() can't be use
On 07.09.21 12:12, Jan Beulich wrote:
Two of the variables can live in .init.data, allowing the open-coded
placing in .data to go away. Another "variable" is used to communicate a
size value only to very early assembly code, which hence can be both
const and live in .init.*. Additionally two func
On 07.09.21 12:11, Jan Beulich wrote:
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as done in PV mode. Clearly
this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
check that was recently removed, as that's a P
On 07.09.21 12:10, Jan Beulich wrote:
Without announcing hvc0 as preferred it won't get used as long as tty0
gets registered earlier. This is particularly problematic with there not
being any screen output for PVH Dom0 when the screen is in graphics
mode, as the necessary information doesn't get
1 - 100 of 255 matches
Mail list logo
