flight 184670 xen-unstable real [real]
flight 184672 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184670/
http://logs.test-lab.xenproject.org/osstest/logs/184672/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
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 +++
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 changed
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 cas
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 files
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:
- "max-s
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)
---
too
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() (us
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 insertions(+)
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 relat
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 d08c
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
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 a/tools/9pfs
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 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)
---
tools/9pfsd/io
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 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: Ant
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
impl
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)
- rena
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 resp
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.
Signed-
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 fr
On 14.02.24 18:48, Andrew Cooper wrote:
On 08/02/2024 4:55 pm, Juergen Gross wrote:
+static struct p9_fid *alloc_fid(device *device, unsigned int fid,
+const char *path)
+{
+struct p9_fid *fidp = NULL;
+
+pthread_mutex_lock(&device->fid_mutex);
+
+if (
On 14.02.24 18:40, Andrew Cooper wrote:
On 08/02/2024 4:55 pm, Juergen Gross wrote:
+static struct p9_fid *alloc_fid_mem(device *device, unsigned int fid,
+const char *path)
+{
+struct p9_fid *fidp;
+size_t pathlen;
+
+pathlen = strlen(path);
+
On 14.02.24 18:27, Anthony PERARD wrote:
On Wed, Feb 14, 2024 at 11:18:18AM +0100, Jürgen Groß wrote:
On 13.02.24 19:03, Anthony PERARD wrote:
On Thu, Feb 08, 2024 at 05:55:39PM +0100, Juergen Gross wrote:
+struct libxl__aop9_state {
+libxl__spawn_state spawn;
+libxl__ao_device *aodev;
On 2/14/24 06:38, Jan Beulich wrote:
> On 02.02.2024 22:33, Stewart Hildebrand wrote:
>> --- a/xen/arch/x86/physdev.c
>> +++ b/xen/arch/x86/physdev.c
>> @@ -123,7 +123,9 @@ int physdev_map_pirq(domid_t domid, int type, int
>> *index, int *pirq_p,
>>
>> case MAP_PIRQ_TYPE_MSI:
>> case M
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:
> >>> On Tue, Feb 13, 2024 at 08:45:54AM +0100, Jan Beulich wrote:
> >>>
On Wed, 31 Jan 2024, Luca Fancellu wrote:
> This serie is enabling the xen-analysis tool to parse and substitute correctly
> a deviation tag put at the end of the line containing a deviation to be
> deviated.
>
> Before this serie the only way to deviate a violation was to put the tag in
> the
>
On Wed, 14 Feb 2024, Federico Serafini wrote:
> On 12/02/24 09:43, Jan Beulich wrote:
> > On 09.02.2024 10:50, Federico Serafini wrote:
> > > On 08/02/24 12:14, Jan Beulich wrote:
> > > > On 08.02.2024 11:45, Federico Serafini wrote:
> > > > > On 07/02/24 17:19, Jan Beulich wrote:
> > > > > > On 07
flight 184668 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184668/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184665
test-amd64-amd64-xl-qemut-win7-amd64
flight 184669 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184669/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf edc6681206c1a8791981a2f911d2fb8b3d2f5768
baseline version:
ovmf 5fd3078a2e08f607dc86a
On 06/02/2024 10:08 am, Petr Beneš wrote:
> From: Petr Beneš
>
> This patch addresses a behavior discrepancy in the handling of altp2m views,
> where upon the creation and subsequent EPT violation, the page access
> permissions were incorrectly inherited from the hostp2m instead of respecting
> th
On 14/02/2024 6:00 pm, 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 standa
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 standard (at least, it seems to be
mandatory since IEEE Std
On 08/02/2024 4:55 pm, Juergen Gross wrote:
> +static struct p9_fid *alloc_fid(device *device, unsigned int fid,
> +const char *path)
> +{
> +struct p9_fid *fidp = NULL;
> +
> +pthread_mutex_lock(&device->fid_mutex);
> +
> +if ( find_fid(device, fid) )
>
On 08/02/2024 4:55 pm, Juergen Gross wrote:
> +static struct p9_fid *alloc_fid_mem(device *device, unsigned int fid,
> +const char *path)
> +{
> +struct p9_fid *fidp;
> +size_t pathlen;
> +
> +pathlen = strlen(path);
> +fidp = calloc(sizeof(*fidp)
On Wed, Feb 14, 2024 at 11:18:18AM +0100, Jürgen Groß wrote:
> On 13.02.24 19:03, Anthony PERARD wrote:
> > On Thu, Feb 08, 2024 at 05:55:39PM +0100, Juergen Gross wrote:
> > > +struct libxl__aop9_state {
> > > +libxl__spawn_state spawn;
> > > +libxl__ao_device *aodev;
> > > +libxl_devi
flight 184667 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184667/
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
On Thu, Feb 08, 2024 at 05:55:45PM +0100, Juergen Gross wrote:
> 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-o
On Thu, Feb 08, 2024 at 05:55:42PM +0100, Juergen Gross wrote:
> diff --git a/tools/include/libxl.h b/tools/include/libxl.h
> index a554f2ccd6..e6ab5ddb94 100644
> --- a/tools/include/libxl.h
> +++ b/tools/include/libxl.h
> @@ -583,6 +583,13 @@
> * libxl_console_add_xenstore() in libxl.
> */
>
On Thu, Feb 08, 2024 at 05:55:40PM +0100, 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 ca
On 12/02/24 09:43, Jan Beulich wrote:
On 09.02.2024 10:50, Federico Serafini wrote:
On 08/02/24 12:14, Jan Beulich wrote:
On 08.02.2024 11:45, Federico Serafini wrote:
On 07/02/24 17:19, Jan Beulich wrote:
On 07.02.2024 16:58, Federico Serafini wrote:
On 07/02/24 16:24, Jan Beulich wrote:
O
On 2024-02-14 16:45, Jan Beulich wrote:
On 14.02.2024 16:31, Nicola Vetrini wrote:
On 2024-02-14 12:49, Jan Beulich wrote:
On 14.02.2024 12:26, Nicola Vetrini wrote:
+-config=MC3R1.R20.12,macros+={deliberate,
"name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}
I said in another c
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in
the QM.
Since the fsl,imx8qm-lpuart compatible in Linux exists in name only and is
not used in the driver any iMX8QM device tree that can boot Linux must set
fsl,imx8qxp-lpuart compatible as well as the QM one.
Thus we repl
The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driver")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.
We're also fixing compatibles in imx-lpuart to allow Xen to use the UART
on the QXP variant as well.
NOTE:
There
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 format of these calls are as follows:
- reg 0: service ID
- reg
On Wed, Feb 14, 2024 at 03:53:24PM +, Andrew Cooper wrote:
> On 14/02/2024 3:29 pm, Roger Pau Monné wrote:
> > On Wed, Feb 14, 2024 at 04:08:12PM +0100, Jan Beulich wrote:
> >> On 14.02.2024 16:02, Roger Pau Monné wrote:
> >>> On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
> >
On 14/02/2024 3:29 pm, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 04:08:12PM +0100, Jan Beulich wrote:
>> On 14.02.2024 16:02, Roger Pau Monné wrote:
>>> On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
We just pushed a 8-bytes zero and exception constants are
small
On 14.02.2024 16:31, Nicola Vetrini wrote:
> On 2024-02-14 12:49, Jan Beulich wrote:
>> On 14.02.2024 12:26, Nicola Vetrini wrote:
>>> +-config=MC3R1.R20.12,macros+={deliberate,
>>> "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}
>>
>> I said in another context already that it is n
On 02.02.2024 22:33, Stewart Hildebrand wrote:
> @@ -836,9 +870,20 @@ static int cf_check init_header(struct pci_dev *pdev)
> if ( pdev->ignore_bars )
> return 0;
>
> -/* Disable memory decoding before sizing. */
> cmd = pci_conf_read16(pdev->sbdf, PCI_COMMAND);
> -if (
On 2024-02-14 12:49, Jan Beulich wrote:
On 14.02.2024 12:26, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -387,6 +387,16 @@ in assignments."
{safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
-doc_end
+-doc_begin
flight 184665 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184665/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 20
guest-start/debianhvm.repeat fail in 184660 pass in 184665
W=1 builds now warn if module is built without a MODULE_DESCRIPTION().
Add descriptions to the Xen backend network module.
Signed-off-by: Breno Leitao
Acked-by: Paul Durrant
---
drivers/net/xen-netback/netback.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/xen-netback/netback
On Wed, Feb 14, 2024 at 04:08:12PM +0100, Jan Beulich wrote:
> On 14.02.2024 16:02, Roger Pau Monné wrote:
> > On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
> >> We just pushed a 8-bytes zero and exception constants are
> >> small so we can just write a single byte saving 3 bytes
On Wed, Feb 14, 2024 at 02:34:11PM +, Anthony PERARD wrote:
> The `which` command is not standard, may not exist on the build host,
> or may not behave as expected. It is recommanded to use `command -v`
> to find out if a command exist and have it's path, and it's part of a
> POSIX shell standa
On 14.02.2024 15:34, Anthony PERARD wrote:
> The `which` command is not standard, may not exist on the build host,
> or may not behave as expected. It is recommanded to use `command -v`
> to find out if a command exist and have it's path, and it's part of a
> POSIX shell standard.
Just to mention
On 14.02.2024 15:34, Anthony PERARD wrote:
> The `which` command is not standard, may not exist on the build host,
> or may not behave as expected. It is recommanded to use `command -v`
> to find out if a command exist and have it's path, and it's part of a
> POSIX shell standard.
>
> Signed-off-b
On 14.02.2024 16:02, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
>> We just pushed a 8-bytes zero and exception constants are
>> small so we can just write a single byte saving 3 bytes for
>> instruction.
>> With ENDBR64 this reduces the size of many en
On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
> We just pushed a 8-bytes zero and exception constants are
> small so we can just write a single byte saving 3 bytes for
> instruction.
> With ENDBR64 this reduces the size of many entry points from 32 to
> 16 bytes (due to alignment
The `which` command is not standard, may not exist on the build host,
or may not behave as expected. It is recommanded to use `command -v`
to find out if a command exist and have it's path, and it's part of a
POSIX shell standard.
Signed-off-by: Anthony PERARD
---
xen/Makefile | 4 ++--
1 file c
On 14.02.2024 15:11, Roger Pau Monne wrote:
> It's not obvious from just the function name whether the incremented value
> will
> be stored in the parameter, or returned to the caller. That has leads to bugs
> in the past as callers may assume the incremented value is stored in the
> parameter.
>
On 14.02.2024 15:05, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 02:29:35PM +0100, Jan Beulich wrote:
>> On 14.02.2024 11:37, Roger Pau Monne wrote:
>>> Adjust the code in the checker to use full addresses rather than frame
>>> numbers,
>>> as it's only page_get_ram_type() that requires an mf
On 14.02.2024 11:35, Frediano Ziglio wrote:
> @@ -898,105 +898,105 @@ END(handle_exception)
> FUNC(entry_DE)
> ENDBR64
> pushq $0
> -movl $X86_EXC_DE, 4(%rsp)
> +movb $X86_EXC_DE, 4(%rsp)
As we're trying to compact things: This writes 0 over the previously
push
Hi Jan,
On Wed, Feb 14, 2024 at 8:55 AM Jan Beulich wrote:
>
> On 13.02.2024 18:29, Carlo Nonato wrote:
> > On Tue, Feb 13, 2024 at 4:25 PM Jan Beulich wrote:
> >> On 29.01.2024 18:18, Carlo Nonato wrote:
> >>> @@ -218,9 +230,44 @@ static void xen_pt_enforce_wnx(void)
> >>> --- a/xen/common/llc-
It's not obvious from just the function name whether the incremented value will
be stored in the parameter, or returned to the caller. That has leads to bugs
in the past as callers may assume the incremented value is stored in the
parameter.
Add the __must_check attribute to the function to easil
flight 184666 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184666/
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
On Wed, Feb 14, 2024 at 02:29:35PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > Adjust the code in the checker to use full addresses rather than frame
> > numbers,
> > as it's only page_get_ram_type() that requires an mfn parameter.
> >
> > Suggested-by: Andrew Coop
On Wed, Feb 14, 2024 at 02:22:09PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > It's easier to correlate with the physical memory map if the addresses are
> > fully printed, instead of using frame numbers.
> >
> > Requested-by: Andrew Cooper
> > Signed-off-by: Roger
On Wed, Feb 14, 2024 at 02:42:46PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > It's not obvious from the function itself whether the incremented value
> > will be
>
> s/the function itself/just the function name/ ?
>
> > stored in the parameter, or returned to the
On 14.02.2024 11:35, Frediano Ziglio wrote:
> We just pushed a 8-bytes zero
This part is now somewhat stale.
> and exception constants are
> small so we can just write a single byte saving 3 bytes for
> instruction.
> With ENDBR64 this reduces the size of many entry points from 32 to
> 16 bytes (
On 14/02/24 14:15, Jan Beulich wrote:
On 14.02.2024 12:27, Federico Serafini wrote:
On 14/02/24 09:28, Jan Beulich wrote:
On 13.02.2024 23:33, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
docs/misra/rules.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/do
Hi Michal,
On Wed, Feb 14, 2024 at 11:14 AM Michal Orzel wrote:
>
> Hi Carlo,
>
> On 29/01/2024 18:17, Carlo Nonato wrote:
> >
> >
> > LLC coloring needs to know the last level cache layout in order to make the
> > best use of it. This can be probed by inspecting the CLIDR_EL1 register,
> > so th
On 14.02.2024 11:37, Roger Pau Monne wrote:
> It's not obvious from the function itself whether the incremented value will
> be
s/the function itself/just the function name/ ?
> stored in the parameter, or returned to the caller. That has leads to bugs in
> the past as callers assume the increm
On 14.02.2024 11:37, Roger Pau Monne wrote:
> Provide more information in case the page can't be converted, and print the
> original type(s).
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
> On 14 Feb 2024, at 11:45, Andrew Cooper wrote:
>
> Xapi is the only consumer of this interface. I've fixed up the build
> against staging, but we're not going to be running KFX under Xapi any
> time soon.
>
> Ultimately it's Christian's call.
After a discussion with Andrew, we will not b
On 14.02.2024 11:37, Roger Pau Monne wrote:
> Adjust the code in the checker to use full addresses rather than frame
> numbers,
> as it's only page_get_ram_type() that requires an mfn parameter.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
In this very shape I'd like to lea
On 14.02.2024 11:37, Roger Pau Monne wrote:
> It's easier to correlate with the physical memory map if the addresses are
> fully printed, instead of using frame numbers.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
In principle
Reviewed-by: Jan Beulich
I'm not sure though t
On 14.02.2024 12:27, Federico Serafini wrote:
> On 14/02/24 09:28, Jan Beulich wrote:
>> On 13.02.2024 23:33, Stefano Stabellini wrote:
>>> Signed-off-by: Stefano Stabellini
>>> ---
>>> docs/misra/rules.rst | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/docs/misra/rules.rs
On 14.02.2024 13:16, Oleksii wrote:
> On Mon, 2024-02-12 at 16:20 +0100, Jan Beulich wrote:
>> On 05.02.2024 16:32, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>
>> Acked-by: Jan Beulich
>> again with a nit, though:
>>
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/event.
On 14.02.2024 13:11, Oleksii wrote:
> On Tue, 2024-02-13 at 12:36 +0100, Jan Beulich wrote:
>> On 05.02.2024 16:32, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/atomic.h
>>> @@ -0,0 +1,395 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Taken an
On 14.02.2024 13:21, Oleksii wrote:
> On Wed, 2024-02-14 at 10:52 +0100, Jan Beulich wrote:
>> On 05.02.2024 16:32, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>> ---
>>> Changes in V4:
>>> - Update version of GCC (12.2) and GNU Binutils (2.39) to the
>>> version
>>> which
On 14.02.2024 13:42, GitLab wrote:
>
>
> Pipeline #1176167215 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/xen )
> Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
>
> Commit: d670c1a3 (
> https://gitlab.com/xen-project/xen/-/commit/d670c1a38ba3561296f6
On Wed, 2024-02-14 at 10:52 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V4:
> > - Update version of GCC (12.2) and GNU Binutils (2.39) to the
> > version
> > which are in Xen's contrainter for RISC-V
> >
On Mon, 2024-02-12 at 16:20 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
>
> Acked-by: Jan Beulich
> again with a nit, though:
>
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/event.h
> > @@ -0,0 +1,40 @@
> > +/* SPDX-Licen
On Mon, 2024-02-12 at 16:18 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > Acked-by: Jan Beulich
>
> Nevertheless ...
>
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/time.h
> > @@ -0,0 +1,29 @@
> > +/* SPDX-License-Ident
On Mon, 2024-02-12 at 16:16 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
>
> Acked-by: Jan Beulich
> with two more nits:
>
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/p2m.h
> > @@ -0,0 +1,102 @@
> > +/* SPDX-License-Iden
On Tue, 2024-02-13 at 12:36 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > From: Bobby Eshleman
> >
> > Additionally, this patch introduces macros in fence.h,
> > which are utilized in atomic.h.
>
> These are used in an earlier patch already, so either you want to
>
Hi Oleksii,
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 device device_t;
+
+#ifdef CONFIG_HAS_DEVICE_TREE
+
On Wed, Feb 14, 2024 at 12:51:36PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > mfn_add() doesn't store the incremented value in the parameter, and instead
> > returns it to the caller. As a result, the loop in iommu_unity_region_ok()
> > didn't make progress. Fix i
Hi,
On 14/02/2024 10:37, Roger Pau Monne wrote:
It's not obvious from the function itself whether the incremented value will be
stored in the parameter, or returned to the caller. That has leads to bugs in
the past as callers assume the incremented value is stored in the parameter.
Add the __m
On 14.02.2024 11:37, Roger Pau Monne wrote:
> mfn_add() doesn't store the incremented value in the parameter, and instead
> returns it to the caller. As a result, the loop in iommu_unity_region_ok()
> didn't make progress. Fix it by storing the incremented value.
>
> Fixes: e45801dea17b ('iommu/
On 14.02.2024 12:26, Nicola Vetrini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -387,6 +387,16 @@ in assignments."
> {safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
> -doc_end
>
> +-doc_begin="The token pasting in varia
On 14/02/2024 7:11 am, Jan Beulich wrote:
> On 08.02.2024 10:13, Christian Lindig wrote:
>>> On 7 Feb 2024, at 22:04, Petr Beneš wrote:
>>> Add the missing `vmtrace_buf_kb` field to the OCaml bindings to match the
>>> vm.cfg configuration, correcting an oversight from its initial introduction.
>>>
Provide more information in case the page can't be converted, and print the
original type(s).
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/x86/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/x86/io
Hello,
First patch is a fix for a silly mistake I introduced in
iommu_unity_region_ok(). The rest are additional chances requested in
that context. Last patch adds __must_check to the gfn/mfn addition
handlers.
Thanks, Roger.
Roger Pau Monne (5):
iommu/x86: fix IVMD/RMRR range checker loop i
It's easier to correlate with the physical memory map if the addresses are
fully printed, instead of using frame numbers.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/x86/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xe
It's not obvious from the function itself whether the incremented value will be
stored in the parameter, or returned to the caller. That has leads to bugs in
the past as callers assume the incremented value is stored in the parameter.
Add the __must_check attribute to the function to easily spot
Adjust the code in the checker to use full addresses rather than frame numbers,
as it's only page_get_ram_type() that requires an mfn parameter.
Suggested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/x86/iommu.c | 23 ++-
1 file changed, 10 in
mfn_add() doesn't store the incremented value in the parameter, and instead
returns it to the caller. As a result, the loop in iommu_unity_region_ok()
didn't make progress. Fix it by storing the incremented value.
Fixes: e45801dea17b ('iommu/x86: introduce a generic IVMD/RMRR range validity
hel
1 - 100 of 138 matches
Mail list logo