Re: [Xen-devel] [PATCH v11 01/17] Xen: ACPI: Hide UART used by Xen

Hi Rafael， Could you please give your comments on this patch? Thanks in advanced! On 2016/4/7 20:03, Shannon Zhao wrote: > From: Shannon Zhao > > ACPI 6.0 introduces a new table STAO to list the devices which are used > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical >

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 14/04/16 21:44, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote: >> On 13/04/16 20:52, Luis R. Rodriguez wrote: >>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote: On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez wrote: > So more

Re: [Xen-devel] Question about the XEN platform pci

On Wed, Apr 13, 2016 at 11:55 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 13, 2016 at 09:00:18AM +0200, karim.allah.ah...@gmail.com wrote: >> On Tue, Apr 12, 2016 at 5:45 PM, Konrad Rzeszutek Wilk >> wrote: >> > On Tue, Apr 12, 2016 at 05:33:47PM +0200, karim.allah.ah...@gmail.com >> > wrote:

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On 14/04/16 19:07, Ian Jackson wrote: > This is my attempt at understanding the situation, from reading > descriptions provided on list in the context of toolstack patches > which were attempting to work around the anomaly. > > The multiple `xxx' entries reflect 1. my lack of complete understandin

[Xen-devel] [libvirt test] 91380: tolerable FAIL - PUSHED

flight 91380 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/91380/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-sup

Re: [Xen-devel] [PATCH 1/3] libxc: Revert "do some retries in xc_cpupool_removecpu() for EBUSY case"

On 14/04/16 19:07, Ian Jackson wrote: > libxc may be called from within long-running daemons such as libvirt. > > In such a system this sleep would enable an uncooperative or buggy > guest to block all toolstack operations for an extended period. > > Sadly, therefore, such a retry loop is not fea

[Xen-devel] [qemu-mainline test] 91359: regressions - FAIL

flight 91359 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/91359/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 9 debian-installfail REGR. vs. 86454 test-armhf-armhf-xl

[Xen-devel] [linux-4.1 test] 91350: tolerable FAIL - PUSHED

flight 91350 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/91350/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt 6 xen-boot fail in 91189 pass in 91350 test-amd64-amd64-xl-qemut-stubdom-deb

Re: [Xen-devel] [sh_eth.c] Problem in dma_map_single()

​Hi Konrad,​ Finally, I can use ethernet :D. It was my mistake. I thought the SET_NETDEV_DEV() makes ndev == pdev->dev, but it's not true. So I changed the dma configuration from: dma_coerce_mask_and_coherent(*&pdev->dev*, DMA_BIT_MASK(32)); SET_NETDEV_DEV(ndev, &pdev->dev); to: dma_coerce_ma

[Xen-devel] [PATCH v2 2/6] ARM: xen: Register with kernel restart handler

Register with kernel restart handler instead of setting arm_pm_restart directly. Select a high priority of 192 to ensure that default restart handlers are replaced if Xen is running. Acked-by: Arnd Bergmann Reviewed-by: Wolfram Sang Reviewed-by: Stefano Stabellini Signed-off-by: Guenter Roeck

Re: [Xen-devel] [PATCH v8.1 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote: > >>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>> > > @@ -460,6 +461,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) > > u_sysctl) > > ret = tmem_control(&op->u.tmem_op); > > break; > > > > +case XEN_SYSCT

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 11:12:01PM +0200, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote: > > > This has nothing to do with dominance or anything nefarious, I'm asking > > > simply for a full engineering evaluation of all possibilities, with > > > t

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 10:56:19PM +0200, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote: > > > On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote: > > > > On

Re: [Xen-devel] [PATCH v8.1] xSplice v1 design and implementation.

On Thu, Apr 14, 2016 at 09:17:14AM -0600, Jan Beulich wrote: > >>> Andrew Cooper 04/14/16 5:14 PM >>> > >On 14/04/16 15:26, Konrad Rzeszutek Wilk wrote: > >> @@ -312,8 +307,8 @@ struct xsplice_patch_func { > >> }; > >> > >> > >> -The size of the structure is 64 bytes or 52 bytes if compiled

Re: [Xen-devel] [PATCH for-4.7] tools/libxl: Fix legacy migration following COLO backchannel breakage

On 04/15/2016 03:54 AM, Andrew Cooper wrote: > c/s f5d947bf1b "tools/libxl: add back channel support to read stream" > made a bogus adjustment to libxl__stream_read_start(), including > removing the comment hinting at what was going on, which breaks > conversion of a legacy migration stream. > > S

Re: [Xen-devel] Regarding Outreachy project on Improving CR Dashboard

Thanks a lot. I can run it now, with the latest version of Perceval, and at first glance seems to work. Some improvements could be done, but it seems to work. Since we're quite close to the evaluation for the microtask, let's stop here, except for the tests. Please, produce some, to validate at lea

Re: [Xen-devel] [libvirt] [PATCH] libxl: use LIBXL_API_VERSION 0x040200

Martin Kletzander wrote: > On Wed, Apr 13, 2016 at 05:37:05PM -0600, Jim Fehlig wrote: >> To ensure the libvirt libxl driver will build with future versions >> of Xen where the libxl API may change in incompatible ways, >> explicitly use LIBXL_API_VERSION 0x040200. The libxl driver >> does use new

Re: [Xen-devel] [PATCH] libxl: use LIBXL_API_VERSION 0x040200

George Dunlap wrote: > On Thu, Apr 14, 2016 at 12:37 AM, Jim Fehlig wrote: >> To ensure the libvirt libxl driver will build with future versions >> of Xen where the libxl API may change in incompatible ways, >> explicitly use LIBXL_API_VERSION 0x040200. The libxl driver >> does use new libxl APIs

[Xen-devel] [PATCH V2] libxl: use LIBXL_API_VERSION 0x040200

To ensure the libvirt libxl driver will build with future versions of Xen where the libxl API may change in incompatible ways, explicitly use LIBXL_API_VERSION 0x040200. The libxl driver does use new libxl APIs that have been added since Xen 4.2, but currently it does not make use of any changes ma

Re: [Xen-devel] [PATCH] documentation: Add disclaimer

On Wed, Jan 27, 2016 at 02:57:07PM +, David Howells wrote: > Peter Zijlstra wrote: > > > +== > > +DISCLAIMER > > +== > > + > > +This document is not a specification; it is intentionally (for the sake of > > +brevity) and unintentionally (due to being human) incomplete. This >

Re: [Xen-devel] [PATCH] documentation: Add disclaimer

On Wed, Jan 27, 2016 at 09:35:46AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote: > > So Peter, would you like to update your patch to include yourself > > and Will as authors? > > Sure, here goes. > > --- > Subject: documentation: Add disclaimer

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote: > > This has nothing to do with dominance or anything nefarious, I'm asking > > simply for a full engineering evaluation of all possibilities, with > > the long term in mind. Not for now, but for hardware assumptions which > > a

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote: > > On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Thu, Apr 14, 2016 at 12:23:17AM +0200, Luis R. Rodriguez wrote: > > > > VGA

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

> This has nothing to do with dominance or anything nefarious, I'm asking > simply for a full engineering evaluation of all possibilities, with > the long term in mind. Not for now, but for hardware assumptions which > are sensible 5 years from now. There are two different things in my mind about

Re: [Xen-devel] [PATCH 2/3] xen: hypercall docs annotations for xen_sysctl_cpupool_op

On Thu, 2016-04-14 at 18:07 +0100, Ian Jackson wrote: > Signed-off-by: Ian Jackson > CC: Jan Beulich > CC: Tim Deegan > Reviewed-by: Dario Faggioli One thing, out of curiosity. This syntax, here: > -/* XEN_SYSCTL_cpupool_op */ > +/* ` enum XEN_SYSCTL_cpupool_op { */ >  #define XEN_SYSCTL_CPUP

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On Thu, 2016-04-14 at 18:56 +0100, Ian Jackson wrote: > Andrew Cooper writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document > XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): > > > > On 14/04/16 18:07, Ian Jackson wrote: > > > > > > +/* > > > + * cpupool operations may return EBUSY if the opera

Re: [Xen-devel] [PATCH v3 1/5] xentrace: Common Support for get_pg_owner/put_pg_owner on ARM and x86

Jan, >> +void put_pg_owner(struct domain *pg_owner) { >> +rcu_unlock_domain(pg_owner); >> +} > I cannot see why this then can't just become an inline function. I investigated this but making put_pg_owner() static inline creates a circular dependency on rcu_unlock_domain(), which is also a st

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 10:42:15AM +0100, George Dunlap wrote: > On 13/04/16 19:54, Luis R. Rodriguez wrote: > > On Wed, Apr 13, 2016 at 11:05:00AM +0100, George Dunlap wrote: > >> On Tue, Apr 12, 2016 at 11:12 PM, Luis R. Rodriguez > >> wrote: > >>> Also, x86 does have a history of short DT use.

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote: > On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Apr 14, 2016 at 12:23:17AM +0200, Luis R. Rodriguez wrote: > > > On Wed, Apr 13, 2016 at 05:08:01PM -0400, Konrad Rzeszutek Wilk wrote: > > > > On

Re: [Xen-devel] [PATCH v3 2/5] xentrace: Memory/Page Mapping support for DOMID_XEN on ARM

Julien, George, Andrew, and Stefano, > Thank you for the explanation. > > The ARM implementation of share_xen_page_with_guest is nearly the same > as the x86 one. However, the type is never used so far for the P2M > code. > > So far, all ARM domains have been auto-translated. DOMID_XEN is the >

[Xen-devel] [PATCH for-4.7] tools/libxl: Fix legacy migration following COLO backchannel breakage

c/s f5d947bf1b "tools/libxl: add back channel support to read stream" made a bogus adjustment to libxl__stream_read_start(), including removing the comment hinting at what was going on, which breaks conversion of a legacy migration stream. Symptoms look like: root@anonymi:~ # xl migrate domU ho

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote: > On 13/04/16 20:52, Luis R. Rodriguez wrote: > > On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote: > >> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez wrote: > >>> So more to it, if the EFI entry already provides a way

[Xen-devel] [ovmf test] 91276: regressions - FAIL

flight 91276 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91276/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovm

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages]

On Thu, Apr 14, 2016 at 07:11:46PM +0100, Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested > Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring > XENVER_ but sane."): > > On the other hand, I think there's a bit of a faulty interp

Re: [Xen-devel] run xen on hikey board

On 14/04/2016 12:39, Safa Hamza wrote: hello Hello, to build xen on hikey board ..only should i write make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- there is no CONFIG_EARLY_PRINTK like other board (omap5432 , cubie ..) Nobody adds earlyprintk support for the hik

Re: [Xen-devel] [PATCH v4 0/3] add hypercall option to temporarily pin a vcpu

On Thu, Apr 14, 2016 at 05:11:05PM +0100, Ian Jackson wrote: > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v4 0/3] add hypercall > option to temporarily pin a vcpu"): > > Applied. > > Damn, I see I am too late with my review. > > I will propose to revert some of this. :-/. It is the s

[Xen-devel] [linux-3.18 test] 91272: regressions - FAIL

flight 91272 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/91272/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86513 test-amd64-i386

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Apr 14, 2016 at 12:23:17AM +0200, Luis R. Rodriguez wrote: > > On Wed, Apr 13, 2016 at 05:08:01PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Wed, Apr 13, 2016 at 10:40:55PM +0200, Luis R. Rodriguez wrote: > > > > On

Re: [Xen-devel] [osstest test] 91154: regressions - FAIL

osstest service owner writes ("[osstest test] 91154: regressions - FAIL"): > flight 91154 osstest real [real] > http://logs.test-lab.xenproject.org/osstest/logs/91154/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-armhf-arm

[Xen-devel] [linux-linus test] 91263: regressions - FAIL

flight 91263 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/91263/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 build-amd64-rumpuserx

Re: [Xen-devel] [PATCH for-4.7] hotplug/Linux: fix same_vm check in block script

Wei Liu writes ("[PATCH for-4.7] hotplug/Linux: fix same_vm check in block script"): > The original same_vm check has two bugs. When stubdom is in use because > it relies on numeric domid to check if two domains are in fact the same > one. Another one is that the check would fail when two stubdom

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages]

George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."): > On the other hand, I think there's a bit of a faulty interpretation of > the procedure here. Jan reviewed the patch thoroughly

Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

On Thu, 2016-04-14 at 18:59 +0100, 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 s

Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

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 LIBXL_HAVE_NO_SUSPEND_RESUME or LIBXL_HAVE_DOM

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

Andrew Cooper writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): > On 14/04/16 18:07, Ian Jackson wrote: > > +/* > > + * cpupool operations may return EBUSY if the operation cannot be > > + * executed right now because of another cpupool operat

Re: [Xen-devel] [for-4.7 0/2] xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2

On Wed, Apr 13, 2016 at 04:55:29PM +0100, Julien Grall wrote: > Hello, > > This small patch series is a bug fix for Xen 4.7 and should also be backported > to Xen 4.6. > > Without it, the faulting IPA reported to memaccess may be wrong. > > Regards, > > Cc: wei.l...@citrix.com > > Julien Grall

Re: [Xen-devel] [PATCH v2] xen: change the sizes of memory fields in the HVM start info to be 64bits

On Wed, Apr 13, 2016 at 10:15:32PM -0600, Jan Beulich wrote: > >>> Roger Pau Monne 04/12/16 6:12 PM >>> > >At the moment the only consumer of this structure is x86, but other arches > >might also use it, so make all the fields 64bits. On x86 Xen will still try > >to place everything below the 4GiB

Re: [Xen-devel] [PATCH for-4.7] libxl/save: set domain_suspend_state->domid in do_domain_soft_reset()

On Mon, Apr 11, 2016 at 01:36:14PM +0100, Wei Liu wrote: > Sorry for breaking it! > > On Mon, Apr 11, 2016 at 02:20:04PM +0200, Vitaly Kuznetsov wrote: > > c/s d5c693d "libxl/save: Refactor libxl__domain_suspend_state" broke soft > > reset as libxl__domain_suspend_device_model() now fails when dom

Re: [Xen-devel] [PATCH v4 2/3] libxl: print message how to recover from xl cpupool-cpu-remove errors

On Thu, 2016-04-14 at 18:22 +0100, Ian Jackson wrote: > Dario Faggioli writes ("Re: [Xen-devel] [PATCH v4 2/3] libxl: print > message how to recover from xl cpupool-cpu-remove errors"): > > > > Not easily (and in general not with any patch that I'd consider > > appropriate for this phase of the re

Re: [Xen-devel] [RFC PATCH v6 00/28] libxl: Deprivilege qemu

Stefano Stabellini writes ("Re: [RFC PATCH v6 00/28] libxl: Deprivilege qemu"): > I take that this series is going to miss 4.7 at this stage, right? I'm afraid so. We concluded that a crucial piece - arranging for the necessary access controls on privcmd - was not going to be in place for 4.7. W

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On 14/04/16 18:07, Ian Jackson wrote: > This is my attempt at understanding the situation, from reading > descriptions provided on list in the context of toolstack patches > which were attempting to work around the anomaly. > > The multiple `xxx' entries reflect 1. my lack of complete understanding

Re: [Xen-devel] [PATCH v4 2/3] libxl: print message how to recover from xl cpupool-cpu-remove errors

Dario Faggioli writes ("Re: [Xen-devel] [PATCH v4 2/3] libxl: print message how to recover from xl cpupool-cpu-remove errors"): > Not easily (and in general not with any patch that I'd consider > appropriate for this phase of the release process), as it depends on > transient situations in the hyp

Re: [Xen-devel] [PATCH v4 3/3] libxl: add force option for xl vcpu-pin

On Thu, 2016-04-14 at 17:10 +0100, Ian Jackson wrote: > Juergen Gross writes ("[PATCH v4 3/3] libxl: add force option for xl > vcpu-pin"): > > > >  > > +Specifying I<-f> or I<--force> will remove a temporary pinning > > done by the > > +operating system (normally this should be done by the operati

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

On Thu, Apr 14, 2016 at 4:59 PM, Jan Beulich wrote: George Dunlap 04/14/16 5:16 PM >>> >>On the other hand, I think there's a bit of a faulty interpretation of >>the procedure here. Jan reviewed the patch thoroughly and then acked >>it; on the basis of that, Konrad legitimately checked it i

Re: [Xen-devel] Regarding Outreachy project on Improving CR Dashboard

Hello Jesus, I had made changes to my code to work with the latest version of Perceval, you can see my latest commit [1]. Let me know if come across issues? I am working on the testing part now, stuck with few issues. Hoping to complete by tomorrow or day after. [1]: https://github.com/priya299

Re: [Xen-devel] [PATCH v4 2/3] libxl: print message how to recover from xl cpupool-cpu-remove errors

On Thu, 2016-04-14 at 17:06 +0100, Ian Jackson wrote: > Juergen Gross writes ("[PATCH v4 2/3] libxl: print message how to > recover from xl cpupool-cpu-remove errors"): > > > > An error occurring when calling "xl cpupool-cpu-remove" might leave > > the system in a state where a cpu is neither comp

[Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

This is my attempt at understanding the situation, from reading descriptions provided on list in the context of toolstack patches which were attempting to work around the anomaly. The multiple `xxx' entries reflect 1. my lack of complete understanding 2. API defects which I think I have identified

[Xen-devel] [PATCH 1/3] libxc: Revert "do some retries in xc_cpupool_removecpu() for EBUSY case"

libxc may be called from within long-running daemons such as libvirt. In such a system this sleep would enable an uncooperative or buggy guest to block all toolstack operations for an extended period. Sadly, therefore, such a retry loop is not feasible without a lot of engineering which is probab

[Xen-devel] [PATCH 2/3] xen: hypercall docs annotations for xen_sysctl_cpupool_op

Signed-off-by: Ian Jackson CC: Jan Beulich CC: Tim Deegan --- xen/include/public/sysctl.h |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index 4596d20..0849908 100644 --- a/xen/include/public/sysctl.h +++ b/x

[Xen-devel] [PATCH 0/3] Revert xc cpupool retries and document anomaly

This small series is part of some cleanup for the CPUPOOL RMCPU EBUSY problem. The first patch in this series, a libxc patch, reverts what I think is simply a mistake. The second is trivial adds some annotations for the benefit of the hypercall API HTML docs generator. The third patch provides a

[Xen-devel] [PATCH] docs/arm64: update the documention for loading XSM support

From: Fu Wei This patch updates the documention for loading XSM by the module which lacks a specific compatible string. This mechanism has been added by the commit ca32012341f3de7d3975407fb963e6028f0d0c8b Signed-off-by: Fu Wei --- docs/misc/arm/device-tree/booting.txt | 17 + 1

Re: [Xen-devel] [PATCH] monitor: Rename vm_event_monitor_get_capabilities to arch_monitor_get_capabilities

On Thu, Apr 14, 2016 at 10:36 AM, Andrew Cooper wrote: > On 14/04/16 17:33, Tamas K Lengyel wrote: > > The monitor_get_capabilities check actually belongs to the monitor > subsystem so > > relocating and renaming it to sanitize the code's name and location. > > > > Signed-off-by: Tamas K Lengyel

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

>>> George Dunlap 04/14/16 6:20 PM >>> >On Thu, Apr 14, 2016 at 4:59 PM, Jan Beulich wrote: > George Dunlap 04/14/16 5:16 PM >>> >>>On the other hand, I think there's a bit of a faulty interpretation of >>>the procedure here. Jan reviewed the patch thoroughly and then acked >>>it; on the ba

[Xen-devel] Update SeaBIOS to include 8a0df3

Hello, I would like to request an update of the SeaBIOS repository to include the latest commits in the 1.9-stable branch. I'm only interested in commit 8a0df3, which is basically our current version (rel-1.9.1) plus a build fix for FreeBSD (or for objcopy implementations that are strict regard

Re: [Xen-devel] [PATCH v8.1 07/27] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup.

>>> Konrad Rzeszutek Wilk 04/14/16 12:04 AM >>> >+/* >+ * RCU locking. Additions are done either at startup (when there is only >+ * one CPU) or when all CPUs are running without IRQs. >+ * >+ * Deletions are big tricky. We do it when xSplicing (all CPUs running "big tricky"? >+ * without IRQs)

Re: [Xen-devel] [PATCH] monitor: Rename vm_event_monitor_get_capabilities to arch_monitor_get_capabilities

On 04/14/16 19:33, Tamas K Lengyel wrote: > The monitor_get_capabilities check actually belongs to the monitor subsystem > so > relocating and renaming it to sanitize the code's name and location. > > Signed-off-by: Tamas K Lengyel > Cc: Razvan Cojocaru > Cc: Keir Fraser > Cc: Jan Beulich > C

Re: [Xen-devel] [PATCH v8.1 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

>>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>> > @@ -460,6 +461,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) > u_sysctl) > ret = tmem_control(&op->u.tmem_op); > break; > > +case XEN_SYSCTL_xsplice_op: > +ret = xsplice_op(&op->u.xsplice); > +copyb

Re: [Xen-devel] [PATCH] monitor: Rename vm_event_monitor_get_capabilities to arch_monitor_get_capabilities

On 14/04/16 17:33, Tamas K Lengyel wrote: > The monitor_get_capabilities check actually belongs to the monitor subsystem > so > relocating and renaming it to sanitize the code's name and location. > > Signed-off-by: Tamas K Lengyel > Cc: Razvan Cojocaru > Cc: Keir Fraser > Cc: Jan Beulich > Cc

[Xen-devel] [PATCH] monitor: Rename vm_event_monitor_get_capabilities to arch_monitor_get_capabilities

The monitor_get_capabilities check actually belongs to the monitor subsystem so relocating and renaming it to sanitize the code's name and location. Signed-off-by: Tamas K Lengyel Cc: Razvan Cojocaru Cc: Keir Fraser Cc: Jan Beulich Cc: Andrew Cooper Cc: Stefano Stabellini Cc: Julien Grall -

Re: [Xen-devel] [PATCH v8.1 02/27] Revert "HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."

>>> Konrad Rzeszutek Wilk 04/14/16 12:04 AM >>> >This reverts commit 2716d875379d538c1dfccad78a99ca7db2e09f90. > >As it was decided that the existing XENVER hypercall - while having >grown organically over the years can still be expanded. > >Signed-off-by: Konrad Rzeszutek Wilk Requested-and-ack

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

>>> Razvan Cojocaru 04/14/16 6:00 PM >>> >On 04/14/2016 06:44 PM, Jan Beulich wrote: >> That's the performance effect on the hypervisor you talk about. But what >> about >> the guest, which all of the sudden gets another domain wide lock applied? > >Well, yes, there's bound to be some performance

Re: [Xen-devel] [PATCH v4 0/3] add hypercall option to temporarily pin a vcpu

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v4 0/3] add hypercall option to temporarily pin a vcpu"): > Applied. Damn, I see I am too late with my review. I will propose to revert some of this. :-/. Ian. ___ Xen-devel mailing list Xen-devel

Re: [Xen-devel] [PATCH v4 3/3] libxl: add force option for xl vcpu-pin

Juergen Gross writes ("[PATCH v4 3/3] libxl: add force option for xl vcpu-pin"): > In order to be able to undo a vcpu pin override in case of a kernel > driver error add a flag "-f" to the "xl vcpu-pin" command forcing the > hypervisor to undo the override. ... > +Specifying I<-f> or I<--force> wil

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

>>> Andrew Cooper 04/14/16 5:46 PM >>> >Short of having the instruction emulator convert any locked instruction >into a stub, I can't think of a solution which works for both emulated >and non-emulated instructions. That's my understanding too. Jan _

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

>>> Razvan Cojocaru 04/14/16 5:45 PM >>> >On 04/14/2016 06:40 PM, Jan Beulich wrote: >> To be honest, just having remembered that we do the write back for locked >> instructions using CMPXCHG, I'd first of all like to see a proper description >> of "the _whole_ issue". > >I believe at least part o

Re: [Xen-devel] [PATCH v4 2/3] libxl: print message how to recover from xl cpupool-cpu-remove errors

Juergen Gross writes ("[PATCH v4 2/3] libxl: print message how to recover from xl cpupool-cpu-remove errors"): > An error occurring when calling "xl cpupool-cpu-remove" might leave > the system in a state where a cpu is neither completely free nor in > a cpupool. Surely this is a bug. Can it not

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

Juergen Gross writes ("[PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case"): > The hypervisor might return EBUSY when trying to remove a cpu from a > cpupool when a domain running in this cpupool has pinned a vcpu > temporarily. Do some retries in this case, perhaps the

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

>>> George Dunlap 04/14/16 5:16 PM >>> >On the other hand, I think there's a bit of a faulty interpretation of >the procedure here. Jan reviewed the patch thoroughly and then acked >it; on the basis of that, Konrad legitimately checked it in. After it >was checked in Jan said, "I've changed my m

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

On 04/14/2016 06:44 PM, Jan Beulich wrote: > Razvan Cojocaru 04/14/16 7:57 AM >>> >> On 04/14/16 07:35, Jan Beulich wrote: >> Razvan Cojocaru 04/13/16 7:53 PM >>> @@ -1589,6 +1591,8 @@ x86_emulate( >>> >} >>> >done_prefixes: >>> > +ops->smp_lock(lock_prefix); +

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

Hi Everyone, On Fri, Apr 8, 2016 at 5:57 PM, Ian Campbell wrote: >> > In your patch for *Hacky* support for Jetsok-TK1 you said that you >> > were able to run guests on >> > Jetson-tk1 board with Xen. Can I know which kernel version you used as >> > dom0 (and possibly domU guests)? > > I'm afraid

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

On 14/04/16 16:40, Jan Beulich wrote: Razvan Cojocaru 04/14/16 1:43 PM >>> >> On 04/14/2016 01:35 PM, David Vrabel wrote: >>> On 13/04/16 13:26, Razvan Cojocaru wrote: LOCK-prefixed instructions are currenly allowed to run in parallel in x86_emulate(), which can lead the guest into

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

On 04/14/2016 06:40 PM, Jan Beulich wrote: Razvan Cojocaru 04/14/16 1:43 PM >>> >> On 04/14/2016 01:35 PM, David Vrabel wrote: >>> On 13/04/16 13:26, Razvan Cojocaru wrote: LOCK-prefixed instructions are currenly allowed to run in parallel in x86_emulate(), which can lead the guest

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

Razvan Cojocaru 04/14/16 7:57 AM >>> >On 04/14/16 07:35, Jan Beulich wrote: > Razvan Cojocaru 04/13/16 7:53 PM >>> >>> @@ -1589,6 +1591,8 @@ x86_emulate( >> >} >> >done_prefixes: >> > >>> +ops->smp_lock(lock_prefix); >>> + >> >if ( rex_prefix & REX_W ) >> >op_by

Re: [Xen-devel] Code Review Dashboard (nearly-complete)

On Thu, Apr 14, 2016 at 01:26:29PM +0100, Lars Kurth wrote: > Hi folks, > > the code review dashboard is nearly complete. The read-only version is > accessible via https://kibana.bitergia.com/xen > > We added plenty of documentation in the Documentation menu at the top, which > explains how the

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

On 04/14/2016 06:31 PM, Jan Beulich wrote: Razvan Cojocaru 04/14/16 10:50 AM >>> >> On 04/14/2016 07:35 AM, Jan Beulich wrote: --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -25,6 +25,8 @@ >>> >#include >>> >#include >>> > > +DEFINE_PERCPU_RWLOC

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

>>> Razvan Cojocaru 04/14/16 1:43 PM >>> >On 04/14/2016 01:35 PM, David Vrabel wrote: >> On 13/04/16 13:26, Razvan Cojocaru wrote: >>> LOCK-prefixed instructions are currenly allowed to run in parallel >>> in x86_emulate(), which can lead the guest into an undefined state. >>> This patch fixes the

Re: [Xen-devel] xl migrate regression in staging

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 took

Re: [Xen-devel] [PATCH V2] vm_event: Allow subscribing to write events for specific MSR-s

On 04/14/2016 06:33 PM, Tamas K Lengyel wrote: > > > On Thu, Apr 14, 2016 at 9:20 AM, Jan Beulich > wrote: > > >>> Razvan Cojocaru > 04/14/16 11:37 AM >>> > >On 04/13/2016 06:05 PM, Tamas K Lengyel wrote: > >> > >>

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

>>> Razvan Cojocaru 04/14/16 11:08 AM >>> >On 04/14/2016 08:56 AM, Razvan Cojocaru wrote: --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -112,6 +112,7 @@ >>> > >#include >>> > >#include >>> > >#include >> +#include >>> > >>> > This header shouldn't be include

Re: [Xen-devel] [PATCH V2] vm_event: Allow subscribing to write events for specific MSR-s

On Thu, Apr 14, 2016 at 9:20 AM, Jan Beulich wrote: > >>> Razvan Cojocaru 04/14/16 11:37 AM >>> > >On 04/13/2016 06:05 PM, Tamas K Lengyel wrote: > >> > >> Yea, well then we need to introduce a new struct with a new subop to > >> pass the bitmask. I guess its a lesson in ABI design to leave some

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

>>> Razvan Cojocaru 04/14/16 10:50 AM >>> >On 04/14/2016 07:35 AM, Jan Beulich wrote: >>> --- a/xen/arch/x86/hvm/emulate.c >>> >+++ b/xen/arch/x86/hvm/emulate.c >>> >@@ -25,6 +25,8 @@ >> >#include >> >#include >> > >>> >+DEFINE_PERCPU_RWLOCK_GLOBAL(emulate_locked_rwlock); >> You should try ha

Re: [Xen-devel] xl migrate regression in staging

On Thu, Apr 14, 2016 at 03:03:01PM +0200, 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 > migration target: Ready to receive domain. > Saving to migration stream new xl format (info 0x1/0x0/267

Re: [Xen-devel] [for-4.7 1/2] xen/bitops: Introduce macros to generate mask

>>> Julien Grall 04/14/16 5:08 PM >>> >On 14/04/16 15:56, Jan Beulich wrote: > Julien Grall 04/14/16 10:55 AM >>> >>> On 14/04/2016 05:01, Jan Beulich wrote: >>> Julien Grall 04/13/16 6:01 PM >>> > --- a/xen/include/xen/bitops.h > +++ b/xen/include/xen/bitops.h > @@ -3,6 +3,1

Re: [Xen-devel] [PATCH V2] vm_event: Allow subscribing to write events for specific MSR-s

>>> Razvan Cojocaru 04/14/16 11:37 AM >>> >On 04/13/2016 06:05 PM, Tamas K Lengyel wrote: >> >> Yea, well then we need to introduce a new struct with a new subop to >> pass the bitmask. I guess its a lesson in ABI design to leave some >> wiggle room for future-proofing it (my bad). So I guess we

Re: [Xen-devel] [PATCH v8.1] xSplice v1 design and implementation.

>>> Andrew Cooper 04/14/16 5:14 PM >>> >On 14/04/16 15:26, Konrad Rzeszutek Wilk wrote: >> @@ -312,8 +307,8 @@ struct xsplice_patch_func { >> }; >> >> >> -The size of the structure is 64 bytes or 52 bytes if compiled under 32-bit >> -hypervisors. >> +The size of the structure is 64 bytes on

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

On Wed, Apr 13, 2016 at 5:07 PM, Ian Jackson wrote: > Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested > Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring > XENVER_ but sane."): >> George Dunlap 04/12/16 11:58 AM >>> >> >2. Use the existing hypercall

Re: [Xen-devel] [PATCH v8.1] xSplice v1 design and implementation.

On 14/04/16 15:26, Konrad Rzeszutek Wilk wrote: > @@ -312,8 +307,8 @@ struct xsplice_patch_func { > }; > > > -The size of the structure is 64 bytes or 52 bytes if compiled under 32-bit > -hypervisors. > +The size of the structure is 64 bytes on 64-bit hypervisors. It will be > +52 on 32-bit

Re: [Xen-devel] [for-4.7 1/2] xen/bitops: Introduce macros to generate mask

Hi Jan, On 14/04/16 15:56, Jan Beulich wrote: Julien Grall 04/14/16 10:55 AM >>> On 14/04/2016 05:01, Jan Beulich wrote: Julien Grall 04/13/16 6:01 PM >>> --- a/xen/include/xen/bitops.h +++ b/xen/include/xen/bitops.h @@ -3,6 +3,17 @@ >#include > >/* + * Create a contiguous bitma

Re: [Xen-devel] [PATCH v8.1 22/27] XENVER_build_id/libxc: Provide ld-embedded build-id

On 04/13/2016 06:02 PM, Konrad Rzeszutek Wilk wrote: If the hypervisor was built with build-ids we can expose the build-id value to the toolstack (if it is not built with it will just return -ENODATA). This is a priviligied operation so only the controlling stack is able to request this. Signed-

Re: [Xen-devel] [PATCH v8.1 23/27] libxl: info: Display build_id of the hypervisor.

On Wed, Apr 13, 2016 at 06:02:04PM -0400, Konrad Rzeszutek Wilk wrote: > If the hypervisor is built with we will display it. > > Signed-off-by: Konrad Rzeszutek Wilk > --- > CC: Ian Jackson > CC: Wei Liu Acked-by: Wei Liu One nit below. > const libxl_version_info* libxl_get_version_info(li

  1   2   >