On Fri, Jul 31, 2015 at 12:28 PM, David Vrabel
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 Trace:
> > [
* Amit Shah (amit.s...@redhat.com) 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:
> > > > > This is a critical issue for Xen as migration either wit
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 Sat, Aug 1, 2015 at 9:21 PM, Julien Grall 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 structure u
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:
> > > > > This is a critical issue for Xen as migration either with the
On Fri, 2015-07-31 at 16:53 +0100, Andrew Cooper wrote:
> On 31/07/15 16:34, Paul Durrant wrote:
> > Both hvm_io_pending() and hvm_wait_for_io() use the shared (with
> > emulator)
> > ioreq structure to determined whether there is a pending I/O. The
> > latter will
> > misbehave if the shared sta
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
> Cc: Stefano Stabellini
> Cc: Russell King
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 w
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 exact
On Thu, Jul 30, 2015 at 3:51 PM, Vitaly Kuznetsov wrote:
> Ian Campbell writes:
>
>> (CC-ing 2x QEMU maintainers and stable release manager)
>>
>> The separate trees are a holdover from mercurial, which didn't (at the
>> time) have a good in-repo branching model.
>>
>> I propose that Xen 4.6 shou
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 those who are working to improve support fo
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 01/08/15 09:50, Vijay Kilari wrote:
> On Wed, Jul 29, 2015 at 12:31 AM, Julien Grall
> wrote:
>> Hi Vijay,
>>
>> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>>> From: Vijaya Kumar K
>>>
>>> Emulate GITS* registers
>>>
>>> Signed-off-by: Vijaya Kumar K
>>> ---
>>> v4: - Removed GICR regi
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
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
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 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 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 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 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.
>
-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
-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
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
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 wrote:
>
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
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: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 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
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 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
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
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
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-
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 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
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 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 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 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
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
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
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
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
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
-
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
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
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
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
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
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 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, 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, 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
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
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
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
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
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 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
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
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 th
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, 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, 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
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
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
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
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
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 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
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 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
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:
> 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
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
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 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
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 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.
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
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
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
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
> --
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:
> 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 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 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: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).
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 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
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 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.
>
>
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 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
1 - 100 of 113 matches
Mail list logo
