While investigating XSA-335 we discovered that many upstream security
fixes were missing. It is not practical to backport them. There is
no good reason to be running this very ancient version of qemu, except
that it is the only way to run a stub dm which is currently supported
by upstream.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
master commit: 8587160b3e
master date: 2020-11-04 09:22:37 +0100
These files are in tree so that people can build (including from git)
without needing less-than-a-decade-old flex and bison.
We should update them periodically. Debian buster has been Debian
stable for a while. Our CI is running buster.
There should be no significant functional change; it's possible that
there are bugfixes but I have not reviewed the changes. I *have*
checked that the flex I am using has the fix for CVE-2016-6354.
CC: Paul Durrant <paul@xen.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
These files are in tree so that people can build (including from git)
without needing recent autotools.
We should update them periodically. Debian buster has been Debian
stable fopr a while. Our CI is running buster.
There should be no significant functional change; it's possible that
there are bugfixes to the configure scripts but I have not reviewed
them.
These files were last changed in
83c845033d
libxl: use vchan for QMP access with Linux stubdomain
where a new feature was added. However, that commit contains a lot of
extraneous noise in configure compared to its parent.
Compared to 83c845033dc8bb3a35ae245effb7832b6823174a~, this commit
restores those extraneous changes, leaving precisely the correct
changes. So one way of looking at the changes we are making now, is
that we are undoing accidental changes to the autoconf output.
I used Debian's autoconf 2.69-11 on amd64.
CC: Wei Liu <wl@xen.org>
CC: Nick Rosbrook <rosbrookn@gmail.com>
Reported-by: Nick Rosbrook <rosbrookn@gmail.com>
CC: Paul Durrant <paul@xen.org>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
Provide the implementation for newer pandoc json.
I have done an adhoc test and this now works on both buster and
stretch and seems to produce the expected support matrix when run
using the example rune (which processes unstable and 4.11).
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
Different pandoc versions generate, and expect, a different toplevel
structure for their json output and inpout. Newer pandoc's toplevel
is a hash. We are going to want to support this. We can tell what
kind of output we should produce by looking at the input we got (which
itself came from pandoc). So:
* Make space for code to read toplevel objects which are not arrays.
Currently this code is absent and we just die explicitly (rather
than dying because we tried to use a hashref as an array ref).
* Move generation of the toplevel json structure out of
pandoc2html_inline, and abstract it away through a subref which is
set up when we read the input file.
This is just prep work. No functional change other than a change to
an error message.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
Change the url scheme to https. This is all in-tree references to
xenbits and the main website except for those in Config.mk.
We leave Config.mk alone for now because those urls are used by CI
systems and we need to check that nothing breaks when we change the
download method.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Change the url scheme to https. This is all in-tree references to the
Xen wiki.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
This seems neater. It doesn't have any significant effect because:
The poller fd wouldn't be emptied by time_occurs. It would only be
woken by time_occurs as a result of an ao completing, or by
libxl__egc_ao_cleanup_1_baton. But ...1_baton won't be called in
between (for one thing, this would violate the rule of not still
having the active caller when ...1_baton is called).
While discussing this patch, I noticed that there is a possibility (in
libxl in general) that poller_put might be called on a woken poller.
It would probably be sensible at some point to make poller_get empty
the pipe, at least if the pipe_nonempty flag is set.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
---
v3: Completely revised commit message; now we think this is just
cleanup.
If the application uses libxl_osevent_beforepoll, a similar hang is
possible to the one described and fixed in
libxl: event: Fix hang when mixing blocking and eventy calls
Application behaviour would have to be fairly unusual, but it
doesn't seem sensible to just leave this latent bug.
We fix the latent bug by waking up the "poller_app" pipe every time we
add osevents. If the application does not ever call beforepoll, we
write one byte to the pipe and set pipe_nonempty and then we ignore
it. We only write another byte if beforepoll is called again.
Normally in an eventy program there would only be one thread calling
libxl_osevent_beforepoll. The effect in such a program is to
sometimes needlessly go round the poll loop again if a timeout
callback becomes interested in a new osevent. We'll fix that in a
moment.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
---
v2: New addition to correctness arguments in libxl_event.c comment.
Track in userland whether the poller pipe is nonempty. This saves us
writing many many bytes to the pipe if nothing ever reads them.
This is going to be relevant in a moment, where we are going to create
a situation where this will happen quite a lot.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
If the application calls libxl with ao_how==0 and also makes calls
like _occurred, libxl will sometimes get stuck.
The bug happens as follows (for example):
Thread A
libxl_do_thing(,ao_how==0)
libxl_do_thing starts, sets up some callbacks
libxl_do_thing exit path calls AO_INPROGRESS
libxl__ao_inprogress goes into event loop
eventloop_iteration sleeps on:
- do_thing's current fd set
- sigchld pipe if applicable
- its poller
Thread B
libxl_something_occurred
the something is to do with do_thing, above
do_thing_next_callback does some more work
do_thing_next_callback becomes interested in fd N
thread B returns to application
Note that nothing wakes up thread A. A is not listening on fd N. So
do_thing_* will not spot when fd N signals. do_thing will not make
further timely progress. If there is no timeout thread A will never
wake up.
The problem here occurs because thread A is waiting on an out of date
osevent set.
There is also the possibility that a thread might block waiting for
libxl osevents but outside libxl, eg if the application used
libxl_osevent_beforepoll. We will deal with that in a moment.
See the big comment in libxl_event.c for a fairly formal correctness
argument.
This depends on libxl__egc_ao_cleanup_1_baton being called everywhere
an egc or ao is disposed of. Firstly egcs: in this patch we rename
libxl__egc_cleanup, which means we catch all the disposal sites.
Secondly aos: these are disposed of by (i) AO_CREATE_FAIL
(ii) ao__inprogress and (iii) an event which completes the ao later.
(i) and (ii) we handle by adding the call to _baton. In the case of
(iii) any such function must be an event-generating function so it has
an egc too, so it will pass on the baton when the egc is disposed.
Reported-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
---
v2: Call libxl__egc_ao_cleanup_1_baton (renamed from __egc_cleanup) on
all exits from ao_inprogress, even requests for async processing.
Fixes a remaining instance of this bug (!)
This involves disposing of ao->poller somewhat earlier.
v2: New correctness arguments in libxl_event.c comment and
in commit message.
We are going to want to call this in the following situation:
* We have just set up an ao, which is to call back - so a
non-synchronous one. It ought not to call the application
back right away, so no egc.
* There is a libxl thread blocking somewhere but it is using
using an out of date fd or timeout set, which does not take into
account the ao we have just started.
* We try to wake that thread up, but libxl__poller_wakeup fails.
In more detail:
The idea before was that these two functions take an egc, not so much
because it actually uses the egc, but to make sure it's only called in a
restricted set of conditions; and now we're relaxing those conditions.
Specifically, we need to make one exception, relating to ao's.
In the situation described above, there is no egc, but we need to call
libxl__poller_wakeup. Introducing an egc is wrong because that would
imply that this situation might result in application callbacks, but
it shouldn't (and not having an egc prevents that).
libxl__poller_wakeup and LIBXL__EVENT_DISASTER only take an egc for
form's sake; they don't use any part of it other than the gc. The
"form's sake" is to stop them being called from libxl entrypoints that
are not involved in event generation.
Before this patch this is enforced by the types: you can't call it in
the wrong place because it wants an egc which you don't have.
After this patch this is no longer enforced. But the mistake
(principally, calling _DISASTER) seems unlikely. The type enforcement
I mention above was done because it was possible and easy, not because
it was important.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
---
v3: Significantly expanded commit message based on irc comments
v2: New patch
We are going to want to change libxl__poller_wakeup to take a gc.
In theory there is a risk here that it would be called inappropriately
in a future patch but this seems unlikely.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
---
v2: New patch
This is a very common exit pattern. We are going to want to change
this pattern. So we should make it into a macro of its own.
No functional change.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
This is only for deregistration. We are going to add another variable
for new events, with different semantics, and this overly-general name
will become confusing.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Tested-by: George Dunlap <george.dunlap@citrix.com>
Jürgen Groß <jgross@suse.com> points out that this is entirely wrong.
Adding the "Backport" tag so we find this revert too.
This reverts commit d34dc88098.
Backport: 4.9+
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
xl is maintained in practice by the libxl maintainers. The effect is
simply to grant maintainership to Anthony.
CC: Wei Liu <wl@xen.org>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
There is already an identical comment for
libxl_osevent_register_hooks.
libxl_childproc_setmode's hooks parameter has the same property and
this should be documented.
Reported-by; George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wl@xen.org>
cr-daily-branch ought to be called via cr-for-branches so that we take
the lock. Otherwise strange things can occur if cron runs
cr-daily-branch in the same directory - in particular, it will be
likely to update the osstest revision, breaking everything.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
In particular, say clearly that X.Y-unstable should be thus, not
X.Y.0-unstable.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Provide a rune, following which a magit selective git add
(or git add -p) can be used to commit the appropriate changes.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
It is only necessary to change Config.mk if it refers to unstable
branches anywhere. This time, for example, it didn't.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
There were some hard tabs here. Replace them with 8 spaces.
(I noticed this because my release technician work involves
untabifying this file.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The pvshim can only be built 64-bit because the hypervisor is only
64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
XEN_TARGET_ARCH which override the information from uname. The pvshim
build runs out of the tools/ directory but calls the hypervisor build
system.
If one runs in a Linux 32-bit userland with a 64-bit kernel, one used
to be able to set XEN_COMPILE_ARCH. But nowadays this does not work.
configure sees the target cpu as 64-bit and tries to build pvshim.
The build prints
echo "*** Xen x86/32 target no longer supported!"
and doesn't build anything. Then the subsequent Makefiles try to
install the non-built pieces.
Fix this anomaly by causing configure to honour the Xen hypervisor way
of setting the target architecture.
In principle this user behaviour is not handled quite right, because
configure will still see 64-bit and so all the autoconf-based
architecture testing will see 64-bit rather than 32-bit x86. But the
tools are in fact generally quite portable: this particular location
in configure{.ac,} is the only place in tools/ where 64-bit x86 is
treated differently from 32-bit x86, so the fix is sufficient and
correct for this use case.
It remains the case that XEN_COMPILE_ARCH or XEN_TARGET_ARCH to a
non-x86 architecture, when configure thinks things are x86, or vice
versa, will not work right.
(This is a bugfix to 8845155c83
pvshim: make PV shim build selectable from configure
which inadvertantly deleted the logic to only build the shim for
XEN_TARGET_ARCH != x86_32.)
I have rerun autogen.sh, so this patch contains the fix to configure
as well as the source fix to configure.ac.
Fixes: 8845155c83
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Olaf Hering <olaf@aepfle.de>
CC: Roger Pau Monné <roger.pau@citrix.com>
Release-acked-by: Jürgen Groß <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
This is going to be the common way to initialise things.
_libxl_C_type_init remains the thing for generating the body of the
init function, and for some special cases.
No functional change with existing types: C output is identical.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
We are going to want this in a moment.
No functional change with existing types: C output is identical.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
When both are provided, init_val is likely to be more direct.
No functional change with existing types: C output is identical.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Previously, defaulting and checking of some aspects of the domain
config was skipped for stub dms. This has been the case forever.
In ad011ad088 "libxl/xl: Overhaul passthrough setting logic" some
defaulting that was needed for stub dms was moved from
libxl__domain_create_info_setdefault to .._config_setdefault with the
result that for stub dms, libxl__domain_make fails with this
assertion:
xl: libxl_create.c:582: libxl__domain_make: Assertion
`info->passthrough != LIBXL_PASSTHROUGH_DEFAULT' failed.
Fix this by properly doing all defaulting and all checking for stub
dms. This is more correct, but (especially at this stage of the
release) it is necessary to more closely evaluate the effects by
reviewing the body of _config_setdefault. The changes are as follows:
One actual functional change:
* The new passthrough defaulting is properly done. This is what we
are trying to actually fix here.
And a lot of things that make no difference:
* shadow_memkb would now be set. Whether this would be correct is not
entirely clear. It seems better to make this patch (whose purpose
is to fix the passthrough defaulting) *not* include that semantic
change, so here I have included a hunk to explicitly override this.
* FLASK ssid_label is processed. But the actual ssidref is copied
from the guest domain by spawn_stub_dm, and ssid_label is set to
NULL. So no change.
* We set iommu_memkb. But to 0 since passthrough is disabled.
* cpuid pool_name is processed. But this is not set by
spawn_stub_dm. (Arguably this is a bug: stub dms should inherit the
parent cpupool.) The effect is to leave poolid set to 0 and call
libxl_cpupoolid_is_valid but that always succeeds for 0. So no
change.
* Various extra checks are done: reject PCI passthrough for HVM with
POD (stub dm is PV); reject pod + vnuma, or PV + vnuma (stub dm has
no vnuma); reject nested HVM or pod, with alt2pm-hvm (again, stub dm
is PV). So these checks will always pass.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
We are going to want to call this from a site which has a domid which
is good for logging but not the domid of the domain we are creating
(namely, the stub device domain).
Consequently, add the same comment to
libxl__arch_passthrough_mode_setdefault.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
version of this code) is doing double duty. We actually need all of
the following to be specifiable:
* "default": enable PT iff we have devices to
pass through specified in the initial config file.
* "enabled" (and fail if the platform doesn't support it).
* "disabled" (and reject future PT hotplug).
* "share_pt"/"sync_pt": enable PT and set a specific PT mode.
Defaulting and error checking should be done in libxl. So, we make
several changes here.
We introduce "enabled", and rename "unknown" to "default".
We move all of the error checking and defaulting code from xl into
libxl. Now, libxl__domain_config_setdefault has all of the necessary
information to get this right. So we can do it all there. Choosing
the specific mode is arch-specific.
We can also arrange to have only one place each which calculates
(i) whether passthrough needs to be enabled because pt devices were
specified (ii) whether pt_share can be used (for each arch).
xl now only has to parse the enum in the same way as it parses all
other enums.
This change fixes a regression from earlier 4.13-pre: until recent
changes, passthrough was only enabled by default if passthrough
devices were specified. We restore this behaviour.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Andrew Cooper <Andrew.Cooper3@citrix.com>
CC: Paul Durrant <pdurrant@gmail.com>
CC: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
We need this before we start to figure out the passthrough mode.
I have checked that nothing in libxl__domain_create_info_setdefault
nor the two implementations of ..._arch_... accesses anything else,
other than (i) the domain type (which this function is responsible for
setting and nothing before it looks at) (ii) c_info->ssidref (which is
defaulted by flask code near the top of
libxl__domain_config_setdefault and not accessed afterwards).
So no functional change.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
No functional change. This will let us refer to it in code we are
about to add to this function.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wl@xen.org>
Release-acked-by: Juergen Gross <jgross@suse.com>
No functional change. This will let us make it into a pointer without
textual change other than to the definition.
While we are here, fix some style errors (missing { }).
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wl@xen.org>
Release-acked-by: Juergen Gross <jgross@suse.com>
These are now redundant because shadow_memkb and iommu_memkb are now
defaulted automatically by libxl_domain_need_memory and
libxl_domain_create etc. Callers should not now call these; instead,
they should just let libxl take care of it.
libxl_get_required_shadow_memory was introduced in f89f555827
"remove late (on-demand) construction of IOMMU page tables"
We can freely remove it because it was never in any release.
libxl_get_required_shadow_memory has been in libxl approximately
forever. It should probably not have survived the creation of
libxl_domain_create, but it seems the API awkwardnesses we see in
recent commits prevented this. So we have to keep it. It remains
functional but we can deprecate it. Hopefully we can get rid of it
completely before we find the need to change the calculation to use
additional information which its arguments do not currently supply.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Defaulting is supposed to be done by libxl. So these calculations
should be here in libxl. libxl__domain_config_setdefault has all the
necessary information including the values of max_memkb and max_vcpus.
The overall functional effect depends on the caller:
For xl, no change. The code moves from xl to libxl.
For callers who set one or both shadow_memkb and iommu_memkb (whether
from libxl_get_required_shadow_memory or otherwise) before calling
libxl_domain_need_memory (any version): the new code will leave their
setting(s) unchanged.
For callers who do not call libxl_domain_need_memory at all, and who
fail to set one of these memory values: now they are both are properly
set. The shadow and iommu memory to be properly accounted for as
intended.
For callers which call libxl_domain_need_memory and request the
current API (4.13) or which track libxl, the default values are also
now right and everything works as intended.
For callers which call libxl_domain_need_memory, and request an old
pre-4.13 libxl API, and which leave one of these memkb settings unset,
we take special measures to preserve the old behaviour.
This means that they don't get the additional iommu memory and are at
risk of the domain running out of memory as a result of f89f555827
"remove late (on-demand) construction of IOMMU page tables". But this
is no worse than the state just after f89f555827, which already
broke such callers in that way. This is perhaps justifiable because
of the API stability warning next to libxl_domain_need_memory.
An alternative would be to drop the special-casing of these callers.
That would cause a discrepancy between libxl_domain_need_memory and
libxl_domain_create: the former would not include the iommu memory and
the latter would. That seems worse, but it's debateable.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
This should calculate the extra memory needed for shadow and iommu,
the defaults for which depend on values in c_info. So we need this to
have the complete domain config available.
And the defaults should actually be updated and stored. So make it
non-const.
We provide the usual kind of compatibility function for callers
expecting 4.12 and earlier. This function becomes responsible for the
clone-and-modify of the b_info.
No overall functional change for external libxl callers which use the
API version system to request a particular API version.
Other external libxl callers will need to update their calling code,
and will then find that the new version of this function fills in most
of the defaults in d_config. Because libxl__domain_config_setdefault
doesn't quite do all of the defaults, that's only partial. For
present purposes that doesn't matter because none of the missing
settings are used by the memory calculations. It does mean we need to
document in the API spec that the defaulting is only partial.
This lack of functional change is despite the fact that
numa_place_domain now no longer calls
libxl__domain_build_info_setdefault (via libxl_domain_need_memory).
That is OK because it's idempotent and numa_place_domain's one call
site is libxl__build_pre which is called from libxl__domain_build
which is called from domcreate_bootloader_done, well after the
defaults are set by initiate_domain_create.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Break out this into a new function. We are going to want to call it
from a new call site.
Unfortunately not all of the defaults can be moved into the new
function without changing the order in which things are done. That
does not seem wise at this stage of the release. The effect is that
additional calls to libxl__domain_config_setdefault (which are going
to be introduced) do not quite set everything. But they will do what
is needed. After Xen 4.13 is done, we should move those settings into
the right order.
No functional change.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
According to git log -G:
0x040700 was introduced in 304400459e (aka 4.7.0-rc1~481)
"tools/libxl: rename remus device to checkpoint device"
0x040800 was introduced in 57f8b13c72 (aka 4.8.0-rc1~437)
"libxl: memory size in kb requires 64 bit variable"
It is surprising that no-one noticed this.
Anyway, in the meantime, we should fix it. Backporting this is
probably a good idea: it won't change the behaviour for existing
callers but it will avoid errors for some older correct uses.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
From CODING_STYLE:
Every indented statement is braced, but blocks that contain just one
statement may have the braces omitted. To avoid confusion, either all
the blocks in an if...else chain have braces, or none of them do.
CC: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
If the end of one enum is the `type' line for the next enum, we would
not notice it.
Fix this by reordering the code, and getting rid of the else: now if
the "we are within an enum" branch decides that it's the end of the
enum, it unsets $ei and we then immediately process the line as a "not
within an enum" line - ie as the start of the next one.
Reported-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
./configure takes a PYTHON=... argument. You can use this to specify
the python interpreter. However, for no good reason, it expects an
absolute path.
Fix this. The new logic is:
* if not set, default to `python'
* if not absolute, look it up with type -p
* split into directory and executable name
The results in config/Tools.mk (which contains @PYTHON@ and
@PYTHONPATH@) are identical for both
./configure
./configure PYTHON=/usr/bin/python
so I assert this has no functional change except that now you can say
./configure PYTHON=python
In particular you can now say
./configure PYTHON=python2
./configure PYTHON=python3
The latter is useful if you want python3 (which should probably be the
default, but does not work right now). The former is useful if you
want python2 but your distro has foolishly made "python" refer to
python3.
CC: Doug Goldstein <cardoe@cardoe.com>
CC: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wl@xen.org>
Fix a broken regexp which would mention `$/' when it ought to have
mentioned `$'. The result would be that it would match lines like
type some_ocaml_type = Thing | Other_Thing
but ignore everything but the type name, giving wrong answers.
Check that we check mentioned types. Otherwise if we fail to spot
some suitable thing in the ocaml, we would just omit checking this
type !
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
In the generated C, add some comments saying where we found the ocaml
type. This helps with debugging. (I considered emitting #line
directives but decided this would be more confusing than helpful.)
Improve two dies.
Use better-named filehandles (perl prints thier names when it dies).
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
c/s f089fddd94 broke the Ocaml ABI by renumering
XEN_SYSCTL_PHYSCAP_directio without adjusting the Ocaml
physinfo_cap_flag enumeration.
Add build machinery which will check the ABI correspondence.
This will result in a compile time failure whenever constants get
renumbered/added without a compatible adjustment to the Ocaml ABI.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <Andrew.Cooper3@citrix.com>
In d290e32517
"build system: don't let install-stubdom depend on install-tools"
the dependency of install-stubdom on install-tools was removed.
However, this was not correct. stubdom/Makefile contains this:
$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
$(MAKE) DESTDIR= -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
As I have written before:
With recursive make, it is necessary for the overall structure of the
makefiles to sequence things so that each directory is entered exactly
once, before its dependent directories are entered. (It is possible
to violate this rule without creating races but it is tricky and
inadvisable.)
Since d290e32517, it can happen that the command for the
qemu-xen-traditional-dir-find rule is run twice simultaneously - once
as a result of $(MAKE) -C tools install, and once as a result of
$(MAKE) -C stubdom install. If you get unlucky, this causes lossage.
(This just happened to me in an osstest flight.)
In principle we could alternatively fix this by lifting the commands
in the qemu-xen-traditional-dir-find target (and perhaps other things
too) into the toplevel Makefile, as was done for mini-os.
But that seems overkill given how bad the stubdom build system is, and
the fact that we think at some point this qemu-trad will go away
entirely. Adding the tools dependency back to the stubdom build is
by and large good enough.
(Someone who really wants to build stubdom without tools is welcome to
do this separation if they really want to.)
CC: Juergen Gross <jgross@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Use master or specific git commits. The only semantic change is to
pick up qemu-xen master again.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This library, which is private to Xen and was properly namespaced in
1a81471188
tools/libfsimage: Add `xen' to .h names and principal .so name
honours an environment variable to override the directory where
shared objects (ie filesystem plugins) are to be loaded from.
Rename that variable from FSIMAGE_FSDIR to XEN_FSIMAGE_FSDIR, to give
it a proper namespace prefix.
Nothing in xen.git sets this variable. The three hits for the string
`FSIMAGE_FSDIR' are this getenv, and two references to a compile-time
manifest constant which provides the default value (the -D which sets
it, and the place it is used).
I have also checked the current Debian Xen package in buster and the
variable is not set there either.
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: George Dunlap <george.dunlap@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
These directories ought not to be even world-readable. If this script
for some reason runs with a lax umask they might be created
overly-writeable. Avoid any such bug by setting the mode explicitly.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
It is useful to have a single `xen' facility (in the LSB Provides
namespace). That allows other facilities to specify that they should
go after `xen' without needing to know the implementation details.
This service name is already Provide'd by the (fairly different) init
scripts used in Debian.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
2006, which was 12 years, 1 month, and 14 days ago.
Nevertheless apparently some people are trying to build Xen on systems
whose kernel headers are that old. Placate these people by providing
a fallback #define for CLONE_NEWIPC.
The actual binary value will of course remain constant, because of the
kernel API promise, so this is and will be correct on all platforms
where the CLONE_NEWIPC is supported. (Even if for some reason we miss
the right #includes.)
Of course at runtime this value will not work on older kernels. It
will be rejected as unknown by anything except some pre-2.6.18
kernels. On those kernels we do not want to support dm_restrict, and
an attempt to use it will fail. It is OK for the failure to be a
messy EINVAL syscall failure. (The IPC namespace unshare is necessary
to avoid a suborned deprivileged qemu from causing trouble with shm,
sem, etc.)
On the very old kernels, the feature is totally out of scope.
(We are only interested, here, in making the build work, to avoid
blocking people who aren't using this feature.)
CC: Wei Liu <wei.liu2@citrix.com>
CC: Juergen Gross <jgross@suse.com>
CC: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
This reverts commit 1bce5f9baf.
This situation should be handled by disabling the dm restrict
feature, not silently falling back to lower protection.
Also this #ifdeffery is bad style.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Coverity understandably complains that get_reaper_lock_and_uid leaks
the fd and hence open-file. But this is intentional: the lock becomes
owned by the child process as a whole, which is entirely the property
of libxl.
(The coding style here in this subprocess is a bit anomalous but it's
probably not worth it to convert get_reaper_lock_and_uid to `goto out'
style and have it explicitly return the fd number.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Now, as well as a `code block', with
| Something: some status
we tolerate a definition list which in pandoc terms looks like this
|Term
|: Definition
This ought not usually be be used for features but it will be useful
for linking to the release notes, because markup is not allowed in
code blocks but is in definitions.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Juergen Gross <jgross@suse.com>
In fact this was not markdown content, but just a string. We are
however going to make it be markdown content. So adjust the comments,
and the consumer.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Juergen Gross <jgross@suse.com>
If our run of pandoc to convert pieces of markup in our hand, into
html, fails, print the json that was rejected.
No change in non-error cases.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Juergen Gross <jgross@suse.com>
In "build: add autoconf to replace custom checks in tools/check"
--enable-githttp was introduced. But we missed this comment where it
was advertised.
Also, that commit had the effect of uncondtionally setting GIT_HTTP
from the configure variable. But the env var has been advertised in
some places as the way to specify this behaviour, and overriding it is
just unfriendly.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Make the bufdev and non-bufdev messages distinct, and always print the
non-constant argument (ie, the size).
This assists diagnosis.
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson