flight 32433 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32433/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Monday, November 24, 2014 11:13 PM
> To: Konrad Rzeszutek Wilk; Hu, Robert; ian.jack...@eu.citrix.com;
> ian.campb...@citrix.com
> Cc: xen-devel@lists.xen.org; jbeul...@suse.com
> Subject: Re: Is: Fixes
>>> On 12/17/2014 at 08:17 PM, in message
<20141217121750.gf1...@zion.uk.xensource.com>, Wei Liu
wrote:
> On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote:
> > Changes to V8:
> > * add an overview document, so that one can has a overall look
> > about the whole domain snapsh
>>> On 12/17/2014 at 08:28 PM, in message
<20141217122817.gg1...@zion.uk.xensource.com>, Wei Liu
wrote:
> On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote:
> > Changes to V8:
> > * xl won't manage snapshots, that means it won't maintain json files,
> > won't maintain snapsho
>>> On 12/17/2014 at 10:09 PM, in message
<20141217140958.gh1...@zion.uk.xensource.com>, Wei Liu
wrote:
> On Tue, Dec 16, 2014 at 02:32:57PM +0800, Chunyan Liu wrote:
> > Changes to V8:
> > * remove libxl_domain_snapshot_create/delete/revert API
> > * export disk snapshot functionality f
Hi,
I built and installed Xen from latest upstream Xen source code, but XL
always failed to work. Do you know what's going on here? My
environment is Lubuntu 14.04. Thanks in advance.
I always got "Permission denied" error.
root@kai-haswell:~# xl list
libxl: error: libxl.c:561:libxl_list_domain:
On 12/11/14 07:08, Ian Campbell wrote:
> On Tue, 2014-12-09 at 17:34 +, Jan Beulich wrote:
>> ... when "conring_size=" was specified on the command line. We can't
>> really do this as early as we would want to when the option was not
>> specified, as the default depends on knowing the system CP
flight 32429 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32429/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32418
Tests which did not succeed,
Julien Grall wrote on 2014-12-17:
> diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h index
> 5f295f3..6ace79d 100644
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -13,6 +13,7 @@
> #include #include #include
> +#include #include
>
> /* @@ -75,8 +76,19 @@ struct
flight 32432 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32432/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen 0a0e61c12101ca4fe48da63f09971bccd331819c
baseline version:
rumpuserxen 2c9e812bc368cb68a6249b99b1fb
== Hardware ==
HP DL380 G5 (2x Intel Xeon 5130)
== Dom0 ==
Arch Linux 64-bit
== Functionality tested ==
Building xen 4.5 RC4 from the tarball, installing it and booting it up
with Arch Linux as the Dom0.
== Comments ==
Xen support on Arch Linux needs a bit of love. Nummerous problems
getting the
On Wed, Dec 17, 2014 at 02:41:50PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 17, 2014 at 08:55:10AM +0100, Olaf Hering wrote:
> > On Tue, Dec 16, Konrad Rzeszutek Wilk wrote:
> >
> > > On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> > > > On Tue, Dec 16, konrad.w...@oracle.c
On Mon, Dec 15, 2014 at 11:13:06AM +, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> > > Hi Konrad,
> > >
> > > This doesn't seem to be applied yet, nor does it seem to have a
> > > releas
On Mon, Dec 15, 2014 at 10:02:31AM +, Ian Campbell wrote:
> On Mon, 2014-08-04 at 10:58 +0100, Ian Campbell wrote:
>
> Ping again. This issue has resurfaced in the Debian packaging of the 4.5
> rcs. I think we should fix this for 4.5, the risks are minimal.
Ah, the patch did not have 'for-xen
On Sat, Dec 13, 2014 at 09:23:48AM +, Juergen Schinker wrote:
> Subject: [TESTDAY] Test report Xen 4.5.0-RC3
>
> * Hardware:
> Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
> 32G Ram
>
> * Software:
> Debian Jessie
>
> * Guest operating systems:
> Debian Jessie
> * Fun
On Tue, Sep 2, 2014 at 12:06 PM, David Vrabel
wrote:
>
> From: Suresh Siddha
>
> For non-eager fpu mode, thread's fpu state is allocated during the first
> fpu usage (in the context of device not available exception). This can be
> a blocking call and hence we enable interrupts (which were origin
On Wed, Dec 17, 2014 at 08:55:10AM +0100, Olaf Hering wrote:
> On Tue, Dec 16, Konrad Rzeszutek Wilk wrote:
>
> > On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote:
> > > On Tue, Dec 16, konrad.w...@oracle.com wrote:
> > >
> > > > In terms of bugs, we have:
> > >
> > > ... systemd SELi
flight 32425 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32425/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 32149
Regressions which are
On 12/17/2014 12:28 PM, Jan Beulich wrote:
Boris Ostrovsky 12/17/14 4:10 PM >>>
+/* Need to clear last_vcpu in case it points to v */
+(void)cmpxchg(last, v, NULL);
In a (later) reply to v2 I had indicated that it doesn't seem safe to so here but
rely on an IPI in the other path alt
On 17/12/14 17:10, Jan Beulich wrote:
Julien Grall 12/17/14 1:55 PM >>>
>> On 17/12/14 10:05, Jan Beulich wrote:
> On 16.12.14 at 21:08, wrote:
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>>> Any reason not to simply use {read,write}_atomic() instead, which we
>>> already
2014-12-17 9:02 GMT+01:00 Olaf Hering :
> See the INSTALL file in the toplevel directory.
I can't believe I didn't see that file, makes me feel rather dumb. Thank you so
much for the pointer, it clears up a lot of things.
Julian Sivertsen
___
Xen-deve
>>> Boris Ostrovsky 12/17/14 4:10 PM >>>
>+/* Need to clear last_vcpu in case it points to v */
>+(void)cmpxchg(last, v, NULL);
In a (later) reply to v2 I had indicated that it doesn't seem safe to so here
but
rely on an IPI in the other path altering that value. Can you explain why you
flight 32423 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Tests which are failin
>>> Julien Grall 12/17/14 2:04 PM >>>
>On 17/12/14 10:46, Jan Beulich wrote:
> On 17.12.14 at 11:30, wrote:
>>> Having a generic way to describe device will really help ARM code (see
>>> IOMMU).
>>>
>>> If we don't have a such thing, we may need to duplicate quite a lots of
>>> code. Which
On Wed, Dec 17, 2014 at 11:53:41AM -0500, Boris Ostrovsky wrote:
> On 12/17/2014 11:21 AM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
> >>We need to make sure that last_vcpu is not pointing to VCPU whose
> >>VPMU is being destroyed. Otherwise we
>>> Julien Grall 12/17/14 1:55 PM >>>
>On 17/12/14 10:05, Jan Beulich wrote:
On 16.12.14 at 21:08, wrote:
>>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>>
>> Any reason not to simply use {read,write}_atomic() instead, which we
>> already have?
>
>To avoid modifying Linux drivers
On 12/17/2014 11:21 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.
We have to do
On Wed, Dec 17, 2014 at 04:34:41PM +, David Vrabel wrote:
> On 17/12/14 16:13, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
> >>
> >> On 12/16/2014 06:32 PM, Roger Pau Monné wrote:
> >>> El 16/12/14 a les 11.11, Bob Liu ha escrit:
> The default
On 17/12/14 16:13, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
>>
>> On 12/16/2014 06:32 PM, Roger Pau Monné wrote:
>>> El 16/12/14 a les 11.11, Bob Liu ha escrit:
The default maximum value of segments in indirect requests was 32, IO
operations
On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
>
> We have to do this atomically since otherwise there is a (s
On Wed, Dec 17, 2014 at 04:18:58PM +0800, Bob Liu wrote:
>
> On 12/16/2014 06:32 PM, Roger Pau Monné wrote:
> > El 16/12/14 a les 11.11, Bob Liu ha escrit:
> >> The default maximum value of segments in indirect requests was 32, IO
> >> operations with bigger block size(>32*4k) would be split and p
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/disk_read.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
index 33aacdd..e147e90 100644
--- a/stubdom/vtpmmgr/disk_read.c
+++ b/stubdom/vtpmmgr/disk_read.c
call the TPM 2.0 various registers that allow communication between
the TPM 2.0 and platform hardware and software. TPM2_SelfTest causes
the TPM 2.0 to perform a test of its capabilities.
Signed-off-by: Quan Xu
---
extras/mini-os/include/tpm_tis.h | 1 +
extras/mini-os/tpm_tis.c | 156
'vtpmmgr on TPM 2.0'
Signed-off-by: Quan Xu
---
docs/misc/vtpmmgr.txt | 150 +-
1 file changed, 149 insertions(+), 1 deletion(-)
diff --git a/docs/misc/vtpmmgr.txt b/docs/misc/vtpmmgr.txt
index 026c52b..1f1af4d 100644
--- a/docs/misc/vtpmmgr.txt
+
These TPM 2.0 Exposed APIs for the Mini-os to access TPM 2.0
hardware.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/Makefile | 2 +-
stubdom/vtpmmgr/tpm2.c | 455 +++
stubdom/vtpmmgr/tpm2.h | 104 +++
3 files changed, 560 insertions(+), 1 d
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/disk_write.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/stubdom/vtpmmgr/disk_write.c b/stubdom/vtpmmgr/disk_write.c
index 4c825c5..ab15a9a 100644
--- a/stubdom/vtpmmgr/disk_write.c
+++ b/stubdom/vtpmmgr/disk_write.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/init.c | 34 ++
stubdom/vtpmmgr/tpm2_types.h | 2 ++
stubdom/vtpmmgr/vtpmmgr.h| 1 +
3 files changed, 37 insertions(+)
diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 7e115a5..8bab764 100644
These data is for the Mini-os to access TPM 2.0 hardware.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/vtpmmgr.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 2d9d153..0d0c604 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/st
TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type o
Add TPM 2.0 data structures on Trusted Platform Module Library Part 2:
Structures and Trust Platform Module Library Part 3: Commands.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/tpm2_types.h | 978 +++
1 file changed, 978 insertions(+)
create mode 100644 s
Bind data with TPM2_RSA_Encrypt, which performs RSA encryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1). If the
scheme of keyHandle is TPM_ALG_NULL, then the caller may use inScheme
to specify the padding scheme.
Unbind data with TPM2_RSA_Decrypt, which performs RSA decryp
TPM2_Create is used to create an object that can be loaded into a
TPM using TPM2_Load(). If the command completes successfully, the
TPM will create the new object and return the object’s creation.
data (creationData), its public area (outPublic), and its encrypted
sensitive area (outPrivate). Prese
Make vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
extra="tpm2"
..
to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
example,
vtpm-stubdom domain configuration on TPM 2.0:
kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
memory=16
disk=["file:/var
Add TPM 2.0 data structure marshal for packing and unpacking TPM
2.0 data structures.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/tpm2_marshal.h | 673 +
1 file changed, 673 insertions(+)
create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h
diff --git a/stub
This series of patch enable the virtual Trusted Platform Module (vTPM)
subsystem for Xen on TPM 2.0.
Noted, functionality for a virtual guest operating system (a DomU) is still
TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
TPM 2.0 is not backward compatible with TPM 1
Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/init.c| 109 ++
stubdom/vtp
A subsequent patch will add an inline routine to vpmu.h that will call
vpmu_load().
This inline will try to access vcpu->vpmu which is not possible since struct
vcpu may not be fully defined at that point. So we will have that inline pass
vpmu pointer to vpmu_load() instead.
This change slightly
Add support for using NMIs as PMU interrupts to allow profiling hypervisor
when interrupts are disabled.
Most of processing is still performed by vpmu_do_interrupt(). However, since
certain operations are not NMI-safe we defer them to a softint that
vpmu_do_interrupt()
will schedule:
* For PV gue
The two routines share most of their logic.
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/vpmu.c| 69 --
xen/include/asm-x86/hvm/vpm
Since PMU is now not HVM specific we can move VPMU-related files up from
arch/x86/hvm/ directory.
Specifically:
arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c
arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c
arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c
include/asm-x86/h
Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
Rev
Add support for handling PMU interrupts for PV guests.
VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hyper
With this patch return value of 1 of vpmu_do_msr() will now indicate whether an
error was encountered during MSR processing (instead of stating that the access
was to a VPMU register).
As part of this patch we also check for validity of certain MSR accesses right
when we determine which register i
There is a possibility that we set VPMU_CONTEXT_SAVE on VPMU context in
vpmu_load() and never clear it (because vpmu_save_force() will see
VPMU_CONTEXT_LOADED bit clear, which is possible on AMD processors)
The problem is that amd_vpmu_save() assumes that if VPMU_CONTEXT_SAVE is set
then (1) we ne
Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.
Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets
The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
forever.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/vpmu.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 1df74c2..b4
Introduce vpmu_are_all_set that allows testing multiple bits at once. Convert
macros
into inlines for better compiler checking.
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/vmx/v
Code for initializing/tearing down PMU for PV guests
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
tools/flask/policy/policy/modules/xen/xen.te | 4 ++
xen/arch/x86/domain.
In preparation for making VPMU code shared with PV make sure that we we update
MSR bitmaps only for HVM/PVH guests
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/svm/vpmu.c |
Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector should
be updated. Instead, handle guest's APIC_LVTPC accesses and write what the guest
explicitly wanted.
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch
Save VPMU state during context switch for both HVM and PV(H) guests.
A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call
context_
Export Xen's symbols as {} triplet via new XENPF_get_symbol
hypercall
Signed-off-by: Boris Ostrovsky
Acked-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/platform_hypercall.c | 28 +++
xen/common/sym
MSR_CORE_PERF_GLOBAL_CTRL register should be set zero initially. It is up to
the guest to set it so that counters are enabled.
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/vmx/vpmu_core2.c | 11 +--
1 file c
Intercept accesses to PMU MSRs and process them in VPMU module. If vpmu ops
for VCPU are not initialized (which is the case, for example, for PV guests that
are not "VPMU-enlightened") access to MSRs will return failure.
Dump VPMU state for all domains (HVM and PV) when requested.
Signed-off-by:
Remove struct pmumsr and core2_pmu_enable. Replace static MSR structures with
fields in core2_vpmu_context.
Call core2_get_pmc_count() once, during initialization.
Properly clean up when core2_vpmu_alloc_resource() fails.
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Dietmar
Move some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.
Signed-off-by: Boris Ostrovsky
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/svm/vpmu.c | 115 +---
xen/arch/x86/hvm/vmx/vpmu_core2.c | 154 ++
Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF: PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
can profile itself
vmx_add_host_load_msr() and vmx_add_guest_msr() share fair amount of code. Merge
them to simplify code maintenance.
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/vmx/vmcs.c
vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/include/asm-x86/domain.h | 2 ++
xen/include/asm-x86/hvm/vcpu.h
Version 16 of PV(H) PMU patches.
* Many changes in VPMU mode patch (#13):
* Replaced arguments to some vpmu routines (vcpu -> vpmu). New patch (#12)
* Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear
MSR bitmaps). This routine may be called in context switch
(vpmu_switc
flight 32424 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 32392
Regressions which ar
The domain vgic lock is used uninitialized.
Signed-off-by: Julien Grall
---
This is a bug fix for Xen 4.5 and Xen 4.4. The vgic lock is used
unitialized. Luckily we only use the field "raw" which is reset to 0
during the domain allocation.
There is no harm to apply for Xen 4.5 b
On 15/12/14 16:07, Julien Grall wrote:
> On 15/12/14 15:32, Stefano Stabellini wrote:
>> On Fri, 12 Dec 2014, Julien Grall wrote:
>>> +spin_lock_init(&d->arch.vgic.lock);
>>
>> you should probably explain in the commit message the reason why you are
>> making changes to the vgic lock
>
> Actua
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.
We have to do this atomically since otherwise there is a (somewhat
theoretical) chance that between test and subsequent clearing
of la
On Tue, Dec 16, 2014 at 01:47:35PM +, Alex Bligh wrote:
> I am running Ubuntu's xen 4.4 (4.4.1-0ubuntu0.14.04.2), but creating VMs
> with libxl.
>
> When I do a 'shutdown -r' or similar with no VMs running, dom0 reboots
> fine. When I do this with one or more VMs running, I get:
>
> "INFO: ta
On Tue, Dec 16, 2014 at 02:32:57PM +0800, Chunyan Liu wrote:
> Changes to V8:
> * remove libxl_domain_snapshot_create/delete/revert API
> * export disk snapshot functionality for both xl and libvirt usage
>
> ===
> Libxl/l
On 10/12/14 14:12, David Vrabel wrote:
> On 10/12/14 13:42, John wrote:
>> David,
>>
>> This patch you put into 3.18.0 appears to break the latest version of
>> stubdomains. I found this out today when I tried to update a machine to
>> 3.18.0 and all of the domUs crashed on start with the dmesg out
Hi Jan,
On 17/12/14 10:46, Jan Beulich wrote:
On 17.12.14 at 11:30, wrote:
>> On 17/12/2014 10:16, Jan Beulich wrote:
>> On 16.12.14 at 21:08, wrote:
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -2,6 +2,7 @@ obj-y += bitmap.o
obj-y += core_parking.o
Hi Jan,
On 17/12/14 10:05, Jan Beulich wrote:
On 16.12.14 at 21:08, wrote:
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -90,4 +90,18 @@
>> __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
>> (typeof(ptr)) (__ptr + (off)); })
>>
>> +/*
>> + * Prevent
El 16/12/14 a les 18.59, Andrew Cooper ha escrit:
> On 16/12/14 17:34, Roger Pau Monné wrote:
>> Hello,
>>
>> While working on the FreeBSD PVH Dom0 port I've realized that IO-APIC
>> interrupts get stuck in a very strange state very easily with the
>> current PIRQ implementation that I'm using on
Hi Jan,
On 17/12/14 10:40, Jan Beulich wrote:
On 17.12.14 at 11:24, wrote:
>> On 17/12/2014 10:11, Andrew Cooper wrote:
>>> On 16/12/14 23:37, Julien Grall wrote:
>>> Introducing a new bugframe is precicely what I meant by "this doesn't
>>> look hard". x86 currently has one more bugframe th
On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote:
> Changes to V8:
> * xl won't manage snapshots, that means it won't maintain json files,
> won't maintain snapshot chain relationship, and then as a result
> won't take care of deleting snapshot and listing snapshots.
> * remo
flight 32422 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32422/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 5 xen-boot fail REGR. vs. 32386
test-amd64-i386-xl
On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote:
> Changes to V8:
> * add an overview document, so that one can has a overall look
> about the whole domain snapshot work, limits, requirements,
> how to do, etc.
>
> =
El 16/12/14 a les 18.59, Andrew Cooper ha escrit:
> On 16/12/14 17:34, Roger Pau Monné wrote:
>> Hello,
>>
>> While working on the FreeBSD PVH Dom0 port I've realized that IO-APIC
>> interrupts get stuck in a very strange state very easily with the
>> current PIRQ implementation that I'm using on
On Tue, Dec 16, 2014 at 09:38:09AM +, Jan Beulich wrote:
> >>> On 16.12.14 at 09:55, wrote:
> > Any comments from you? It would be greatly appreciated if you can look
> > at this when you have time. Your comments are always important to me :)
>
> I don't think I have to say much here:
>
> >
On 16/12/14 23:04, Christopher S. Aker wrote:
> On Dec 15, 2014, at 6:11 AM, David Vrabel wrote:
>> On 11/12/14 15:12, Christopher S. Aker wrote:
>>> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
>>> Dom0: 3.17.4
>>>
>>> Things go badly after a day or four. We've hit this on a numb
>>> On 17.12.14 at 11:30, wrote:
> On 17/12/2014 10:16, Jan Beulich wrote:
> On 16.12.14 at 21:08, wrote:
>>> --- a/xen/common/Makefile
>>> +++ b/xen/common/Makefile
>>> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>>> obj-y += core_parking.o
>>> obj-y += cpu.o
>>> obj-y += cpupool.o
>>> +obj-y +=
>>> On 17.12.14 at 11:24, wrote:
> On 17/12/2014 10:11, Andrew Cooper wrote:
>> On 16/12/14 23:37, Julien Grall wrote:
>> Introducing a new bugframe is precicely what I meant by "this doesn't
>> look hard". x86 currently has one more bugframe than arm, being
>> BUGFRAME_run_fn.
>
> And how do yo
On 17/12/14 10:24, Julien Grall wrote:
>
>
> On 17/12/2014 10:11, Andrew Cooper wrote:
>> On 16/12/14 23:37, Julien Grall wrote:
>> Introducing a new bugframe is precicely what I meant by "this doesn't
>> look hard". x86 currently has one more bugframe than arm, being
>> BUGFRAME_run_fn.
>
> And h
Hi Jan,
On 17/12/2014 10:16, Jan Beulich wrote:
On 16.12.14 at 21:08, wrote:
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -2,6 +2,7 @@ obj-y += bitmap.o
obj-y += core_parking.o
obj-y += cpu.o
obj-y += cpupool.o
+obj-y += device.o
Shouldn't this instead be two lines, one using
On 17/12/14 09:50, Juergen Gross wrote:
> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
> use the auto generated symbol list.
>
> This also corrects the wrong address of xen_hypercall_mca which was
> located 32 bytes higher than it should.
>
> Symbol addresses have been verif
On 17/12/14 09:50, Juergen Gross wrote:
> Today there are several places in the kernel which build tables
> containing one entry for each possible Xen hypercall. Create an
> infrastructure to be able to generate these tables at build time.
Reviewed-by: David Vrabel
David
___
On 17/12/2014 10:11, Andrew Cooper wrote:
On 16/12/14 23:37, Julien Grall wrote:
Introducing a new bugframe is precicely what I meant by "this doesn't
look hard". x86 currently has one more bugframe than arm, being
BUGFRAME_run_fn.
And how do you pass the pointer of the function? As I said,
>>> On 17.12.14 at 11:08, wrote:
> On 17/12/14 09:59, Jan Beulich wrote:
> On 16.12.14 at 21:28, wrote:
>>> On 16/12/14 19:33, Mihai Donțu wrote:
+static bool_t __xmem_pool_check_locked(const char *file, int line,
+ const struct xmem_pool *pool)
>>> On 16.12.14 at 21:08, wrote:
> @@ -123,22 +124,17 @@ struct page_info;
> struct iommu_ops {
> int (*init)(struct domain *d);
> void (*hwdom_init)(struct domain *d);
> -#ifdef HAS_PCI
> -int (*add_device)(u8 devfn, struct pci_dev *);
> -int (*enable_device)(struct pci_dev *pd
>>> On 16.12.14 at 21:08, wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -2,6 +2,7 @@ obj-y += bitmap.o
> obj-y += core_parking.o
> obj-y += cpu.o
> obj-y += cpupool.o
> +obj-y += device.o
Shouldn't this instead be two lines, one using HAS_PCI and the second
HAS_DEVICE_TRE
On 16/12/14 23:37, Julien Grall wrote:
>
>
> On 16/12/2014 23:26, Andrew Cooper wrote:
>> On 16/12/2014 23:06, Julien Grall wrote:
>>> Hi,
>>>
>>> On 16/12/2014 20:28, Andrew Cooper wrote:
I suspect you also would be better, and certainly more brief, with
"run_in_exception_handler(show_st
On 17/12/14 09:59, Jan Beulich wrote:
On 16.12.14 at 21:28, wrote:
>> On 16/12/14 19:33, Mihai Donțu wrote:
>>> +static bool_t __xmem_pool_check_locked(const char *file, int line,
>>> + const struct xmem_pool *pool)
>>> +{
>>> +unsigned int i;
>>> +
>>> On 16.12.14 at 21:08, wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -90,4 +90,18 @@
> __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> (typeof(ptr)) (__ptr + (off)); })
>
> +/*
> + * Prevent the compiler from merging or refetching accesses. The c
1 - 100 of 110 matches
Mail list logo
