On Wed, Apr 20, Paulina Szubarczyk wrote:
> *libxl__device_from_pcidev() initialize the values of libxl__device
> struct and can be void.
> -static int libxl__device_from_pcidev(libxl__gc *gc, uint32_t domid,
> +static void libxl__device_from_pcidev(libxl__gc *gc, uint32_t domid,
>
On Wed, Apr 20, Paulina Szubarczyk wrote:
> @@ -398,34 +398,34 @@ libxl_device_pci
> *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num)
> dir = opendir(SYSFS_PCIBACK_DRIVER);
> +while((de = readdir(dir))) {
> -closedir(dir);
This change seems to leak 'dir' in success
On Thu, Apr 14, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] Fixing libvirt's libxl driver
> breakage -- where to define LIBXL_API_VERSION?"):
> > And, in those cases, usage should be gated by the appropriate
> > LIBXL_HAVE_FOOBAR symbol, which I see in the sources (e.g.,
> > for
ration stream.
Thanks!
Tested-by: Olaf Hering <o...@aepfle.de>
root@anonymi:~ # xl migrate domU host
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x1/0x0/2675)
Loading new save file (new xl fmt info 0x1/0x0/2675)
Savefile contains xl domain c
On Thu, Apr 14, Wei Liu wrote:
> Maybe go back to 96ae556569b8eaedc0bb242932842c3277b515d8 and try again?
> Then 5cf46a66883ad7a56c5bdee97696373473f80974 and try? So that I can
> know if it is related to COLO series. No, don't try to bisect that
> because it's broken in the middle.
I think I
On Thu, Apr 14, Juergen Gross wrote:
> Overwriting the array pointer is done in other places already. Seems
> as if this would be the way to go. See device_disk_add() in libxl.c
Yes, there is no other way. Calling flexarray_free works only with NO_GC
allocations.
Olaf
On Thu, Apr 14, Juergen Gross wrote:
> On 13/04/16 10:56, Olaf Hering wrote:
> > +back = flexarray_make(gc, i, 1);
> Shouldn't be this in the loop below? Otherwise the array might be
> expanded with the same entries several times in case of a transaction
> collision.
I thin
On Thu, Apr 14, Andrew Cooper wrote:
> How large is save.img?
domU.cfg has memory=1024, save.img has 1076188625.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, Apr 14, Olaf Hering wrote:
> On Thu, Apr 14, Andrew Cooper wrote:
>
> > Can you do an `xl save` to file on the source side, and on the
> > destination side manually invoke convert-legacy-stream and
> > verify-stream-v2 (both of which are also specifically usable
On Thu, Apr 14, Andrew Cooper wrote:
> Can you do an `xl save` to file on the source side, and on the
> destination side manually invoke convert-legacy-stream and
> verify-stream-v2 (both of which are also specifically usable on the
> command line as well as automatically) ? This will identify
On Thu, Apr 14, Olaf Hering wrote:
> Migration from staging-4.5.3f802a5 to staging-4-7.3dac42f fails with a HVM
> guest:
> root@anonymi:~ # xl migrate domU host
Related to that:
The domU--incoming on "host" is not destroyed. Which part of 'xl
migrate' would be responsible to
Migration from staging-4.5.3f802a5 to staging-4-7.3dac42f fails with a HVM
guest:
root@anonymi:~ # xl migrate domU host
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x1/0x0/2677)
xc: error: error polling suspend notification channel: -1: Internal
On Wed, Apr 13, Olaf Hering wrote:
> rawio='yes'>
>
>
>
>
>
>
>
What is the virsh equivalent of the following command?
xl scsi-attach domU [5:0:1:0|/dev/sdd|naa.23fd7b9cc41c4934.0] 0:0:0:0
Olaf
___
Add support for upcoming vscsi= in libxl.
Changes between v1 and v2:
- rebase to 'master' (ad584cb)
- Update API to v12
Olaf Hering (2):
libxl: include a XLU_Config in _libxlDriverConfig
libxl: support vscsi
src/libxl/libxl_conf.c | 66 +
src/libxl/libxl_conf.h | 8
devices with
persistant names. Example used during testing:
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Jim Fehlig <jfeh...@suse.com>
---
src/libxl/libxl_conf.c | 59 +++
src/libxl/libxl_conf.h | 1 +
src/libxl/libxl_domain.c | 2 +
Upcoming changes for vscsi will use libxlutil.so to prepare the
configuration for libxl. The helpers needs a xlu struct for logging.
Provide one and reuse the existing output as log target.
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Jim Fehlig <jfeh...@suse.com>
---
src/libxl/
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Cc: Ian C
l/xen-devel/2015-03/msg00030.html
Initial attempt was sent a year ago:
http://lists.xenproject.org/archives/html/xen-devel/2014-04/msg03958.html
Most comments are addressed.
This version has been tested with SLES as backend and frontend.
This version has been tested with pvops as backend and SLES a
These scripts are not use by libxl.
These scripts are meant for testing vscsi= in libxl
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/misc/Makefile | 4 +
tools/misc/target-create-xen-scsiback.sh | 135 +++
tools/misc/target-dele
On Mon, Apr 11, George Dunlap wrote:
> if [ -d ${XEN_LOCK_DIR}/subsys ] ; then
> LOCKFILE=${XEN_LOCK_DIR}/subsys/xendomains
> else
> LOCKFILE=${XEN_LOCK_DIR}/xendomains
> fi
This will probably work, yes.
Olaf
___
Xen-devel mailing list
and libxc.
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Wei Liu <wei.l...@citrix.com>
---
tools/blktap2/drivers/tapdisk-vbd.c | 6 +++---
tools/libxc/xc_cpupool.c| 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
On Tue, Apr 12, Juergen Gross wrote:
> IMO this is a compiler bug. The compiler could detect easily that err
> can't be uninitialized at the return statement (e.g. via loop
> unrolling).
There is another place like that in blktap2. There was some discussion
about -Og usage in tools, not sure if
On Thu, Mar 10, Juergen Gross wrote:
> +#define NUM_RMCPU_BUSY_RETRIES 5
> +
> int xc_cpupool_removecpu(xc_interface *xch,
> uint32_t poolid,
> int cpu)
> {
> +unsigned retries;
> +int err;
> DECLARE_SYSCTL;
>
> sysctl.cmd
On Fri, Apr 08, Olaf Hering wrote:
> +r = sscanf(be_path,"/local/domain/%d/backend/%15[^/]/%d",
> + _domid, be_type, _domid);
Why are these values parsed as signed integers, and then placed in
uint32? Was this just an oversight duri
On Fri, Apr 08, Wei Liu wrote:
> On Fri, Apr 08, 2016 at 04:16:46PM +0200, Olaf Hering wrote:
> > What do you have in mind? Something like in vusb_be_from_xs_fe?
> Yes.
Thanks, I will test this change:
Sanitize input from frontend in vscsi_fill_ctrl
Signed-off-by: Ol
On Fri, Apr 08, Wei Liu wrote:
> What Ian wanted was that we need clear correlation of xl configuration
> syntax with libxl API fields. For example, for a FOO device
>
>xl.cfg: FOO = [ "bar=baz" ]
>
>libxl_types.idl:
>
> libxl_device_FOO = Struct("device_foo", [
> ("bar",
On Fri, Apr 08, Wei Liu wrote:
> On Fri, Apr 08, 2016 at 07:01:31AM +0000, Olaf Hering wrote:
> > Just to make them public, not meant for merging:
> > The scripts used during development to create a bunch of SCSI devices in
> > dom0 using the Linux target framework. targetcli
On Fri, Apr 08, Olaf Hering wrote:
> +int xlu_vscsi_get_ctrl(XLU_Config *cfg, libxl_ctx *ctx, uint32_t domid,
> + const char *str,
> + libxl_device_vscsictrl *ctrl,
> + libxl_device_v
On Fri, Apr 01, Ian Jackson wrote:
> > +static int xlu__vscsi_parse_dev(XLU_Config *cfg, char *pdev,
> > libxl_vscsi_hctl *hctl)
> > +{
> > +struct stat dentry;
> > +char *sysfs = NULL;
> > +const char *type;
> > +int rc, found = 0;
> > +DIR *dirp;
> > +struct dirent *de;
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Cc: Ian C
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/misc/Makefile | 4 +
tools/misc/target-create-xen-scsiback.sh | 135 +++
tools/misc/target-delete-xen-scsiback.sh | 41 ++
3 files changed, 180 insertions(+)
diff --git a/tool
xenproject.org/archives/html/xen-devel/2014-04/msg03958.html
Most comments are addressed.
This version has been tested with SLES as backend and frontend.
This version has been tested with pvops as backend and SLES as frontend.
(thanks for reading that far, this iteration got no runtime testing...
Doing a 'xl migrate --debug domU host' on xen-4.5 adds a
XC_SAVE_ID_ENABLE_VERIFY_MODE marker, which is not handled.
Since using --debug is valid usage, handle it by logging the fact
instead of aborting the migration.
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <
convert-legacy-stream.py fails to receive a HVM domU coming from xen-4.5.
It runs into legacy.CHUNK_enable_verify_mode "Unable to convert a debug
stream", but only if the '--debug' knob was passed to 'xl migrate'.
The comment there is clearly wrong.
How is this supposed to be handled? I think
On Mon, Apr 04, Wei Liu wrote:
> The fix is to patch libvirt. Looking at libvirt code I think I need to
> patch Makefile.in to pass in an explicit LIBXL_API_VERSION number.
That might be true.
But shouldnt at the same time libxl.h get a change to recognize
0x040700? Perhaps this will be part of
On Fri, Mar 25, Changlong Xie wrote:
> +#elif defined(LIBXL_API_VERSION) && LIBXL_API_VERSION >= 0x040400 \
> + && LIBXL_API_VERSION < 0x040700
Is this supposed to work? libvirt.git fails to build now:
libxl/libxl_domain.c: In function 'libxlDomainStart':
was not including the
> kernel header file that is used to communicate support of the API in the
> kernel. Fix the issue by including the required header file.
>
> Signed-off-by: Mike Meyer <mike.me...@teradata.com>
> Reviewed-by: Jan Beulich <jbeul...@suse.com>
Acked-by:
On Fri, Apr 01, Olaf Hering wrote:
> On Fri, Apr 01, Wei Liu wrote:
>
> > Does this work?
>
> Most likely yes.
Yes, this change fixes it. Thanks.
There is another failure on arm now, see the other mail "arm: staging
build error in libxl helper_setca
d887c19 fails to build on armv7:
_libxl_save_msgs_helper.c: In function 'helper_setcallbacks_restore':
_libxl_save_msgs_helper.c:147:26: error: assignment from incompatible pointer
type [-Werror]
cbs->restore_results = (cbflags & (1u<<8)) ? helper_stub_restore_results
: 0;
On Fri, Apr 01, Ian Jackson wrote:
> I'm not sure that this sysfs parsing ought to be in xl rather than
> libxl. Also, this is Linux-specific code. So it needs to be made
> conditional somehow.
The whole libxlu file is inside #ifdef __linux__?
I will address the other comments in another mail.
On Fri, Apr 01, Wei Liu wrote:
> Does this work?
Most likely yes.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, Mar 31, Wei Liu wrote:
> +static int xc_domain_resume_hvm(xc_interface *xch, uint32_t domid)
> #if defined(__i386__) || defined(__x86_64__)
> +return xc_domain_resume_hvm(xch, domid);
This causes a build error no non-x86.
[ 334s] xc_resume.c:112:12: error:
On Fri, Apr 01, Ian Jackson wrote:
> Olaf Hering writes ("[PATCH v2] tools/libxc: Fix build error when using
> xc_version_len"):
> > Tools fails to build with gcc 4.5, it does not provide ssize_t.
>
> Changlong Xie writes ("[PATCH] tools: add missing header for
On Thu, Mar 31, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 31, 2016 at 01:25:30PM +0200, Olaf Hering wrote:
> > Tools fails to build with gcc 4.5, it does not provide ssize_t.
>
> Which version of SLES/OpenSuSE had that? I had been using 4.4.4 and
> 5.3 and the compiler didn'
Tools fails to build with gcc 4.5, it does not provide ssize_t.
Fixes d275ec9 ("libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION
hypercall")
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Wei Liu <wei.l...@citrix.c
Tools fails to build with gcc 4.5, it does not provide ssize_t.
Fixes d275ec9 ("libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION
hypercall")
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Wei Liu <wei.l...@citrix.com&
On Thu, Mar 31, Juergen Gross wrote:
> On 22/03/16 09:23, Olaf Hering wrote:
> > +#define COMPARE_VSCSI(a, b) ((a)->devid == (b)->devid)
> Is this really needed? I'd prefer using COMPARE_DEVID() instead.
COMPARE_VSCSI used to do something else in an earlier variant.
Now
On Tue, Mar 22, Boris Ostrovsky wrote:
> Can you apply PAT changes from
> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02127.html
> and see if it helps?
I will try, thanks.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/misc/Makefile | 4 +
tools/misc/target-create-xen-scsiback.sh | 135 +++
tools/misc/target-delete-xen-scsiback.sh | 41 ++
3 files changed, 180 insertions(+)
diff --git a/tool
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Cc: Ian C
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Acked-by: Wei Liu <wei.l...@citrix.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Jan Beulich <jbeul...@suse.com>
Cc
hives/html/xen-devel/2014-04/msg03958.html
Most comments are addressed.
This version has been tested with SLES as backend and frontend.
This version has been tested with pvops as backend and SLES as frontend.
Olaf Hering (5):
vscsiif.h: fix WWN notation for p-dev property
docs: add vscsi to xenstor
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Acked-by: Wei Liu <wei.l...@citrix.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Jan Beulich <jbeul...@suse.com>
Cc
The pvops kernel expects either "naa.WWN:LUN" or "h:c:t:l" in the p-dev
property. Add the missing :LUN part to the comment.
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Acked-by: Wei Liu <wei.l...@citr
On Sat, Mar 19, Wei Liu wrote:
> My assessment of the pending patch: that's two thousand lines of code in
> a single patch, which potentially requires quite a few iterations to get
> right. Furthermore its prerequisite PVUSB was only merged yesterday,
> which has its own defects that needs
On Fri, Mar 18, Wei Liu wrote:
> Today is that last posting day for new features. And we are two weeks
> away from the anticipated freeze date.
What about features which got posted weeks ago already, namely pvscsi?
I should probably rebase ontop of pvusb, but the beef remains the same.
Olaf
On Tue, Mar 01, Boris Ostrovsky wrote:
> on domU:
>
> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096 /dev/mem
> od: /dev/mem: read error: Bad address
> 001
> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#
>
> with
>
> (XEN) mm.c:1767:d14v0 Bad L1 flags 10
How
On Mon, Feb 29, Konrad Rzeszutek Wilk wrote:
> .. A fix for what issue?
#include
#include
#include
#include
#include
int main(void)
{
unsigned long long *p;
int fd;
fd = open("/dev/mem", O_RDWR);
if (fd < 0) {
perror("/dev/mem");
On Mon, Feb 29, Boris Ostrovsky wrote:
> Do you see any messages in hypervisor log (like "Bad L1 flags 10")?
Yes, with a debug build of xen.gz.
(XEN) mm.c:1882:d1v0 Bad L1 flags 10
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On Mon, Feb 29, Olaf Hering wrote:
> 77fec3a tools/console: correct make dependencies for _paths.h
Sorry, I read the Subject as 4.6.x ...
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, Feb 29, Ian Jackson wrote:
> I rely on someone (which might be the maintainer or submitter, or
> anyone else) noticing that a fix ought to be considered for backport
> and bringing it to my attention.
I propose this build fix:
77fec3a tools/console: correct make dependencies for _paths.h
On Mon, Feb 29, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
> > Would this change be the correct fix?
> .. A fix for what issue?
mmap returns some pointer, but appearently that memory can not be used.
https://bugzilla.suse.com/sho
On Mon, Feb 29, Andrew Cooper wrote:
> This set of options is very messy. We have both an -O1, an -O0 and an
> -O2, as well as three different -g's
-O1 is a global CFLAG, -O0 is appended in tools/, and -O2 comes from
RPM_OPT_FLAGS.
Olaf
___
What is the correct way to identify a Xen PV domU in the kenrel?
devmem_is_allowed() used to disable access to pages < 256 in domU.
With pvops this check was removed, or never ported forward.
Would this change be the correct fix?
+++ b/arch/x86/mm/init.c
@@ -637,7 +637,7 @@ void __init
On Sun, Feb 28, Wei Liu wrote:
> If the current set of compiler flags is not good enough, we should
> improve it. I'm afraid having a third set of maintainer mode flags that
> nobody else uses is going to cause us more headache.
There is nothing wrong with the CFLAGS. They are perfect for
On Sat, Feb 27, Olaf Hering wrote:
> -O2 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
I think the cause is the lack of a "maintainer mode", which should
enable realworld CFLAGS. Either a new configure knob gets added (and
used!) or the existing EXTRA_CFLAGS_*
On Sat, Feb 27, Wei Liu wrote:
> And fwiw even if I manually added that option to libxl build, gcc
> doesn't complain.
Well, Debian is appearently not the first choice anymore...
My cmdline is like this, fails with gcc4.3 ... 5.3:
gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
Current staging fails to compile:
[ 276s] libxl_dom_save.c: In function 'libxl__domain_save':
[ 276s] libxl_dom_save.c:328:9: error: 'rc' may be used uninitialized in this
function
It was introduced between abf8824fe530bcf060c757596f68663c87546a6a and
On Fri, Feb 19, Olaf Hering wrote:
> Not sure how to handle it, perhaps exit when xl -N is called?
Also the interface is 'xl -N' is not clearly defined. What is it
supposed to do with the newly introduced ctrl types? Should it display
the json just for the dev, just for the ctrl+
On Fri, Feb 19, Chun Yan Liu wrote:
>
>
> >>> On 2/17/2016 at 12:56 AM, in message <20160216165608.ga21...@gmail.com>,
> >>> Olaf
> Hering <o...@aepfle.de> wrote:
> > On Tue, Jan 19, Chunyan Liu wrote:
> >
> > > #xl usbctr
On Thu, Feb 18, Wei Liu wrote:
> Sorry I don't follow. What do you mean by 1:1 copy? Why does it make the
> update unnecessary?
The current code does:
libxl_device_nic_init(_saved);
libxl_device_nic_copy(CTX, _saved, nic);
nic->devid = libxl__device_nextid(gc, domid, "vif");
On Thu, Feb 18, Wei Liu wrote:
> For example, user might not have specified mac address so the library
> generates one for (s)he. You don't want mac address to regenerate after
> save / restore or migration. But you don't want to preserve all
> autogenerated state, so you use the original copy
What is the point of libxl__update_config_nic and
libxl__update_config_vtmp?
In libxl__device_type_add (called from DEFINE_DEVICE_ADD) the input
type is copied with libxl_device_type_copy to type_saved, which is a
1:1 copy. If needed, a new devid is assigned to the input. Later the
copy is
On Tue, Feb 16, Ian Jackson wrote:
> Olaf Hering writes ("Re: [PATCH v8 3/5] libxl: add support for vscsi"):
> > On Mon, Feb 15, Ian Jackson wrote:
> > > One reason you might define a virtual controller with no devices yet
> > > is so that you have a stable
On Tue, Jan 19, Chunyan Liu wrote:
> #xl usbctrl-attach test_vm version=1 ports=8
> #xl usbdev-attach test_vm hostbus=1 hostaddr=2
I think this does not handle the -N knob of xl. Other commands check the
global dryrun_only variable.
Olaf
___
On Mon, Feb 15, Ian Jackson wrote:
> One reason you might define a virtual controller with no devices yet
> is so that you have a stable and pre-expected device path for any
> actual targets you choose to hotplug later.
Would it be acceptable to reuse the devid as the "group index"?
The various
On Mon, Feb 15, Wei Liu wrote:
> > I think yes, DEFINE_DEVICES_ADD has to be used somewhere.
> I'm confused. You're joking, right? "Has to be used somewhere" is not
> a justification for having it in this particular place.
What would be the appropriate place? I think its there since I started
On Fri, Feb 12, Wei Liu wrote:
> CC'ing other tools maintainer.
>
> On Thu, Feb 11, 2016 at 11:37:49AM +0100, Olaf Hering wrote:
> > How should libxl__initiate_device_generic_remove deal with devices which
>
> I think you meant libxl__initiate_device_remove. There is
On Fri, Feb 12, Wei Liu wrote:
> There seems to be a lot of places in this patch where the lines are
> longer than 80 characters. I'm not going to point them out one by one.
> Can you fix as many of those as you can where sensible?
Many lines are slightly longer than 80 chars already, as can be
On Fri, Feb 12, Wei Liu wrote:
> On Thu, Feb 11, 2016 at 03:43:31PM +0000, Olaf Hering wrote:
> > Just to make them public, not meant for merging:
>
> I might be mistaken, but if you don't provide a hotplug script or some
> sort for Xen how do you expect user to make use vs
On Tue, Feb 09, Luis R. Rodriguez wrote:
> The error log from compiling the libSDL test is:
> /tmp/qemu-conf--5604-.c:1:17: fatal error: SDL.h: No such file or directory
This is just the configure test, it can be ignored.
Olaf
___
Xen-devel mailing
On Thu, Feb 11, Olaf Hering wrote:
> I'm in the process to move the counter to the backend path.
... which fails due to libxl__device_exists(). So, back to /libxl
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, Feb 05, Olaf Hering wrote:
> +static int libxl__vscsictrl_next_vscsidev_id(libxl__gc *gc, uint32_t domid,
> + libxl_device_vscsictrl *vscsi,
> + libxl_devid *vscsidev_id)
> +{
> +p
How should libxl__initiate_device_generic_remove deal with devices which
have no frontend driver? Right now it moves "state" from either
XenbusStateInitialising or XenbusStateInitWait to XenbusStateClosing.
Then it expects the backend to move "state" to XenbusStateClosed. This
will never happen,
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Jan Beulich <jbeul...@suse.com>
Cc: Keir Fraser <k...@xen.org>
Cc: Tim
Signed-off-by: Olaf Hering <o...@aepfle.de>
---
tools/misc/Makefile | 4 +
tools/misc/target-create-xen-scsiback.sh | 135 +++
tools/misc/target-delete-xen-scsiback.sh | 41 ++
3 files changed, 180 insertions(+)
diff --git a/tool
The pvops kernel expects either "naa.WWN:LUN" or "h:c:t:l" in the p-dev
property. Add the missing :LUN part to the comment.
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Campbell <ian.campb...@ci
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Cc: Ian C
ted with pvops as backend and SLES as frontend.
Olaf Hering (5):
vscsiif.h: fix WWN notation for p-dev property
docs: add vscsi to xenstore-paths.markdown
libxl: add support for vscsi
vscsiif.h: add some notes about xenstore layout
Scripts to create and delete xen-scsiback nodes in L
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Jan Beulich <jbeul...@suse.com>
Cc: Keir Fraser <k...@xen.org>
Cc: Tim De
Correct dependencies for _paths.h to avoid build failure with make -j.
Only main.c requires _paths.h. This fixes commit 8398ec70 ("xenconsole:
Ensure exclusive access to console using locks")
Signed-off-by: Olaf Hering <o...@aepfle.de>
Cc: Ian Jackson <ian.jack...@eu.citr
On Wed, Feb 10, Luis R. Rodriguez wrote:
> cherry picks for fixes or huge interest to keep it compatible with latest
> compilers qemu-xen-traditional seems to be more of a liability than a
Hey, this is about gnutls, not gcc!
Olaf
___
Xen-devel
On Fri, Feb 05, Konrad Rzeszutek Wilk wrote:
> Also - how does this work if you have an older version of SuSE,
> say SLES10?
SLE10 is out of scope since along time already.
This patch for current gnutls is already in qemu mainline.
f40d55081667a716312b9a8b6e13835c4074f56b
On Tue, Feb 09, Luis R. Rodriguez wrote:
> Thanks so it seems the other option is to bump the release, can that
> be decided? What's the process for deciding that?
Which release should be bumped?
Olaf
___
Xen-devel mailing list
On Fri, Feb 05, Olaf Hering wrote:
> +int xlu_vscsi_detach(XLU_Config *cfg, libxl_ctx *ctx, uint32_t domid, char
> *str)
> +{
> +if (vc->num_vscsidevs > 1) {
> +/* Remove single vscsidev connected to this vscsictrl */;
> +
On Thu, Feb 04, Olaf Hering wrote:
> On Thu, Feb 04, Ian Campbell wrote:
>
> > I think the append_to variant is probably least gross.
>
> libxl_device_vscsidev_append_to_vscsictrl() would work too.
While looking at the MERGE macro in libxl.c, a _remove_from could be
add
The pvops kernel expects either "naa.WWN:LUN" or "h:c:t:l" in the p-dev
property. Add the missing :LUN part to the comment.
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Campbell <ian.campb...@ci
.html
Initial attempt was sent a year ago:
http://lists.xenproject.org/archives/html/xen-devel/2014-04/msg03958.html
Most comments are addressed.
This version has been tested with SLES as backend and frontend.
This version has been tested with pvops as backend and SLES as frontend.
Olaf Hering (5):
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Jan Beulich <jbeul...@suse.com>
Cc: Keir Fraser <k...@xen.org>
Cc: Tim De
Signed-off-by: Olaf Hering <o...@aepfle.de>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Campbell <ian.campb...@citrix.com>
Cc: Ian Jackson <ian.jack...@eu.citrix.com>
Cc: Jan Beulich <jbeul...@suse.com>
Cc: Keir Fraser <k...@xen.org>
Cc: Tim
301 - 400 of 812 matches
Mail list logo
