Re: [libvirt] [Xen-devel] Question about hypervisor that are not tristate

2017-01-11 Thread Konrad Rzeszutek Wilk 
On Wed, Jan 11, 2017 at 10:49:48AM -0700, Jim Fehlig wrote:
> On 01/06/2017 05:31 PM, Jim Fehlig wrote:
> 
> Adding xen-devel for a question below...
> 
> > Happy new year!
> > 
> > Nearly a year ago I reported an issue with the  hypervisor feature on 
> > Xen
> > [1] and am now seeing a similar issue with the  feature. Setting the
> > default value of pae changed between xend and libxl. When not specified, 
> > xend
> > would enable pae for HVM domains. Clients such as xm and the old libvirt 
> > driver
> > did not have to explicitly enable it. In libxl, the pae field within
> > libxl_domain_build_info is initialized to 0. Clients must enable pae, and 
> > indeed
> > xl will do so if pae=1 is not specified in the xl.cfg.
> > 
> > The xend behavior prevents libvirt from disabling pae, whereas the libxl 
> > behvior
> > causes a guest ABI change (config that worked with libvirt+xend doesn't with
> > libvirt+libxl). The libxl behavior also forces management software (e.g.
> > OpenStack nova) to add  where it wasn't needed before.
> > 
> > To solve this problem for , it was changed it to a tristate [2], 
> > allowing
> > it to be turned off with explicit , and on if not 
> > specified or
> >  or . Should  (and the remaining hypervisor 
> > features
> > that are not tristate) be converted to tristate similar to ? 
> > Alternatively,
> > I could simply set pae=1 for all HVM domains in the libxl driver. Like the 
> > old
> > libvirt+xend behavior it couldn't be turned off, but I don't think there is 
> > a
> > practical use-case to do so. At least no one has complained over all the 
> > years
> > of libvirt+xend use.
> 
> Xen folks, what is your opinion of always enabling pae for HVM domains in
> the libvirt libxl driver? Is there a need these days to disable it?

No. I think it should be enabled all the time.
> 
> Jan had mentioned that some old, buggy guest OS's (Win 9x) might need it
> disabled, and perhaps some cases where it may be desirable to suppress a
> guest OS entering 64-bit mode. But in practice do you think it is necessary
> to expose this knob to users?

Um, Win 98? People use that? Microsoft doesn't even support that.

I would ignore such ancient OSes.
> 
> Thanks for your comments!
> 
> Regards,
> Jim
> 
> > [1] https://www.redhat.com/archives/libvir-list/2016-February/msg00197.html
> > [2] https://www.redhat.com/archives/libvir-list/2016-March/msg1.html
> 
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> https://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] Opinions on removing the old, legacy libvirt Xen driver

2016-11-18 Thread Konrad Rzeszutek Wilk 
On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
> Hi All,
> 
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
> driver from the libvirt sources?

RIP.

It will make your life easier! All the code that Joao and Bob are
doing is against libxl and I presume other folks are more interested
in that.

> 
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
> 
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.

