The legacy toolstack record as implemented in libxl turns out not to
be 32/64bit safe. As migration v2 has not shipped yet, take this
opportunity to adjust the specification and fix the incompatibility.
Libxl shall loose all knowledge of the old toolstack blob and use this
EMULATOR_XENSTORE_DATA
No functional change. It is not used any more.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
Acked-by: Wei Liu wei.l...@citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
---
tools/libxl/libxl_dom.c | 223
Read and write toolstack information using the new
EMULATOR_XENSTORE_DATA record, and have the conversion script take care
of the old format.
The entire libxc and libxl migration v2 streams are now bitness-neutral
in their records.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by:
Previously, in the case of an error causing a call to
libxl__conversion_helper_abort() on a stream without legacy conversion,
libxl would fall over a NULL pointer because chs-ao was not set up.
Arrange for all -ao's to be set up at _init() time, by having each
_init() function assert that their
The new EMULATOR_XENSTORE_DATA content is a sequence of NUL terminated
key/value strings, with the key relative to the device model's xenstore
tree.
A sample might look like (as decoded by verify-stream-v2):
Emulator Xenstore Data (Qemu Upstream, idx 0)
'physmap/1f0/start_addr' =
With the newly specified EMULATOR_XENSTORE_DATA record, there are two
libxl records with an emulator subheader. Refactor the existing code to
make future additions easier, and rename some functions for consistency
with the new scheme.
* Calculate the subheader at stream start time, rather than
The libxl blob for toolstack records was not 32/64bit safe. In 64bit
builds, it had an extra 4 bytes of padding due to alignment, and because
of the pointer arithmatic used to build it, leaked 4 bytes of libxl heap
into the stream.
Respecify XENSTORE_DATA as EMULATOR_XENSTORE_DATA and take
Hi Vijay,
On 31/07/15 08:01, Vijay Kilari wrote:
The vITS will only expose 1 ITS to dom0. So there is no need to try to
allocate memory in order to expose all the ITS.
We can extend vits_setup_hw if we ever want to support more ITS in the
future.
Furthermore I'd like to see all the ITS
When doing migration via the QMP command xen_save_devices_state, the
current runstate is not store into the global state section. Also the
current runstate is not the one we want on the receiver side.
During migration, the Xen toolstack paused QEMU before save the devices
state. Also, the
This fix migration from the same QEMU version and from previous QEMU
version.
From the global state section, we don't need runstate with Xen. Right now,
the way the Xen toolstack knows when QEMU is ready is when QEMU reach
running runstate.
The configuration section and the section footers are
This adds the configuration section in the vmstate saved by
xen_save_devices_state.
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index 6071215..b3f605c 100644
---
The following changes since commit 2a3612ccc1fa9cea77bd193afbfe21c77e7e91ef:
Merge remote-tracking branch
'remotes/stefanha/tags/rtl8139-cplus-tx-input-validation-pull-request' into
staging (2015-08-03 13:09:10 +0100)
are available in the git repository at:
Determine if a fraglist is needed in the tx path, and allocate it if
necessary before setting up the copy and map operations.
Otherwise, undoing the copy and map operations is tricky.
This fixes a use-after-free: if allocating the fraglist failed, the copy
and map operations that had been set up
On Fri, Jul 31, 2015 at 08:58:47AM +0100, Ian Campbell wrote:
On Thu, 2015-07-30 at 16:32 -0500, Doug Goldstein wrote:
I'm not sure what I can use to identify the system early on. I see the
EFI FW vendor and EFI FW revision. I'm not sure if that would be
enough. In the case of using that
Hi,
We've spotted several regression which prevent migration with Xen using the
same version of QEMU or from a previous version of QEMU (tryied with 2.2).
Regression have been introduce by at least:
- df4b1024526cae3479da3492d6371fd4a7324a03
migration: create new section to store global state
On Mon, 2015-08-03 at 14:54 +0100, Andrew Cooper wrote:
On 03/08/15 14:35, Ben Catterall wrote:
Hi all,
I am working on an x86 proof-of-concept to evaluate if it is feasible
to move device models and x86 emulation code for HVM guests into a
de-privileged context.
I was hoping to
pci_piix3_xen_ide_unplug should completely unhook the unplugged
IDEDevice from the corresponding BlockBackend, otherwise the next call
to release_drive will try to detach the drive again.
Suggested-by: Kevin Wolf kw...@redhat.com
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
On Mon, 3 Aug 2015, Anthony PERARD wrote:
This adds the configuration section in the vmstate saved by
xen_save_devices_state.
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
It doesn't seem to me that this patch is actually necessary to fix the
issue, is that right?
If that is the
On Mon, Aug 03, 2015 at 03:48:18PM +0100, Stefano Stabellini wrote:
On Mon, 3 Aug 2015, Anthony PERARD wrote:
This adds the configuration section in the vmstate saved by
xen_save_devices_state.
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
It doesn't seem to me that this
On Fri, 2015-07-24 at 17:28 +0100, Ian Campbell wrote:
@@ -191,6 +208,27 @@ create_build_jobs () {
revision_ovmf=$REVISION_OVMF
done
+if [ x$want_prevxen = xy ] ; then
+if [ x$REVISION_PREVXEN = x ] ; then
+echo 2 prevxen ?; exit 1
+
On (Mon) 03 Aug 2015 [15:53:57], Stefano Stabellini wrote:
On Mon, 3 Aug 2015, Anthony PERARD wrote:
When doing migration via the QMP command xen_save_devices_state, the
current runstate is not store into the global state section. Also the
current runstate is not the one we want on the
On (Mon) 03 Aug 2015 [15:29:18], Anthony PERARD wrote:
Hi,
We've spotted several regression which prevent migration with Xen using the
same version of QEMU or from a previous version of QEMU (tryied with 2.2).
Regression have been introduce by at least:
-
On Mon, 3 Aug 2015, Fabio Fantoni wrote:
Some years ago the support/improvement of hvm domUsseemed neglected, recently
seems to be good.
Qemu upstream when I started using early versions from the 1.2 was neglected
but now it seems early to be quite used, tested and considered, thanks to all
On Mon, 3 Aug 2015, Amit Shah wrote:
On (Mon) 03 Aug 2015 [15:29:18], Anthony PERARD wrote:
Hi,
We've spotted several regression which prevent migration with Xen using the
same version of QEMU or from a previous version of QEMU (tryied with 2.2).
Regression have been introduce by at
flight 60203 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60203/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 60155 REGR.
vs. 58880
From: Anthony PERARD anthony.per...@citrix.com
When doing migration via the QMP command xen_save_devices_state, the
current runstate is not store into the global state section. Also the
current runstate is not the one we want on the receiver side.
During migration, the Xen toolstack paused QEMU
From: Anthony PERARD anthony.per...@citrix.com
This fix migration from the same QEMU version and from previous QEMU
version.
From the global state section, we don't need runstate with Xen. Right now,
the way the Xen toolstack knows when QEMU is ready is when QEMU reach
running runstate.
The
On Mon, Aug 03, 2015 at 09:37:07PM +0530, Amit Shah wrote:
On (Mon) 03 Aug 2015 [15:29:18], Anthony PERARD wrote:
Hi,
We've spotted several regression which prevent migration with Xen using the
same version of QEMU or from a previous version of QEMU (tryied with 2.2).
Regression
From: Ting-Wei Lan [mailto:lant...@gmail.com]
Sent: Friday, July 31, 2015 4:38 PM
Tian, Kevin 於 西元2015年07月31日 09:26 寫道:
From: Ting-Wei Lan [mailto:lant...@gmail.com]
Sent: Sunday, July 26, 2015 12:58 AM
When using Linux = 3.19 (commit 47591df) as dom0 on some Intel Ironlake
devices,
On 03/08/2015 20:54, Boris Ostrovsky wrote:
On 08/03/2015 03:34 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The
On Mon, Aug 03, 2015 at 03:35:15PM -0700, Kees Cook wrote:
Yay for perm disable! Thank you! :)
Andy would like to see this evolve towards something possibly
more complete and/or generic. I think this needs more thoughts
and that we should possibly stick to 0/1 for now and decide how
we want to
flight 60205 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60205/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
58380
On Mon, Aug 3, 2015 at 4:19 PM, Willy Tarreau w...@1wt.eu wrote:
On Mon, Aug 03, 2015 at 03:35:15PM -0700, Kees Cook wrote:
Yay for perm disable! Thank you! :)
Andy would like to see this evolve towards something possibly
more complete and/or generic. I think this needs more thoughts
and
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau w...@1wt.eu wrote:
For distros who prefer not to take the risk of completely disabling the
modify_ldt syscall using CONFIG_MODIFY_LDT_SYSCALL, this patch adds a
sysctl to enable, temporarily disable, or permanently disable it at
runtime, and
On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote:
P.P.P.S. Who thought that IRET faults unmasking NMIs made any sense
whatsoever when NMIs run on an IST stack? Seriously, people?
What happened with asking Intel for a sane IRET-NG?
Should be relatively easy - take the current
From: Shannon Zhao shannon.z...@linaro.org
Shannon Zhao (2):
ACPI/table: Always count matched and successfully parsed entries
ACPI/table: Make acpi_table_init return meaningful value
xen/drivers/acpi/tables.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
--
2.0.4
From: Shannon Zhao shannon.z...@linaro.org
If ACPI fails to initialize tables, it should return one meaningful
value to tell the caller to diable acpi.
Signed-off-by: Shannon Zhao shannon.z...@linaro.org
---
xen/drivers/acpi/tables.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Ross Lagerwall ross.lagerw...@citrix.com
Date: Mon, 3 Aug 2015 15:38:03 +0100
Determine if a fraglist is needed in the tx path, and allocate it if
necessary before setting up the copy and map operations.
Otherwise, undoing the copy and map operations is tricky.
This fixes a
From: Shannon Zhao shannon.z...@linaro.org
acpi_parse_entries() allows to traverse all available table entries (aka
subtables) by passing max_entries parameter equal to 0, but since its count
variable is only incremented if max_entries is not 0, the function always
returns 0 for max_entries equal
On Sat, 25 Jul 2015, Julien Grall wrote:
the xen_platform_pci int. makes the x86 version of
xen_pci_platform_unplug static.
Therefore we don't need anymore to define a dummy xen_pci_platform_unplug
for ARM.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Stefano Stabellini
On Sat, 2015-08-01 at 06:21 +, Kun Cheng wrote:
I've looked into those settings and vcpu affinities on Xen wiki page.
However what I'm trying to argue about is memory should be migrated
when vcpus are moved to another node.
I still struggle a bit to understand what you mean. It's exactly
On Fri, 2015-07-31 at 10:10 -0400, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 30, 2015 at 05:10:10PM +0200, Roger Pau Monné wrote:
El 30/07/15 a les 17.04, Wei Liu ha escrit:
Hi all
Here are some bugs that I'm aware of. The name after a item is the
person who is working on it.
On Mon, 3 Aug 2015, Amit Shah wrote:
On (Fri) 31 Jul 2015 [10:59:47], Stefano Stabellini wrote:
On Thu, 30 Jul 2015, Stefano Stabellini wrote:
On Thu, 30 Jul 2015, Juan Quintela wrote:
Anthony PERARD anthony.per...@citrix.com wrote:
This is a critical issue for Xen as migration
On Mon, 2015-08-03 at 01:36 +, Wu, Feng wrote:
-Original Message-
From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
It's safe in any case. In fact, the spinlock will prevent both the
vcpu's processor to schedule, as well as any other processors to steal
the waking
On Sat, Aug 1, 2015 at 9:21 PM, Julien Grall julien.gr...@citrix.com wrote:
Hi Vijay,
On 01/08/2015 11:25, Vijay Kilari wrote:
I guess you mean vgic_enable_irqs? And no what you've implemented is
definitely not the same as vgic_enable_irqs.
vgic_enable_irqs is locking the pending_irq
TL;DR: I've dropped a stop file for:
xen-4.2-testing + qemu-upstream-4.2-testing
xen-4.3-testing + qemu-upstream-4.3-testing
while we figure this out. I also killed flight 60373 (xen-4.2-testing).
Recently the amount of log files collected by osstest seems to have
rocketed for some flights.
On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel david.vra...@citrix.com
wrote:
On 31/07/15 11:24, Stefano Stabellini wrote:
This is a Linux Dom0 crash on x86 (Dell PowerEdge R320, Xeon E5-2450),
CC'ing relevant people. As you can see from the links below the crash
is:
[ 253.619326] Call
On Mon, 3 Aug 2015, Anthony PERARD wrote:
This fix migration from the same QEMU version and from previous QEMU
version.
From the global state section, we don't need runstate with Xen. Right now,
the way the Xen toolstack knows when QEMU is ready is when QEMU reach
running runstate.
The
On Mon, 3 Aug 2015, Anthony PERARD wrote:
When doing migration via the QMP command xen_save_devices_state, the
current runstate is not store into the global state section. Also the
current runstate is not the one we want on the receiver side.
During migration, the Xen toolstack paused QEMU
On Mon, 2015-08-03 at 15:34 +0100, Ian Campbell wrote:
On Mon, 2015-08-03 at 14:54 +0100, Andrew Cooper wrote:
I think it would be entirely reasonable to have a deadline for a single
execution of depriv mode, after which the domain is declared malicious
and killed.
I think this could
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The 'final_levels' of patch ids have been obtained empirically.
Refer bug
On Fri, 31 Jul 2015, Ian Jackson wrote:
(Please disregard my previous incomplete mail about this patch. This
reply has all of my comments. Thanks.)
Stefano Stabellini writes ([PATCH v8 1/2] OSSTEST: introduce a raisin build
test):
Make divide_xen_build common between ts-raisin-build and
On Fri, 31 Jul 2015, Ian Jackson wrote:
Stefano Stabellini writes ([PATCH v8 2/2] OSSTest: push successful raisin
builds):
Determine the most recent raisin revision that needs to be tested,
by comparing the staging with the master branches. Push to
raisin.git:master when the build is
On 3 August 2015 at 17:19, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
The following changes since commit f60c87154ac722c528fd5582f7137914a93c5eec:
configure: Drop vnc-ws feature from help text (2015-08-03 15:32:17 +0100)
are available in the git repository at:
On 8/3/2015 12:22 PM, Boris Ostrovsky wrote:
On 08/03/2015 12:35 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The
This is the second version. It adds a strategy for the sysctls so that we
can reject any change to a value that was already negative. This way it's
possible to disable modify_ldt temporarily or permanently (eg: lock down a
server) as suggested by Kees.
Willy Tarreau (2):
sysctl: add a new
The new function is proc_dointvec_minmax_negperm(), it refuses to change
the value if the current one is already negative. This will be used to
lock down some settings such as sensitive system calls.
Signed-off-by: Willy Tarreau w...@1wt.eu
---
kernel/sysctl.c | 36
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau w...@1wt.eu wrote:
The new function is proc_dointvec_minmax_negperm(), it refuses to change
the value if the current one is already negative. This will be used to
lock down some settings such as sensitive system calls.
Signed-off-by: Willy
On 8/3/2015 1:18 PM, Boris Ostrovsky wrote:
On 08/03/2015 01:52 PM, Aravind Gopalakrishnan wrote:
On 8/3/2015 12:22 PM, Boris Ostrovsky wrote:
On 08/03/2015 12:35 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau w...@1wt.eu wrote:
For distros who prefer not to take the risk of completely disabling the
modify_ldt syscall using CONFIG_MODIFY_LDT_SYSCALL, this patch adds a
sysctl to enable, temporarily disable, or permanently disable it at
runtime, and
On Mon, Aug 03, 2015 at 11:33:30AM -0700, Andy Lutomirski wrote:
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau w...@1wt.eu wrote:
The new function is proc_dointvec_minmax_negperm(), it refuses to change
the value if the current one is already negative. This will be used to
lock down some
flight 60207 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60207/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate fail REGR. vs. 58383
On 8/3/2015 2:00 PM, Boris Ostrovsky wrote:
On 08/03/2015 02:42 PM, Aravind Gopalakrishnan wrote:
Ah. I see what you mean.
I can think of two ways around this-
a. I can move the check_final_patch_levels() call to
apply_microcode(). That way, our initial checks in microcode_fits()
would have
On Mon, Aug 03, 2015 at 12:06:12PM -0700, Andy Lutomirski wrote:
On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau w...@1wt.eu wrote:
(...)
I feel like it's probably part of a larger project then. Do you think
we should step back and only support 0/1 for now ? I also have the
patch available.
On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote:
I'm not entirely convinced that the lock bit should work this way. At
some point, we might want a setting for 32-bit only or even 32-bit,
present, not non-conforming only (like we do unconditionally for
set_thread_area). When
On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau w...@1wt.eu wrote:
On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote:
I'm not entirely convinced that the lock bit should work this way. At
some point, we might want a setting for 32-bit only or even 32-bit,
present, not
On 08/03/2015 02:42 PM, Aravind Gopalakrishnan wrote:
Ah. I see what you mean.
I can think of two ways around this-
a. I can move the check_final_patch_levels() call to
apply_microcode(). That way, our initial checks in microcode_fits()
would have already checked equivalent cpu IDs so we know
On 24/07/15 17:54, Roger Pau Monné wrote:
struct vcpu_hvm_context {
/* 16bit fields of the strucutre will be used. */
#define _VCPUHVM_MODE_16B 0
#define VCPUHVM_MODE_16B (1_VCPUHVM_MODE_16B)
/* 32bit fields of the structure will be used. */
#define
El 03/08/15 a les 18.55, Andrew Cooper ha escrit:
On 24/07/15 17:54, Roger Pau Monné wrote:
struct vcpu_hvm_context {
/* 16bit fields of the strucutre will be used. */
#define _VCPUHVM_MODE_16B 0
#define VCPUHVM_MODE_16B (1_VCPUHVM_MODE_16B)
/* 32bit fields of the
On 08/03/2015 12:35 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The 'final_levels' of patch ids have been obtained
On 03/08/15 17:35, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The 'final_levels' of patch ids have been obtained
It is not used, and can cause a spurious failure of the set_gdt() hypercall in
low memory situations.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
---
CC: Jan Beulich jbeul...@suse.com
---
xen/arch/x86/mm.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git
On 08/03/2015 01:52 PM, Aravind Gopalakrishnan wrote:
On 8/3/2015 12:22 PM, Boris Ostrovsky wrote:
On 08/03/2015 12:35 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-5165 / XSA-140
version 2
QEMU leak of uninitialized heap memory in rtl8139 device model
UPDATES IN VERSION 2
CVE assigned.
Public release.
Updated
On 01/08/15 09:50, Vijay Kilari wrote:
On Wed, Jul 29, 2015 at 12:31 AM, Julien Grall julien.gr...@citrix.com
wrote:
Hi Vijay,
On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Emulate GITS* registers
Signed-off-by: Vijaya Kumar K
On Mon, 2015-08-03 at 11:47 +0100, Ian Campbell wrote:
I am going to manually run gzip on these files to alleviate some of the
pressure. They should compress well. If not I may truncate them to around
the point the repetition starts.
Each one got 99.6% compression, so the logs partition now
On Mon, 2015-08-03 at 12:23 +, Kun Cheng wrote:
On Mon, Aug 3, 2015 at 6:10 PM Dario Faggioli
dario.faggi...@citrix.com wrote:
On Sat, 2015-08-01 at 06:21 +, Kun Cheng wrote:
I've looked into those settings and vcpu affinities on Xen
wiki page.
Hi Vijay,
On 03/08/15 10:36, Vijay Kilari wrote:
On Sat, Aug 1, 2015 at 9:21 PM, Julien Grall julien.gr...@citrix.com wrote:
On 01/08/2015 11:25, Vijay Kilari wrote:
I guess you mean vgic_enable_irqs? And no what you've implemented is
definitely not the same as vgic_enable_irqs.
From: David Vrabel david.vra...@citrix.com
Instead of cpu_relax() while spinning and observing the ticket head,
introduce arch_lock_relax() which executes a WFE instruction. After
the ticket head is changed call arch_lock_signal() to execute an SEV
instruction (with the required DSB first) to
On Mon, Aug 3, 2015 at 6:10 PM Dario Faggioli dario.faggi...@citrix.com
wrote:
On Sat, 2015-08-01 at 06:21 +, Kun Cheng wrote:
I've looked into those settings and vcpu affinities on Xen wiki page.
However what I'm trying to argue about is memory should be migrated
when vcpus are moved
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-5166 / XSA-139
version 2
Use after free in QEMU/Xen block unplug protocol
UPDATES IN VERSION 2
CVE assigned.
Public release.
Updated status
flight 60229 qemu-upstream-4.3-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/60229/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 2 hosts-allocate
On (Mon) 03 Aug 2015 [10:37:26], Stefano Stabellini wrote:
On Mon, 3 Aug 2015, Amit Shah wrote:
On (Fri) 31 Jul 2015 [10:59:47], Stefano Stabellini wrote:
On Thu, 30 Jul 2015, Stefano Stabellini wrote:
On Thu, 30 Jul 2015, Juan Quintela wrote:
Anthony PERARD
On Mon, 3 Aug 2015, Ian Campbell wrote:
From: David Vrabel david.vra...@citrix.com
Instead of cpu_relax() while spinning and observing the ticket head,
introduce arch_lock_relax() which executes a WFE instruction. After
the ticket head is changed call arch_lock_signal() to execute an SEV
flight 60199 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60199/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
like 60154
On Mon, 2015-08-03 at 12:51 +0100, Stefano Stabellini wrote:
On Mon, 3 Aug 2015, Ian Campbell wrote:
From: David Vrabel david.vra...@citrix.com
Instead of cpu_relax() while spinning and observing the ticket head,
introduce arch_lock_relax() which executes a WFE instruction. After
the
On Mon, 2015-08-03 at 12:36 +0100, Ian Campbell wrote:
On Mon, 2015-08-03 at 11:47 +0100, Ian Campbell wrote:
I am going to manually run gzip on these files to alleviate some of the
pressure. They should compress well. If not I may truncate them to
around
the point the repetition
flight 60183 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60183/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt-raw 14 guest-start/debian.repeat fail baseline untested
Tests which did not succeed, but
On 03/08/15 14:35, Ben Catterall wrote:
Hi all,
I am working on an x86 proof-of-concept to evaluate if it is feasible
to move device models and x86 emulation code for HVM guests into a
de-privileged context.
I was hoping to get feedback from relevant maintainers on scheduling
flight 60164 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60164/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR.
vs. 59059
flight 60373 xen-4.2-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/60373/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64none executed queued
flight 60159 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60159/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt 11 guest-start fail like 58381
flight 60151 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60151/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
58884
Hi Julien,
On Mon, Aug 3, 2015 at 6:31 PM, Julien Grall julien.gr...@citrix.com wrote:
Hi Vijay,
On 03/08/15 10:36, Vijay Kilari wrote:
On Sat, Aug 1, 2015 at 9:21 PM, Julien Grall julien.gr...@citrix.com wrote:
On 01/08/2015 11:25, Vijay Kilari wrote:
I guess you mean vgic_enable_irqs?
On 03/08/15 14:51, Vijay Kilari wrote:
If so, this is wrong for 2 reasons:
1) The guest may decide to setup a bigger property table later.
2) vgic.id_bits should never be touched. The GITS_TYPER is static and
defined before the guest is booted.
If GICR_PROPBASER.id_bits is
flight 60150 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 9 windows-install fail REGR. vs. 58892
flight 60194 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60194/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 10 capture-logs(10) broken REGR. vs.
On Mon, 2015-08-03 at 14:26 +0100, Ian Campbell wrote:
On Mon, 2015-08-03 at 12:36 +0100, Ian Campbell wrote:
On Mon, 2015-08-03 at 11:47 +0100, Ian Campbell wrote:
I am going to manually run gzip on these files to alleviate some of
the
pressure. They should compress well. If not
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The 'final_levels' of patch ids have been obtained empirically.
Refer bug
On 08/03/2015 03:34 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that certain number of
applied microcode patch levels should not be overwritten by
the microcode loader. Otherwise, system hangs are known to occur.
The 'final_levels' of patch ids have been obtained
100 matches
Mail list logo
