> -Original Message-
> From: Marek Marczykowski-Górecki
> Sent: 10 May 2021 20:43
> To: Michael Brown ; p...@xen.org
> Cc: p...@xen.org; xen-devel@lists.xenproject.org; net...@vger.kernel.org;
> wei@kernel.org; Durrant,
> Paul
> Subject: RE: [EXTERNAL] [PATCH] xen-netback: Check for
kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.
There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h
flight 161901 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161901/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
Short-form boolean options are deprecated in QEMU 6.0.
Upstream commit that deprecate those: ccd3b3b8112b ("qemu-option: warn
for short-form boolean options").
Signed-off-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
tools/libs/light/libxl_dm.c | 14 +++---
1 file changed, 7 inserti
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.deprecated-qemu-qmp-and-cmd-v2
v2:
- fix coding style in patch 3
- all reviewed
The Xen 4.15 release that went out just before QEMU 6.0 won't be compaptible
with the latter. This patch
We use the deprecated QMP command "query-cpus" which is removed in the
QEMU 6.0 release. There's a replacement which is "query-cpus-fast",
and have been available since QEMU 2.12 (April 2018).
This patch try the new command first and when the command isn't
available, it fall back to the deprecated
This allows to set an `id` on the device instead of only the drive. We
are going to need the `id` with the "eject" and
"blockdev-change-media" QMP command as using `device` parameter on
those is deprecated. (`device` is the `id` of the `-drive` on the
command line).
We set the same `id` on both -d
The command "cpu-add" for CPU hotplug is deprecated and has been
removed from QEMU 6.0 (April 2021). We need to add cpus with the
command "device_add" now.
In order to find out which parameters to pass to "device_add" we first
make a call to "query-hotpluggable-cpus" which list the cpus drivers
an
We are supposed to read the version information only when qmp_ev is in
state "Connected" (that correspond to state==qmp_state_connected),
assert it so that the function isn't used too early.
Signed-off-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
tools/libs/light/libxl_qmp.c | 2 ++
1 file
We are going to want to check QEMU's version in other places where we
can use libxl__ev_qmp_send.
Signed-off-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
tools/libs/light/libxl_internal.h | 8
tools/libs/light/libxl_qmp.c | 4 ++--
2 files changed, 10 insertions(+), 2 deletio
"change" command as been removed in QEMU 6.0. We can use
"blockdev-change-medium" instead.
Using `id` with "blockdev-change-medium" requires a change to the QEMU
command line, introduced by:
"libxl: Use -device for cd-rom drives"
Signed-off-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
`device` parameter is deprecated since QEMU 2.8.
This requires changes to the command line introduced by:
"libxl: Use -device for cd-rom drives"
Signed-off-by: Anthony PERARD
Reviewed-by: Jason Andryuk
---
tools/libs/light/libxl_disk.c | 43 +--
1 file chang
flight 161898 xen-unstable real [real]
flight 161903 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161898/
http://logs.test-lab.xenproject.org/osstest/logs/161903/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Tue, May 11, 2021 at 07:06:55AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Marek Marczykowski-Górecki
> > Sent: 10 May 2021 20:43
> > To: Michael Brown ; p...@xen.org
> > Cc: p...@xen.org; xen-devel@lists.xenproject.org; net...@vger.kernel.org;
> > wei@kernel.org;
On Tue, May 11, 2021 at 12:40:54PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, May 11, 2021 at 07:06:55AM +, Durrant, Paul wrote:
> > > -Original Message-
> > > From: Marek Marczykowski-Górecki
> > > Sent: 10 May 2021 20:43
> > > To: Michael Brown ; p...@xen.org
> > > Cc: p...@x
flight 161900 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161900/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
> -Original Message-
> From: Marek Marczykowski-Górecki
> Sent: 11 May 2021 11:45
> To: Durrant, Paul
> Cc: Michael Brown ; p...@xen.org;
> xen-devel@lists.xenproject.org;
> net...@vger.kernel.org; wei@kernel.org
> Subject: RE: [EXTERNAL] [PATCH] xen-netback: Check for hotplug-status
On 5/11/21 2:41 AM, Andy Shevchenko wrote:
kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.
There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by m
On Mon, Apr 05, 2021 at 04:57:04PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> literal strings are not meant to be modified. So we should use const
> *char rather than char * when we want to store a pointer to them.
>
> Signed-off-by: Julien Grall
> ---
> diff --git a/tools/libs/guest/x
On Mon, Apr 05, 2021 at 04:57:05PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> literal strings are not meant to be modified. So we should use const
> char * rather than char * when we want to store a pointer to them.
>
> Signed-off-by: Julien Grall
Reviewed-by: Anthony PERARD
Thanks,
On Mon, Apr 05, 2021 at 04:57:08PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> literal strings are not meant to be modified. So we should use const
> char * rather than char * when we want to store a pointer to them.
>
> Signed-off-by: Julien Grall
> ---
> diff --git a/tools/console/dae
On Mon, Apr 05, 2021 at 04:57:10PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> literal strings are not meant to be modified. So we should use const
> char * rather than char * when we we to store a pointer to them.
>
> Signed-off-by: Julien Grall
Reviewed-by: Anthony PERARD
Thanks,
flight 161902 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161902/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Mon, Apr 05, 2021 at 04:57:11PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> Neither string parameter in set_prompt() and set_delay() are meant to
> be modified. In particular, new_prompt can point to a literal string.
>
> So mark the two parameters as const and propagate it.
>
> Sign
On Mon, Apr 05, 2021 at 04:57:12PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> The field text in stat_map_t will point to string literals. So mark it
> as const to allow the compiler to catch any modified of the string.
>
> Signed-off-by: Julien Grall
Reviewed-by: Anthony PERARD
Than
On 03/05/2021 15:22, Jan Beulich wrote:
>> Another consequence is that we need to rethink our hypercall behaviour.
>> There is no such thing as supervisor states in an uncompressed XSAVE
>> image, which means we can't continue with that being the ABI.
> I don't think the hypercall input / output b
On Mon, May 10, 2021 at 11:03 PM Christoph Hellwig wrote:
>
> > +static inline struct io_tlb_mem *get_io_tlb_mem(struct device *dev)
> > +{
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + if (dev && dev->dma_io_tlb_mem)
> > + return dev->dma_io_tlb_mem;
> > +#endif /* CONFIG_DMA_RESTR
On Mon, May 10, 2021 at 11:03 PM Christoph Hellwig wrote:
>
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#endif
>
> I don't think any of this belongs into swiotlb.c. Marking
> swiotlb_init_io_tlb_mem non-static and having a
On Tue, 11 May 2021, Christoph Hellwig wrote:
> On Mon, May 10, 2021 at 06:46:34PM -0700, Stefano Stabellini wrote:
> > On Mon, 10 May 2021, Christoph Hellwig wrote:
> > > On Sat, May 08, 2021 at 12:32:37AM +0100, Julien Grall wrote:
> > > > The pointer dereferenced seems to suggest that the swiotl
On Mon, May 10, 2021 at 11:05 PM Christoph Hellwig wrote:
>
> > +static inline bool is_dev_swiotlb_force(struct device *dev)
> > +{
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + if (dev->dma_io_tlb_mem)
> > + return true;
> > +#endif /* CONFIG_DMA_RESTRICTED_POOL */
> > + return
On Tue, May 11, 2021 at 09:47:33AM -0700, Stefano Stabellini wrote:
> That's a much better plan. It is also not super urgent, so maybe for now
> we could add an explicit check for io_tlb_default_mem != NULL at the
> beginning of xen_swiotlb_init? So that at least we can fail explicitly
> or ignore
On Tue, 11 May 2021, Christoph Hellwig wrote:
> On Tue, May 11, 2021 at 09:47:33AM -0700, Stefano Stabellini wrote:
> > That's a much better plan. It is also not super urgent, so maybe for now
> > we could add an explicit check for io_tlb_default_mem != NULL at the
> > beginning of xen_swiotlb_init
On Tue, May 11, 2021 at 09:51:20AM -0700, Stefano Stabellini wrote:
> On Tue, 11 May 2021, Christoph Hellwig wrote:
> > On Tue, May 11, 2021 at 09:47:33AM -0700, Stefano Stabellini wrote:
> > > That's a much better plan. It is also not super urgent, so maybe for now
> > > we could add an explicit c
From: Stefano Stabellini
Although SWIOTLB_NO_FORCE is meant to allow later calls to swiotlb_init,
today dma_direct_map_page returns error if SWIOTLB_NO_FORCE.
For now, without a larger overhaul of SWIOTLB_NO_FORCE, the best we can
do is to avoid setting SWIOTLB_NO_FORCE in mem_init when we know
From: Stefano Stabellini
xen_swiotlb_init calls swiotlb_late_init_with_tbl, which fails with
-ENOMEM if the swiotlb has already been initialized.
Add an explicit check io_tlb_default_mem != NULL at the beginning of
xen_swiotlb_init. If the swiotlb is already initialized print a warning
and retur
These patches have been posted previously.
The gnttab patches (tools/ocaml/libs/mmap) were not applied at the time
to avoid conflicts with an in-progress XSA.
The binary format live-update and fuzzing patches were not applied
because it was too close to the next Xen release freeze.
The patches dep
Do not dump -1, it'll trigger an assertion, use 0xFF.. instead.
Signed-off-by: Edwin Török
---
tools/ocaml/xenstored/connection.ml | 63 +
tools/ocaml/xenstored/disk.ml | 3 +-
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/tools/ocaml/xenstor
This is implemented by C xenstored as live update dump format.
oxenstored already has its own (text-based) dump format, but for
compatibility implement one compatible with C xenstored.
This will also be useful in the future for non-cooperative guest live migration.
docs/designs/xenstore-migration
Signed-off-by: Edwin Török
---
docs/designs/xenstore-migration.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/designs/xenstore-migration.md
b/docs/designs/xenstore-migration.md
index 5f1155273e..87ef540918 100644
--- a/docs/designs/xenstore-migration.md
+++ b/docs/
oxenstored already had support for loading a partial dump from a text format.
Add support for the binary format too.
We no longer dump the text format, but we support loading the text format for
backwards compatibility purposes.
(a version of oxenstored supporting live-update with the old text form
Based on initial work by Christian Lindig
Doing oxenstored development, especially fuzzing/unit tests requires
an incremental and fast build system.
Dune is the preferred upstream build system for OCaml, and has been in
use by the XAPI project for years.
Is is incremental and also generates edito
Based on ideas from qcstm, implemented using Crowbar.
Quickcheck-style property tests that uses AFL for quickly
exploring various values that trigger bugs in the code.
This is structured/guided fuzzing: we read an arbitrary random number,
and use it to generate some valid looking xenstore trees a
Also expose these macros in a header file that can be reused by
the upcoming grant table code.
Signed-off-by: Edwin Török
---
tools/ocaml/libs/mmap/mmap_stubs.h| 7 +++
tools/ocaml/libs/mmap/xenmmap_stubs.c | 2 --
tools/ocaml/libs/xb/xs_ring_stubs.c | 14 +-
3 files chan
The configuration file can contain typos or various errors that could prevent
live update from succeeding (e.g. a flag only valid on a different version).
Unknown entries in the config file would be ignored on startup normally,
add a strict --config-test that live-update can use to check that the c
On Tue, 2021-05-11 at 19:05 +0100, Edwin Török wrote:
> These patches have been posted previously.
A git tree is available here for easier reviewing:
https://github.com/edwintorok/xen/pull/2
> The gnttab patches (tools/ocaml/libs/mmap) were not applied at the
> time
> to avoid conflicts with an
Xenmmap is only modified by the ring functions,
these functions are unused.
Signed-off-by: Edwin Török
---
tools/ocaml/libs/mmap/xenmmap.ml | 5
tools/ocaml/libs/mmap/xenmmap.mli | 4 ---
tools/ocaml/libs/mmap/xenmmap_stubs.c | 41 ---
3 files changed, 50
This is a port of the following C xenstored commit
122b52230aa5b79d65e18b8b77094027faa2f8e2 tools/xenstore: don't store domU's mfn
of ring page in xenstored
Backwards compat: accept a domain dump both with and without MFN.
CC: Juergen Gross
Signed-off-by: Edwin Török
---
tools/ocaml/xenstored
These functions can potentially take some time,
so allow other OCaml code to proceed meanwhile (if any).
Signed-off-by: Edwin Török
---
tools/ocaml/libs/mmap/xenmmap_stubs.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/ocaml/libs/mmap/xenmmap_stubs.c
b
Upstream URL: https://github.com/mirage/ocaml-gnt
Mirage is part of the Xen project and the license is compatible,
copyright headers are retained.
Changes from upstream:
* cut down dependencies: dropped Lwt, replaced Io_page with Xenmmap
* only import Gnttab and not Gntshr
This is for xenstored's
This is an oxenstored port of the following C xenstored commit:
38eeb3864de40aa568c48f9f26271c141c62b50b tools/xenstored: Drop mapping of the
ring via foreign map
Now only Xenctrl.domain_getinfo remains as the last use of unstable xenctrl
interface
in oxenstored.
Depends on: tools/ocaml: safer
OCaml memory allocation functions use words as units,
unless explicitly documented otherwise.
Thus we were allocating more memory than necessary,
caml_alloc should've been called with the parameter '2',
but was called with a lot more.
To account for future changes in the struct keep using sizeof,
b
This also handles mmap errors better by using the `uerror` helper
to raise a proper exception using `errno`.
Changed type of `len` from `int` to `size_t`: at construction time we
ensure the length is >= 0, so we can reflect this by using an unsigned
type. The type is unsigned at the C API level, a
Xenmmap.mmap_interface is created from multiple places:
* via mmap(), which needs to be unmap()-ed
* xc_map_foreign_range
* xengnttab_map_grant_ref
Signed-off-by: Edwin Török
---
tools/ocaml/libs/mmap/gnt.ml | 14 --
tools/ocaml/libs/mmap/gnt.mli | 3 ++-
tools/ocaml/libs/m
flight 161904 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161904/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On 11/05/2021 19:05, Edwin Török wrote:
> These patches have been posted previously.
> The gnttab patches (tools/ocaml/libs/mmap) were not applied at the time
> to avoid conflicts with an in-progress XSA.
> The binary format live-update and fuzzing patches were not applied
> because it was too clos
On Thu, 6 May 2021, Jan Beulich wrote:
> An alternative to correcting the (as it seems) v2 related issues, it
> may be worth considering to extract only v1 documentation in this
> initial phase.
FWIW I agree with Jan that "grant table v1" documentation only is a good idea.
flight 161905 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161905/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> Commit 05031fa87357 "xen/arm: guest_walk: Only generate necessary
> offsets/masks" introduced LPAE_ENTRIES_MASK_GS. In a follow-up patch,
> we will use it for to define LPAE_ENTRY_MASK.
>
> This will lead to inconsistent naming. A
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> Currently, Xen PT helpers are only working with 4KB page granularity
> and open-code the generic helpers. To allow more flexibility, we can
> re-use the generic helpers and pass Xen's page granularity
> (PAGE_SHIFT).
>
> As Xen PT
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> The array level_orders and level_masks can be replaced with the
> recently introduced macros LEVEL_ORDER and LEVEL_MASK.
>
> Signed-off-by: Julien Grall
So you actually planned to use LEVEL_ORDER and LEVEL_MASK in the xen/
code.
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, xen_pt_update_entry() only supports mapping at level 3
> (i.e 4KB mapping). While this is fine for most of the runtime helper,
> the boot code will require to use superpage mapping.
>
> We don't want to allow superp
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> Currently, the function xen_pt_update() will flush the TLBs even when
> the mappings are inserted. This is a bit wasteful because we don't
> allow mapping replacement. Even if we were, the flush would need to
> happen earlier becau
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> Now that xen_pt_update_entry() is able to deal with different mapping
> size, we can replace the open-coding of the page-tables update by a call
> to modify_xen_mappings().
>
> As the function is not meant to fail, a BUG_ON() is a
On 5/11/21 1:41 PM, Stefano Stabellini wrote:
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -164,6 +164,11 @@ int __ref xen_swiotlb_init(void)
> int rc = -ENOMEM;
> char *start;
>
> + if (io_tlb_default_mem != NULL) {
> + printk(KERN_WARNIN
Add support for the xHCI debug capability (DbC). The DbC provides
a SuperSpeed serial link between a debug target running Xen and a
debug host. To use it you will need a USB3 A/A debug cable plugged into
a root port on the target machine. Recent kernels report the existence
of the DbC capability at
Hi all,
This goal of this series is to allow the USB3 debug capability (DbC) to be
safely used by xen while linux runs as dom0. The first patch prevents
the early DbC driver from using an already-running DbC. The second
exports xen_dbgp_reset_prep and xen_dbgp_external_startup functions when
CONFI
Check if the debug capability is enabled in early_xdbc_parse_parameter,
and if it is, return with an error. This avoids collisions with whatever
enabled the DbC prior to linux starting.
Signed-off-by: Connor Davis
---
drivers/usb/early/xhci-dbc.c | 10 ++
1 file changed, 10 insertions(+)
When running as a dom0 guest on Xen, check if the USB3 debug
capability is enabled before xHCI reset, suspend, and resume. If it
is, call xen_dbgp_reset_prep() to notify Xen that it is unsafe to touch
MMIO registers until the next xen_dbgp_external_startup().
This notification allows Xen to avoid
Export xen_dbgp_reset_prep and xen_dbgp_external_startup
when CONFIG_XEN_DOM0 is defined. This allows use of these symbols
even if CONFIG_EARLY_PRINK_DBGP is defined.
Signed-off-by: Connor Davis
---
drivers/xen/dbgp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xe
flight 161906 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161906/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 161908 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161908/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4e5ecdbac8bdf235b2072baa0c5e170cd9f57463
baseline version:
ovmf ef3840c1ff320698523dd
On 12.05.21 02:18, Connor Davis wrote:
Export xen_dbgp_reset_prep and xen_dbgp_external_startup
when CONFIG_XEN_DOM0 is defined. This allows use of these symbols
even if CONFIG_EARLY_PRINK_DBGP is defined.
Signed-off-by: Connor Davis
Acked-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628B
Ping?
On 12.04.21 17:22, Juergen Gross wrote:
There are some corners left which don't support the not so very new
linear p2m list of pv guests, which has been introduced in Linux kernel
3.19 and which is mandatory for non-legacy versions of Xen since kernel
4.14.
This series adds support for th
73 matches
Mail list logo