/me nods.
> 
> Thanks for opinions and comments!
> 
> Regards,
> Jim
> 
> [0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> https://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH v3 2/8] libxl: implement virDomainMemorystats

2015-11-18 Thread Konrad Rzeszutek Wilk 
On November 17, 2015 6:15:38 PM EST, Jim Fehlig  wrote:
>Joao Martins wrote:
>> Introduce support for domainMemoryStats API call, which
>> consequently enables the use of `virsh dommemstat` command to
>> query for memory statistics of a domain. We support
>> the following statistics: balloon info, available and currently
>> in use. swap-in, swap-out, major-faults, minor-faults require
>> cooperation of the guest and thus currently not supported.
>> 
>> We build on the data returned from libxl_domain_info and deliver
>> it in the virDomainMemoryStat format.
>> 
>> Signed-off-by: Joao Martins 
>> ---
>> Changes since v1:
>>  - Cleanup properly after error fetching domain stats
>>  - Dispose libxl_dominfo after succesfull call to
>>  libxl_domain_info()
>>  - Bump version to 1.2.22
>> ---
>>  src/libxl/libxl_driver.c | 70
>
>>  1 file changed, 70 insertions(+)
>> 
>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>> index 50f6e34..f4fc7bc 100644
>> --- a/src/libxl/libxl_driver.c
>> +++ b/src/libxl/libxl_driver.c
>> @@ -4749,6 +4749,75 @@ libxlDomainGetCPUStats(virDomainPtr dom,
>>  return ret;
>>  }
>>  
>> +#define LIBXL_SET_MEMSTAT(TAG, VAL) \
>> +if (i < nr_stats) { \
>> +stats[i].tag = TAG; \
>> +stats[i].val = VAL; \
>> +i++; \
>> +}
>> +
>> +static int
>> +libxlDomainMemoryStats(virDomainPtr dom,
>> +   virDomainMemoryStatPtr stats,
>> +   unsigned int nr_stats,
>> +   unsigned int flags)
>> +{
>> +libxlDriverPrivatePtr driver = dom->conn->privateData;
>> +libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
>> +virDomainObjPtr vm;
>> +libxl_dominfo d_info;
>> +unsigned mem, maxmem;
>> +size_t i = 0;
>> +int ret = -1;
>> +
>> +virCheckFlags(0, -1);
>> +
>> +if (!(vm = libxlDomObjFromDomain(dom)))
>> +goto cleanup;
>> +
>> +if (virDomainMemoryStatsEnsureACL(dom->conn, vm->def) < 0)
>> +goto cleanup;
>> +
>> +if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_QUERY) < 0)
>> +goto cleanup;
>> +
>> +if (!virDomainObjIsActive(vm)) {
>> +virReportError(VIR_ERR_OPERATION_INVALID,
>> +   "%s", _("domain is not running"));
>> +goto endjob;
>> +}
>> +
>> +if (libxl_domain_info(cfg->ctx, _info, vm->def->id) != 0) {
>> +virReportError(VIR_ERR_INTERNAL_ERROR,
>> +   _("libxl_domain_info failed for domain
>'%d'"),
>> +   vm->def->id);
>> +goto endjob;
>> +}
>> +mem = d_info.current_memkb;
>> +maxmem = d_info.max_memkb;
>> +
>> +LIBXL_SET_MEMSTAT(VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON, maxmem
>- mem);
>
>Should this just be 'mem'? On a domain with
>
>  1048576
>  1048576
>
>I see
>
># virsh dommemstat test
>actual 1024
>available 1049600
>rss 1048576
>
>The documentation for VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON only says
>"Current
>balloon value (in KB)". I (perhaps incorrectly) interpret that as the
>amount of
>memory currently assigned to the domain.
>
>Also, I wonder if we should provide rss for Xen domains? I'm not sure
>it makes
>much sense since Xen domains are more than just a process running on
>the host.
>AFAIK, rss would always be set to d_info.current_memkb even if a domain
>was not
>actually using all the memory.
>

You could go negative with that - say dom0 has 8GB and your guest has 16GB. 
From a Linux dom0 POV we are -8GB, and since tools would most likely use 
unsigned int the sum of RSS would minus total memory would be negative,but that 
is 0x... So the tools might show the guest consuming gobs of memory?


Perhaps just how much QEMU is consuming (if running)?

>Regards,
>Jim
>
>> +LIBXL_SET_MEMSTAT(VIR_DOMAIN_MEMORY_STAT_AVAILABLE, maxmem);
>> +LIBXL_SET_MEMSTAT(VIR_DOMAIN_MEMORY_STAT_RSS, mem);
>> +
>> +ret = i;
>> +
>> +libxl_dominfo_dispose(_info);
>> +
>> + endjob:
>> +if (!libxlDomainObjEndJob(driver, vm)) {
>> +virObjectUnlock(vm);
>> +vm = NULL;
>> +}
>> +
>> + cleanup:
>> +if (vm)
>> +virObjectUnlock(vm);
>> +return ret;
>> +}
>> +
>> +#undef LIBXL_SET_MEMSTAT
>> +
>>  static int
>>  libxlConnectDomainEventRegisterAny(virConnectPtr conn, virDomainPtr
>dom, int eventID,
>>
>virConnectDomainEventGenericCallback callback,
>> @@ -5342,6 +5411,7 @@ static virHypervisorDriver
>libxlHypervisorDriver = {
>>  #endif
>>  .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */
>>  .nodeGetCellsFreeMemory = libxlNodeGetCellsFreeMemory, /* 1.1.1
>*/
>> +.domainMemoryStats = libxlDomainMemoryStats, /* 1.2.22 */
>>  .domainGetCPUStats = libxlDomainGetCPUStats, /* 1.2.22 */
>>  .connectDomainEventRegister = libxlConnectDomainEventRegister,
>/* 0.9.0 */
>>

Re: [libvirt] [Xen-devel] [PATCH 1/4] libxl: populate build_info vfb in separate function

2015-05-09 Thread Konrad Rzeszutek Wilk 
On Fri, May 08, 2015 at 04:31:02PM -0600, Jim Fehlig wrote:
 For HVM domains, vfb info must be populated in the libxl_domain_build_info
 stuct.  Currently this is done in the libxlMakeVfbList function, but IMO

struct
 it would be cleaner to populate the build_info vfb in a separate
 libxlMakeBuildInfoVfb function.  libxlMakeVfbList would then handle only
 vfb devices, simiar to the other libxlMakedeviceList functions.
 
 A future patch will extend libxlMakeBuildInfoVfb to support SPICE.
 
 Signed-off-by: Jim Fehlig jfeh...@suse.com
 ---
  src/libxl/libxl_conf.c | 79 
 ++
  1 file changed, 48 insertions(+), 31 deletions(-)
 
 diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
 index fccada5..8552c77 100644
 --- a/src/libxl/libxl_conf.c
 +++ b/src/libxl/libxl_conf.c
 @@ -1323,37 +1323,6 @@ libxlMakeVfbList(virPortAllocatorPtr graphicsports,
  d_config-vkbs = x_vkbs;
  d_config-num_vfbs = d_config-num_vkbs = nvfbs;
  
 -/*
 - * VNC or SDL info must also be set in libxl_domain_build_info
 - * for HVM domains.  Use the first vfb device.
 - */
 -if (def-os.type == VIR_DOMAIN_OSTYPE_HVM) {
 -libxl_domain_build_info *b_info = d_config-b_info;
 -libxl_device_vfb vfb = d_config-vfbs[0];
 -
 -if (libxl_defbool_val(vfb.vnc.enable)) {
 -libxl_defbool_set(b_info-u.hvm.vnc.enable, true);
 -if (VIR_STRDUP(b_info-u.hvm.vnc.listen, vfb.vnc.listen)  0)
 -goto error;
 -if (VIR_STRDUP(b_info-u.hvm.vnc.passwd, vfb.vnc.passwd)  0)
 -goto error;
 -b_info-u.hvm.vnc.display = vfb.vnc.display;
 -libxl_defbool_set(b_info-u.hvm.vnc.findunused,
 -  libxl_defbool_val(vfb.vnc.findunused));
 -} else if (libxl_defbool_val(vfb.sdl.enable)) {
 -libxl_defbool_set(b_info-u.hvm.sdl.enable, true);
 -libxl_defbool_set(b_info-u.hvm.sdl.opengl,
 -  libxl_defbool_val(vfb.sdl.opengl));
 -if (VIR_STRDUP(b_info-u.hvm.sdl.display, vfb.sdl.display)  0)
 -goto error;
 -if (VIR_STRDUP(b_info-u.hvm.sdl.xauthority, vfb.sdl.xauthority) 
  0)
 -goto error;
 -}
 -
 -if (VIR_STRDUP(b_info-u.hvm.keymap, vfb.keymap)  0)
 -goto error;
 -}
 -
  return 0;
  
   error:
 @@ -1367,6 +1336,51 @@ libxlMakeVfbList(virPortAllocatorPtr graphicsports,
  }
  
  /*
 + * Populate vfb info in libxl_domain_build_info struct for HVM domains.
 + * Use first libxl_device_vfb device in libxl_domain_config-vfbs.
 + * Prior to calling this function, libxlMakeVfbList must be called to
 + * populate libxl_domain_config-vfbs.
 + */
 +static int
 +libxlMakeBuildInfoVfb(virDomainDefPtr def, libxl_domain_config *d_config)
 +{
 +libxl_domain_build_info *b_info = d_config-b_info;
 +libxl_device_vfb x_vfb;
 +
 +if (def-os.type != VIR_DOMAIN_OSTYPE_HVM)
 +return 0;
 +
 +if (d_config-num_vfbs == 0)
 +return 0;
 +
 +x_vfb = d_config-vfbs[0];
 +
 +if (libxl_defbool_val(x_vfb.vnc.enable)) {
 +libxl_defbool_set(b_info-u.hvm.vnc.enable, true);
 +if (VIR_STRDUP(b_info-u.hvm.vnc.listen, x_vfb.vnc.listen)  0)
 +return -1;
 +if (VIR_STRDUP(b_info-u.hvm.vnc.passwd, x_vfb.vnc.passwd)  0)
 +return -1;
 +b_info-u.hvm.vnc.display = x_vfb.vnc.display;
 +libxl_defbool_set(b_info-u.hvm.vnc.findunused,
 +  libxl_defbool_val(x_vfb.vnc.findunused));
 +} else if (libxl_defbool_val(x_vfb.sdl.enable)) {
 +libxl_defbool_set(b_info-u.hvm.sdl.enable, true);
 +libxl_defbool_set(b_info-u.hvm.sdl.opengl,
 +  libxl_defbool_val(x_vfb.sdl.opengl));
 +if (VIR_STRDUP(b_info-u.hvm.sdl.display, x_vfb.sdl.display)  0)
 +return -1;
 +if (VIR_STRDUP(b_info-u.hvm.sdl.xauthority, x_vfb.sdl.xauthority)  
 0)
 +return -1;
 +}
 +
 +if (VIR_STRDUP(b_info-u.hvm.keymap, x_vfb.keymap)  0)
 +return -1;
 +
 +return 0;
 +}
 +
 +/*
   * Get domain0 autoballoon configuration.  Honor user-specified
   * setting in libxl.conf first.  If not specified, autoballooning
   * is disabled when domain0's memory is set with 'dom0_mem'.
 @@ -1764,6 +1778,9 @@ libxlBuildDomainConfig(virPortAllocatorPtr 
 graphicsports,
  if (libxlMakeVfbList(graphicsports, def, d_config)  0)
  return -1;
  
 +if (libxlMakeBuildInfoVfb(def, d_config)  0)
 +return -1;
 +
  if (libxlMakePCIList(def, d_config)  0)
  return -1;
  
 -- 
 1.8.4.5
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] libxl: Disallow save or migrate when host devices are assigned to a guest.

2015-04-15 Thread Konrad Rzeszutek Wilk 
On Tue, Apr 14, 2015 at 08:15:52PM -0600, Jim Fehlig wrote:
 Konrad Rzeszutek Wilk wrote:
  It is unhealthy. If the device is not doing any DMA operations
  it would work - but if you are saving and there are DMA operations
  happening the chance of corruption (outstanding DMAs) increase.
 
  As such re-use the check migration used.

 
 s/used// ?

nods
 
  Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
  ---
   src/libxl/libxl_domain.c| 19 +++
   src/libxl/libxl_domain.h|  3 +++
   src/libxl/libxl_driver.c|  6 ++
   src/libxl/libxl_migration.c | 15 +--
   4 files changed, 29 insertions(+), 14 deletions(-)
 
  diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
  index 5e0ab56..c038989 100644
  --- a/src/libxl/libxl_domain.c
  +++ b/src/libxl/libxl_domain.c
  @@ -178,6 +178,25 @@ libxlDomainObjEndJob(libxlDriverPrivatePtr driver 
  ATTRIBUTE_UNUSED,
   return virObjectUnref(obj);
   }
   
  +/*
  + * Checks whether the domain has host devices (PCIe) to disallow
  + * migration or saving of guest - unless they are detached.
  + *
  + * Returns true if the domain has host devices, otherwise false.
  + */
  +bool
  +libxlDomainHasHostDevices(virDomainDefPtr def)
  +{
  +/* Migration is not allowed if definition contains any hostdevs */
  +if (def-nhostdevs  0) {
  +virReportError(VIR_ERR_OPERATION_INVALID, %s,
  +   _(domain has assigned host devices));
  +return true;
  +}
  +
  +return false;
  +}
  +
   static void *
   libxlDomainObjPrivateAlloc(void)
   {
  diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
  index aa647b8..76c0c8d 100644
  --- a/src/libxl/libxl_domain.h
  +++ b/src/libxl/libxl_domain.h
  @@ -95,6 +95,9 @@ char *
   libxlDomainManagedSavePath(libxlDriverPrivatePtr driver,
  virDomainObjPtr vm);
   
  +bool
  +libxlDomainHasHostDevices(virDomainDefPtr def);
  +
   int
   libxlDomainSaveImageOpen(libxlDriverPrivatePtr driver,
libxlDriverConfigPtr cfg,
  diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
  index 9eb071e..b9faba8 100644
  --- a/src/libxl/libxl_driver.c
  +++ b/src/libxl/libxl_driver.c
  @@ -1650,6 +1650,9 @@ libxlDomainSaveFlags(virDomainPtr dom, const char 
  *to, const char *dxml,
   goto endjob;
   }
   
  +if (libxlDomainHasHostDevices(vm-def))
  +goto endjob;
  +
   if (libxlDoDomainSave(driver, vm, to)  0)
   goto endjob;
   
  @@ -1876,6 +1879,9 @@ libxlDomainManagedSave(virDomainPtr dom, unsigned int 
  flags)
   goto endjob;
   }
   
  +if (libxlDomainHasHostDevices(vm-def))
  +goto endjob;
  +
   name = libxlDomainManagedSavePath(driver, vm);
   if (name == NULL)
   goto endjob;
  diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
  index 4010506..aaed448c 100644
  --- a/src/libxl/libxl_migration.c
  +++ b/src/libxl/libxl_migration.c
  @@ -209,19 +209,6 @@ libxlDoMigrateSend(libxlDriverPrivatePtr driver,
   return ret;
   }
   
  -static bool
  -libxlDomainMigrationIsAllowed(virDomainDefPtr def)
  -{
  -/* Migration is not allowed if definition contains any hostdevs */
  -if (def-nhostdevs  0) {
  -virReportError(VIR_ERR_OPERATION_INVALID, %s,
  -   _(domain has assigned host devices));
  -return false;
  -}
  -
  -return true;
  -}
  -
 
 This function was created with the intention of adding more checks, e.g.
 is the cpu and numa configuration migratable?  Are there pending
 snapshot or block jobs (once those are supported)? ...
 
 I'd like to keep libxlDomainMigrationIsAllowed even though it currently
 only checks for assigned hostdevs.  I think it improves readability of
 the migration code.  For the time it could simply call
 libxlDomainHasHostDevices.

You got it.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).

2015-04-08 Thread Konrad Rzeszutek Wilk 
Hey Jim, Andrew, and Ian,

This is libvirt v1.2.14 + three patches:
c82a59b libxl: drop virDomainObj lock when destroying a domain
a1c9d30 libxl: acquire a job when destroying a domain
5bd5406 libxl: Move job acquisition in libxlDomainStart to callers

For fun I've set up an guest with PCI passthrough and tried to save it
(HAHAH) with an disastrous result (xc_save_helper was stuck). Probably
due to outstanding DMA operations wreaking havoc.

I will shortly send an patch to disallow 'save' with hosted devices
but this scenario exposed an interesting livelock that can happen
without passthrough if things go wrong.


I have not dug entirely in the code so my observation and theory
are most likely incorrect. CC-ing Ian and Andrew.

The full dump is below, the end result is that libvirtd is locked.
Doing 'libvirt list' or any other commands ends with such command
hanged.

libvirtd itself locks to be deadlocked on CTX_LOCK. On one thread
it has received an event (libxl_osevent_occurred_fd) and tries to
take the CTX_LOCK, while another thread (number 10) is stuck
in eventloop_iteration which holds the CTX_LOCK.

It looks like thread #10 is blocking in libxl_read_exactly waiting
for 'libxl-save-helper'. Said application (see below) has dispatched
an message through helper_getreply and is blocking on __read_nocancel.

I presume the message it has dispatched is the same message
the 'libxl_osevent_occurred_fd' is trying to get.

In other words, one thread has taken the lock, and is blocked
waiting for 'libxl-save-helper'. While 'libxl-save-helper' is blocked
waiting for its message to be replied to - which another libvirtd
thread tries to do but it cannot as the lock has been already taken.

Since I did not dig completely in the code I am probably very
wrong about this. Would appreciate thoughts whether this is possible
and where I've gotten it wrong.


Sorry about the control characters and such. I was on a serial
console and capturing this.

thread apply bt full
(gdb) bt
#0  0x7fd3c50d5f1d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x7fd3c50d0906 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x7fd3c5b849b9 in libxl__ctx_lock (ctx=0x7fd38c027ed0) at 
libxl_internal.h:3259
#3  0x7fd3c5b87c8e in libxl_osevent_occurred_fd (ctx=0x7fd38c027ed0, 
for_libxl=0x7fd3ac004230, fd=23, events_ign=0, 
revents_ign=1) at libxl_event.c:1235
#4  0x7fd3c6825dc3 in virEventPollDispatchHandles (fds=optimized out, 
nfds=optimized out) at util/vireventpoll.c:508
#5  virEventPollRunOnce () at util/vireventpoll.c:657
#6  0x7fd3c6824651 in virEventRunDefaultImpl () at util/virevent.c:308
#7  0x7fd3c72aee2d in virNetServerRun (srv=0x7fd3c8bfab40) at 
rpc/virnetserver.c:1139
#8  0x7fd3c727add5 in main (argc=optimized out, argv=optimized out) at 
libvirtd.c:1491
(gdb) thread apply all bt full

Thread 12 (Thread 0x7fd3bc1b6700 (LWP 1263)):
#0  0x7fd3c50d3590 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
No symbol table info available.
#1  0x7fd3c685c0e6 in virCondWait (c=c@entry=0x7fd3c8bfad98, 
m=m@entry=0x7fd3c8bfad70) at util/virthread.c:154
ret = optimized out
#2  0x7fd3c685c99b in virThreadPoolWorker 
(opaque=opaque@entry=0x7fd3c8bfa7a0) at util/virthreadpool.c:105
data = 0x0
pool = 0x7fd3c8bfad30
cond = 0x7fd3c8bfad98
priority = false
job = 0x0
#3  0x7fd3c685be88 in virThreadHelper (data=optimized out) at 
util/virthread.c:206
args = 0x0
local = {func = 0x7fd3c685c7b0 virThreadPoolWorker, funcName = 
0x7fd3c72c0bb1 virNetServerHandleJob, worker = true, 
  opaque = 0x7fd3c8bfa7a0}
