flight 156160 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156160/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> Note that I tried to repro the issue here at my end but it works for me
> with device tree. So the swiotlb_init memory allocation failure probably
> only shows on ACPI, maybe because ACPI is reserving too much low memory.
Found
flight 156159 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156159/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> On Fri, 23 Oct 2020, Elliott Mitchell wrote:
> > Finally came up with one detail of a change I'd made in the right time
> > frame to trigger this issue. As such I can now control this behavior and
> > get it to occur or not.
>
flight 156127 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156127/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
flight 156143 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> This is what is going on. kernel/dma/swiotlb.c:swiotlb_init gets called
> and tries to allocate a buffer for the swiotlb. It does so by calling
>
> memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
>
> In your case, the
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug
flight 156146 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156146/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
On Fri, Oct 23, 2020 at 04:59:30PM -0700, Stefano Stabellini wrote:
> This is what is going on. kernel/dma/swiotlb.c:swiotlb_init gets called
> and tries to allocate a buffer for the swiotlb. It does so by calling
>
> memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
>
> In your case, the
On Fri, 23 Oct 2020, Stefano Stabellini wrote:
> On Fri, 23 Oct 2020, Julien Grall wrote:
> > From: Julien Grall
> >
> > The length of the GICC structure in the MADT ACPI table differs between
> > version 5.1 and 6.0, although there are no other relevant differences.
> >
> > Use the
On Fri, 23 Oct 2020, Julien Grall wrote:
> From: Julien Grall
>
> Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
>
> The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
> of the MADT. In the ACPI 5.1 version of the spec, the struct for the
>
On Fri, 23 Oct 2020, Julien Grall wrote:
> From: Julien Grall
>
> The length of the GICC structure in the MADT ACPI table differs between
> version 5.1 and 6.0, although there are no other relevant differences.
>
> Use the BAD_MADT_GICC_ENTRY macro, which was specifically designed to
> overcome
On Fri, 23 Oct 2020, Julien Grall wrote:
> From: Julien Grall
>
> At the moment Xen requires the FADT ACPI table to be at least version
> 6.0, apparently because of some reliance on other ACPI v6.0 features.
>
> But actually this is overzealous, and Xen works now fine with ACPI v5.1.
>
> Let's
On Fri, 23 Oct 2020, Julien Grall wrote:
> From: Julien Grall
>
> Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree
> later on in the boot", the device-tree will not be kept mapped when
> using ACPI.
>
> However, a few places are calling dt_unreserved_regions() which expects
>
On Fri, 23 Oct 2020, Julien Grall wrote:
> From: Julien Grall
>
> Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
> {set, clear}_fixmap()" enforced that each set_fixmap() should be
> paired with a clear_fixmap(). Any failure to follow the model would
> result to a platform
On Fri, 23 Oct 2020, Julien Grall wrote:
> From: Julien Grall
>
> The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
> while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
>
> Currently, the former are still containing x86 specific code.
>
> To avoid this
+ xen-devel
On Fri, 23 Oct 2020, Elliott Mitchell wrote:
> On Thu, Oct 22, 2020 at 06:02:46PM -0700, Stefano Stabellini wrote:
> > On Thu, 22 Oct 2020, Elliott Mitchell wrote:
> > > On Thu, Oct 22, 2020 at 04:27:23PM -0700, Stefano Stabellini wrote:
> > > > On Wed, 21 Oct 2020, Elliott Mitchell
- 23 paź, 2020 o 6:47, Jürgen Groß jgr...@suse.com napisał(a):
> On 23.10.20 00:59, Michał Leszczyński wrote:
>> Hello,
>>
>> when using DRAKVUF against a Windows 7 x64 DomU, the whole machine hangs
>> after a
>> few minutes.
>>
>> The chance for a hang seems to be correlated with number
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in
flight 156140 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
flight 156130 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156130/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On Fri, Oct 23, 2020 at 04:41:49PM +0100, Julien Grall wrote:
> Xen on ARM has been broken for quite a while on ACPI systems. This
> series aims to fix it.
>
> This series also introduced support for ACPI 5.1. This allows Xen to
> boot on QEMU.
>
> I have only build tested the x86 side so far.
flight 156133 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
flight 156129 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156117
flight 156122 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156122/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On Thu, 22 Oct 2020, Elliott Mitchell wrote:
> Linux requires UEFI support to be enabled on ARM64 devices. While many
> ARM64 devices lack ACPI, the writing seems to be on the wall of UEFI/ACPI
> potentially taking over. Some common devices may require ACPI table
> support to boot.
Let's not
On Fri, 23 Oct 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 22/10/2020 22:17, Stefano Stabellini wrote:
> > On Thu, 22 Oct 2020, Julien Grall wrote:
> > > On 22/10/2020 02:43, Elliott Mitchell wrote:
> > > > Linux requires UEFI support to be enabled on ARM64 devices. While many
> > > > ARM64
From: Paul Durrant
A subsequent patch will introduce code to allow a name to be specified to
'xl pci-assignable-add' such that the assignable device may be referred to
by than name in subsequent operations.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
docs/man/xl.1.pod.in
From: Paul Durrant
This patch adds a 'name' field into the idl for 'libxl_device_pci' and
libxlu_pci_parse_spec_string() is modified to parse the new 'name'
parameter of PCI_SPEC_STRING detailed in the updated documention in
xl-pci-configuration(5).
If the 'name' field is non-NULL then both
From: Paul Durrant
This patch largely re-writes the code to parse a PCI_SPEC_STRING and enters
it via the newly introduced function. The new parser also deals with 'bdf'
and 'vslot' as non-positional paramaters, as per the documentation in
xl-pci-configuration(5).
The existing
From: Paul Durrant
... and use in 'libxl_device_pci'
This patch is preparatory work for restricting the type passed to functions
that only require BDF information, rather than passing a 'libxl_device_pci'
structure which is only partially filled. In this patch only the minimal
mechanical
From: Paul Durrant
Currently the documentation completely fails to mention the existence of
PCI_SPEC_STRING. This patch tidies things up, specifically clarifying that
'pci-assignable-add/remove' take arguments where as 'pci-attach/detach'
take arguments (which will be enforced in a subsequent
From: Paul Durrant
A previous patch introduced libxl_device_pci_list_free() which should be used
by callers of libxl_device_pci_list() to properly dispose of the exported
'libxl_device_pci' types and the free the memory holding them. Whilst all
current callers do ensure the memory is freed, only
From: Paul Durrant
This patch modifies libxl_device_pci_assignable_add() to take an optional
'name' argument, which (if supplied) is saved into xenstore and can hence be
used to refer to the now-assignable BDF in subsequent operations. To
facilitate this, a new
From: Paul Durrant
Other parameters, such as 'msitranslate' and 'permissive' are dealt with
but 'rdm_policy' appears to be have been completely missed.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 9 ++---
1 file changed, 6
From: Paul Durrant
... rather than an open-coded equivalent.
This patch tidies up the is_pci_in_array() function, making it take a single
'libxl_device_pci' argument rather than separate domain, bus, device and
function arguments. The already-available COMPARE_PCI() macro can then be
used and
From: Paul Durrant
... to use 'libxl_pci_bdf' rather than 'libxl_device_pci'.
This patch modifies the API and callers accordingly. It also modifies
several internal functions in libxl_pci.c that support the API to also use
'libxl_pci_bdf'.
NOTE: The OCaml bindings are adjusted to contain the
From: Paul Durrant
... and prepare for adding support for non-positional parsing of 'bdf' and
'vslot' in a subsequent patch.
Also document 'BDF' as a first-class parameter type and fix the documentation
to state that the default value of 'rdm_policy' is actually 'strict', not
'relaxed', as can
From: Paul Durrant
... and put it into a new xl-pci-configuration(5) manpage, akin to the
xl-network-configration(5) and xl-disk-configuration(5) manpages.
This patch moves the content of the section verbatim. A subsequent patch
will improve the documentation, once it is in its new location.
From: Paul Durrant
... to be used by callers of libxl_device_pci_assignable_list().
Currently there is no API for callers of libxl_device_pci_assignable_list()
to free the list. The xl function pciassignable_list() calls
libxl_device_pci_dispose() on each element of the returned list, but
From: Paul Durrant
Use of this function is a very inefficient way to check whether a device
has already been assigned.
This patch adds code that saves the domain id in xenstore at the point of
assignment, and removes it again when the device id de-assigned (or the
domain is destroyed). It is
From: Paul Durrant
Since assignable devices can be named, a subsequent patch will support use
of a PCI_SPEC_STRING containing a 'name' parameter instead of a 'bdf'. In
this case the name will be used to look up the 'bdf' in the list of assignable
(or assigned) devices.
Signed-off-by: Paul
From: Paul Durrant
Currently libxl__device_pci_add_xenstore() is broken in that does not
update the domain's configuration for the first device added (which causes
creation of the overall backend area in xenstore). This can be easily observed
by running 'xl list -l' after adding a single device:
On Fri, 23 Oct 2020, Julien Grall wrote:
> On 23/10/2020 01:02, Stefano Stabellini wrote:
> > On Thu, 22 Oct 2020, Julien Grall wrote:
> > > > > On 20/10/2020 16:25, Rahul Singh wrote:
> > > > > > Add support for ARM architected SMMUv3 implementations. It is based
> > > > > > on
> > > > > > the
From: Paul Durrant
The code currently checks explicitly whether the device is already assigned,
but this is actually unnecessary as assigned devices do not form part of
the list returned by libxl_device_pci_assignable_list() and hence the
libxl_pci_assignable() test would have already failed.
From: Paul Durrant
Both 'domid' and 'pci' are available in 'pci_remove_state' so there is no
need to also pass them as separate arguments.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 9 -
1 file changed, 4 insertions(+), 5
From: Paul Durrant
It's pointless having two stack variables to hold exactly the same value.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 43 ---
1 file changed, 20 insertions(+), 23 deletions(-)
diff
From: Paul Durrant
For the purposes of re-binding a device to its previous driver
libxl__device_pci_assignable_add() writes the driver path into xenstore.
This path is then read back in libxl__device_pci_assignable_remove().
The functions that support this writing to and reading from xenstore
From: Paul Durrant
Remove open coded definition of libxl_device_pci_list().
NOTE: Using the macro also defines libxl_device_pci_list_free() so a prototype
for it is added. Subsequent patches will make used of it.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
From: Paul Durrant
The seemingly arbitrary use of 'pci' and 'pcidev' in the code in libxl_pci.c
is confusing and also compromises use of some macros used for other device
types. Indeed it seems that DEFINE_DEVICE_TYPE_STRUCT_X exists solely because
of this duality.
This patch purges use of
From: Paul Durrant
This series adds support for naming devices added to the assignable list
and then using a name (instead of a BDF) for convenience when attaching
a device to a domain.
The first 15 patches are cleanup. The remaining 10 modify documentation
and add the new functionality.
Paul
From: Paul Durrant
Remove open-coded definitions of libxl_device_nic_list() and
libxl_device_nic_list_free().
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
This patch is slightly tangential. I just happend to notice the inefficiency
while looking at code for various device
From: Paul Durrant
... to hold a pointer to the device.
There is already a 'pci' field in 'pci_add_state' so simply use that from
the start. This also allows the 'pci' (#3) argument to be dropped from
do_pci_add().
NOTE: This patch also changes the type of the 'pci_domid' field in
From: Paul Durrant
Simply spelling correction. Purely cosmetic fix.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/libs/light/libxl_pci.c
The algorithm for clearing out old lifecycle entries was wrong: it
would delete all entries for non-live tasks.
In practice this would properly remove all the old entries for
non-static tasks, since ownd tasks typically don't releease things
until the task ends (and it becomes non-live). And it
Hi Jason,
On 20/10/2020 14:27, Jason Andryuk wrote:
On Tue, May 26, 2020 at 10:13 AM Ian Jackson wrote:
Jason Andryuk writes ("[PATCH] SUPPORT: Add linux device model stubdom to
Toolstack"):
Add qemu-xen linux device model stubdomain to the Toolstack section as a
Tech Preview.
Acked-by:
Hi Jan,
On 23/10/2020 09:02, Jan Beulich wrote:
They have no definitions, and hence users, anywhere.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -155,9 +155,6 @@ bool_t pci_device_detect(u16 seg, u8 bus
int
On 23.10.2020 17:41, Julien Grall wrote:
> From: Julien Grall
>
> The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
> while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
>
> Currently, the former are still containing x86 specific code.
>
> To avoid this
Hi,
On 26/09/2020 14:00, Julien Grall wrote:
Hi Andrew,
On 22/09/2020 19:56, Andrew Cooper wrote:
On 22/09/2020 19:20, Julien Grall wrote:
+
#endif /* __ASM_DOMAIN_H__ */
/*
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5c5e55ebcb76..7564df5e8374 100644
From: Julien Grall
The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
Currently, the former are still containing x86 specific code.
To avoid this rather strange split, the generic helpers are reworked so
On 30.09.2020 15:30, Roger Pau Monné wrote:
> On Wed, Sep 30, 2020 at 12:41:08PM +0200, Roger Pau Monne wrote:
>> Introduce a per virtual timer lock that replaces the existing per-vCPU
>> and per-domain vPT locks. Since virtual timers are no longer assigned
>> or migrated between vCPUs the locking
From: Julien Grall
Dom0less requires a device-tree. However, since commit 6e3e77120378
"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
device-tree will not get unflatten when using ACPI.
This will lead to a crash during boot.
Given the complexity to setup dom0less with
From: Julien Grall
Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree
later on in the boot", the device-tree will not be kept mapped when
using ACPI.
However, a few places are calling dt_unreserved_regions() which expects
a valid DT. This will lead to a crash.
As the DT should
From: Julien Grall
The length of the GICC structure in the MADT ACPI table differs between
version 5.1 and 6.0, although there are no other relevant differences.
Use the BAD_MADT_GICC_ENTRY macro, which was specifically designed to
overcome this issue.
Signed-off-by: Julien Grall
From: Julien Grall
At the moment Xen requires the FADT ACPI table to be at least version
6.0, apparently because of some reliance on other ACPI v6.0 features.
But actually this is overzealous, and Xen works now fine with ACPI v5.1.
Let's relax the version check for the FADT table to allow QEMU
From: Julien Grall
Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
of the MADT. In the ACPI 5.1 version of the spec, the struct for the
GICC subtable (struct acpi_madt_generic_interrupt) is
From: Julien Grall
Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()" enforced that each set_fixmap() should be
paired with a clear_fixmap(). Any failure to follow the model would
result to a platform crash.
Unfortunately, the use of fixmap in the ACPI
From: Julien Grall
Hi all,
Xen on ARM has been broken for quite a while on ACPI systems. This
series aims to fix it.
This series also introduced support for ACPI 5.1. This allows Xen to
boot on QEMU.
I have only build tested the x86 side so far.
Cheers,
Julien Grall (7):
xen/acpi: Rework
On 30.09.2020 12:41, Roger Pau Monne wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1964,7 +1964,7 @@ void context_switch(struct vcpu *prev, struct vcpu
> *next)
> vpmu_switch_from(prev);
> np2m_schedule(NP2M_SCHEDLE_OUT);
>
> -if ( is_hvm_domain(prevd)
On 23/10/2020 15:27, Rahul Singh wrote:
Hello Julien,
On 23 Oct 2020, at 2:00 pm, Julien Grall wrote:
On 23/10/2020 12:35, Rahul Singh wrote:
Hello,
On 23 Oct 2020, at 1:02 am, Stefano Stabellini wrote:
On Thu, 22 Oct 2020, Julien Grall wrote:
On 20/10/2020 16:25, Rahul Singh
On 23.10.2020 16:52, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH v2 1/3] tools/libs: move official headers to
> common directory"):
>> Instead of each library having an own include directory move the
>> official headers to tools/include instead. This will drop the need to
>> link those
On 30.09.2020 12:41, Roger Pau Monne wrote:
> Currently vPT relies on timers being assigned to a vCPU and performing
> checks on every return to HVM guest in order to check if an interrupt
> from a vPT timer assigned to the vCPU is currently being injected.
>
> This model doesn't work properly
Juergen Gross writes ("[PATCH v2 1/3] tools/libs: move official headers to
common directory"):
> Instead of each library having an own include directory move the
> official headers to tools/include instead. This will drop the need to
> link those headers to tools/include and there is no need any
Hello Julien,
> On 23 Oct 2020, at 2:00 pm, Julien Grall wrote:
>
>
>
> On 23/10/2020 12:35, Rahul Singh wrote:
>> Hello,
>>> On 23 Oct 2020, at 1:02 am, Stefano Stabellini
>>> wrote:
>>>
>>> On Thu, 22 Oct 2020, Julien Grall wrote:
>> On 20/10/2020 16:25, Rahul Singh wrote:
>>>
The rework of the Xen library build introduced creating some additional
symbolic links during the build process.
This series is undoing that by moving all official Xen library headers
to tools/include and by using include paths and the vpath directive
when access to some private headers of
Instead of each library having an own include directory move the
official headers to tools/include instead. This will drop the need to
link those headers to tools/include and there is no need any longer
to have library-specific include paths when building Xen.
While at it remove setting of the
Instead of using symbolic links to include files from xenstored use
the vpath directive and an include path.
Signed-off-by: Juergen Gross
Acked-by: Christian Lindig
Tested-by: Bertrand Marquis
---
tools/libs/store/Makefile | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff
Instead of using symbolic links for accessing the xenctrl private
headers use an include path instead.
Signed-off-by: Juergen Gross
Acked-by: Christian Lindig
Tested-by: Bertrand Marquis
---
tools/libs/guest/Makefile | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git
flight 156118 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156118/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 152631
build-amd64
On 10/22/20 5:49 AM, Juergen Gross wrote:
> Do some cleanups in Xen event handling code.
>
> Changes in V2:
> - addressed comments
>
> Juergen Gross (5):
> xen: remove no longer used functions
> xen/events: make struct irq_info private to events_base.c
> xen/events: only register debug
Juergen Gross writes ("[PATCH 0/2] maintainers: correct some entries"):
> Fix some paths after reorg of library locations, and drop unreachable
> maintainer.
Thanks, both
Acked-by: Ian Jackson
and committed.
Ian.
Juergen Gross writes ("[PATCH 0/3] tools: avoid creating symbolic links during
make"):
> The rework of the Xen library build introduced creating some additional
> symbolic links during the build process.
>
> This series is undoing that by moving all official Xen library headers
> to
On 23/10/2020 12:35, Rahul Singh wrote:
Hello,
On 23 Oct 2020, at 1:02 am, Stefano Stabellini wrote:
On Thu, 22 Oct 2020, Julien Grall wrote:
On 20/10/2020 16:25, Rahul Singh wrote:
Add support for ARM architected SMMUv3 implementations. It is based on
the Linux SMMUv3 driver.
Major
On 30.09.2020 12:41, Roger Pau Monne wrote:
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -327,9 +327,10 @@ static void hvm_gsi_eoi(struct domain *d, unsigned int
> gsi,
> hvm_pirq_eoi(pirq, ent);
> }
>
> -void hvm_dpci_eoi(unsigned int guest_gsi, const
On 30.09.2020 12:41, Roger Pau Monne wrote:
> This is code movement in order to simply further changes.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
albeit ...
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -276,6
On 30.09.2020 12:41, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -595,6 +595,66 @@ int hvm_local_events_need_delivery(struct vcpu *v)
> return !hvm_interrupt_blocked(v, intack);
> }
>
> +int hvm_gsi_register_callback(struct domain *d, unsigned
Hi Stefano,
On 23/10/2020 01:02, Stefano Stabellini wrote:
On Thu, 22 Oct 2020, Julien Grall wrote:
On 20/10/2020 16:25, Rahul Singh wrote:
Add support for ARM architected SMMUv3 implementations. It is based on
the Linux SMMUv3 driver.
Major differences between the Linux driver are as
flight 156117 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156117/
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
Hello Julien,
> On 22 Oct 2020, at 9:32 am, Julien Grall wrote:
>
>
>
> On 21/10/2020 12:25, Rahul Singh wrote:
>> Hello Julien,
>
> Hi Rahul,
>
>>> On 20 Oct 2020, at 6:03 pm, Julien Grall wrote:
>>>
>>> Hi Rahul,
>>>
>>> Thank you for the contribution. Lets make sure this attempt to
Hello,
> On 23 Oct 2020, at 1:02 am, Stefano Stabellini wrote:
>
> On Thu, 22 Oct 2020, Julien Grall wrote:
On 20/10/2020 16:25, Rahul Singh wrote:
> Add support for ARM architected SMMUv3 implementations. It is based on
> the Linux SMMUv3 driver.
> Major differences between
Build this code into an archive, partly paralleling bsearch().
Signed-off-by: Jan Beulich
---
xen/common/Makefile| 1 -
xen/lib/Makefile | 1 +
xen/{common => lib}/sort.c | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename xen/{common => lib}/sort.c (100%)
diff --git
Convert this code to an inline function (backed by an instance in an
archive in case the compiler decides against inlining), which results
in not having it in x86 final binaries. This saves a little bit of dead
code.
Signed-off-by: Jan Beulich
---
v2: Make the function an extern inline in its
Build this code into an archive, which results in not linking it into
x86 final binaries. This saves about 1.5k of dead code.
While moving the source file, take the opportunity and drop the
pointless EXPORT_SYMBOL().
Signed-off-by: Jan Beulich
---
xen/common/Makefile | 1 -
... into its own CU, to build it into an archive.
Signed-off-by: Jan Beulich
... into its own CU, to build it into an archive.
Signed-off-by: Jan Beulich
---
xen/common/lib.c | 39 --
xen/lib/Makefile | 1 +
xen/lib/parse-size.c | 50
... into its own CU, for being unrelated to other things in
common/lib.c. For now it gets compiled into built_in.o rather than
lib.a, as it gets used unconditionally by Arm's as well as x86'es
{,__}start_xen(). But this could be changed in principle, the more that
there typically aren't any
Build the source file always, as by putting it into an archive it still
won't be linked into final binaries when not needed. This way possible
build breakage will be easier to notice, and it's more consistent with
us unconditionally building other library kind of code (e.g. sort() or
bsearch()).
This is, besides for tidying, in preparation of then starting to use an
archive rather than an object file for generic library code which
arch-es (or even specific configurations within a single arch) may or
may not need.
Signed-off-by: Jan Beulich
---
xen/Makefile | 3 ++-
xen/Rules.mk
In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
just to avoid bloating binaries when only some arch-es and/or
configurations need generic library routines, combine objects under lib/
into an archive, which the linker then can pick the necessary objects
out of.
Note that we
In a few cases we link in library-like functions when they're not
actually needed. While we could use Kconfig options for each one
of them, I think the better approach for such generic code is to
build it always (thus making sure a build issue can't be introduced
for these in any however exotic
1 - 100 of 124 matches
Mail list logo
