flight 184679 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184679/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-raw broken
test-amd64-amd64-libvirt-raw 5
flight 184677 xen-unstable real [real]
flight 184680 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184677/
http://logs.test-lab.xenproject.org/osstest/logs/184680/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 184678 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184678/
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
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
The pull request you sent on Thu, 15 Feb 2024 16:24:26 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.8a-rc5-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cc9c4f0b3113d513a94bcf489f2fa8cb9cc7c679
Thank you!
--
Deet-doot-dot,
On Thu, Feb 15, 2024 at 05:22:00PM +0100, Jan Beulich wrote:
> On 15.02.2024 17:08, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 02:02:41PM +0100, Jan Beulich wrote:
> >> --- a/xen/Rules.mk
> >> +++ b/xen/Rules.mk
> >> @@ -15,7 +15,11 @@ srcdir := $(srctree)/$(src)
> >> PHONY := __build
>
>
> On 14/02/2024 09:32, Oleksii wrote:
> > On Tue, 2024-02-13 at 18:09 +, Julien Grall wrote:
> > > > +#ifdef CONFIG_HAS_PASSTHROUGH
> > > > + struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU
> > > > instance data */
> > > > +#endif
> > > > +};
> > > > +
> > > > +typedef struct
The feature is defined in the tertiary exec control, and is available starting
from Sapphire Rapids and Alder Lake CPUs.
When enabled, two extra VMCS fields are used: SPEC_CTRL mask and shadow. Bits
set in mask are not allowed to be toggled by the guest (either set or clear)
and the value in the
On 15.02.2024 17:38, Oleksii wrote:
> On Tue, 2024-02-13 at 14:33 +0100, Jan Beulich wrote:
>> On 05.02.2024 16:32, Oleksii Kurochko wrote:
>>> + depends on LLD_VERSION >= 15 || LD_VERSION >= 23600
>>
>> What's the linker dependency here? Depending on the answer I might
>> further
>> ask why
On Tue, 2024-02-13 at 14:33 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/Kconfig
> > +++ b/xen/arch/riscv/Kconfig
> > @@ -45,6 +45,13 @@ config RISCV_ISA_C
> >
> > If unsure, say Y.
> >
> > +config TOOLCHAIN_HAS_ZIHINTPAUSE
> > +
flight 184675 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184675/
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
On 15.02.2024 17:08, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 02:02:41PM +0100, Jan Beulich wrote:
>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -15,7 +15,11 @@ srcdir := $(srctree)/$(src)
>> PHONY := __build
>> __build:
>>
>> --include $(objtree)/include/config/auto.conf
>> +ifneq
On Thu, Feb 15, 2024 at 02:02:41PM +0100, Jan Beulich wrote:
> On 15.02.2024 12:04, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 11:43:02AM +0100, Jan Beulich wrote:
> >> On 15.02.2024 11:28, Roger Pau Monné wrote:
> >>> On Thu, Feb 15, 2024 at 10:49:31AM +0100, Jan Beulich wrote:
> On
On 15.02.2024 16:54, Roger Pau Monné wrote:
> On Mon, Feb 12, 2024 at 03:09:01PM +0100, Jan Beulich wrote:
>> On 09.02.2024 12:40, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -823,18 +823,29 @@ static void cf_check
On 15.02.24 14:04, Juergen Gross wrote:
Add the transport layer of 9pfs. This is basically the infrastructure
to receive requests from the frontend and to send the related answers
via the rings.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Acked-by: Anthony PERARD
Seems CI is
Hi Michal,
On 15/02/2024 14:39, Michal Orzel wrote:
At the moment, the hardware domain vUART is always compiled in. In the
spirit of fine granular configuration, make it optional so that the
feature can be disabled if not needed. This UART is not exposed (e.g.
via device tree) to a domain and
On Mon, Feb 12, 2024 at 03:09:01PM +0100, Jan Beulich wrote:
> On 09.02.2024 12:40, Roger Pau Monne wrote:
> > @@ -1378,6 +1379,10 @@ static int construct_vmcs(struct vcpu *v)
> > rc = vmx_add_msr(v, MSR_PRED_CMD, PRED_CMD_IBPB,
> > VMX_MSR_HOST);
> >
> > +
> On 15 Feb 2024, at 14:39, Michal Orzel wrote:
>
> At the moment, the hardware domain vUART is always compiled in. In the
> spirit of fine granular configuration, make it optional so that the
> feature can be disabled if not needed. This UART is not exposed (e.g.
> via device tree) to a
flight 184673 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184673/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail in 184670 pass in 184673
test-armhf-armhf-libvirt-qcow2
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-6.8a-rc5-tag
xen: branch for v6.8-rc5
It contains the following fixes and simple cleanups:
- A fix using a proper flexible array instead of a one-element array in order to
avoid
I do like the idea. I applied some of the suggestions to this proof of
concept patch (attached). Still not compile-tested, since the CI seems
a bit slow today.
arch_grant_cache_flush is missing the return type on x86, sorry.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl
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
At the moment, the hardware domain vUART is always compiled in. In the
spirit of fine granular configuration, make it optional so that the
feature can be disabled if not needed. This UART is not exposed (e.g.
via device tree) to a domain and is mostly used to support special use
cases like Linux
Hi Julien,
On 2024-02-13 18:14, Julien Grall wrote:
Hi Jan,
On 13/02/2024 07:13, Jan Beulich wrote:
On 12.02.2024 19:38, Julien Grall wrote:
An alternative would be to introduced arch_grant_cache_flush() and
move
the if/else logic there. Something like:
diff --git
Hi Michal,
On 2/15/24 10:02, Michal Orzel wrote:
> Hi,
>
> On 14/02/2024 17:06, John Ernberg wrote:
>>
>>
>> When using Linux for dom0 there are a bunch of drivers that need to do SMC
>> SIP calls into the firmware to enable certain hardware bits like the
>> watchdog.
>>
>> Provide a basic
> > + : "=r" (ret), "+A" (*ptr) \
> > + : "r" (new) \
> > + : "memory" ); \
> > +})
> > +
> > +#define emulate_xchg_1_2(ptr, new, ret, release_barrier,
> > acquire_barrier) \
> > +({ \
> > + uint32_t *ptr_32b_aligned = (uint32_t *)ALIGN_DOWN((unsigned
> > long)ptr, 4); \
>
Mount the 9pfs device in stubdom enabling it to use files.
This has to happen in a worker thread in order to allow the main thread
handling the required Xenstore accesses in parallel.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Reviewed-by: Julien Grall
---
V3:
- add logging in
Add the read request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Acked-by: Anthony PERARD
---
V2:
- make error check more readable (Jason Andryuk)
V4:
- add directory read support
V5:
- rewinddir() if reading a directory and offset is 0 (Jason Andryuk)
---
Add the create request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
V2:
- set permissions correctly (Jason Andryuk)
V3:
- use opendirat() etc. (Jason Andryuk)
- rework error handling a little bit
---
tools/9pfsd/io.c | 151
Add support for the new 9pfs backend "xen_9pfsd". For this backend type
the tag defaults to "Xen" and the host side path to
"/var/log/xen/guests/".
Do most of the default settings in libxl. Unfortunately the default
path can't easily be set in libxl, as the domain name isn't available
in the
With 9pfs now available in Xenstore-stubdom, there is no reason to
have distinct do_control_memreport() variants for the daemon and the
stubdom implementations.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/xenstored/control.c | 27 +++
1 file
Add the stat request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
V3:
- use fstatat() (Jason Andryuk)
V4:
- add "s" format to fill_buffer() as a preparation for reading dirs
---
tools/9pfsd/io.c | 102
Add the write request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Acked-by: Anthony PERARD
---
tools/9pfsd/io.c | 54
1 file changed, 54 insertions(+)
diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c
index
Add some helpers for handling filenames which might need different
implementations between stubdom and daemon environments:
- expansion of relative filenames (those are not really defined today,
just expand them to be relative to /var/lib/xen/xenstore)
- expansion of xenstore_daemon_rundir()
Certain macros are allowed to violate the Rule, since their meaning and
intended use is well-known to all Xen developers.
Variadic macros that rely on the GCC extension for removing a trailing
comma when token pasting the variable argument are similarly
well-understood and therefore allowed.
No
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"
- type = "xen_9pfsd"
- path = "/var/lib/xen/xenstore"
- security-model = "none"
For now don't limit allowed file space or number of
Extend the config files of the Xenstore stubdoms to include XENBUS
and 9PFRONT items in order to support file based logging.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
stubdom/xenstore-minios.cfg| 2 +-
stubdom/xenstorepvh-minios.cfg | 2 +-
2 files changed, 2
With 9pfs being fully available in Xenstore-stubdom now, there is no
reason to not fully support all logging capabilities in stubdom.
Open the logfile on stubdom only after the 9pfs file system has been
mounted.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Reviewed-by: Julien Grall
Make the backend type of 9pfs PV devices configurable. The default is
"qemu" with the related Xenstore backend-side directory being "9pfs".
Add another type "xen_9pfsd" with the related Xenstore backend-side
directory "xen_9pfs".
As additional security features it is possible to specify:
-
On 13.02.24 14:14, Anthony PERARD wrote:
Hello Anthony
> On Tue, Feb 06, 2024 at 02:38:14PM +0200, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Allow administrators to control whether Xen grant mappings for
>> the virtio disk devices should be used. By default (when new
>>
Add the clunk request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
V3:
- use unlinkat() (Jason Andryuk)
---
tools/9pfsd/io.c | 43 +++
1 file changed, 43 insertions(+)
diff --git
Add the open request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
V2:
- don't allow to open symbolic link
V3:
- use openat() (Jason Andryuk)
- use common error handling in p9_open()
---
tools/9pfsd/io.c| 137
Add the attach request of the 9pfs protocol. This introduces the "fid"
scheme of the 9pfs protocol.
As this will be needed later, use a dedicated memory allocation
function in alloc_fid() and prepare a fid reference count.
For filling the qid data take the approach from the qemu 9pfs backend
Add the walk request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
V2:
- don't allow walking across symbolic links
V6:
- use EBADF instead of EBADFD (Andrew Cooper)
- use strncpy() with strlen() + 1 (Andrew Cooper)
V7:
- undo V6
Add support for generation a 9pfs protocol response via a format based
approach.
Strings are stored in a per device string buffer and they are
referenced via their offset in this buffer. This allows to avoid
having to dynamically allocate memory for each single string.
As a first user of the
Add the version request of the 9pfs protocol. For the version use the
"9P2000.u" variant, as it is supported by Mini-OS and Linux.
For the request parsing add all format items needed even in future in
order to avoid code churn for those additions later.
Signed-off-by: Juergen Gross
Acked-by:
Add the code for connecting to frontends to xenlogd.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
V2:
- support multiple rings per device (Jason Andryuk)
- don't set .revents initially (Jason Andryuk)
- call poll() with infinite timeout (Jason Andryuk)
-
This series is adding 9pfs support to Xenstore-stubdom, enabling it
to do logging to a dom0 directory.
This is a prerequisite for the final goal to add live update support
to Xenstore-stubdom, as it enables the stubdom to store its state in
a dom0 file.
The 9pfs backend is a new daemon written
Add the transport layer of 9pfs. This is basically the infrastructure
to receive requests from the frontend and to send the related answers
via the rings.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Acked-by: Anthony PERARD
---
V2:
- rename put_request_bytes() (Jason Andryuk)
-
Add "xen-9pfsd", a new 9pfs daemon meant to support infrastructure
domains (e.g. xenstore-stubdom) to access files in dom0.
For now only add the code needed for starting the daemon and
registering it with Xenstore via a new "libxl/xen-9pfs/state" node by
writing the "running" state to it.
On 15.02.2024 12:04, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 11:43:02AM +0100, Jan Beulich wrote:
>> On 15.02.2024 11:28, Roger Pau Monné wrote:
>>> On Thu, Feb 15, 2024 at 10:49:31AM +0100, Jan Beulich wrote:
On 15.02.2024 10:30, Roger Pau Monne wrote:
> --- a/xen/Makefile
>
On 15.02.2024 13:11, Jan Beulich wrote:
> On 15.02.2024 12:04, Roger Pau Monné wrote:
>> On Thu, Feb 15, 2024 at 11:43:02AM +0100, Jan Beulich wrote:
>>> On 15.02.2024 11:28, Roger Pau Monné wrote:
Without the reordering the include of include/config/auto.conf will
always succeed on
On 08/02/2024 16:27, Julien Grall wrote:
Hi Juergen,
On 08/02/2024 16:05, Juergen Gross wrote:
Today the CODING_STYLE contains a section "Handling unexpected
conditions" specific to the hypervisor. This section is kind of
misplaced for a coding style. It should rather be part of a "Coding
On 15.02.2024 12:04, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 11:43:02AM +0100, Jan Beulich wrote:
>> On 15.02.2024 11:28, Roger Pau Monné wrote:
>>> Without the reordering the include of include/config/auto.conf will
>>> always succeed on rebuilds, because the include is done before
>>>
On Thu, Feb 15, 2024 at 10:42:18AM +0100, Juergen Gross wrote:
> On 15.02.24 07:55, Juergen Gross wrote:
> > Add support for the new 9pfs backend "xen_9pfsd". For this backend type
> > the tag defaults to "Xen" and the host side path to
> > "/var/log/xen/guests/".
> >
> > Do most of the default
Hi Jan,
On 12/02/2024 09:13, Jan Beulich wrote:
On 08.02.2024 23:09, Julien Grall wrote:
On 05/02/2024 13:28, Jan Beulich wrote:
In preparation for further removal of regs parameters, drop it here. In
the two places where it's actually needed, retrieve IRQ context if
available, or else guest
flight 184671 linux-linus real [real]
flight 184674 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184671/
http://logs.test-lab.xenproject.org/osstest/logs/184674/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Thu, Feb 15, 2024 at 10:32:57AM +, Anthony PERARD wrote:
> On Thu, Feb 15, 2024 at 10:30:02AM +0100, Roger Pau Monne wrote:
> > When doing a rebuild with an xen/include/config/auto.conf already present in
> > the tree, failures from Kconfig are ignored since the target is present:
> >
> >
On Thu, Feb 15, 2024 at 09:39:41AM +0100, Jan Beulich wrote:
> On 15.02.2024 03:19, Marek Marczykowski wrote:
> > On Tue, Feb 13, 2024 at 04:44:04PM +0100, Jan Beulich wrote:
> >> On 13.02.2024 16:11, Marek Marczykowski wrote:
> >>> On Tue, Feb 13, 2024 at 04:00:32PM +0100, Jan Beulich wrote:
>
On Thu, Feb 15, 2024 at 11:43:02AM +0100, Jan Beulich wrote:
> On 15.02.2024 11:28, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 10:49:31AM +0100, Jan Beulich wrote:
> >> On 15.02.2024 10:30, Roger Pau Monne wrote:
> >>> --- a/xen/Makefile
> >>> +++ b/xen/Makefile
> >>> @@ -358,10 +358,10 @@
On 15.02.2024 11:28, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 10:49:31AM +0100, Jan Beulich wrote:
>> On 15.02.2024 10:30, Roger Pau Monne wrote:
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -358,10 +358,10 @@ config: tools_fixdep outputmakefile FORCE
>>> else # !config-build
>>>
On 15.02.2024 11:32, Anthony PERARD wrote:
> On Thu, Feb 15, 2024 at 10:30:02AM +0100, Roger Pau Monne wrote:
>> When doing a rebuild with an xen/include/config/auto.conf already present in
>> the tree, failures from Kconfig are ignored since the target is present:
>>
>> gmake -C xen install
>>
On Thu, Feb 15, 2024 at 10:30:02AM +0100, Roger Pau Monne wrote:
> When doing a rebuild with an xen/include/config/auto.conf already present in
> the tree, failures from Kconfig are ignored since the target is present:
>
> gmake -C xen install
> gmake[1]: Entering directory '/root/src/xen/xen'
>
On 15.02.2024 11:07, Federico Serafini wrote:
> On 15/02/24 09:10, Jan Beulich wrote:
>> On 14.02.2024 17:11, Federico Serafini wrote:
>>> I did some tries with example programs
>>> and the assembler error always points to file and line
>>> of the most enclosing function that caused the failure.
On Thu, Feb 15, 2024 at 10:49:31AM +0100, Jan Beulich wrote:
> On 15.02.2024 10:30, Roger Pau Monne wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -358,10 +358,10 @@ config: tools_fixdep outputmakefile FORCE
> > else # !config-build
> >
> > ifeq ($(need-config),y)
> > --include
On 15.02.2024 11:15, Jan Beulich wrote:
> Make the variable a tristate, with (as done elsewhere) a negative value
> meaning "default". Since all use sites need looking at, also rename it
> to match our usual "opt_*" pattern. While touching it, also move it to
> .data.ro_after_init.
>
> The only
Use appropriate types for the control register value as well as the
capability position. Constify a pointer. Use "else" in favor of encoding
the opposite condition of the earlier if().
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/drivers/passthrough/ats.c
+++
All call sites pass it using the flag from the IOMMU which they also
pass.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -57,8 +57,7 @@ int __must_check cf_check vtd_flush_cont
uint8_t function_mask,
..., thus allowing them to become static. There's nothing x86-specific
about these functions anyway.
Since only the "iommu_inclusive_mapping" parameter declaration would be
left in the file, move that as well. There's nothing VT-d specific about
it (anymore?): "dom0-iommu=map-inclusive" is
..., thus allowing it and qinval_device_iotlb_sync() to become static.
There's nothing x86-specific about the function anyway. While moving,
adjust types to better match ./CODING_STYLE (albeit use of fixed-width
types for parameters is retained to limit the effective change).
Append a UL to a
..., thus allowing it to become static, and thus reducing scope overlap
between it and pci_ats_device(). There's nothing x86-specific about this
function anyway.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
--- a/xen/drivers/passthrough/vtd/extern.h
+++
All callers only care about boolean outcome. For this there's no point
in allocating a duplicate of the respective DRHD structure; a simple
boolean suffices (which eventually may want to become a count, such that
the "any ATS devices assigned state" can also clear again). With that
boolean, remove
When the flag is set, permit Dom0 to control the device (no worse than
what we had before and in line with other "best effort" behavior we use
when it comes to Dom0), but suppress passing through to DomU-s unless
ATS can actually be enabled for such devices (and was explicitly enabled
on the
Make the variable a tristate, with (as done elsewhere) a negative value
meaning "default". Since all use sites need looking at, also rename it
to match our usual "opt_*" pattern. While touching it, also move it to
.data.ro_after_init.
The only place it retains boolean nature is pci_ats_device(),
The same set of conditions is used in three places, requiring to be kept
in sync. Introduce a helper to centralize these checks.
To allow all parameters of the new helper be pointer-to-const,
iommu_has_cap() also needs its 1st parameter to be constified. Beyond
that further "modernize" that
This is a prereq to us, in particular, respecting the "ATC required"
flag.
Note that ACPI_SATC_ATC_REQUIRED has its #define put in dmar.h, as we
try to keep actbl*.h in sync what Linux (who in turn inherit from ACPI
CA) has.
Signed-off-by: Jan Beulich
---
Lovely: On the SPR system with the SATC
It's acpi_parse_one_rmrr() where the allocation is coming from (by way
of invoking acpi_parse_dev_scope()), or in add_one_user_rmrr()'s case
allocation is even open-coded there, so freeing would better also happen
there. Care needs to be taken to preserve acpi_parse_one_rmrr()'s
ultimate return
Spec version 4.1 says
"The ATSR structures identifies PCI Express Root-Ports supporting
Address Translation Services (ATS) transactions. Software must enable
ATS on endpoint devices behind a Root Port only if the Root Port is
reported as supporting ATS transactions."
Clearly root complex
On a Sapphire Rapids system I noticed a line in the serial log
indicating a DMAR entry type we're not recognizing. While arranging
for it to be both recognized and respected, I noticed some further
potential for cleaning up.
01: VT-d: correct ATS checking for root complex integrated devices
02:
On 15/02/24 09:10, Jan Beulich wrote:
On 14.02.2024 17:11, Federico Serafini wrote:
I did some tries with example programs
and the assembler error always points to file and line
of the most enclosing function that caused the failure.
If I am not missing something, using __FILE__ and __LINE__
On 15.02.2024 10:30, Roger Pau Monne wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -358,10 +358,10 @@ config: tools_fixdep outputmakefile FORCE
> else # !config-build
>
> ifeq ($(need-config),y)
> --include include/config/auto.conf
> # Read in dependencies to all Kconfig* files, make
On 15.02.24 07:55, Juergen Gross wrote:
Add support for the new 9pfs backend "xen_9pfsd". For this backend type
the tag defaults to "Xen" and the host side path to
"/var/log/xen/guests/".
Do most of the default settings in libxl. Unfortunately the default
path can't easily be set in libxl, as
On 14.02.2024 19:00, Anthony PERARD wrote:
> The `which` command is not standard, may not exist on the build host,
> or may not behave as expected by the build system. It is recommended
> to use `command -v` to find out if a command exist and have its path,
> and it's part of a POSIX shell
When doing a rebuild with an xen/include/config/auto.conf already present in
the tree, failures from Kconfig are ignored since the target is present:
gmake -C xen install
gmake[1]: Entering directory '/root/src/xen/xen'
tools/kconfig/conf --syncconfig Kconfig
common/Kconfig:2: syntax error
On 15.02.2024 01:05, Stefano Stabellini wrote:
> I don't think is a good idea to add further changes to this patch. I
> think we should go ahead with it as-is.
I didn't suggest adding anything right here; there may want/need to be new
prereq-s, though. I'd like to make sure that we don't
Hi,
On 14/02/2024 17:06, John Ernberg wrote:
>
>
> When using Linux for dom0 there are a bunch of drivers that need to do SMC
> SIP calls into the firmware to enable certain hardware bits like the
> watchdog.
>
> Provide a basic platform glue that implements the needed SMC forwarding.
>
> The
On 05.02.2024 14:27, Jan Beulich wrote:
> In preparation of dropping the register parameters from
> serial_[rt]x_interrupt() and in turn from IRQ handler functions,
> register state needs making available another way for the few key
> handlers which need it. Fake IRQ-like state.
>
>
On 15.02.2024 03:19, Marek Marczykowski wrote:
> On Tue, Feb 13, 2024 at 04:44:04PM +0100, Jan Beulich wrote:
>> On 13.02.2024 16:11, Marek Marczykowski wrote:
>>> On Tue, Feb 13, 2024 at 04:00:32PM +0100, Jan Beulich wrote:
On 13.02.2024 15:53, Marek Marczykowski wrote:
> Generally
On Mon, Feb 12, 2024 at 01:18:58PM -0600, Bjorn Helgaas wrote:
> On Mon, Feb 12, 2024 at 10:13:28AM +0100, Roger Pau Monné wrote:
> > On Fri, Feb 09, 2024 at 03:05:49PM -0600, Bjorn Helgaas wrote:
> > > On Thu, Feb 01, 2024 at 09:39:49AM +0100, Roger Pau Monné wrote:
> > > > On Wed, Jan 31, 2024
On 14.02.2024 17:11, Federico Serafini wrote:
> I did some tries with example programs
> and the assembler error always points to file and line
> of the most enclosing function that caused the failure.
> If I am not missing something, using __FILE__ and __LINE__ does not add
> any information.
>
90 matches
Mail list logo