#4  0x7fd3c50ce52a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5  0x7fd3c4e0a22d in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 11 (Thread 0x7fd3bb9b5700 (LWP 1264)):
#0  0x7fd3c50d3590 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
No symbol table info available.
#1  0x7fd3c685c0e6 in virCondWait (c=c@entry=0x7fd3c8bfad98, 
m=m@entry=0x7fd3c8bfad70) at util/virthread.c:154
ret = optimized out
#2  0x7fd3c685c99b in virThreadPoolWorker 
(opaque=opaque@entry=0x7fd3c8bfa960) at util/virthreadpool.c:105
data = 0x0
pool = 0x7fd3c8bfad30
cond = 0x7fd3c8bfad98
priority = false
job = 0x0
#3  0x7fd3c685be88 in virThreadHelper (data=optimized out) at 
util/virthread.c:206
args = 0x0
local = {func = 0x7fd3c685c7b0 virThreadPoolWorker, funcName = 
0x7fd3c72c0bb1 virNetServerHandleJob, worker = true, 
  opaque = 0x7fd3c8bfa960}
#4  0x7fd3c50ce52a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5  0x7fd3c4e0a22d in clone () from /lib64/libc.so.6
No symbol table info available.

Thread 10 (Thread 0x7fd3bb1b4700 (LWP 1265)):
---Type return to continue, or q return to quit---
#0  0x7fd3c50d61cd in

