On Thursday, February 1st, 2024 at 18:01, Roger Pau Monne
wrote:
> The current code that parses the IVMD blocks is relaxed with regard to the
> restriction that such unity regions should always fall into memory ranges
> marked as reserved in the memory map.
>
> However the type checks for the
flight 184564 xen-4.17-testing real [real]
flight 184574 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184564/
http://logs.test-lab.xenproject.org/osstest/logs/184574/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 184563 linux-6.1 real [real]
flight 184569 linux-6.1 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184563/
http://logs.test-lab.xenproject.org/osstest/logs/184569/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
On Fri, 2 Feb 2024, Julien Grall wrote:
> On 01/02/2024 16:17, John Ernberg wrote:
> > On 2/1/24 13:20, Julien Grall wrote:
> > >
> > >
> > > On 31/01/2024 15:32, John Ernberg wrote:
> > > > Hi Julien,
> > >
> > > Hi John,
> > >
> > > > On 1/31/24 13:22, Julien Grall wrote:
> > > > > Hi,
> > >
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
From: Volodymyr Babchuk
This function can be used when user wants to remove all rangeset
entries but do not want to destroy rangeset itself.
Signed-off-by: Volodymyr Babchuk
Signed-off-by: Stewart Hildebrand
Acked-by: Jan Beulich
---
Changes in v13:
- Added Jan's A-b
Changes in v12:
-
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's (domU) view of this will want to be zero (for now), the host
having set it to 1 should be preserved, or else we'd
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by:
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value.
This way hardware domain sees physical BAR values and guest sees
emulated ones.
Hardware domain continues getting the BARs identity
From: Volodymyr Babchuk
Guest can try to read config space using different access sizes: 8,
16, 32, 64 bits. We need to take this into account when we are
returning an error back to MMIO handler, otherwise it is possible to
provide more data than requested: i.e. guest issues LDRB instruction
to
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note that
From: Oleksandr Andrushchenko
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers.
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest
From: Volodymyr Babchuk
Introduce "fail" label in init_header() function to have the centralized
error return path. This is the pre-requirement for the future changes
in this function.
This patch does not introduce functional changes.
Suggested-by: Roger Pau Monné
Signed-off-by: Volodymyr
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned we need to
initialize/de-initialize vPCI state for the device.
Also, rename vpci_add_handlers() to vpci_assign_device() and
vpci_remove_device() to vpci_deassign_device() to better reflect role
of the functions.
From: Oleksandr Andrushchenko
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make
From: Oleksandr Andrushchenko
Use the per-domain PCI read/write lock to protect the presence of the
pci device vpci field. This lock can be used (and in a few cases is used
right away) so that vpci removal can be performed while holding the lock
in write mode. Previously such removal could race
This is next version of vPCI rework. Aim of this series is to prepare
ground for introducing PCI support on ARM platform.
in v13:
- drop ("xen/arm: vpci: permit access to guest vpci space") as it was
unnecessary
in v12:
- I (Stewart) coordinated with Volodomyr to send this whole series. So,
flight 184562 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184562/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184537
test-armhf-armhf-libvirt-qcow2 15
On 2/2/2024 11:25 AM, David Woodhouse wrote:
> On Thu, 2024-02-01 at 18:39 +, John L. Poole wrote:
>> While the Xen Project "make" works, the Gentoo emerge
>> of app-emulation/xen-tools does not unless the three lines are
>> removed to simulate prior 4.17.3 and earlier code.
>>
>> I suspect
On Thu, 2024-02-01 at 18:39 +, John L. Poole wrote:
>
> While the Xen Project "make" works, the Gentoo emerge
> of app-emulation/xen-tools does not unless the three lines are
> removed to simulate prior 4.17.3 and earlier code.
>
> I suspect the Gentoo approach
> of building tools first
flight 184557 xen-unstable real [real]
flight 184567 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184557/
http://logs.test-lab.xenproject.org/osstest/logs/184567/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi,
On 14/11/2023 17:50, Krystian Hebel wrote:
This location is easier to access from assembly. Having it close to
other data required during initialization has also positive (although
rather small) impact on prefetching data from RAM.
I understand your goal but...
Signed-off-by: Krystian
Hi,
On 14/11/2023 17:50, Krystian Hebel wrote:
Both fields held the same data.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 8 +---
xen/arch/x86/include/asm/asm_defns.h | 2 +-
xen/arch/x86/include/asm/processor.h | 2 ++
xen/arch/x86/include/asm/smp.h
Move the macros mentioned in the commit subject to their appropriate
locations.
Additionally, eliminate the dependency of xen/lib.h from xen/bug.h and
include "xen/bug.h" in files where xen/bug.h macros are utilized.
Most of the changes were made because a file requires macros from xen/bug.h,
Fixes: cf7fe8b72dea ("x86/ucode: Fix stability of the raw CPU Policy rescan")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
I don't know what went wrong here.
---
xen/arch/x86/cpu/microcode/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Tue, 2024-01-23 at 14:03 +0100, Jan Beulich wrote:
> On 22.12.2023 16:13, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V3:
> > - update the commit message
>
> ??? (yet again)
>
> > --- a/xen/arch/riscv/include/asm/mm.h
> > +++
On 15.01.24 16:31, Anthony PERARD wrote:
On Thu, Jan 04, 2024 at 10:00:43AM +0100, Juergen Gross wrote:
Add a 9pfs device to Xenstore stubdom in order to allow it to do e.g.
logging into a dom0 file.
Use the following parameters for the new device:
- tag = "xen"
Is it ok to have here tag
On 02.02.24 16:28, Juergen Gross wrote:
On 31.01.24 16:20, Jürgen Groß wrote:
On 15.01.24 16:14, Anthony PERARD wrote:
On Thu, Jan 04, 2024 at 10:00:39AM +0100, Juergen Gross wrote:
@@ -2242,6 +2256,28 @@ void parse_config_data(const char *config_source,
We have two copies of __bitmap_weight() that differ by whether they make
hweight32() or hweight64() calls, yet we already have hweight_long() which is
the form that __bitmap_weight() wants.
Fix hweight_long() to return unsigned int like all the other hweight helpers,
and fix __bitmap_weight() to
On 31.01.24 16:20, Jürgen Groß wrote:
On 15.01.24 16:14, Anthony PERARD wrote:
On Thu, Jan 04, 2024 at 10:00:39AM +0100, Juergen Gross wrote:
@@ -2242,6 +2256,28 @@ void parse_config_data(const char *config_source,
libxl_string_list_dispose();
+ if (p9->type ==
On 02/02/24 10:37, Simone Ballarin wrote:
From: Maria Celeste Cesario
The Xen sources contain violations of MISRA C:2012 Rule 13.1 whose headline
states:
"Initializer lists shall not contain persistent side effects".
The file properties.json containing function and macro properties is
flight 184554 linux-linus real [real]
flight 184565 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184554/
http://logs.test-lab.xenproject.org/osstest/logs/184565/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Rule 13.1: Initializer lists shall not contain persistent side effects
The assignment operation in:
.irq = rc = uart->irq,
is a persistent side effect in a struct initializer list.
This patch assigns rc separately outside the structure.
No functional change.
Signed-off-by: Simone Ballarin
The Xen sources contain violations of MISRA C:2012 Rule 13.1 whose headline
states:
"Initializer lists shall not contain persistent side effects".
The file properties.json containing function and macro properties is
introduced, as
stated in v2 discussion. Some functions and macros are found
From: Maria Celeste Cesario
Function and macro properties contained in ECLAIR/call_properties.ecl are of
general interest: this patch moves these annotations in a generaric JSON file
in docs. In this way, they can be exploited for other purposes (i.e.
documentation,
other tools).
Add rst file
Rule 13.1: Initializer lists shall not contain persistent side effects
This patch moves expressions with side-effects into new variables before
the initializer lists.
No functional changes.
Signed-off-by: Simone Ballarin
---
xen/arch/x86/io_apic.c | 9 ++---
xen/arch/x86/mpparse.c | 3 ++-
Rule 13.1: Initializer lists shall not contain persistent side effects
Effects caused by debug/logging macros and functions (like ASSERT,
__bad_atomic_size,
LOG, etc ...) that crash execution or produce logs are not dangerous in
initializer
lists. The evaluation order in abnormal conditions is
Hi all,
Please find the community call recording below.
https://www.youtube.com/watch?v=MJSTvwvNtF8_channel=TheXenProject
These are unlisted and published on our new YouTube channel. Only users
with the specific link below will be able to access the recording.
This has also been saved in the
On 02.02.24 13:03, Viresh Kumar wrote:
Hello Viresh
> On 02-02-24, 12:49, Oleksandr Tyshchenko wrote:
>> diff --git a/docs/man/xl-disk-configuration.5.pod.in
>> b/docs/man/xl-disk-configuration.5.pod.in
>> index bc945cc517..3c035456d5 100644
>> --- a/docs/man/xl-disk-configuration.5.pod.in
On 02.02.2024 13:13, Andrew Cooper wrote:
> On 23/01/2024 11:00 am, Jan Beulich wrote:
>> While not performance critical, these hook invocations still want
>> converting: This way all pre-filled struct cpu_dev instances can become
>> __initconst_cf_clobber, thus allowing to eliminate further 8
On 23/01/2024 11:00 am, Jan Beulich wrote:
> While not performance critical, these hook invocations still want
> converting: This way all pre-filled struct cpu_dev instances can become
> __initconst_cf_clobber, thus allowing to eliminate further 8 ENDBR
> during the 2nd phase of alternatives
On 02/02/24 10:37, Simone Ballarin wrote:
From: Maria Celeste Cesario
Add JSON file containing properties.
Add rst file containing explanation on how to update properties.json.
Add instruction to eclair_analysis/prepare.sh to parse the JSON file.
Signed-off-by: Maria Celeste Cesario
On 02-02-24, 12:49, Oleksandr Tyshchenko wrote:
> diff --git a/docs/man/xl-disk-configuration.5.pod.in
> b/docs/man/xl-disk-configuration.5.pod.in
> index bc945cc517..3c035456d5 100644
> --- a/docs/man/xl-disk-configuration.5.pod.in
> +++ b/docs/man/xl-disk-configuration.5.pod.in
> @@ -404,6
From: Oleksandr Tyshchenko
Allow administrators to control whether Xen grant mappings for
the virtio disk devices should be used. By default (when new
parameter is not specified), the existing behavior is retained
(we enable grants if backend-domid != 0).
Signed-off-by: Oleksandr Tyshchenko
Rule 13.1: Initializer lists shall not contain persistent side effects
The assignment operation in:
.irq = rc = uart->irq,
is a persistent side effect in a struct initializer list.
This patch assigns rc separately outside the structure.
No functional change.
Signed-off-by: Simone Ballarin
From: Maria Celeste Cesario
Add JSON file containing properties.
Add rst file containing explanation on how to update properties.json.
Add instruction to eclair_analysis/prepare.sh to parse the JSON file.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
---
From: Maria Celeste Cesario
The Xen sources contain violations of MISRA C:2012 Rule 13.1 whose headline
states:
"Initializer lists shall not contain persistent side effects".
The file properties.json containing function and macro properties is
introduced, as
stated in v2 discussion. Some
Rule 13.1: Initializer lists shall not contain persistent side effects
Effects caused by debug/logging macros and functions (like ASSERT,
__bad_atomic_size,
LOG, etc ...) that crash execution or produce logs are not dangerous in
initializer
lists. The evaluation order in abnormal conditions is
Rule 13.1: Initializer lists shall not contain persistent side effects
This patch moves expressions with side-effects into new variables before
the initializer lists.
No functional changes.
Signed-off-by: Simone Ballarin
---
xen/arch/x86/io_apic.c | 9 ++---
xen/arch/x86/mpparse.c | 3 ++-
On 01/02/2024 16:17, John Ernberg wrote:
On 2/1/24 13:20, Julien Grall wrote:
On 31/01/2024 15:32, John Ernberg wrote:
Hi Julien,
Hi John,
On 1/31/24 13:22, Julien Grall wrote:
Hi,
On 31/01/2024 11:50, John Ernberg wrote:
When using Linux for dom0 there are a bunch of drivers that
flight 184553 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184553/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184532
On 02/02/2024 07:08, Jan Beulich wrote:
On 17.01.2024 10:31, Jan Beulich wrote:
While .setup() and .e820_fixup() don't need fiddling with for being run
only very early, both .ap_setup() and .resume() want converting too:
This way both pre-filled struct hypervisor_ops instances can become
54 matches
Mail list logo
