On Wed, Dec 14, 2016 at 07:52:00AM +, Ross Lagerwall wrote:
> Exit with 0 for success.
> Exit with 1 for an error.
> Exit with 2 if the operation should be retried for any reason (e.g. a
> timeout or because another operation was in progress).
>
> This allows a program or script driving xen-li
On Wed, Dec 14, 2016 at 07:51:59AM +, Ross Lagerwall wrote:
> Fix a number of incorrect uses of errno after an operation that could
> set it (e.g. fprintf, close).
>
> Signed-off-by: Ross Lagerwall
> ---
Acked-by: Wei Liu
___
Xen-devel mailing li
On Wed, Dec 14, 2016 at 07:51:57AM +, Ross Lagerwall wrote:
> The default timeout in the hypervisor for a livepatch operation is 30 ms,
> but xen-livepatch currently waits for up to 30 seconds for the operation
> to complete. Instead, remove the retry loop and simply wait for 2 * 30 ms
> for th
On Wed, Dec 14, 2016 at 07:51:56AM +, Ross Lagerwall wrote:
> The hypervisor expects the timeout from the hypercall to be in
> nanoseconds, so document this correctly. Also correctly document
> what happens when timeout is set to zero.
>
> Signed-off-by: Ross Lagerwall
Acked-by: Wei Liu
__
On Wed, Dec 14, 2016 at 07:51:54AM +, Ross Lagerwall wrote:
> Using both stdout and stderr interleaved without newlines can result in
> strange output when using line buffered mode (e.g. a terminal) or when
> fully buffered (e.g. redirected to a file). Set stdout to unbuffered mode
> to fix thi
Signed-off-by: Ross Lagerwall
Acked-by: Wei Liu
Reviewed-by: Konrad Rzeszutek Wilk
---
tools/misc/xen-livepatch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index 4ebe95e..fd2f968 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools
Hi Cédric and Jim
On Wed, Dec 14, 2016 at 06:24:15AM +, osstest service owner wrote:
> flight 103306 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/103306/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could n
Exit with 0 for success.
Exit with 1 for an error.
Exit with 2 if the operation should be retried for any reason (e.g. a
timeout or because another operation was in progress).
This allows a program or script driving xen-livepatch to determine if
the operation should be retried without parsing the
Hi all,
This series contains a few fixes to the xen-livepatch tool.
It also contains a few changes to make the output more readable.
Changed in v2:
* Fix minor comments.
* Split the last patch into two.
Ross Lagerwall (8):
tools/livepatch: Show the correct expected state before action
tools/
Using both stdout and stderr interleaved without newlines can result in
strange output when using line buffered mode (e.g. a terminal) or when
fully buffered (e.g. redirected to a file). Set stdout to unbuffered mode
to fix this (stderr is always unbuffered by default).
Signed-off-by: Ross Lagerwa
Improving the output of xen-livepatch, which is currently hard to read,
especially when an error occurs.
Some examples of the changes:
Before:
$ xen-livepatch apply test
Performing apply:. completed
After:
$ xen-livepatch apply test
Applying test:. completed
Before:
$ xen-live
The hypervisor expects the timeout from the hypercall to be in
nanoseconds, so document this correctly. Also correctly document
what happens when timeout is set to zero.
Signed-off-by: Ross Lagerwall
---
docs/misc/livepatch.markdown | 13 +++--
tools/libxc/include/xenctrl.h | 2 +-
xen
The default timeout in the hypervisor for a livepatch operation is 30 ms,
but xen-livepatch currently waits for up to 30 seconds for the operation
to complete. Instead, remove the retry loop and simply wait for 2 * 30 ms
for the operation to complete. The extra period is to account for the
time to
Somewhat confusingly, before the action has been executed the patch is
expected to be in the "allow" state, not the "expected" state. The
check for this was correct but the subsequent error message was not.
Fix the error message to show this state correctly.
Before:
$ xen-livepatch unload tes
Fix a number of incorrect uses of errno after an operation that could
set it (e.g. fprintf, close).
Signed-off-by: Ross Lagerwall
---
tools/misc/xen-livepatch.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/tools/misc/xen-livepatch.c b/tools/m
On Wed, Dec 14, 2016 at 06:44:43AM +, Ross Lagerwall wrote:
[...]
> >
> >And perhaps you should check the return value of setvbuf?
> >
>
> I don't think there's anything that can be done if it fails, so there's not
> much point in checking the return value.
>
This is a fair point.
Wei.
> -
On 12/14/2016 09:14 AM, Jan Beulich wrote:
On 13.12.16 at 23:02, wrote:
>> On 13/12/2016 21:55, Razvan Cojocaru wrote:
>>> On a somewhat related note, it's important to also figure out how best
>>> to avoid emulation races such as the LOCK CMPXCHG issue we've discussed
>>> in the past. Maybe
>>> On 13.12.16 at 17:53, wrote:
> On 13/12/16 11:28, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -1185,7 +1185,7 @@ static int ioport_access_check(
>>
>> fail_if(ops->read_segment == NULL);
>> if ( (rc = ops-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, December 14, 2016 3:25 AM
>
> Hello,
>
> All of this came about while reviewing some of Jans improvements to the
> x86 instruction emulator.
>
> It turns out that the XSA-156 / CVE-2015-8104 fix, c/s bd2239d9
> "x86/HVM:
>>> On 13.12.16 at 23:02, wrote:
> On 13/12/2016 21:55, Razvan Cojocaru wrote:
>> On a somewhat related note, it's important to also figure out how best
>> to avoid emulation races such as the LOCK CMPXCHG issue we've discussed
>> in the past. Maybe that's also worth taking into consideration at t
>>> On 14.12.16 at 02:37, wrote:
> On 12/13/16 08:21 -0700, Jan Beulich wrote:
> On 13.12.16 at 13:16, wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>>> @@ -32,6 +32,18 @@ static DEFINE_PER_CPU(u64 *, vvmcs_buf);
>>>
>>> static void nvmx_purge_vvmcs(struc
Juergen Gross, on Tue 13 Dec 2016 16:38:06 +0100, wrote:
> Several stubdom libraries are being rebuilt each time a top level make
> is called as they depend on stubdom/ioemu/linkfarm.stamp which is
> depending on tools/qemu-xen-traditional-dir. Unfortunately this
> directory is modified by each "ma
On Tue, Dec 13, 2016 at 1:00 PM, Ian Jackson wrote:
> The conversion is as follows: if a scenario is affected by the caveat,
> in there must be at least one transaction T which firstly produces
> "impossible" results I, and in which some later statement S produces a
> serialisation failure.
>
> To
flight 103196 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 52 leak-check/check fail REGR. vs. 102721
test-xtf-amd64-
On 12/12/2016 05:02 PM, Wei Liu wrote:
On Mon, Dec 12, 2016 at 04:18:05PM +, Ross Lagerwall wrote:
Using both stdout and stderr interleaved without newlines can result in
strange output when using line buffered mode (e.g. a terminal) or when
fully buffered (e.g. redirected to a file). Set bo
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, December 13, 2016 8:56 PM
>
> >>> On 13.12.16 at 13:00, wrote:
> > During the most recent Cambridge Hackathon (April 2016), there was a
> > suggestion made (sorry - I don't recall from whom) to feed the the
> > SVM/VMX intercept info
flight 103306 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
flight 103169 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103169/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs.
101675
test-amd64-i38
> From: Zhang, Haozhong
> Sent: Tuesday, December 13, 2016 8:16 PM
>
> Check whether the operand of L1 vmxon is a valid VMXON region address
> and whether the VMXON region at that address contains a valid revision
> ID.
>
> Signed-off-by: Haozhong Zhang
Acked-by: Kevin Tian
__
> From: Zhang, Haozhong
> Sent: Tuesday, December 13, 2016 8:16 PM
>
> According to Intel SDM, section "VMXON - Enter VMX Operation", a
> VMfail should be returned to L1 hypervisor if L1 vmxon is executed in
> VMX operation, rather than just print a warning message.
>
> Signed-off-by: Haozhong Zh
flight 103220 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103220/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-saverestore fail
REGR. vs. 102942
> From: Zhang, Haozhong
> Sent: Tuesday, December 13, 2016 8:16 PM
>
> nvmx_handle_vmxon() previously checks whether a vcpu is in VMX
> operation by comparing its vmxon_region_pa with GPA 0. However, 0 is
> also a valid VMXON region address. If L1 hypervisor had set the VMXON
> region address to 0
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, December 13, 2016 3:30 PM
>
> >>> On 13.12.16 at 06:23, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, December 09, 2016 4:47 PM
> >>
> >> >>> On 08.12.16 at 18:33, wrote:
> >> > On 08/12/16 16:01, Jan
flight 103240 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103240/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 102521
test-xtf-amd64-
> On Dec 8, 2016, at 4:37 AM, Andrew Cooper wrote:
>
> Hello,
>
> While digging around, it looks like there is some major bitrot of the PV
> autotranslate code.
>
> When constructing an autotranslate domain, tools/libxc/xc_dom_x86.c:
> x86_shadow() sets refcount | translate on the domain.
>
>
flight 103296 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103296/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
> On Dec 10, 2016, at 4:18 AM, Stefano Stabellini
> wrote:
>
> On Fri, 9 Dec 2016, Andre Przywara wrote:
>> On 07/12/16 20:20, Stefano Stabellini wrote:
>>> On Tue, 6 Dec 2016, Julien Grall wrote:
On 06/12/2016 22:01, Stefano Stabellini wrote:
> On Tue, 6 Dec 2016, Stefano Stabellini w
On Mon, Dec 12, 2016 at 4:46 PM, Thomas Munro
wrote:
> On Tue, Dec 13, 2016 at 10:47 AM, Kevin Grittner wrote:
>> Barring objections I will back-patch to 9.2 through 9.5 tomorrow.
>> (9.1 is out of support and the fix is already in 9.6 and forward.)
>
> +1
Done.
I will add a test case based on
On 12/13/16 08:21 -0700, Jan Beulich wrote:
On 13.12.16 at 13:16, wrote:
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -32,6 +32,18 @@ static DEFINE_PER_CPU(u64 *, vvmcs_buf);
static void nvmx_purge_vvmcs(struct vcpu *v);
+/*
+ * When a vcpu is out of VMXON region, s
On 12/13/16 10:16 -0500, Konrad Rzeszutek Wilk wrote:
On Tue, Dec 13, 2016 at 08:16:19PM +0800, Haozhong Zhang wrote:
According to Intel SDM, section "VMXON - Enter VMX Operation", a
VMfail should be returned to L1 hypervisor if L1 vmxon is executed in
VMX operation, rather than just print a war
Hi Guys,
Xen currently does not handle mapping of MMIO regions specified under
OperationRegion in ACPI ASL. OperationRegion is well defined in ACPI
specification. I'm seeking for architectural direction on adding support for
mapping OperationRegion.
Some context here. Mapping of resources s
> On Dec 13, 2016, at 12:16 PM, Tian, Kevin wrote:
>
>> From: Li, Liang Z
>> Sent: Tuesday, December 13, 2016 11:58 AM
>>
>> Hi All,
>>
>> We are now working on enabling 5 level paging & 5 level EPT for XEN. We need
>> the
>> community's opinions about the following aspects:
>>
>> 1. Should
flight 68215 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68215/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 68165
build
On Mon, 12 Dec 2016, Andre Przywara wrote:
> >> The _pending_ table is exactly that: one bit per VLPI.
> >
> > Actually the spec says about the pending table, ch 6.1.2:
> >
> > "Each Redistributor maintains entries in a separate LPI Pending table
> > that indicates the pending state of each LPI w
flight 103292 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103292/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
test-armhf-a
This run is configured for baseline tests only.
flight 68214 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68214/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3
flight 103226 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103226/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 94a1bc1212edf521b7c96bfb9dc653818c95bec7
baseline version:
ovmf 8b78de74dc6a7d655de50
On 13/12/2016 21:55, Razvan Cojocaru wrote:
> On 12/13/2016 11:03 PM, Andrew Cooper wrote:
>> On 13/12/2016 20:51, Razvan Cojocaru wrote:
>>> On 12/13/2016 07:10 PM, Andrew Cooper wrote:
On 13/12/16 15:58, Razvan Cojocaru wrote:
> Hello, and first of all thanks for the discussion!
>
>>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-win7-amd64
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tradi
On 12/13/2016 11:03 PM, Andrew Cooper wrote:
> On 13/12/2016 20:51, Razvan Cojocaru wrote:
>> On 12/13/2016 07:10 PM, Andrew Cooper wrote:
>>> On 13/12/16 15:58, Razvan Cojocaru wrote:
Hello, and first of all thanks for the discussion!
> Think of it a bit more like introducing a new a
Juergen Gross, on Tue 13 Dec 2016 16:18:07 +0100, wrote:
> On 13/12/16 16:02, Wei Liu wrote:
> > After 5623e2d2 ("x86: use unified linker script") the linker script for
> > x86 build is generated. But the special rule to generate linker script
> > doesn't have OBJ_DIR prepended so in parallel build
flight 103284 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103284/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 13/12/2016 20:51, Razvan Cojocaru wrote:
> On 12/13/2016 07:10 PM, Andrew Cooper wrote:
>> On 13/12/16 15:58, Razvan Cojocaru wrote:
>>> Hello, and first of all thanks for the discussion!
>>>
Think of it a bit more like introducing a new action emulator (name
definitely subject to impr
On 12/13/2016 07:10 PM, Andrew Cooper wrote:
> On 13/12/16 15:58, Razvan Cojocaru wrote:
>> Hello, and first of all thanks for the discussion!
>>
>>> Think of it a bit more like introducing a new action emulator (name
>>> definitely subject to improvement), which implements things such as
>>> wrmsr
On Tue, Dec 13, 2016 at 05:31:52PM +0100, Cédric Bosdonnat wrote:
> Qdisk supports qcow and qcow2, extend it to also support qed disk
> format.
>
> Signed-off-by: Cédric Bosdonnat
Regenerate libxlu_disk_l.{c,h} and apply.
___
Xen-devel mailing list
Xe
On 13/12/16 18:49, Ian Jackson wrote:
> Ian Jackson writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"):
>> As we discussed yesterday, while this may be a real bug, I think it is
>> not really a _regression_ in the sense that the osstest baseline
>> version has the same bug.
>>
>> I th
On 13/12/16 18:41, Julien Grall wrote:
> Hi Andrew,
>
> On 13/12/16 18:28, Andrew Cooper wrote:
>> On 12/12/16 23:47, Tamas K Lengyel wrote:
>>>
It works on x86 because, IIRC, you do a software page table walking.
Although, I don't think you have particular write/read access
checking
Hello,
All of this came about while reviewing some of Jans improvements to the
x86 instruction emulator.
It turns out that the XSA-156 / CVE-2015-8104 fix, c/s bd2239d9
"x86/HVM: always intercept #AC and #DB", introduced an awkward bug on
Intel hardware.
Executing a sti while singlestepping is a
On Tue, Dec 13, 2016 at 12:00 PM, Ian Jackson wrote:
> Kevin Grittner writes:
> I still hope to be able to convince you that the definition of
> SERIALIZABLE (in the pgsql docs) ought to be a stronger version, which
> covers even non-committed transactions.
That doesn't seem likely. The stronge
Hi Stefano,
On 13/12/16 19:08, Stefano Stabellini wrote:
Rt is four bit at offset 12, not three. See see encoding T2 for LDRB
A8.8.70 in ARM DDI 0406C.c
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
Regards,
--
Julien Grall
__
Rt is four bit at offset 12, not three. See see encoding T2 for LDRB
A8.8.70 in ARM DDI 0406C.c
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
diff --git a/xen/arch/arm/decode.c b/xen/arch/arm/decode.c
index c6f49a5..514b7a2 100644
--- a/xen/arch/arm/decode.c
+++ b/xen/arch/arm/de
On Tue, 13 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 10/12/16 01:31, Stefano Stabellini wrote:
> > The rt variable can only be 0 or 7, no need to check if it's 15.
>
> Be careful, Coverity may point to dead code but it does not mean that deleting
> it is the right thing to do. The code w
Hi all,
Stefano suggested to move the call at 5pm and I haven't seen any
disagreement.
So the call will be tomorrow (Wednesday 14th December at 5pm).
The conference details are the same as last time. For reminder:
Use either of the following to join the call:
Call+44 1223 406065
Cédric Bosdonnat writes ("[PATCH v4] libxl: QED disks support"):
> Qdisk supports qcow and qcow2, extend it to also support qed disk
> format.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Ian Jackson writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"):
> As we discussed yesterday, while this may be a real bug, I think it is
> not really a _regression_ in the sense that the osstest baseline
> version has the same bug.
>
> I therefore propose to do a force push of 4.4 to
This run is configured for baseline tests only.
flight 68212 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68212/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 52 leak-check/c
Hi Andrew,
On 13/12/16 18:28, Andrew Cooper wrote:
On 12/12/16 23:47, Tamas K Lengyel wrote:
It works on x86 because, IIRC, you do a software page table walking.
Although, I don't think you have particular write/read access checking on
x86.
I don't recall there being any software page walkin
On Tue, Dec 13, 2016 at 5:50 AM, Julien Grall wrote:
> Hello Tamas,
>
> On 12/12/16 23:47, Tamas K Lengyel wrote:
>>
>> On Mon, Dec 12, 2016 at 2:28 PM, Julien Grall
>> wrote:
>>>
>>> On 12/12/2016 19:41, Tamas K Lengyel wrote:
On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall
wrote:
On 12/12/16 23:47, Tamas K Lengyel wrote:
>
>> It works on x86 because, IIRC, you do a software page table walking.
>> Although, I don't think you have particular write/read access checking on
>> x86.
> I don't recall there being any software page walking being involved on
> x86. Why would that be
Andrew Cooper writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"):
> On 12/12/16 11:47, Ian Jackson wrote:
> > AIUI this is a known and accepted regression in Xen 4.5: some of the
> > strange things done by one of the XTF tests causes a guest crash
> > (after a security updates was app
Anthony PERARD writes ("[OSSTEST PATCH v9 3/3] Create a flight to test
OpenStack with xen-unstable and libvirt"):
> This patch should create a flight "openstack-nova", with those jobs:
...
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
I think that this is all good now.
Can you provide
This patch should create a flight "openstack-nova", with those jobs:
build-amd64
build-amd64-xsm
build-amd64-pvops
build-amd64-libvirt
test-amd64-amd64-devstack
test-amd64-amd64-devstack-xsm
build-armhf
build-armhf-libvirt
build-armhf-pvops
build-armhf-xsm
test-armhf-armhf-dev
This script installs any necessary packages and clones all of the OpenStack
trees which are used by devstack to deploy OpenStack.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Changes in V9:
- runvars for openstack trees have been renamed to openstack_*
Changes in V8:
- fix job name i
Hi,
I have looked into getting OpenStack been tested on the latest Xen via
osstest.
The ts-openstack-deploy script does prepare a bit more the host, clone
devstack and other OpenStack trees, then run ./stack.sh, which is a bit
like raisin and deploy OpenStack on the host. Once the machine is read
This script runs the OpenStack integration test suite, Tempest.
Signed-off-by: Anthony PERARD
Acked-by: Ian Campbell
Acked-by: Ian Jackson
---
Changes in V8:
- fix copyright year
- fix job name in sg-run-job
- fix too long lines
Changes in V7:
- reindent
- acked
No change in V5
Change in V4
On Tue, Dec 13, 2016 at 5:50 AM, Julien Grall wrote:
> Hello Tamas,
>
> On 12/12/16 23:47, Tamas K Lengyel wrote:
>>
>> On Mon, Dec 12, 2016 at 2:28 PM, Julien Grall
>> wrote:
>>>
>>> On 12/12/2016 19:41, Tamas K Lengyel wrote:
On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall
wrote:
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages]"):
> [various things]
I get the feeling from your message that I have irritated you. I'm
sorry if I have. In particular, I wanted to say that I certainly
don't expect bug
flight 103277 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 103265
Tests which
On 13/12/16 05:44, Li, Liang Z wrote:
>> Subject: RE: [Xen-devel] Future support of 5-level paging in Xen:wq
>>
>>> From: Li, Liang Z
>>> Sent: Tuesday, December 13, 2016 11:58 AM
>>>
>>> Hi All,
>>>
>>> We are now working on enabling 5 level paging & 5 level EPT for XEN.
>>> We need the community'
On Tue, Dec 13, 2016 at 05:15:40PM +, Roger Pau Monne wrote:
> Fix a build breakage after the libacpi changes, this is due to rombios using
> the
> libacpi headers in order to parse the ACPI tables.
>
> Signed-off-by: Roger Pau Monné
> Reported-by: Razvan Cojocaru
Pushed with Andrew's Revi
On Tue, Dec 13, 2016 at 07:53:02AM -0700, Jan Beulich wrote:
> >>> On 13.12.16 at 15:17, wrote:
> > While re-basing the patch on staging, I've got this (unrelated) error
> > while doing 'make dist':
> >
> > make[9]: Entering directory `~/work/xen.git/tools/firmware/rombios/32bit'
> > gcc -m32 -
On 13/12/16 15:58, Razvan Cojocaru wrote:
> Hello, and first of all thanks for the discussion!
>
>> Think of it a bit more like introducing a new action emulator (name
>> definitely subject to improvement), which implements things such as
>> wrmsr, cpuid, pagewalk, task_switch, etc.
>>
>> The vmexi
On Tue, Dec 13, 2016 at 05:31:52PM +0100, Cédric Bosdonnat wrote:
> Qdisk supports qcow and qcow2, extend it to also support qed disk
> format.
>
> Signed-off-by: Cédric Bosdonnat
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
h
>>> On 13.12.16 at 17:54, wrote:
> PV guests necessarily can't be external, as Xen must steal address space from
> them. Pagefaults for HVM guests are handled by {vmx,svm}_vmexit_handler() and
> don't enter the PV fixup_page_fault() path. Therefore, the first call to
> paging_fault() is dead, an
This run is configured for baseline tests only.
flight 68213 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68213/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build
>>> On 13.12.16 at 17:53, wrote:
> On 13/12/16 11:28, Jan Beulich wrote:
>> +static int priv_op_insn_fetch(enum x86_segment seg,
>> + unsigned long offset,
>> + void *p_data,
>> + unsigned int bytes,
>> +
Fix a build breakage after the libacpi changes, this is due to rombios using the
libacpi headers in order to parse the ACPI tables.
Signed-off-by: Roger Pau Monné
Reported-by: Razvan Cojocaru
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Razvan Cojocaru
Cc: Jan Beulich
---
The usage of ACPI tables in
Konrad Rzeszutek Wilk writes ("[PATCH v2 8/9] sg-run-job: Add the
test-livepatch."):
> This way we have the test-livepatch which can unroll to depend on:
> ts-livepatch-install
> ts-livepatch-run
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-
Konrad Rzeszutek Wilk writes ("[PATCH v2 7/9] ts-livepatch-[install|run]:
Install and initial test-cases."):
> There are 37 of the test-cases in there. Before we run
> any of them we verify that the payload files are present
> in /usr/lib/debug.
> +# Whether we can actually execute it.
> +
On 13/12/16 11:28, Jan Beulich wrote:
> +static int priv_op_insn_fetch(enum x86_segment seg,
> + unsigned long offset,
> + void *p_data,
> + unsigned int bytes,
> + struct x86_emulate
At 16:54 + on 13 Dec (1481648074), Andrew Cooper wrote:
> PV guests necessarily can't be external, as Xen must steal address space from
> them. Pagefaults for HVM guests are handled by {vmx,svm}_vmexit_handler() and
> don't enter the PV fixup_page_fault() path. Therefore, the first call to
>
Setting PG_refcounts but not PG_translate is not useful.
While adjusting this, make a few other improvements.
* Have paging_enable() unilaterally reject any unknown modes.
* Drop the or'ing of PG_{HAP,SH}_enable. The underlying functions already do
this.
Signed-off-by: Andrew Cooper
Acked
PV guests necessarily can't be external, as Xen must steal address space from
them. Pagefaults for HVM guests are handled by {vmx,svm}_vmexit_handler() and
don't enter the PV fixup_page_fault() path. Therefore, the first call to
paging_fault() is dead, and dropped.
Logdirty mode is now the only
Autotranslate PV domains haven't been able to be built for two releases of
Xen, and noone has noticed. The shadow emulation code for such domains has
never functioned correctly for guests running in a mode different to Xen.
All important change is in patch 3.
Andrew Cooper (3):
x86/paging: Enf
Emulation is only performed for paging_mode_refcount() domains, which in
practice means HVM domains only.
Drop the PV emulation code. As it always set addr_side and sp_size to
BITS_PER_LONG, it can't have worked correctly for PV guests running in a
different mode to Xen.
Signed-off-by: Andrew Co
Konrad Rzeszutek Wilk writes ("[PATCH v2 6/9] ts-xen-build: Build the livepatch
test-cases"):
> +buildcmd_stamped_logged(600, 'xen', 'xenlpt-build', '',< $dokconfig;
> +if test -d xen/test; then
> +$make_prefix make -C xen tests
> +fi
Is $dokconfig really the right
Wei Liu writes ("Re: [Xen-devel] [PATCH v2 9/9] make-flight/mfi-common: Add
livepatch build/test target in the matrix."):
> I think you need to filter this test case to only run for 4.7+.
>
> There is no point in running it for older releases.
There are basically two plausible approaches to this
On Tue, Dec 13, 2016 at 9:50 AM, Ian Jackson wrote:
> Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db:
> Retry on constraint violation [and 2 more messages]"):
>> On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson
>> wrote:
>>> Are all of these cases fixed by fcff8a57519847 "D
>>> On 13.12.16 at 17:04, wrote:
> Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce
> elf_iter_ok and elf_strcmp_safe"):
>> On 12.12.16 at 17:56, wrote:
>> > I have replaced the limit with a comment. Now I have:
>> >
>> > elf->iteration_deaccumulator =
>> > 1024*
Qdisk supports qcow and qcow2, extend it to also support qed disk
format.
Signed-off-by: Cédric Bosdonnat
---
v2:
* Add qed to the list for possible format values in xl-disk-configuration.txt
* Add LIBXL_HAVE_QED
v3:
* Remove the qed: obsolete prefix support
v4:
* Added backing f
1 - 100 of 205 matches
Mail list logo