[libvirt] [PATCH] libxl: Disallow save or migrate when host devices are assigned to a guest.

2015-04-08 Thread Konrad Rzeszutek Wilk 
It is unhealthy. If the device is not doing any DMA operations
it would work - but if you are saving and there are DMA operations
happening the chance of corruption (outstanding DMAs) increase.

As such re-use the check migration used.

Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
 src/libxl/libxl_domain.c| 19 +++
 src/libxl/libxl_domain.h|  3 +++
 src/libxl/libxl_driver.c|  6 ++
 src/libxl/libxl_migration.c | 15 +--
 4 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 5e0ab56..c038989 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -178,6 +178,25 @@ libxlDomainObjEndJob(libxlDriverPrivatePtr driver 
ATTRIBUTE_UNUSED,
 return virObjectUnref(obj);
 }
 
+/*
+ * Checks whether the domain has host devices (PCIe) to disallow
+ * migration or saving of guest - unless they are detached.
+ *
+ * Returns true if the domain has host devices, otherwise false.
+ */
+bool
+libxlDomainHasHostDevices(virDomainDefPtr def)
+{
+/* Migration is not allowed if definition contains any hostdevs */
+if (def-nhostdevs  0) {
+virReportError(VIR_ERR_OPERATION_INVALID, %s,
+   _(domain has assigned host devices));
+return true;
+}
+
+return false;
+}
+
 static void *
 libxlDomainObjPrivateAlloc(void)
 {
diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
index aa647b8..76c0c8d 100644
--- a/src/libxl/libxl_domain.h
+++ b/src/libxl/libxl_domain.h
@@ -95,6 +95,9 @@ char *
 libxlDomainManagedSavePath(libxlDriverPrivatePtr driver,
virDomainObjPtr vm);
 
+bool
+libxlDomainHasHostDevices(virDomainDefPtr def);
+
 int
 libxlDomainSaveImageOpen(libxlDriverPrivatePtr driver,
  libxlDriverConfigPtr cfg,
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 9eb071e..b9faba8 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -1650,6 +1650,9 @@ libxlDomainSaveFlags(virDomainPtr dom, const char *to, 
const char *dxml,
 goto endjob;
 }
 
+if (libxlDomainHasHostDevices(vm-def))
+goto endjob;
+
 if (libxlDoDomainSave(driver, vm, to)  0)
 goto endjob;
 
@@ -1876,6 +1879,9 @@ libxlDomainManagedSave(virDomainPtr dom, unsigned int 
flags)
 goto endjob;
 }
 
+if (libxlDomainHasHostDevices(vm-def))
+goto endjob;
+
 name = libxlDomainManagedSavePath(driver, vm);
 if (name == NULL)
 goto endjob;
diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 4010506..aaed448c 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -209,19 +209,6 @@ libxlDoMigrateSend(libxlDriverPrivatePtr driver,
 return ret;
 }
 
-static bool
-libxlDomainMigrationIsAllowed(virDomainDefPtr def)
-{
-/* Migration is not allowed if definition contains any hostdevs */
-if (def-nhostdevs  0) {
-virReportError(VIR_ERR_OPERATION_INVALID, %s,
-   _(domain has assigned host devices));
-return false;
-}
-
-return true;
-}
-
 char *
 libxlDomainMigrationBegin(virConnectPtr conn,
   virDomainObjPtr vm,
@@ -251,7 +238,7 @@ libxlDomainMigrationBegin(virConnectPtr conn,
 def = vm-def;
 }
 
-if (!libxlDomainMigrationIsAllowed(def))
+if (libxlDomainHasHostDevices(def))
 goto endjob;
 
 xml = virDomainDefFormat(def, VIR_DOMAIN_DEF_FORMAT_SECURE);
-- 
2.1.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH V3 0/3] libxl: domain destroy fixes

2015-04-08 Thread Konrad Rzeszutek Wilk 
On Fri, Apr 03, 2015 at 04:49:01PM -0600, Jim Fehlig wrote:
 V3 of a small series to fix issues wrt domain destroy
 
 V1:
 https://www.redhat.com/archives/libvir-list/2015-March/msg01337.html
 
 V2:
 https://www.redhat.com/archives/libvir-list/2015-April/msg00072.html
 
 In this version, patch 3 is changed a bit to provide a wrapper for
 unlocking, destroying, and locking the domain.  Existing
 libxl_domain_destroy callers are changed to use the wrapper.

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 
 Jim Fehlig (3):
   libxl: Move job acquisition in libxlDomainStart to callers
   libxl: acquire a job when destroying a domain
   libxl: drop virDomainObj lock when destroying a domain
 
  src/libxl/libxl_domain.c| 106 
 ++--
  src/libxl/libxl_domain.h|   8 ++--
  src/libxl/libxl_driver.c|  81 -
  src/libxl/libxl_migration.c |   4 +-
  4 files changed, 118 insertions(+), 81 deletions(-)
 
 -- 
 1.8.4.5
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH 0/3] libxl: domain destroy fixes

