On 27.11.20 17:07, t...@redhat.com wrote:
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
Applied to: xen/tip.git for-linus-5.11
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital
On 20.11.20 19:40, Gustavo A. R. Silva wrote:
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R.
On 20.11.20 19:32, Gustavo A. R. Silva wrote:
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R.
On 14.10.20 19:53, Jason Andryuk wrote:
A Xen PVH domain doesn't have a PCI bus or devices, so it doesn't need
PCI support built in. Currently, XEN_PVH depends on XEN_PVHVM which
depends on PCI.
The first patch introduces XEN_PVHVM_GUEST as a toplevel item and
changes XEN_PVHVM to a hidden
On 17.09.20 14:55, Qinglang Miao wrote:
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Qinglang Miao
Applied to: xen/tip.git for-linus-5.11
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital
On 15.12.20 19:09, Andrew Cooper wrote:
On 15/12/2020 16:35, Juergen Gross wrote:
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Reviewed-by: Julien Grall
---
V7:
- new patch
V8:
- some minor comments by Julien Grall addressed
Signed-off-by: Juergen Gross
Various of your patches
flight 157564 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157564/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-check fail blocked in 157133
flight 157590 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157590/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157560
Tests which
flight 157563 xen-4.13-testing real [real]
flight 157592 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157563/
http://logs.test-lab.xenproject.org/osstest/logs/157592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 157562 xen-4.12-testing real [real]
flight 157578 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157562/
http://logs.test-lab.xenproject.org/osstest/logs/157578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Tue, Dec 15, 2020 at 08:36:34AM -0800, Stefano Stabellini wrote:
> On Mon, 14 Dec 2020, Elliott Mitchell wrote:
> > The available examples seem geared towards Linux DomUs. I'm looking at a
> > FreeBSD installation image and it appears to expect an EFI firmware.
> > Beyond having a bunch of
flight 157582 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157560
Tests which
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64-libvirt
testid libvirt-build
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu
Hi all,
I am building Xen tools for ARM32 using qemu-user. I am getting the
following error building tools/flask. Everything else works fine. It is
worth noting that make -j1 works fine, it is only make -j4 that fails.
I played with .NOTPARALLEL but couldn't get it to work. Anyone has any
ideas?
On Tue, Dec 15, 2020 at 03:54:08PM +0100, Peter Zijlstra wrote:
> The problem is that a single instance of unwind information (ORC) must
> capture and correctly unwind all alternatives. Since the trivially
> correct mandate is out, implement the straight forward brute-force
> approach:
>
> 1)
flight 157575 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157575/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157560
Tests which
Hopefully I can provide a little more context. Here is a link to the patch:
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-extended/xen/files/libxl-fix-reboot.patch
The patch is a bit mis-named. It does not implement
XEN_DOMCTL_SENDTRIGGER_RESET. It's just a workaround to handle
On 15/12/2020 11:10, Juergen Gross wrote:
> In case a process waits for any Xenstore action in the xenbus driver
> it should be interruptible by signals.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - don't special case SIGKILL as libxenstore is handling -EINTR fine
> ---
>
Hi Daniel,
On Fri, 13 Nov 2020 at 19:07, Daniel Kiper wrote:
>
> Hey,
>
> This is next attempt to create firmware and bootloader log specification.
> Due to high interest among industry it is an extension to the initial
> bootloader log only specification. It takes into the account most of the
>
flight 157570 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157560
Tests which
On 12/15/20 6:10 AM, Juergen Gross wrote:
> In case a process waits for any Xenstore action in the xenbus driver
> it should be interruptible by signals.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - don't special case SIGKILL as libxenstore is handling -EINTR fine
Reviewed-by: Boris
On 11/11/2020 21:51, Ash Wilding wrote:
From: Ash Wilding
Hey,
Hi Ash,
I've found some time to improve this series a bit:
Changes since RFC v1
- Broken up patches into smaller chunks to aid in readability.
- As per Julien's feedback I've also introduced
Hi list,
This is a reply to the thread of the same title (linked here:
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg84916.html
) which I could not reply to because I receive this list by digest.
I'm unclear if this is exactly the reason, but I experienced the
same
flight 157555 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157555/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
Hi Ash,
On 11/11/2020 21:51, Ash Wilding wrote:
From: Ash Wilding
- s/arch_xchg/xchg/
- s/arch_cmpxchg/cmpxchg/
- Replace calls to BUILD_BUG() with calls to __bad_cmpxchg() as we
don't currently have a BUILD_BUG() macro in Xen and this will
equivalently cause a link-time
Hi Ash,
On 11/11/2020 21:51, Ash Wilding wrote:
From: Ash Wilding
Most of the "work" here is simply deleting the atomic64_t helper
definitions as we don't have an atomic64_t type in Xen.
There is some request to support atomic64_t in Xen. I would suggest to
keep as this would be simpler to
Hi Ash,
Apologies for the late reply.
On 05/11/2020 18:55, Ash Wilding wrote:
The current Arm boot_cpu_feature64() and boot_cpu_feature32() macros
are hardcoded to only detect features in ID_AA64PFR{0,1}_EL1 and
ID_PFR{0,1} respectively.
This patch replaces these macros with a new macro,
On 15/12/2020 16:35, Juergen Gross wrote:
> Signed-off-by: Juergen Gross
> Reviewed-by: Wei Liu
> Reviewed-by: Julien Grall
> ---
> V7:
> - new patch
>
> V8:
> - some minor comments by Julien Grall addressed
>
> Signed-off-by: Juergen Gross
Various of your patches still have double SoB.
On Tue, Dec 15, 2020 at 04:01:19PM +0100, Kevin Wolf wrote:
> Am 15.12.2020 um 14:15 hat Sergio Lopez geschrieben:
> > On Tue, Dec 15, 2020 at 01:12:33PM +0100, Kevin Wolf wrote:
> > > Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> > > > While processing the parents of a BDS, one of the
On Tue, Dec 15, 2020 at 04:34:05PM +0100, Kevin Wolf wrote:
> Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> > There's a cross-dependency between closing the block exports and
> > draining the block layer. The latter needs that we close all export's
> > client connections to ensure they
On Tue, Dec 15, 2020 at 01:12:33PM +0100, Kevin Wolf wrote:
> Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> > While processing the parents of a BDS, one of the parents may process
> > the child that's doing the tail recursion, which leads to a BDS being
> > processed twice. This is
On Tue, Dec 15, 2020 at 11:28 AM Jan Beulich wrote:
>
> Signed-off-by: Jan Beulich
Reviewed-by: Tamas K Lengyel
Hi,
On 15/12/2020 02:35, Roman Shaposhnik wrote:
On Mon, Dec 14, 2020 at 6:16 PM Elliott Mitchell wrote:
Finally getting to the truly productive stages of my project with Xen on
ARM.
How many of the OSes which function as x86 DomUs for Xen, function as
ARM DomUs? Getting Linux operational
Add reading the watch state records for live update.
This requires factoring out some of the add watch functionality into a
dedicated function.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
---
V4:
- add comment (Julien Grall)
V6:
- correct check_watch_path() (setting errno)
Add the needed functions for reading connection state for live update.
As the connection is identified by a unique connection id in the state
records we need to add this to struct connection. Add a new function
to return the connection based on a connection id.
Signed-off-by: Juergen Gross
flight 157561 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157561/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
From: Julien Grall
A domain could just be dying when live updating Xenstore, so the case
of not being able to map the ring page or to connect to the event
channel must be handled gracefully.
Signed-off-by: Julien Grall
Reviewed-by: Paul Durrant
---
V4:
- new patch (Julien, I hope adding the
On Mon, 14 Dec 2020, Elliott Mitchell wrote:
> Finally getting to the truly productive stages of my project with Xen on
> ARM.
>
> How many of the OSes which function as x86 DomUs for Xen, function as
> ARM DomUs? Getting Linux operational was straightforward, but what of
> others?
I know of
Hi,
On 15/12/2020 02:16, Elliott Mitchell wrote:
Finally getting to the truly productive stages of my project with Xen on
ARM.
How many of the OSes which function as x86 DomUs for Xen, function as
ARM DomUs? Getting Linux operational was straightforward, but what of
others?
If you are
Add activation of the new binary for live update. The daemon case is
handled completely, while for stubdom we only add stubs.
Signed-off-by: Juergen Gross
---
V7:
- added unbinding dom0 and virq event channels
V8:
- no longer close dom0 evtchn (Julien Grall)
V10:
- remember original argc and
Add the needed functions for reading node state for live update.
This requires some refactoring of current node handling in Xenstore in
order to avoid repeating the same code patterns multiple times.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Acked-by: Julien Grall
---
V4:
- drop
Dump the complete Xenstore status to a file (daemon case) or memory
(stubdom case).
As we don't know the exact length of the needed area in advance we are
using an anonymous rather large mapping in stubdom case, which will
use only virtual address space until accessed. And as we are writing
the
In the live update case several initialization steps of xenstore must
be omitted or modified. Add the proper handling for that.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
V4:
- set xprintf = trace in daemon case (Julien Grall)
- only update /tool/xenstored node contents
V7:
-
For support of live update the locally used files need to have the
"close on exec" flag set. Fortunately the used Xen libraries are
already doing this, so only the logging and tdb related files and
pipes are affected. openlog() has the close on exec attribute, too.
In order to be able to keep the
Add reading the global state for live update.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
Reviewed-by: Paul Durrant
---
tools/xenstore/xenstored_control.c | 1 +
tools/xenstore/xenstored_core.c| 9 +
tools/xenstore/xenstored_core.h| 2 ++
3 files changed, 12
When started due to a live upgrade read the internal state and apply
it to the data base and internal structures.
Add the main control functions for that.
For now only handle the daemon case.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Acked-by: Julien Grall
---
V4:
- directly
For live update of Xenstore some records defined in the migration
stream document need to be changed:
- Support of the read-only socket has been dropped from all Xenstore
implementations, so ro-socket-fd in the global record can be removed.
- Some guests require the event channel to Xenstore
Add the basic parts for parsing the live-update control command.
For now only add the parameter evaluation and calling appropriate
functions. Those function only print a message for now and return
success.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Julien Grall
---
For live update the functionality to introduce a new domain similar to
the XS_INTRODUCE command is needed, so split that functionality off
into a dedicated function introduce_domain().
Switch initial dom0 initialization to use this function, too.
Signed-off-by: Juergen Gross
Reviewed-by: Julien
In order to simplify live update state dumping only allow live update
to happen when no transaction is active.
A timeout is used to detect guests which have a transaction active for
longer periods of time. In case such a guest is detected when trying
to do a live update it will be reported and
Add the "live-update" command to xenstore-control enabling updating
xenstored to a new version in a running Xen system.
With -c it is possible to pass a different command line to the
new instance of xenstored. This will replace the command line used
for the invocation of the just running
Add an include file containing all structures and defines needed for
dumping and restoring the internal Xenstore state.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
---
V4:
- drop mfn from connection record (rebase to V5 of state doc patch)
- add #ifdef __MINIOS__ (Julien Grall)
-
In order to allow control commands with binary data refactor handling
of XS_CONTROL:
- get primary command first
- add maximum number of additional parameters to pass to command
handler
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Reviewed-by: Paul Durrant
---
V2:
- add comment
Add the main framework for executing the live update. This for now
only defines the basic execution steps with empty dummy functions.
This final step returning means failure, as in case of success the
new executable will have taken over.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
domain->remote_port and restore_existing_connections() are useless and
can be removed.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
V7:
- new patch
---
tools/xenstore/xenstored_core.c | 3 ---
tools/xenstore/xenstored_domain.c | 11 ---
Save the new binary name for the daemon case and the new kernel for
stubdom in order to support live update of Xenstore..
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_control.c | 41 +-
1 file
Updating an instance of Xenstore via live update needs to hand over
the command line parameters to the updated instance. Those can be
either the parameters used by the updated instance or new ones when
supplied when starting the live update.
So when supplied store the new command line parameters
Today Xenstore is not restartable. This means a Xen server needing an
update of xenstored has to be rebooted in order to let this update
become effective.
This patch series is changing that: The internal state of xenstored
(the contents of Xenstore, all connections to various clients like
Live update of Xenstore is done in multiple steps. It needs a status
block holding the current state of live update and related data. It
is allocated as child of the connection live update was started over
in order to abort live update in case the connection is closed.
Allocation of the block is
set_tdb_key() can be used by destroy_node(), too. So remove the static
attribute and move it to xenstored_core.c.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
---
V5:
- new patch
V6:
- add comment (Julien Grall)
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c
Today the file descriptor for the access of the event channel driver
is being closed in case of exec(2). For the support of live update of
a daemon using libxenevtchn this can be problematic, so add a way to
keep that file descriptor open.
Add support of a flag XENEVTCHN_NO_CLOEXEC for
When xenstored crashes due to an unrecoverable condition it is calling
either barf() or barf_perror() to issue a message and then exit().
Make sure the message is visible somewhere by using syslog()
additionally to xprintf(), as the latter will be visible only with
tracing active.
Signed-off-by:
On Tue, Dec 15, 2020 at 05:13:43PM +0100, Jan Beulich wrote:
> As of 005de45c887e ("xen: do live patching only from main idle loop")
> the comment ahead of livepatch_do_action() has been stale.
>
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
> Signed-off-by: Jan Beulich
>
> ---
On Tue, Dec 15, 2020 at 05:29:17PM +0100, Olaf Hering wrote:
> Am Tue, 15 Dec 2020 16:22:44 +
> schrieb Wei Liu :
>
> > What's wrong with requiring the input addr be const unsigned long *?
>
> Probably nothing. In the end I just borrowed the prototypes from the other
> functions in this
On Tue, Dec 15, 2020 at 05:12:36PM +0100, Jan Beulich wrote:
> Invoking check_wakeup_from_wait() from assembly allows the new
> continue_pv_domain() to replace the prior continue_nonidle_domain() as
> the tail hook, eliminating an extra reset_stack_and_jump().
>
> Signed-off-by: Jan Beulich
>
Am Tue, 15 Dec 2020 16:22:44 +
schrieb Wei Liu :
> What's wrong with requiring the input addr be const unsigned long *?
Probably nothing. In the end I just borrowed the prototypes from the other
functions in this file.
I will resend with this change once I have the consumers ready.
Olaf
On Tue, Dec 15, 2020 at 05:12:12PM +0100, Jan Beulich wrote:
> In order to have the same effect on registers as a call to
> check_for_livepatch_work() may have, clobber all call-clobbered
> registers in debug builds.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
On Tue, Dec 15, 2020 at 05:11:41PM +0100, Jan Beulich wrote:
> It is imperative that the functions passed here are taking no arguments,
> return no values, and don't return in the first place. While the type
> can be checked uniformly, the attribute check is limited to gcc 9 and
> newer (no clang
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1476,6 +1476,8 @@ int clear_identity_p2m_entry(struct doma
return ret;
}
+#ifdef CONFIG_MEM_SHARING
+
/* Returns: 0 for success, -errno for failure */
int set_shared_p2m_entry(struct domain *d,
As is the adjacent ga_to_gfn() one as well as paging_gva_to_gfn().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1772,7 +1772,6 @@ void np2m_schedule(int dir)
p2m_unlock(p2m);
}
}
-#endif
unsigned long paging_gva_to_gfn(struct vcpu *v,
Mirror the "translated" check the functions do to do_domctl(), allowing
the calls to be DCEd by the compiler. Add ASSERT_UNREACHABLE() to the
original checks.
Also arrange for {set,clear}_mmio_p2m_entry() and
{set,clear}_identity_p2m_entry() to respectively live next to each
other, such that
Extend a respective #ifdef from inside set_typed_p2m_entry() to around
all three functions. Add ASSERT_UNREACHABLE() to the latter one's safety
check path.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1257,6 +1257,8 @@ int p2m_finish_type_change(struct
This is together with its only caller, xenmem_add_to_physmap_one(). Move
the latter next to p2m_add_foreign(), allowing this one to become static
at the same time.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -118,7 +118,6 @@
#include
#include
#include
Drop a bogus ASSERT() - we don't typically assert incoming domain
pointers to be non-NULL, and there's no particular reason to do so here.
Replace the open-coded DOMID_SELF check by use of
rcu_lock_remote_domain_by_id(), at the same time covering the request
being made with the current domain's
1: p2m: tidy p2m_add_foreign() a little
2: mm: p2m_add_foreign() is HVM-only
3: p2m: set_{foreign,mmio}_p2m_entry() are HVM-only
4: p2m: {,un}map_mmio_regions() are HVM-only
5: mm: the gva_to_gfn() hook is HVM-only
6: p2m: set_shared_p2m_entry() is MEM_SHARING-only
Jan
On Wed, Dec 09, 2020 at 04:54:51PM +0100, Olaf Hering wrote:
> Introduce new API to test if a fixed number of bits is clear or set,
> and clear or set them all at once.
>
> The caller has to make sure the input bitnumber is a multiply of
> BITS_PER_LONG.
>
> This API avoids the loop over each
On Wed, Dec 09, 2020 at 04:54:50PM +0100, Olaf Hering wrote:
> There are no users left, xenpaging has its own variant.
> The last user was removed with commit 11d0044a168994de85b9b328452292852aedc871
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
On 15.12.20 14:11, Julien Grall wrote:
Hi Juergen,
On 15/12/2020 11:31, Jürgen Groß wrote:
On 15.12.20 12:26, Julien Grall wrote:
From: Julien Grall
So far, our implementation of WARN_ON() cannot be used in the following
situation:
if ( WARN_ON() )
...
This is because the WARN_ON()
flight 157548 qemu-mainline real [real]
flight 157567 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157548/
http://logs.test-lab.xenproject.org/osstest/logs/157567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
As of 005de45c887e ("xen: do live patching only from main idle loop")
the comment ahead of livepatch_do_action() has been stale.
Signed-off-by: Jan Beulich
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1392,8 +1392,8 @@ static inline bool was_action_consistent
}
/*
- * This
Invoking check_wakeup_from_wait() from assembly allows the new
continue_pv_domain() to replace the prior continue_nonidle_domain() as
the tail hook, eliminating an extra reset_stack_and_jump().
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
--- a/xen/arch/x86/pv/domain.c
+++
flight 157560 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157560/
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
In order to have the same effect on registers as a call to
check_for_livepatch_work() may have, clobber all call-clobbered
registers in debug builds.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -120,6 +120,14 @@ unsigned
It is imperative that the functions passed here are taking no arguments,
return no values, and don't return in the first place. While the type
can be checked uniformly, the attribute check is limited to gcc 9 and
newer (no clang support for this so far afaict).
Note that I didn't want to have the
On Wed, Dec 09, 2020 at 04:54:49PM +0100, Olaf Hering wrote:
> Allocate enough memory so that the returned pointer can be safely
> accessed as an array of unsigned long.
>
> The actual bitmap size in units of bytes, as returned by bitmap_size,
> remains unchanged.
>
> Signed-off-by: Olaf Hering
The changes for this XSA introduced an inefficiency and could
do with some further hardening. Addressing of this wasn't
sensible as part of the XSA, though (but you may take this as
an explanation of why this starts out as v2).
1: x86: verify function type (and maybe attribute) in
On Tue, Dec 08, 2020 at 07:30:31PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch converts libxl to use libxl_pci_bdf_assignable_add/remove/list/
> list_free() rather than libxl_device_pci_assignable_add/remove/list/
> list_free(), which then allows naming of assignable devices
On Tue, Dec 08, 2020 at 07:30:30PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> which support naming and use 'libxl_pci_bdf' rather than 'libxl_device_pci',
> as replacements for libxl_device_pci_assignable_add/remove/list/list_free().
>
> libxl_pci_bdf_assignable_add() takes a 'name'
On Tue, Dec 08, 2020 at 07:30:29PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... to use 'libx_pci_bdf' where appropriate.
>
> No API change.
>
> Signed-off-by: Paul Durrant
Acked-by: Wei Liu
On Tue, Dec 08, 2020 at 07:30:10PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> To improve naming consistency, replaces occurrences of 'pcidev' with 'pci'.
> The only remaining use of the term should be in relation to
> 'libxl_domain_config' where there are fields named 'pcidevs' and
>
On Tue, Dec 08, 2020 at 07:30:09PM +, Paul Durrant wrote:
> 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
On Tue, Dec 15, 2020 at 04:04:11PM +0100, Juergen Gross wrote:
> The different fixed limits for absolute and relative path lengths of
> Xenstore nodes make it possible to create per-domain nodes via
> absolute paths which are not accessible using relative paths, as the
> two limits differ by 1024
On Mon, Dec 14, 2020 at 06:35:32PM -0800, Elliott Mitchell wrote:
> Somewhat helpful to actually install the example configurations.
>
> Signed-off-by: Elliott Mitchell
Acked-by: Wei Liu
Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> There's a cross-dependency between closing the block exports and
> draining the block layer. The latter needs that we close all export's
> client connections to ensure they won't queue more requests, but the
> exports may have coroutines
On 15.12.20 15:54, Peter Zijlstra wrote:
On Tue, Dec 15, 2020 at 03:18:34PM +0100, Peter Zijlstra wrote:
Ah, I was waiting for Josh to have an opinion (and then sorta forgot
about the whole thing again). Let me refresh and provide at least a
Changelog.
How's this then?
Thanks, will add it
On 15/12/2020 15:04, Juergen Gross wrote:
> The different fixed limits for absolute and relative path lengths of
> Xenstore nodes make it possible to create per-domain nodes via
> absolute paths which are not accessible using relative paths, as the
> two limits differ by 1024 characters.
>
>
The different fixed limits for absolute and relative path lengths of
Xenstore nodes make it possible to create per-domain nodes via
absolute paths which are not accessible using relative paths, as the
two limits differ by 1024 characters.
Instead of this weird limits use only one limit, which
Am 15.12.2020 um 14:15 hat Sergio Lopez geschrieben:
> On Tue, Dec 15, 2020 at 01:12:33PM +0100, Kevin Wolf wrote:
> > Am 14.12.2020 um 18:05 hat Sergio Lopez geschrieben:
> > > While processing the parents of a BDS, one of the parents may process
> > > the child that's doing the tail recursion,
On Tue, Dec 15, 2020 at 03:18:34PM +0100, Peter Zijlstra wrote:
> Ah, I was waiting for Josh to have an opinion (and then sorta forgot
> about the whole thing again). Let me refresh and provide at least a
> Changelog.
How's this then?
---
Subject: objtool: Alternatives vs ORC, the hard way
From:
On Mon, 14 Dec 2020 12:24:18 -0500
Eduardo Habkost wrote:
> On Mon, Dec 14, 2020 at 03:55:30PM +0100, Igor Mammedov wrote:
> > On Fri, 11 Dec 2020 17:05:20 -0500
> > Eduardo Habkost wrote:
> >
> > > Every single qdev property setter function manually checks
> > > dev->realized. We can just
1 - 100 of 142 matches
Mail list logo
