On 22/10/2020 17.29, Paolo Bonzini wrote:
> On 22/10/20 17:17, Jason Andryuk wrote:
>> On Tue, Oct 13, 2020 at 1:16 PM Paolo Bonzini wrote:
>>>
>>> On 13/10/20 16:05, Jason Andryuk wrote:
Xen was left behind when CpusAccel became mandatory and fails the assert
in qemu_init_vcpu(). It re
On 22.10.2020 21:18, Elliott Mitchell wrote:
> On Thu, Oct 22, 2020 at 07:44:26PM +0100, Julien Grall wrote:
>> Thank you for the patch. FIY I tweak a bit the commit title before
>> committing.
>>
>> The title is now: "xen/arm: acpi: Don't fail it SPCR table is absent".
>
> Perhaps "xen/arm: acpi
On 23.10.2020 05:35, Elliott Mitchell wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -32,13 +32,18 @@ menu "Architecture Features"
> source "arch/Kconfig"
>
> config ACPI
> - bool "ACPI (Advanced Configuration and Power Interface) Support" if
> EXPERT
> + bool "A
They have no definitions, and hence users, anywhere.
Signed-off-by: Jan Beulich
--- 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 scan_pci_devices(void);
enum pdev_type pdev_type(u16 seg, u8 bus, u8 devfn);
int find_upstre
Parts of this were discussed in the context of Andrew's CET-SS work.
Further parts simply fit the underlying picture. And a few patches
towards the end get attached here simply because of their dependency.
Patch 7 is new.
All patches except for the new ones in principle have acks / R-b-s
which wou
Introduce proper assembler macros instead, enabled only when the
assembler itself doesn't support the insns. To avoid duplicating the
macros for assembly and C files, have them processed into asm-macros.h.
This in turn requires adding a multiple inclusion guard when generating
that header.
No chan
Use ALTERNATIVE directly, such that at the use sites it is visible that
alternative code patching is in use. Similarly avoid hiding the fact in
SAVE_ALL.
No change to generated code.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Further adjust comment in asm_domain_crash_synchro
Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
to introduce a number of #ifdef-s to make the build work with older tool
chains. Introduce an assembler macro covering for tool chains not
knowing of CET-SS, allowing some conditionals where just SETSSBSY is the
problem to be d
There's little point in having two separate headers both getting
included by asm_defns.h. This in particular reduces the number of
instances of guarding asm(".include ...") suitably in such dual use
headers.
No change to generated code.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
-
Under certain conditions CPUs can speculate into the instruction stream
past a RET instruction. Guard against this just like 3b7dab93f240
("x86/spec-ctrl: Protect against CALL/JMP straight-line speculation")
did - by inserting an "INT $3" insn. It's merely the mechanics of how to
achieve this that
There's no point having every replacement variant to also specify the
INT3 - just have it once in the base macro. When patching, NOPs will get
inserted, which are fine to speculate through (until reaching the INT3).
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
I also wonder whether t
Put insertion of INT3 behind CONFIG_SPECULATIVE_HARDEN_BRANCH
conditionals.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/indirect-thunk.S
+++ b/xen/arch/x86/indirect-thunk.S
@@ -11,8 +11,10 @@
#include
+#ifdef CONFIG_SPECULATIVE_HARDEN_BRANCH
/* Don't transform the "ret" fur
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 devices lack ACPI, the writing seems to be on the wall of UEFI/ACPI
pot
flight 156115 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156115/
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
Hi Elliott,
On 22/10/2020 20:18, Elliott Mitchell wrote:
On Thu, Oct 22, 2020 at 07:38:26PM +0100, Julien Grall wrote:
On Thu, Oct 22, 2020 at 07:44:26PM +0100, Julien Grall wrote:
Thank you for the patch. FIY I tweak a bit the commit title before
committing.
The title is now: "xen/arm: acpi:
On 23/10/20 09:09, Thomas Huth wrote:
> On 22/10/2020 17.29, Paolo Bonzini wrote:
>> On 22/10/20 17:17, Jason Andryuk wrote:
>>> On Tue, Oct 13, 2020 at 1:16 PM Paolo Bonzini wrote:
On 13/10/20 16:05, Jason Andryuk wrote:
> Xen was left behind when CpusAccel became mandatory and fail
Hi all,
On Tue, 2020-10-20 at 18:13 +0100, Julien Grall wrote:
> Hi,
>
> On 19/10/2020 19:07, Stefano Stabellini wrote:
> > On Fri, 16 Oct 2020, Artem Mygaiev wrote:
> > > -Original Message-
> > > From: Julien Grall
> > > Sent: пятница, 16 октября 2020 г. 13:24
> > > To: Anastasiia Lukia
On 21.10.2020 02:00, Stefano Stabellini wrote:
> @@ -140,38 +173,74 @@ struct vcpu_register_runstate_memory_area {
> typedef struct vcpu_register_runstate_memory_area
> vcpu_register_runstate_memory_area_t;
> DEFINE_XEN_GUEST_HANDLE(vcpu_register_runstate_memory_area_t);
>
> -/*
> - * Set or s
On 21.10.2020 02:00, Stefano Stabellini wrote:
> --- a/xen/include/public/version.h
> +++ b/xen/include/public/version.h
> @@ -30,19 +30,32 @@
>
> #include "xen.h"
>
> -/* NB. All ops return zero on success, except XENVER_{version,pagesize}
> - * XENVER_{version,pagesize,build_id} */
> +/**
>
On 21.10.2020 02:00, Stefano Stabellini wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -81,14 +81,62 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>
> #endif
>
> -/*
> - * HYPERCALLS
> - */
> -
> -/* `incontents 100 hcalls List of hypercalls
> - * ` enum hypercall_num
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 con
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 c
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()).
W
... 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 constru
... 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 ++
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 -
xen/lib/Mak
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 a
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 hea
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 the
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 SMM
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 1
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 follows:
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 i
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/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 uni
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 diff
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 tools/include
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.
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 inte
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
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 a/
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 unu
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 --g
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 another
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:
>>> Add
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 l
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 sin
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 head
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 wrote:
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) &&
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 a
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
Signed-off-by
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 code
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
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 ACPI
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
the
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
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
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 rath
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 scan_
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: I
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 w
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 b/tools/l
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 D
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 type
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
'pci_ad
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
---
tools/in
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 'pcid
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 deletions(
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
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.
Si
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 ar
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 Lin
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:
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 the
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 it
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 in
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 b
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 Durran
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.
Si
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
libxl_
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 insertions(+),
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 libx
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 xlu_pci_parse_bdf(
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 changes
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
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
p
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 libxl_device_pci_assignable_name2bd
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 de
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 mak
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
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
build-arm64-
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
build-arm64-
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.
O
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
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
build-arm64-
1 - 100 of 120 matches
Mail list logo