2015-03-27 Thread Konrad Rzeszutek Wilk 
On Wed, Mar 25, 2015 at 02:08:33PM -0600, Jim Fehlig wrote:
 This small series of patches fixes some issues wrt domain destroy in
 the libxl driver.  The primary motivation for this work is to
 prevent locking the virDomainObj during long running destroy operations
 on large memory domains.
 
 Patch 1 moves job acquisition from libxlDomainStart to it's callers so
 they have more control over when the job is acquired.  Patch 2 fixes a
 few spots where we never acquired a job during domain destroy.  Patch 3
 contains the interesting change, where the virDomainObj is unlocked
 during the long-running destroy operation.
 
 This series wraps up my work to improve parallel OpenStack Tempest runs
 against the libxl driver.  With libvirt.git master + this series + a
 patched libxl [1], I've successfully run a reproducer that was hitting
 the same issues encountered by Tempest.
 
 [1] libxl commits from xen.git: 93699882d, f1335f0d, 4783c99a, 1c91d6fba,
 and 188e9c54.  I'll contact the stable branch maintainers and ask them
 to include these commits in the next Xen 4.4.x and 4.5.x releases.
 
 Jim Fehlig (3):
   libxl: Move job acquisition in libxlDomainStart to callers
   libxl: acquire a job when destroying a domain
   libxl: drop virDomainObj lock when destroying a domain

