On Thu, Nov 23, Jan Beulich wrote:
> Olaf, are you still playing with it every now and then?
No, I have not tried it since I last touched it.
The last thing I know was that integrating it into libxl was difficult
because it was not straight forward to describe "memory usage" properly.
Olaf
si
On Thu, Nov 23, Olaf Hering wrote:
> On Thu, Nov 23, Jan Beulich wrote:
> > Olaf, are you still playing with it every now and then?
> No, I have not tried it since I last touched it.
I just tried it, and it failed:
root@stein-schneider:~ # /usr/lib/xen/bin/xenpaging -d 7 -f /dev
On Thu, Nov 23, Andrew Cooper wrote:
> Its not that. This failure comes from the ring living inside the p2m,
> and has already been found with introspection.
In my case it was just a wrong domid. Now I use 'xl domid domU' and
xenpaging does something. It seems paging out and in works still to so
If a custom precopy_policy, called by
tools/libxc/xc_sr_save.c:send_memory_live, returns XGS_POLICY_ABORT then
the migration is not aborted as expected. Instead the domU is suspended
and transfered. How is the caller supposed to stop the migration and
cleanup?
Olaf
signature.asc
Description: PGP
list of ignored paths and adjust the check for API
mounts.
Now "proc-xen.mount" is silently accepted, it gets into state "start
condition failed" because "ConditionPathExists=!/proc/xen/capabilities
was not met". But all units depending on "proc-xen.mount" start
On Wed, Nov 29, Jan Beulich wrote:
> With all of the above, was it considered to check /sys/hypervisor
> alongside with or perhaps even in preference to /proc/xen?
Yes.
/proc/xen/capabilities is the one and only place that indicates a dom0.
Olaf
signature.asc
Description: PGP signature
___
On Wed, Nov 29, Jan Beulich wrote:
> But in the description you talk about detect_vm() - by its name that
> doesn't look to care about Dom0, but whether running on top of
> _some_ hypervisor.
dom0 has to be handled as "no virtualization" because it has access to
all hardware, all services dependi
On Wed, Nov 29, Jan Beulich wrote:
> Ah, I see. But then still I don't see why at least on half way
> recent Xen /sys/hypervisor/properties/features wouldn't have
> the information you're after (and even more precise, because
> down the road control domain and hardware domain may be
> separate ent
Am Fri, 1 Dec 2017 10:21:46 +
schrieb Wei Liu :
> In Olaf's case, he cares about knowing whether the domain runs the
> controlling toolstack, he doesn't care about if it is the hardware
> domain or not, so my conclusion was using that flag was wrong.
I think this is not entirely accurate. Rig
Am Fri, 1 Dec 2017 12:29:24 +
schrieb Wei Liu :
> But Olaf needs to know if some of the services like xenconsoled or
> xenstored should be started, and if some of the special file systems
> should be mounted, right? Those aren't tied to hardware in anyway. In my
> view that's the responsibilit
On Fri, Dec 01, Wei Liu wrote:
> What information do you need? For a moment let's skip using the fuzzy
> "Dom0" term and try to be precise. Like "I would like to know if that
> domain has access to all hardware" or something else.
That depends on the .service files. This is the list of openSUSE T
A plain crashkernel=size is apparently not supported by the code
anymore. In case kdump ever worked like that, the code which removed
support for this notation did not update the documentation.
Signed-off-by: Olaf Hering
---
docs/misc/kexec_and_kdump.txt | 14 ++
1 file changed, 2
Am Wed, 4 Sep 2019 10:18:41 +0100
schrieb Andrew Cooper :
> That sounds like an accidental regression in parsing of crashkernel=,
> rather than a deliberate action.
Maybe just the lack of b49225dc9df336405292dc08862b4c7c9d887bd6 in vendor
binaries...
It is likely broken since 4.10. I have not tr
Am Wed, 4 Sep 2019 14:19:23 +0200
schrieb Jan Beulich :
> On 04.09.2019 11:37, Olaf Hering wrote:
> > Maybe just the lack of b49225dc9df336405292dc08862b4c7c9d887bd6 in vendor
> > binaries...
> But this change was only to deal with the bogus log message.
> The handling w
Am Wed, 4 Sep 2019 16:22:37 +0200
schrieb Jan Beulich :
> First of all - does "the code" here mean master/staging, or any
> release branch? And then, yes, on release branches there will be
> EINVAL, but as said before kexec_crash_area.size will get/remain
> set nevertheless (as the error path does
The referenced versions can not run staging anymore since a while.
Signed-off-by: Olaf Hering
---
tools/examples/Makefile | 1 -
tools/examples/README.incompatibilities | 38 -
2 files changed, 39 deletions(-)
delete mode 100644 tools/examples
Maybe xm create had a feature to create a domU based on a configuration
file. xl create requires the '-f' option to refer to a file.
There is no code to look into XEN_CONFIG_DIR, so remove the example.
Signed-off-by: Olaf Hering
---
docs/man/xl.1.pod.in | 7 ---
1 file changed, 7
directory. The expected values are all described in xl.conf(5). There is
no need to duplicate this info into another file.
If the local admin really needs to tweak the defaults he will be able to
create this file with the desired content.
Signed-off-by: Olaf Hering
Acked-by: Dario Faggioli
---
tools
Resending due to lack of responses.
Olaf
Olaf Hering (8):
stubdom/vtpm: include stdio.h for declaration of printf
tools: move scripts from etc to libexec
Use XEN_SCRIPT_DIR to refer to /etc/xen/scripts
Remove tools/examples/README.incompatibilities
tools: remove empty xl.conf
Remove
because they are not exactly configuration.
Signed-off-by: Olaf Hering
---
m4/paths.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/paths.m4 b/m4/paths.m4
index 89d3bb8312..0ccc92d0ff 100644
--- a/m4/paths.m4
+++ b/m4/paths.m4
@@ -137,7 +137,7 @@ AC_SUBST(INITD_DIR
Now that scripts are stored in libexec, replace all hardcoded paths to
use XEN_SCRIPT_DIR to expand the actual location.
Update .gitignore.
Signed-off-by: Olaf Hering
---
.gitignore | 3 +++
docs/configure.ac
printf("Expected: ");
vtpmblk.c:322:7: warning: incompatible implicit declaration of built-in
function 'printf'
vtpmblk.c:322:7: note: include '' or provide a declaration of 'printf'
Signed-off-by: Olaf Hering
---
stubdom/vtpm/vtpmblk.c | 1 +
1 file changed, 1
xl(1) opens xl.conf in XEN_CONFIG_DIR.
Substitute this variable also in the man page.
Signed-off-by: Olaf Hering
Reviewed-by: Anthony PERARD
---
docs/man/xl.1.pod.in | 2 +-
docs/man/xl.conf.5.pod.in | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/man/xl.1
directory. The expected values are all described in xlcpupool.cfg(5).
There is no need to duplicate this info into another file.
The need for a dedicated file is also described in xl(1) cpupool-create.
Signed-off-by: Olaf Hering
---
tools/examples/Makefile | 1 -
tools/examples/README | 1 -
tools
Am Tue, 24 Sep 2019 15:09:58 +0100
schrieb Ian Jackson :
> Err, no ?
It will happen for sure:
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
https://en.opensuse.org/openSUSE:Packaging_UsrEtc
Olaf
pgpK7xJyPc0sl.pgp
Description: Digitale Signatur von OpenPGP
Am Tue, 24 Sep 2019 15:17:43 +0100
schrieb Ian Jackson :
> I think the ability of the admin to edit these scripts is important and I
> have used it myself in the past.
Since they are scripts, they can be edited in any location. To me it is not
clear what the case would be to diverge from the v
at function is only called after stream_header_done.
Any error before that will leave dss partly uninitialized.
Fix this crash by checking if ->completion_callback is valid.
Signed-off-by: Olaf Hering
---
tools/libxl/libxl_save_callout.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(
Am Tue, 24 Sep 2019 15:17:43 +0100
schrieb Ian Jackson :
> I might be open to argument on that for specific target operating systems if
> the appropriate distro maintainers were to make a case.
I provided reasons why the current default is not appropriate, and the change
should be applied.
Did
ize ret in libxl__need_xenpv_qemu
Signed-off-by: Olaf Hering
Cc: Roger Pau Monné
Cc: Anthony PERARD
---
tools/libxl/libxl_create.c | 39 +++
tools/libxl/libxl_dm.c | 40 +++-
tools/libxl/libxl_dom_suspend.c |
Am Fri, 3 May 2019 13:04:11 +0200
schrieb Roger Pau Monné :
> Wouldn't it be easier to leave libxl__need_xenpv_qemu alone and just
> use the contents of the migration stream to decide whether to launch a
> QEMU for the PV backends or not? ie: just parsing the domain config on
> the migration strea
Am Mon, 6 May 2019 16:50:19 +0200
schrieb Marek Marczykowski-Górecki :
> The limit 1900x1200 do not match real world devices (1900 looks like a
> typo, should be 1920). But in practice the limits are arbitrary and do
> not serve any real purpose. As discussed in "Increase framebuffer size
> to to
Am Fri, 3 May 2019 13:04:11 +0200
schrieb Roger Pau Monné :
> I think the above call is wrong, libxl__need_xenpv_qemu expects to get
> the domid of the toolstack domain (ie: the domain running this code),
> not the domain being created.
So, how do I actually test such setups? It seems a driver do
Am Thu, 9 May 2019 15:56:21 +0200
schrieb Olaf Hering :
> Am Fri, 3 May 2019 13:04:11 +0200
> schrieb Roger Pau Monné :
>
> > I think the above call is wrong, libxl__need_xenpv_qemu expects to get
> > the domid of the toolstack domain (ie: the domain running this code),
>
Am Thu, 9 May 2019 16:29:56 +0200
schrieb Olaf Hering :
> Are you saying the current users of libxl__need_xenpv_qemu
> (libxl__dm_check_start,
> spawn_stub_launch_dm and domcreate_launch_dm) do not only run in dom0, but
> also somewhere else?
And if it is indeed running somewhere
Am Fri, 3 May 2019 17:29:53 +0200
schrieb Roger Pau Monné :
> On Fri, May 03, 2019 at 04:11:32PM +0200, Olaf Hering wrote:
> > Am Fri, 3 May 2019 13:04:11 +0200
> > schrieb Roger Pau Monné :
> >
> > > Wouldn't it be easier to leave libxl__need_xenpv_qemu al
Am Thu, 9 May 2019 18:14:10 +0200
schrieb Roger Pau Monné :
> The patch below looks sensible to me, and it's more like what I was
> expecting would be needed to solve this issue.
The remaining question is if a new state should be introduced,
or if LIBXL_DEVICE_MODEL_VERSION_UNKNOWN would be good
ialize ret in libxl__need_xenpv_qemu
Signed-off-by: Olaf Hering
Cc: Roger Pau Monné
Cc: Anthony PERARD
---
v3 not runtime tested
tools/libxl/libxl_create.c | 95 +++--
tools/libxl/libxl_dm.c | 2 +
tools/libxl/libxl_dom_suspend.c | 8 +++-
Am Fri, 10 May 2019 12:04:16 +0200
schrieb Olaf Hering :
> v3 not runtime tested
The initialization for device_model_stubdomain must be moved to the new
function.
Olaf
pgphrT_DcBomp.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-de
update wording in a comment
- remove stale goto in domcreate_launch_dm
- initialize ret in libxl__need_xenpv_qemu
Signed-off-by: Olaf Hering
Cc: Roger Pau Monné
Cc: Anthony PERARD
---
tools/libxl/libxl_create.c | 99 ++---
tools/libxl/libxl_dm.c |
What is the recommended way to disable CONFIG_PV_SHIM, which is set in
tools/firmware/Makefile? From my understanding there is no way to influence
its value from outside, which means the build always enters xen-dir/.
Olaf
pgpFnjX5_1j1z.pgp
Description: Digitale Signatur von OpenPGP
Am Mon, 13 May 2019 16:37:33 +0200
schrieb Roger Pau Monné :
> FTR I would have preferred a pre-patch that did the move of this chunk
> of code into libxl__domain_set_device_model without any functional
> change, and then a second patch that introduces the new functionality.
If that needs to be d
Am Mon, 13 May 2019 16:34:14 +0100
schrieb Wei Liu :
> Seeing that you were the last people who changed blktap2 in a meaningful
> way: do you use it at all?
The default for --enable-blktap2 in tools/configure.ac is off, and nothing
seems to pass --enable-blktap2 to configure. So I'm ok to remove
available anyway, and the callers provide a populated b_info.
Signed-off-by: Olaf Hering
---
tools/libxl/libxl_create.c | 90 +++-
tools/libxl/libxl_dm.c | 2 +
tools/libxl/libxl_internal.h | 2 +
3 files changed, 59 insertions(+), 35 deletions(-)
diff
create_launch_dm
- initialize ret in libxl__need_xenpv_qemu
Signed-off-by: Olaf Hering
Cc: Roger Pau Monné
Cc: Anthony PERARD
---
tools/libxl/libxl.h | 7 +++
tools/libxl/libxl_create.c | 17 ++---
tools/libxl/libxl_dom_suspend.c | 8 ++--
tools/libxl/libxl_types.idl |
Am Tue, 14 May 2019 10:05:58 +0200
schrieb Olaf Hering :
> @@ -459,7 +461,9 @@ int libxl__domain_resume(libxl__gc *gc, uint32_t domid,
> int suspend_cancel)
> goto out;
> }
>
> -if (type == LIBXL_DOMAIN_TYPE_HVM) {
> +if (type ==
Am Tue, 14 May 2019 12:18:56 +0200
schrieb Roger Pau Monné :
> Why is it not fine to set the device model version in
> libxl__domain_build_info_setdefault?
Because it receives just build_info, which lacks all the data to decide
if a device type needs a device model or not.
Olaf
pgpQ16reJpDar.p
Am Mon, 13 May 2019 17:20:05 +0200
schrieb Roger Pau Monné :
> enabled by default
Does anyone actually require it at all?
Those who do pass --enable-pvshim to configure. No need for (incorrect)
host_cpu checks.
Olaf
pgpBfGEmkd8MY.pgp
Description: Digitale Signatur von OpenPGP
Am Tue, 14 May 2019 15:38:55 +0100
schrieb Wei Liu :
> > While it is easy for the resume path, doing the same in the suspend path
> > needs more changes. libxl__domain_suspend_device_model would need to receive
> > the callback and set it if a device model is active.
>
> What do you mean here?
Am Tue, 14 May 2019 15:32:27 +0100
schrieb Wei Liu :
> Olaf, if you can provide me with an updated version of the commit
> message I can fold that in while committing. No need to resend this
> patch.
Maybe just append this paragraph?
The upcoming change needs a full libxl_domain_config, and the
Am Mon, 13 May 2019 17:20:05 +0200
schrieb Roger Pau Monné :
> Let me know if that works for you and I will submit it formally.
Yes, it works for me. Thanks.
Olaf
pgp_Q1jrXfL2b.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
domain and
Type=simple for daemon.
Signed-off-by: Olaf Hering
---
Tested with systemd on SLE15.
sysv case untested because support for SLE11 was dropped a while ago.
tools/configure| 3 +-
tools/configure.ac | 1 +
tools
Am Wed, 15 May 2019 17:06:32 +0200
schrieb Olaf Hering :
> A followup change will remove the code which calls to sd_notify, they
> are not needed after the separation of Type=oneshot for domain and
> Type=simple for daemon.
This is not accurate. Type=notify has to be used because unit
Am Thu, 16 May 2019 10:09:38 +0200
schrieb Juergen Gross :
> Has this patch ever been tested to work?
With PV only. I will have a look.
Olaf
pgpFmdIt7ya8J.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenpr
Am Thu, 16 May 2019 10:27:06 +0200
schrieb Olaf Hering :
> Am Thu, 16 May 2019 10:09:38 +0200
> schrieb Juergen Gross :
> > Has this patch ever been tested to work?
> With PV only. I will have a look.
It happens to work for me:
xen_changeset : 2019-05-15 16:19:57 +0100
Am Thu, 16 May 2019 10:09:38 +0200
schrieb Juergen Gross :
> assert(b_info->device_model_version);
Is the codepath perhaps coming from libxl_domain_need_memory?
Olaf
pgpOLHZ6mhjYg.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing l
Am Thu, 16 May 2019 10:40:46 +0200
schrieb Olaf Hering :
> Am Thu, 16 May 2019 10:09:38 +0200
> schrieb Juergen Gross :
> > assert(b_info->device_model_version);
> Is the codepath perhaps coming from libxl_domain_need_memory?
If I read create_domain() correctly, freemem will
Am Thu, 16 May 2019 10:09:38 +0200
schrieb Juergen Gross :
> The patch "libxl: add helper function to set device_model_version"
> breaks creating any domain for me.
The issue is, create_domain will eventually call freemem.
If autoballoon is set, due to dom0_mem= for example, all is fine.
If memor
While preparing the recent b_info->device_model_version change all my testing
went fine. But now with "2019-05-15 16:19:57 +0100 git:2a556b63a2" all domUs
(PV/HVM with and without device model) do not finish shutdown:
Name ID Mem VCPUs State Time(s)
Domain-0
Am Thu, 16 May 2019 12:45:40 +0200
schrieb Roger Pau Monné :
> Having a field in build_info with a default value that depends on
> fields outside of build_info is problematic, since not all callers of
> libxl__domain_build_info_setdefault have access to libxl_domain_config.
One option would be a
On Thu, May 16, Jan Beulich wrote:
> At least to me it is far from obvious why we would want/need to
> do this update, or where the canonical "latest version" lives and
It is not yet Friday. But I do blame GNU anyway for missing the obvious
missing part in their 'configure;make;make install' para
Am Thu, 16 May 2019 12:24:50 +0100
schrieb Wei Liu :
> The problem with this approach is that it doesn't help existing libxl
> users. They will need to be fixed by calling this new API.
If the API needs to be changed, a LIBXL_HAVE_ came with the change.
I'm not sure how to fix this without chang
Am Thu, 16 May 2019 12:39:02 +0100
schrieb Wei Liu :
> I guess all I can say at this point is that I haven't done a survey on
> the differences of the autotools shipped in all the distros we care
> about (especially the older ones), so I would err on the safe side to
> keep the in-tree configure s
Am Thu, 16 May 2019 13:38:57 +0200
schrieb Olaf Hering :
> To me it looks like something like
> libxl_domain_config_finish(libxl_domain_config*)
> is missing now.
If we do not want to add a new API, a hack might be to use container_of()
and assume that the libxl_domain_build_info
Am Thu, 16 May 2019 12:50:43 +0100
schrieb Wei Liu :
> Adding new APIs and defining LIBXL_HAVE won't get you out of this hole.
From what I see, src/libxl/libxl_conf.c:libxlBuildDomainConfig would need
to call libxl_domain_config_finish(libxl_domain_config*) at the end of
that function, wrapped in
Am Thu, 16 May 2019 14:04:51 +0200
schrieb Olaf Hering :
> There are quite a few checks for device_model_version, they would be all
> wrong if the assert is removed, or changed back to QEMU_XEN. Perhaps we
> can continue to live with that error. device_model_version could become
need to be created to fully populate
libxl_domain_build_info with missing defaults. For existing, unchanged
consumers of libxl the assumption about QEMU_XEN needs to be restored
within this function to properly populate the amount of required memory.
Signed-off-by: Olaf Hering
Reported-by: Jue
Am Thu, 16 May 2019 12:39:02 +0100
schrieb Wei Liu :
> autotools shipped in all the distros we care about
I see autoconf 2.69 is available practically everywhere, starting
with openSUSE 12.2, which was released in Q3 2012. SLE11, which
can not be properly supported anymore, had autoconf 2.63.
O
Am Thu, 16 May 2019 14:30:13 +0100
schrieb Wei Liu :
> Would the following work?
This is not exactly the same because that copy will end up in
libxl__domain_set_device_model, and we are back to square #1.
Olaf
pgpcjNNwubdpG.pgp
Description: Digitale Signatur von OpenPGP
___
Am Thu, 16 May 2019 14:46:53 +0100
schrieb Wei Liu :
> Can you clarify?
create_domain has a libxl_domain_config on its stack. This is passed to
freemem, and libxl_domain_need_memory modifies it as needed.
The modification will go through libxl_domain_create_new, do_domain_create,
initiate_domain_
Am Thu, 16 May 2019 16:03:55 +0100
schrieb Wei Liu :
> Does this make sense?
Sure, I was looking at the wrong function.
Doing it within libxl_domain_need_memory will certainly work.
Thanks!
Olaf
pgpJFwebL9FWO.pgp
Description: Digitale Signatur von OpenPGP
__
Am Thu, 16 May 2019 14:30:13 +0100
schrieb Wei Liu :
> @@ -457,6 +457,12 @@ int libxl_domain_need_memory(libxl_ctx *ctx,
> +if (!b_info->device_model_version)
> + b_info->device_model_version = LIBXL_DEVICE_MODEL_XXX;
I think this will work and should be applied to unbreak staging.
The
:
575b300b795b6 ("pid1: rework how we dispatch SIGCHLD and other signals")
v02:
- preserve Type=notify
Signed-off-by: Olaf Hering
---
tools/hotplug/Linux/init.d/xencommons.in | 2 +-
tools/hotplug/Linux/launch-xenstore.in | 56 ++--
tools/hot
Am Tue, 21 May 2019 15:37:02 +0100
schrieb Wei Liu :
> bxl: debug: libxl_device.c:380:libxl__device_disk_set_backend: Disk vdev=xvda
> spec.backend=qdisk
> libxl: debug: libxl_linux.c:235:libxl__get_hotplug_script_info: Domain
> 1:backend_kind 3, no need to execute scripts
I will check why qdis
Am Tue, 21 May 2019 15:43:15 +0100
schrieb Wei Liu :
> Yeah, that's indeed strange. Thanks for having a look.
Is the used domU.cfg available? I think In my testing disk=[] had backend=qdisk.
Olaf
pgpR3Q_4Qz3p3.pgp
Description: Digitale Signatur von OpenPGP
_
On Tue, May 21, Wei Liu wrote:
> bxl: debug: libxl_device.c:380:libxl__device_disk_set_backend: Disk vdev=xvda
> spec.backend=qdisk
> libxl: debug: libxl_linux.c:235:libxl__get_hotplug_script_info: Domain
> 1:backend_kind 3, no need to execute scripts
The backtrace looks like that:
(gdb) bt
#0
Am Wed, 22 May 2019 01:11:54 -0600
schrieb "Jan Beulich" :
> libxl__domain_build_info_setdefault (gc=0x7fffdee0, b_info=0x7fffdb80)
> at libxl_create.c:143
This is libxl_defbool_val(b_info->device_model_stubdomain).
Due to the lack of a proper way to describe all the dependencies wit
Am Wed, 22 May 2019 15:51:40 +0100
schrieb Anthony PERARD :
> Can you give it a try with one of the affected qemu? (qemu-xen-4.10 or
> qemu-xen-4.11)
Thanks for the patch. Unfortunately there is no easy way to trigger the race.
Is the changed code path also exercised for PV domUs?
Olaf
pgpLmBW
Am Tue, 28 May 2019 20:59:24 +0100
schrieb Ian Jackson :
> I am still struggling with this. 4.7 and 4.6 still do not build.
I maintain the various staging-X.Y branches for various releases,
just for my own entertainment. The remaining build error in SLE_15
(and Tumbleweed) is some asm error in i
On Mon, Dec 31, Andrew Cooper wrote:
> * tbuf_size and tevt_mask
> Given that xentrace can set them at runtime, and it is debugging
> functionality, I don't see a plausible use the command line options at all.
'tbuf_size=-1 dom0_mem=N' collects events during boot.
xenalyze is (or was) unable to p
With 'xl migrate' the migration is always live, while 'virsh migrate' will do
an offline migration unless '--live' is used. Such non-live migration will
break with HVM because the sending side does not seem to unlock the qcow2 image.
I wonder if its worth keeping (and fixing) the concept of an "
Am Fri, 4 Jan 2019 16:57:55 +0100
schrieb Olaf Hering :
> worth keeping (and fixing) the concept of an "offline migration"
And regarding the fix, it looks like qmp_xen_save_devices_state does not need
the concept of "live". Just shutdown the blockdevices and be done wi
Am Fri, 4 Jan 2019 17:48:31 +0100
schrieb Olaf Hering :
> Am Fri, 4 Jan 2019 16:57:55 +0100
> schrieb Olaf Hering :
>
> > worth keeping (and fixing) the concept of an "offline migration"
>
> And regarding the fix, it looks like qmp_xen_save_devices_state does n
Am Thu, 13 Dec 2018 11:05:25 +
schrieb Anthony PERARD :
> Hi,
>
> Ian, we have those XC_WANT_COMPAT_* #defines to allow consumers of Xen
> libs be able to use old interfaces. Do you think it's a good idea to
> have this consumers (QEMU here) #undef the flag when it has implemented
> the newer
On Wed, Nov 28, Wei Liu wrote:
> OVMF has become dependent on OpenSSL, which it is included as a submodule.
> Initialise submodules before building.
> +++ b/tools/firmware/ovmf-makefile
> build:
> + $(GIT) submodule update --init --recursive
At least ef529e6ab7c31290a33045bb1f1837447cc0eb56
Am Mon, 14 Jan 2019 11:28:57 +
schrieb Wei Liu :
> Are you saying that the breakage is shown when you put a snapshot of
> ovmf under xen.git? How does ovmf distribute their snapshot? How is that
> generated? Does it contain snapshots of submodules it needs already?
I export all required sourc
Am Mon, 14 Jan 2019 17:11:56 +
schrieb Anthony PERARD :
> I think it's fine to keep the current `submodule update` call where it
> is. We could just make it check that it's an actual git worktree by
> checking for the presence of ".git" (file or directory) before executing
> git.
>
> Would th
Am Mon, 14 Jan 2019 17:44:57 +
schrieb Wei Liu :
> - $(GIT) submodule update --init --recursive
> + [ -d .git ] && $(GIT) submodule update --init --recursive
This syntax fails, but this works for me:
if test -d .git ; then $(GIT) submodule update --init --recursive ;
On Wed, May 15, Olaf Hering wrote:
> Am Mon, 13 May 2019 17:20:05 +0200
> schrieb Roger Pau Monné :
>
> > Let me know if that works for you and I will submit it formally.
> Yes, it works for me. Thanks.
Did you have a chance to submit a fix to support '--disable-pv-shim&#
Am Sun, 18 Aug 2019 18:20:26 +0100
schrieb Wei Liu :
> This doesn't apply. There is no such file.
My changes need to be applied in this order, some of them may apply in any
order:
20190619120633.27466-1-o...@aepfle.de
20190619121715.28532-1-o...@aepfle.de
20190619123818.30747-1-o...@aepfle.de
2
Ian, Wei,
we got a report about a crash from libxl_domain_suspend like this, from 'virsh
migrate --live xen+ssh://host':
#1 helper_done (egc=0x7fc0284aa6c0, shs=0x7fc0180256c8) at
libxl_save_callout.c:371
helper_failed
helper_stop
libxl__save_helper_abort
#2 check_all_finished (egc=0x7fc0284
In domcreate_bootloader_done, libxl__build_pre is called.
If that function fails, the label 'out:' is called, which goes straight into
domcreate_stream_done. This function uses srs->dcs to set
libxl__domain_create_state.
In my case ->dcs is NULL. The result is a crash in STATE_AO_GC().
How can t
Am Thu, 28 Feb 2019 14:17:18 +0100
schrieb Olaf Hering :
> In domcreate_bootloader_done, libxl__build_pre is called.
> If that function fails, the label 'out:' is called, which goes straight into
> domcreate_stream_done. This function uses srs->dcs to set
> libxl__dom
Am Thu, 28 Feb 2019 14:17:18 +0100
schrieb Olaf Hering :
> In domcreate_bootloader_done, libxl__build_pre is called.
> If that function fails, the label 'out:' is called, which goes straight into
> domcreate_stream_done. This function uses srs->dcs to set
> libxl__dom
Am Mon, 4 Mar 2019 14:54:01 +
schrieb Wei Liu :
> > > +/* Prepare environment for domcreate_stream_done */
> > > +dcs->srs.ao = ao;
> > > +dcs->srs.dcs = dcs;
> > > +dcs->srs.fd = -1;
> As far as I can tell only srs.dcs needs to be initialised before hand.
fd needs to be tweak
OVMF does not build itself with -fPIC, as a result it fails to compile with
recent toolchains.
Luckily ovmf.git#master has changes for
BaseTools/Source/C/Makefiles/header.makefile to recognize EXTRA_OPTFLAGS, which
can be used as vehicle to pass the required CFLAGS.
What are the options to upgra
_OF.
Signed-off-by: Olaf Hering
---
tools/libxl/libxl_create.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a4e74a5cd2..989ce6d5bd 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -109
Am Thu, 7 Mar 2019 11:02:47 +
schrieb Wei Liu :
> Have you seen the field been set before entering this function? Or is
> the if () just a precaution?
Sorry, this is not the variant I intended to send.
The assignment was supposed to be unconditionally.
Today I browsed the code and it was not
Am Thu, 7 Mar 2019 12:18:20 +
schrieb Wei Liu :
> That code has been changed quite a bit with migration v2 and COLO. I
> wouldn't be surprised if some code becomes stale.
Are you ok with just moving that assignment up to avoid the crash?
This should be backported to at least 4.10, older branc
_OF.
Signed-off-by: Olaf Hering
---
v2:
unconditional assignment
tools/libxl/libxl_create.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a4e74a5cd2..c8b5ea984b 100644
--- a/tools/libxl/libxl_create.c
+++ b/to
Am Fri, 8 Mar 2019 14:08:10 +
schrieb Ian Jackson :
> In fact this is OK because domcreate_stream_done only reads srs->dcs
> and then does everything with the obtained dcs. But there is nothing
> there to indicate that srs might be mostly uninitialised. Maybe we
> could add a comment there,
1 - 100 of 943 matches
Mail list logo
