On Mon, Aug 3, 2015 at 7:28 PM, Julien Grall wrote:
> 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
>>
On Tue, Aug 04, 2015 at 05:54:51AM +0200, Borislav Petkov wrote:
> 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 aski
From: Ross Lagerwall
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 use-after-free: if allocating t
From: Shannon Zhao
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 to 0. It would be more
From: Shannon Zhao
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
If ACPI fails to initialize tables, it should return one meaningful
value to tell the caller to diable acpi.
Signed-off-by: Shannon Zhao
---
xen/drivers/acpi/tables.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/acpi/tables.c b/xen/dri
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: 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 Iro
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
R
On Mon, Aug 3, 2015 at 4:19 PM, Willy Tarreau 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 that we
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 m
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.
>>
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau 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 proposes to t
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 empi
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 https://bugzilla.suse.com/show_bug.cg
On Mon, Aug 03, 2015 at 12:06:12PM -0700, Andy Lutomirski wrote:
> On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau 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 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 a
On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau 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 non-conformin
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
test-amd64-amd64
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).
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 Mon, Aug 03, 2015 at 11:33:30AM -0700, Andy Lutomirski wrote:
> On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau 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 settin
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau 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 proposes to t
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 shoul
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau 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 Tarreau
> --
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
---
kernel/sysctl.c | 36
1 fi
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 proposes to temporarily disable it by default. This can be
a safe alternativ
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 generi
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 loader.
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 'fina
On 3 August 2015 at 17:19, Stefano Stabellini
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:
>
> git://xenbits.xen.org/people/sstabel
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)
>>>
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 empi
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 bui
It is not used, and can cause a spurious failure of the set_gdt() hypercall in
low memory situations.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/mm.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index
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-b
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. */
>>> #d
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 em
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 https://bugzilla.suse.com/show_bug.cg
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).
> >
> > Re
From: Anthony PERARD
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
From: Anthony PERARD
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
st
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:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git
tags/xen-migration-2.4-tag
for you to fetch ch
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
T
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 int
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
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:
> - df4b1024526cae3479da3492d63
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 th
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
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 al
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_D
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 on
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' = 'f
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
Acked-by: Wei Liu
---
CC: Ian Ca
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
No functional change. It is not used any more.
Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
Acked-by: Wei Liu
---
CC: Ian Campbell
---
tools/libxl/libxl_dom.c | 223 --
tools/libxl/libxl_internal.h |4 -
tools/libxl/libxl_sr_str
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 remedi
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
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 QE
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.
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
>
> It doesn't seem to me that this patch is actually
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
It doesn't seem to me that this patch is actually necessary to fix the
issue, is that right?
If that is the case, I would rather s
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 w
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
Signed-off-by: Stefano Stabellini
---
hw/ide/piix.c |7 +++
1 file changed
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 w
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:
git://xenbits.xen.org/people/ss
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 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 us
This adds the configuration section in the vmstate saved by
xen_save_devices_state.
Signed-off-by: Anthony PERARD
---
migration/savevm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index 6071215..b3f605c 100644
--- a/migration/savevm.c
+++ b/m
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 toolstac
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
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
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
Regressions
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. 588
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-amd64 queued
build-amd64-r
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
test-amd64-i386-x
flight 60165 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60165/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59875
Tests which did not succeed, but a
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
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
test-amd64-i386-
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
test-amd64
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
> consid
Hi Julien,
On Mon, Aug 3, 2015 at 6:31 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 03/08/15 10:36, Vijay Kilari wrote:
>> On Sat, Aug 1, 2015 at 9:21 PM, Julien Grall wrote:
>>> On 01/08/2015 11:25, Vijay Kilari wrote:
>
> I guess you mean vgic_enable_irqs? And no what you've implemented
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
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
considerations for this system to mitigate potential Do
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 repet
Hi Vijay,
On 03/08/15 10:36, Vijay Kilari wrote:
> On Sat, Aug 1, 2015 at 9:21 PM, Julien Grall 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.
vgic_enable
On Mon, 2015-08-03 at 12:23 +, Kun Cheng wrote:
> On Mon, Aug 3, 2015 at 6:10 PM Dario Faggioli
> 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 tr
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 wrote:
>
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, 2015-08-03 at 11:47 +0100, Ian Campbell wrote:
> 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).
I also subsequently spotted 60229
-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 st
-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 of
On Mon, Aug 3, 2015 at 6:10 PM Dario Faggioli
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 to another node.
>
On Fri, Jul 31, 2015 at 4:09 PM, Stefano Stabellini
wrote:
[...]
>
>
> One option going forward is to map MMIO regions in Dom0 on demand when
> trapping in Xen with a data abort. Specifically in
> xen/arch/arm/traps.c:do_trap_data_abort_guest we could check that the
> guest is dom0 and that the
On 03/08/15 12:29, Ian Campbell wrote:
> From: David Vrabel
>
> 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
On Mon, 2015-08-03 at 12:51 +0100, Stefano Stabellini wrote:
> On Mon, 3 Aug 2015, Ian Campbell wrote:
> > From: David Vrabel
> >
> > Instead of cpu_relax() while spinning and observing the ticket head,
> > introduce arch_lock_relax() which executes a WFE instruction. After
> > the ticket head i
On Mon, 3 Aug 2015, Ian Campbell wrote:
> From: David Vrabel
>
> 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 t
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
test-amd64-amd64-
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 n
From: David Vrabel
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 wake any spinners.
This s
1 - 100 of 113 matches
Mail list logo