I am no expert at this- but I dug through the code to understand how
the job and locking is done and now I am more comfortable with it.

Since I am new to this I went through all of the the callsites (which used
the job now) from the driver to make sure that there are no chained calls
(one function calling another which also uses a mutex or job locking).

I only found one culprit (libxlDomainAutoCoreDump being called from
 libxlDomainShutdownThread).

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

 
  src/libxl/libxl_domain.c | 77 +++
  src/libxl/libxl_domain.h |  4 ---
  src/libxl/libxl_driver.c | 78 
 
  3 files changed, 89 insertions(+), 70 deletions(-)
 
 -- 
 1.8.4.5
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] libxl: Fix memory leak if pthread_create fails.

2015-03-25 Thread Konrad Rzeszutek Wilk 
If we fail to create the thread we leak the shutdown_info
structure.

Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
 src/libxl/libxl_domain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 774b070..0ac5c62 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -482,7 +482,7 @@ libxlDomainEventHandler(void *data, VIR_LIBXL_EVENT_CONST 
libxl_event *event)
 libxlDriverPrivatePtr driver = data;
 virDomainObjPtr vm = NULL;
 libxl_shutdown_reason xl_reason = event-u.domain_shutdown.shutdown_reason;
-struct libxlShutdownThreadInfo *shutdown_info;
+struct libxlShutdownThreadInfo *shutdown_info = NULL;
 virThread thread;
 libxlDriverConfigPtr cfg;
 
@@ -535,6 +535,7 @@ libxlDomainEventHandler(void *data, VIR_LIBXL_EVENT_CONST 
libxl_event *event)
 virObjectUnref(cfg);
 if (vm)
 virObjectUnlock(vm);
+VIR_FREE(shutdown_info);
 }
 
 void
-- 
1.8.4.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH 2/3] libxl: acquire a job when destroying a domain

2015-03-25 Thread Konrad Rzeszutek Wilk 
On Wed, Mar 25, 2015 at 02:08:35PM -0600, Jim Fehlig wrote:
 A job should be acquired at the beginning of a domain destroy operation,
 not at the end when cleaning up the domain.  Fix two occurances of this
 late job acquisition in the libxl driver.  Doing so renders
 libxlDomainCleanup unused, so it is removed.
 
 Signed-off-by: Jim Fehlig jfeh...@suse.com
 ---
  src/libxl/libxl_domain.c | 49 
 +---
  src/libxl/libxl_domain.h |  4 
  src/libxl/libxl_driver.c | 20 
  3 files changed, 29 insertions(+), 44 deletions(-)
 
 diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
 index eca1ff0..e240eae 100644
 --- a/src/libxl/libxl_domain.c
 +++ b/src/libxl/libxl_domain.c
 @@ -371,6 +371,9 @@ libxlDomainShutdownThread(void *opaque)
  
  cfg = libxlDriverConfigGet(driver);
  
 +if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_MODIFY)  0)
 +goto cleanup;
 +

Won't this a deadlock with 'libxlDomainAutoCoreDump'  (line 410) (which also
calls :

 727 if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_MODIFY)  0)
 728 goto cleanup;

well, not deadlock - but spin up to 30 seconds? and then give up?

Perhaps this patch should be folded in?

From 9f2bac0c28815fc51850290c4b1962881691bfca Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Wed, 25 Mar 2015 22:34:51 -0400
Subject: [PATCH] squash

---
 src/libxl/libxl_domain.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index aef0157..774b070 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -723,15 +723,11 @@ libxlDomainAutoCoreDump(libxlDriverPrivatePtr driver,
 timestr)  0)
 goto cleanup;
 
-if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_MODIFY)  0)
-goto cleanup;
-
 /* Unlock virDomainObj while dumping core */
 virObjectUnlock(vm);
 libxl_domain_core_dump(cfg-ctx, vm-def-id, dumpfile, NULL);
 virObjectLock(vm);
 
-ignore_value(libxlDomainObjEndJob(driver, vm));
 ret = 0;
 
  cleanup:
-- 
1.8.4.2

  if (xl_reason == LIBXL_SHUTDOWN_REASON_POWEROFF) {
  dom_event = virDomainEventLifecycleNewFromObj(vm,
 VIR_DOMAIN_EVENT_STOPPED,
 @@ -384,7 +387,7 @@ libxlDomainShutdownThread(void *opaque)
  goto restart;
  case VIR_DOMAIN_LIFECYCLE_PRESERVE:
  case VIR_DOMAIN_LIFECYCLE_LAST:
 -goto cleanup;
 +goto endjob;
  }
  } else if (xl_reason == LIBXL_SHUTDOWN_REASON_CRASH) {
  dom_event = virDomainEventLifecycleNewFromObj(vm,
 @@ -399,7 +402,7 @@ libxlDomainShutdownThread(void *opaque)
  goto restart;
  case VIR_DOMAIN_LIFECYCLE_CRASH_PRESERVE:
  case VIR_DOMAIN_LIFECYCLE_CRASH_LAST:
 -goto cleanup;
 +goto endjob;
  case VIR_DOMAIN_LIFECYCLE_CRASH_COREDUMP_DESTROY:
  libxlDomainAutoCoreDump(driver, vm);
  goto destroy;
 @@ -420,11 +423,11 @@ libxlDomainShutdownThread(void *opaque)
  goto restart;
  case VIR_DOMAIN_LIFECYCLE_PRESERVE:
  case VIR_DOMAIN_LIFECYCLE_LAST:
 -goto cleanup;
 +goto endjob;
  }
  } else {
  VIR_INFO(Unhandled shutdown_reason %d, xl_reason);
 -goto cleanup;
 +goto endjob;
  }
  
   destroy:
 @@ -433,13 +436,11 @@ libxlDomainShutdownThread(void *opaque)
  dom_event = NULL;
  }
  libxl_domain_destroy(cfg-ctx, vm-def-id, NULL);
 -if (libxlDomainCleanupJob(driver, vm, reason)) {
 -if (!vm-persistent) {
 -virDomainObjListRemove(driver-domains, vm);
 -vm = NULL;
 -}
 -}
 -goto cleanup;
 +libxlDomainCleanup(driver, vm, reason);
 +if (!vm-persistent)
 +virDomainObjListRemove(driver-domains, vm);
 +
 +goto endjob;
  
   restart:
  if (dom_event) {
 @@ -447,13 +448,17 @@ libxlDomainShutdownThread(void *opaque)
  dom_event = NULL;
  }
  libxl_domain_destroy(cfg-ctx, vm-def-id, NULL);
 -libxlDomainCleanupJob(driver, vm, VIR_DOMAIN_SHUTOFF_SHUTDOWN);
 +libxlDomainCleanup(driver, vm, VIR_DOMAIN_SHUTOFF_SHUTDOWN);
  if (libxlDomainStart(driver, vm, false, -1)  0) {
  virErrorPtr err = virGetLastError();
  VIR_ERROR(_(Failed to restart VM '%s': %s),
vm-def-name, err ? err-message : _(unknown error));
  }
  
 + endjob:
 +if (!libxlDomainObjEndJob(driver, vm))
 +vm = NULL;
 +
   cleanup:
  if (vm)
  virObjectUnlock(vm);
 @@ -690,26 +695,6 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
  }
  
  /*
 - * Cleanup function for domain that has reached shutoff state.
 - * Executed in the context of a job.
 - *
 - * virDomainObjPtr should be locked on invocation
 - * Returns true if references remain on virDomainObjPtr

Re: [libvirt] [PATCH v2] PCI: Introduce new device binding path using pci_dev.driver_override

2014-05-16 Thread Konrad Rzeszutek Wilk 
On Fri, May 16, 2014 at 10:48:00AM -0400, Konrad Rzeszutek Wilk wrote:
 On Fri, May 9, 2014 at 12:50 PM, Alex Williamson alex.william...@redhat.com
  wrote:
 
  The driver_override field allows us to specify the driver for a device
  ...
 
 ...
 
  Signed-off-by: Alex Williamson alex.william...@redhat.com
  Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 
 
 Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

And somehow my emailer (Google) decided to add yucky HTML crud
to the end.

So here is an nice plain email so that it can go the the right
mailing lists - and sorry for the extra emails to those on the
'To' and 'CC'!
 ___
 iommu mailing list
 io...@lists.linux-foundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/iommu

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2] PCI: Introduce new device binding path using pci_dev.driver_override

2014-05-16 Thread Konrad Rzeszutek Wilk 
On Fri, May 9, 2014 at 12:50 PM, Alex Williamson alex.william...@redhat.com
 wrote:

 The driver_override field allows us to specify the driver for a device
 ...

...

 Signed-off-by: Alex Williamson alex.william...@redhat.com
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org


Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH v2] libxl: Support PV consoles

2014-04-25 Thread Konrad Rzeszutek Wilk 
On Fri, Apr 25, 2014 at 11:24:07AM -0600, Jim Fehlig wrote:
 Jim Fehlig wrote:
  Ian Campbell wrote:

  Currently the driver only exposes the ability to connect to the serial 
  console
  of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest 
  the
  serial devices are duplicated as consoles it is sufficient to just use the
  console devices unconditionally.
 
  Tested with the following bit of config XML:
 
  domain type='xen'
...
devices
  console type='pty'
target type='xen'/
  /console
/devices
  /domain
 
  I have observed and tested this on ARM but I believe it also applies to 
  x86 PV
  guests.

  
 
  Yep, I think you are right.
 
  ACK to the patch.  I'll push it, after a bit of testing.
 
  Regards,
  Jim
 

  Signed-off-by: Ian Campbell ian.campb...@citrix.com
  Cc: Jim Fehlig jfeh...@suse.com
  Cc: Dario Faggioli dario.faggi...@citrix.com
  Cc: Clark Laughlin clark.laugh...@linaro.org
  ---
  v2: Just use nconsoles unconditionally, they contain serial too
  ---
   src/libxl/libxl_driver.c |   12 +---
   1 file changed, 9 insertions(+), 3 deletions(-)
 
  diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
  index a6ae8a1..535e7da 100644
  --- a/src/libxl/libxl_driver.c
  +++ b/src/libxl/libxl_driver.c
  @@ -3780,6 +3780,7 @@ libxlDomainOpenConsole(virDomainPtr dom,
   {
   virDomainObjPtr vm = NULL;
   int ret = -1;
  +libxl_console_type console_type = LIBXL_CONSOLE_TYPE_UNKNOWN;
  
 
 This doesn't compile with Xen 4.2.x

Hey Jim!

The development version of Xen is 4.5. The latest stable
is Xen 4.4.

If you want to backport it - then your suggestion is correct.
Or just backport the relevant patches ?

 
 libxl/libxl_driver.c: In function 'libxlDomainOpenConsole':
 libxl/libxl_driver.c:3783:39: error: 'LIBXL_CONSOLE_TYPE_UNKNOWN'
 undeclared (first use in this function)
 libxl/libxl_driver.c:3783:39: note: each undeclared identifier is
 reported only once for each function it appears in
 
 xen.git commit 166bb0fe introduced UNKNOWN in the enum.  I suppose it is
 best to initialize console_type with 0, along  with a comment?
 
 Regards,
 Jim
 
   virDomainChrDefPtr chr = NULL;
   libxlDomainObjPrivatePtr priv;
   char *console = NULL;
  @@ -3807,8 +3808,8 @@ libxlDomainOpenConsole(virDomainPtr dom,
   
   priv = vm-privateData;
   
  -if (vm-def-nserials)
  -chr = vm-def-serials[0];
  +if (vm-def-nconsoles)
  +chr = vm-def-consoles[0];
   
   if (!chr) {
   virReportError(VIR_ERR_INTERNAL_ERROR,
  @@ -3824,7 +3825,12 @@ libxlDomainOpenConsole(virDomainPtr dom,
   goto cleanup;
   }
   
  -ret = libxl_primary_console_get_tty(priv-ctx, vm-def-id, console);
  +console_type =
  +(chr-targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ?
  +LIBXL_CONSOLE_TYPE_SERIAL : 
  LIBXL_CONSOLE_TYPE_PV);
  +
  +ret = libxl_console_get_tty(priv-ctx, vm-def-id, chr-target.port,
  +console_type, console);
   if (ret)
   goto cleanup;
   

  
 
  --
  libvir-list mailing list
  libvir-list@redhat.com
  https://www.redhat.com/mailman/listinfo/libvir-list
 

 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH v2] libxl: Support PV consoles

2014-04-25 Thread Konrad Rzeszutek Wilk 
On Fri, Apr 25, 2014 at 07:52:55PM +0100, Ian Campbell wrote:
 On Fri, 2014-04-25 at 13:32 -0400, Konrad Rzeszutek Wilk wrote:
  The development version of Xen is 4.5. The latest stable
  is Xen 4.4.
 
  If you want to backport it - then your suggestion is correct.
  Or just backport the relevant patches ?
 
 This patch is against libvirt, which wishes to support Xen versions back
 to Xen 4.2, this is not a patch against Xen.

Ah, that makes more sense.
 
 Or maybe I've missed your point?

No, I just assumed it would be only applicable to Xen - didn't think
that API promises this.

blushes
 
 Ian.
 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH] libxl: Correctly initialize vcpu bitmap

2013-07-22 Thread Konrad Rzeszutek Wilk 
On Mon, Jul 22, 2013 at 12:51:05PM +0200, Stefan Bader wrote:
 This fixes the basic setup but there is likely more to do if things
 like manual CPU hirarchy (nodes, cores, threads) to be working.
 
 Cross-posting to xen-devel to make sure I am doing things correctly.
 
 -Stefan
 
 
 From 1ec5e7ea0d3498b9f61b83e8aed87cc3cae106de Mon Sep 17 00:00:00 2001
 From: Stefan Bader stefan.ba...@canonical.com
 Date: Fri, 19 Jul 2013 15:20:00 +0200
 Subject: [PATCH] libxl: Correctly initialize vcpu bitmap
 
 The avai_vcpu bitmap has to be allocated before it can be used (using

avail_vcpu ?

 the maximum allowed value for that). Then for each available VCPU the
 bit in the mask has to be set (libxl_bitmap_set takes a bit position
 as an argument, not the number of bits to set).
 
 Without this, I would always only get one VCPU for guests created
 through libvirt/libxl.
 
 Signed-off-by: Stefan Bader stefan.ba...@canonical.com

The libxl calling logic looks Ok to me. So from the libxl perspective
you can tack on Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

 ---
  src/libxl/libxl_conf.c |   14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)
 
 diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
 index 4a0fba9..7592dd2 100644
 --- a/src/libxl/libxl_conf.c
 +++ b/src/libxl/libxl_conf.c
 @@ -331,7 +331,8 @@ error:
  }
  
  static int
 -libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config)
 +libxlMakeDomBuildInfo(libxlDriverPrivatePtr driver, virDomainDefPtr def,
 +  libxl_domain_config *d_config)
  {
  libxl_domain_build_info *b_info = d_config-b_info;
  int hvm = STREQ(def-os.type, hvm);
 @@ -343,8 +344,15 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, 
 libxl_domain_config *d_config)
  libxl_domain_build_info_init_type(b_info, LIBXL_DOMAIN_TYPE_HVM);
  else
  libxl_domain_build_info_init_type(b_info, LIBXL_DOMAIN_TYPE_PV);
 +
  b_info-max_vcpus = def-maxvcpus;
 -libxl_bitmap_set((b_info-avail_vcpus), def-vcpus);
 +if (libxl_cpu_bitmap_alloc(driver-ctx, b_info-avail_vcpus,
 +   def-maxvcpus))
 +goto error;
 +libxl_bitmap_set_none(b_info-avail_vcpus);
 +for (i = 0; i  def-vcpus; i++)
 +libxl_bitmap_set((b_info-avail_vcpus), i);
 +
  if (def-clock.ntimers  0 
  def-clock.timers[0]-name == VIR_DOMAIN_TIMER_NAME_TSC) {
  switch (def-clock.timers[0]-mode) {
 @@ -802,7 +810,7 @@ libxlBuildDomainConfig(libxlDriverPrivatePtr driver,
  if (libxlMakeDomCreateInfo(driver, def, d_config-c_info)  0)
  return -1;
  
 -if (libxlMakeDomBuildInfo(def, d_config)  0) {
 +if (libxlMakeDomBuildInfo(driver, def, d_config)  0) {
  return -1;
  }
  
 -- 
 1.7.9.5
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] libxl: calculating free pages in libvirt

2013-06-11 Thread Konrad Rzeszutek Wilk 
On Thu, Jun 06, 2013 at 03:53:13PM +0200, Dario Faggioli wrote:
 Hi Jim,
 
 As I told you in Dublin, I'm looking into libvirt a bit, with the main
 purpose of implementing the NUMA interface for the libxl driver.
 
 While at it I noticed that libxlNodeGetFreeMemory() uses the value
 contained in phy_info.free_pages to check how many pages of free memory
 we have.
 
 However, starting from (Xen's git) commit bec8f17e, the number of free
 pages should be computed like this:
 
  (phy_info.free_pages - phy_info.outstanding_pages)
 
 to take the memory claiming mechanism introduced by Oracle properly into
 account. You can see an example of that, for instance, looking at the
 output_physinfo() function in tools/libxl/xl_cmdimpl.c (in the Xen
 codebase, of course :-) ).
 
 Said commit is from last May, and the claim mechanism altogether --which
 includes adding the outstanding_pages field to the libxl_physinfo struct
 in libxl-- was introduced during the 4.3 development cycle.
 
 So, forgive the possibly dumb question, but what's the preferred way to
 fix this in libvirt, without breaking build with old libxl versions?
 (Provided this is something libvirt cares about, does it?)
 
 For other features added within this last dev cycle, libxl has a
 `#define LIBXL_HAVE_foo' (e.g., LIBXL_HAVE_DOMAIN_NODEAFFINITY), but I
 don't see one for this particular field... Konrad, Ian, am I missing it?
 If no, should we add it?

I think we missed it. I remember thinking about it, but I can't recall
what I didn't submit. It certainly should be added.

And I think that would fix the build of old libxl against new libvirt.
Or vice-versa (if libxl supported the claim operation).
 
 Thanks and Regards,
 Dario
 
 -- 
 This happens because I choose it to happen! (Raistlin Majere)
 -
 Dario Faggioli, Ph.D, http://about.me/dario.faggioli
 Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK)
 


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list