>>> On 14.12.16 at 17:53, wrote:
> There are two bugs.
>
> Firstly, the ASSERT(paging_mode_only_log_dirty(d)) can trip when servicing a
> hypervisor #PF in the context of an HVM guest, e.g. a copy_to_user() failure
> in the shadow pagetable code.
>
> Secondly, the entry conditions paging_fault()
Signed-off-by: Jan Beulich
---
v2: Latch x86_seg_* value to use into local variable. Prefer "else"
over early "break".
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -432,6 +432,7 @@ typedef union {
#define CR4_OSFXSR (1<<9)
#define CR4_OSXM
1: reduce CMPXCHG{8,16}B footprint and casting
2: check for CMPXCHG8B availability
3: CMPXCHG16B requires an aligned operand
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 103313 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103313/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102942
test-amd64-i386-xl-qemuu-wi
We can't exclude someone wanting to hide the instruction from guests.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Re-base.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1289,6 +1289,7 @@ static bool vcpu_has(
#define vcpu_has_
Re-use an existing stack variable (reducing stack footprint, which also
results in smaller code due to some stack accesses no longer needing a
32-bit displacement), at once using a union instead of casts. Also
switch to rex_prefix based conditionals instead of op_bytes ones.
Signed-off-by: Jan Beu
This distinguishes it from CMPXCHG8B.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -5372,6 +5372,9 @@ x86_emulate(
if ( rex_prefix & REX_W )
{
host_and_vcpu_must_have(cx16);
+gen
>>> On 06.12.16 at 11:51, wrote:
> As such clearing of flags may have an impact on the selected rendezvous
> function, handle such in a central place.
>
> But don't allow such feature flags to be cleared during CPU hotplug:
> Platform and local system times may have diverged significantly by
> th
>>> On 06.12.16 at 12:25, wrote:
> Their size parameters being "unsigned", there's neither a point for
> them returning "unsigned long", nor for any of their (assembly)
> arithmetic to involved 64-bit operations on other than addresses.
>
> Take the opportunity and fold __do_clear_user() into its
>>> On 08.12.16 at 12:38, wrote:
> The memory clobber is rather harsh here. However, fic.exn_raised may be
> modified as a side effect, so we need to let the compiler know that all
> of "fic" may be changed (preventing it from moving around accesses to
> the exn_raised field).
>
> Signed-off-by:
>>> On 09.12.16 at 09:47, wrote:
On 08.12.16 at 18:33, wrote:
>> On 08/12/16 16:01, Jan Beulich wrote:
>>> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
>>
>> Which commit?
>
> Oops - initially I had intended the title to include the hash: 83cd2038fe.
> I've adjusted
>>> On 09.12.16 at 09:59, wrote:
On 08.12.16 at 18:51, wrote:
>> On 08/12/16 16:02, Jan Beulich wrote:
>>> variable. With an IRQ happening at the deepest point of the stack, and
>>> with send_guest_pirq() being called from there (leading to vcpu_kick()
>>> -> ... -> csched_vcpu_wake() -> __r
>>> On 09.12.16 at 16:27, wrote:
On 09.12.16 at 16:19, wrote:
> On 09.12.16 at 15:56, wrote:
>>> It is a layering violation to remove the host_has_* part of the check
>>> from the emulator.
>>
>> This is from a very, very abstract perspective. The fact that
>> host_and_vcpu_*() and vcp
Hi Bhupinder,
Nothing related to this patch. I got confused this morning with this
patch because there is no version numbering, I thought it was just a
resend, but you did some changes and added my reviewed-by. In the
future, may I ask you to put the same version number on all the patches
of
flight 103390 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103390/
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
Hi Bhupinder,
On 15/12/16 06:13, Bhupinder Thakur wrote:
VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.
This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.
Signed-off-by: Bh
Hi Julien,
On 15 December 2016 at 15:34, Julien Grall wrote:
> Hi Bhupinder,
>
> Nothing related to this patch. I got confused this morning with this patch
> because there is no version numbering, I thought it was just a resend, but
> you did some changes and added my reviewed-by. In the future
Hi Bhupinder,
On 15/12/16 06:13, Bhupinder Thakur wrote:
+
+/* set a flag if the current cpu does not suppot 16 bit VMIDs */
+if ( info->mm64.vmid_bits != MM64_VMID_16_BITS_SUPPORT )
+vmid_8_bit = true;
}
+/*
I just spot a trailing white space here while t
On 15/12/16 08:41, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 103316 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 103196
test-amd64-amd6
On 15/12/16 09:39, Jan Beulich wrote:
> Re-use an existing stack variable (reducing stack footprint, which also
> results in smaller code due to some stack accesses no longer needing a
> 32-bit displacement), at once using a union instead of casts. Also
> switch to rex_prefix based conditionals ins
On 15/12/16 09:40, Jan Beulich wrote:
> This distinguishes it from CMPXCHG8B.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 15/12/16 09:49, Jan Beulich wrote:
On 06.12.16 at 11:51, wrote:
>> As such clearing of flags may have an impact on the selected rendezvous
>> function, handle such in a central place.
>>
>> But don't allow such feature flags to be cleared during CPU hotplug:
>> Platform and local system ti
flight 68223 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68223/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 68176
jobs:
build-amd64 pass
build-armh
Hi Julien,
>> -#define MAX_VMID 256
>> -#define INVALID_VMID 0 /* VMID 0 is reserved */
>>
>> static spinlock_t vmid_alloc_lock = SPIN_LOCK_UNLOCKED;
>>
>> /*
>> - * VTTBR_EL2 VMID field is 8 bits. Using a bitmap here limits us to
>> - * 256 concurrent domains.
>> + * VTTBR_EL2 VMID field is 8
Hi Julien,
On 15 December 2016 at 16:00, Julien Grall wrote:
> Hi Bhupinder,
>
> On 15/12/16 06:13, Bhupinder Thakur wrote:
>>
>> +
>> +/* set a flag if the current cpu does not suppot 16 bit VMIDs */
>> +if ( info->mm64.vmid_bits != MM64_VMID_16_BITS_SUPPORT )
>> +v
From: "Edgar E. Iglesias"
This patch changes the mapping from non-cached to cached
for mmio-sram nodes that do not have the no-memory-wc property.
This is a hang-over from 4.8 since the mmio-sram patches went
in late in the cycle.
I've explained the rationale in the commit message:
Rationale
Hi Bhupinder,
On 15/12/16 11:23, Bhupinder Thakur wrote:.
+ * VMIDs.
+ */
+if ( !vmid_8_bit )
+max_vmid = MAX_VMID_16_BIT;
+
/* pa_range is 4 bits, but the defined encodings are only 3 bits */
if ( pa_range&0x8 || !pa_range_info[pa_range].pabits )
panic("
From: "Edgar E. Iglesias"
Relax the mapping of mmio-sram nodes that do not set the
no-memory-wc property to cached normal memory.
Rationale:
Allthough on chip memories are relatively fast compared to
off-chip memories, large OCMs are still significantly slower
than L1 caches. Depending on the me
Hi Andre,
On 22/11/16 15:09, Andre Przywara wrote:
diff --git a/configure.ac b/configure.ac
index ab8f5b3..f7e24c7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,6 +40,18 @@ AC_ARG_WITH([dtb],
AS_HELP_STRING([--with-dtb], [Specify a particular DTB to use]),
[KERN_DTB="$withv
On 15/12/16 09:52, Jan Beulich wrote:
On 08.12.16 at 12:38, wrote:
>> The memory clobber is rather harsh here. However, fic.exn_raised may be
>> modified as a side effect, so we need to let the compiler know that all
>> of "fic" may be changed (preventing it from moving around accesses to
>>
Hi Andre,
On 22/11/16 15:09, Andre Przywara wrote:
From: Christoffer Dall
Support adding xen,xen-bootargs node via --with-xen-bootargs to the
Based the code, the configure option is --with-xen-cmdline.
configure script and automatically add the Dom0 node to the DT as well.
Signed-off-by:
On Mon, Dec 12, 2016 at 02:50:20PM +, Andre Przywara wrote:
> Hi Konrad,
>
> On 12/12/16 14:47, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 22, 2016 at 03:09:17PM +, Andre Przywara wrote:
> >> From: Christoffer Dall
> >>
> >> When doing a make clean, only the output image currently confi
flight 103329 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103329/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 103065
test-armhf-armhf-libvirt-xsm 13
On 12/14/16 19:29 +0800, Haozhong Zhang wrote:
Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and
vmfail_invalid(), which are consistent to the pseudo code on Intel
SDM, and allow to return VM instruction error numbers to L1
hypervisor.
Signed-off-by: Haozhong Zhang
---
* This patc
On 15/12/16 09:57, Jan Beulich wrote:
On 09.12.16 at 16:27, wrote:
> On 09.12.16 at 16:19, wrote:
>> On 09.12.16 at 15:56, wrote:
It is a layering violation to remove the host_has_* part of the check
from the emulator.
>>> This is from a very, very abstract perspective. Th
Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and
vmfail_invalid(), which are consistent to the pseudo code on Intel
SDM, and allow to return VM instruction error numbers to L1
hypervisor.
Signed-off-by: Haozhong Zhang
---
Changes in v2:
* Fix the incorrect eflags in vmfail_invalid
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> As Robert pointed out, a read-only transaction cannot normally be
> aborted by a serialization failure on COMMIT. Under exceptional
> conditions,
On 15/12/16 12:06, Haozhong Zhang wrote:
> Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and
> vmfail_invalid(), which are consistent to the pseudo code on Intel
> SDM, and allow to return VM instruction error numbers to L1
> hypervisor.
>
> Signed-off-by: Haozhong Zhang
> ---
> Chan
The autotools documentation states that AC_CHECK_FILE cannot be used when
cross-compiling [1], because it's meant to check files in the target
system, not on the build host. When just giving --host on the configure
command line, the script detects cross compilation rather late; and as the
file test
These patches allow to include a Xen hypervisor binary into a boot-wrapper
ELF file, so that a Foundation Platform or a Fast Model can boot a Xen
system (including a Dom0 kernel).
The original patches have been around for a while, so this series is
merely an update to apply on the latest boot-wrapp
From: Christoffer Dall
When doing a make clean, only the output image currently configured to
build is being removed. However, one would expect all build artifacts
to be removed when doing a 'make clean' and when switching between Xen
and Linux builds, it is easy to accidentally run an older bui
From: Ian Campbell
If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
the usual ttyAMA0 otherwise.
Signed-off-by: Ian Campbell
Signed-off-by: Christoffer Dall
Signed-off-by: Andre Przywara
Reviewed-by: Julien Grall
Tested-by: Konrad Rzeszutek Wilk
---
configure.ac | 3
From: Christoffer Dall
Add support for building a Xen binary which includes a Dom0 image and
the Dom0 command-line.
If the user specifies --with-xen=, where Xen is an appropriate
AArch64 Xen binary, the build system will generate a xen-system.axf
instead of a linux-system.axf.
Original patch fr
From: Christoffer Dall
Support adding xen,xen-bootargs node via --with-xen-cmdline to the
configure script and automatically add the Dom0 node to the DT as well.
Signed-off-by: Christoffer Dall
Signed-off-by: Andre Przywara
Tested-by: Konrad Rzeszutek Wilk
Reviewed-by: Julien Grall
---
Make
On 12/15/16 12:18 +, Andrew Cooper wrote:
On 15/12/16 12:06, Haozhong Zhang wrote:
Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and
vmfail_invalid(), which are consistent to the pseudo code on Intel
SDM, and allow to return VM instruction error numbers to L1
hypervisor.
Signe
On 14/12/16 07:37, Razvan Cojocaru wrote:
> 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 CMPXC
From: "Edgar E. Iglesias"
We usually cross-compile the Xen tools for ARM in Yocto, including
support for xentop.
These patches remove two blockers in the Makefiles for cross-compiled
xentop.
Cheers,
Edgar
Edgar E. Iglesias (2):
tools/xenstat: Remove redundant check for curses.h
tools/xenst
From: "Edgar E. Iglesias"
This check for curses.h does not consider cross-compilation.
It only checks host paths.
Luckily, commit 65da4913214120ddc95bd846cb3649a29f87146a
introduced proper configure checks for ncurses so we can
remove the redundant check in the Makefile.
Signed-off-by: Edgar E.
On 15/12/16 12:32, Haozhong Zhang wrote:
> On 12/15/16 12:18 +, Andrew Cooper wrote:
>> On 15/12/16 12:06, Haozhong Zhang wrote:
>>> Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and
>>> vmfail_invalid(), which are consistent to the pseudo code on Intel
>>> SDM, and allow to retur
From: "Edgar E. Iglesias"
This partially reverts 16504669c5cbb8b195d20412aadc838da5c428f7
since xentop cross-compiles fine.
Signed-off-by: Edgar E. Iglesias
---
tools/xenstat/Makefile | 4
1 file changed, 4 deletions(-)
diff --git a/tools/xenstat/Makefile b/tools/xenstat/Makefile
index 0
branch xen-4.4-testing
xenbranch xen-4.4-testing
job test-xtf-amd64-amd64-3
testid leak-check/check
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xen
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm
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
Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and
vmfail_invalid(), which are consistent to the pseudo code on Intel
SDM, and allow to return VM instruction error numbers to L1
hypervisor.
Signed-off-by: Haozhong Zhang
Acked-by: Andrew Cooper
---
Changes in v3:
* Replace VMSUCCEED
On 15/12/16 09:54, Jan Beulich wrote:
On 09.12.16 at 09:47, wrote:
> On 08.12.16 at 18:33, wrote:
>>> On 08/12/16 16:01, Jan Beulich wrote:
That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
>>> Which commit?
>> Oops - initially I had intended the title to include t
>>> On 15.12.16 at 13:32, wrote:
> On 14/12/16 07:37, Razvan Cojocaru wrote:
>> 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 avo
flight 103401 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103401/
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 14/12/16 21:18, Edgar E. Iglesias wrote:
On Wed, Dec 14, 2016 at 03:59:00PM +0100, Dario Faggioli wrote:
On Tue, 2016-12-13 at 19:00 +, Julien Grall wrote:
Hi all,
Stefano suggested to move the call at 5pm and I haven't seen any
disagreement.
So the call will be tomorrow (Wednesday 14t
On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson wrote:
> However, in that example, as you seem to allude to, there is still a
> complete serialisation of all the transactions, even the failed T3:
> T1,T2,T3. The database has detected the problem before returning data
> in T3 that would contradict t
flight 103323 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103323/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 11 guest-start fail REGR. vs. 103209
test-armhf-armh
Despite all attempts so far (ending in commit fecf584294 ["Config.mk:
fix comment for debug option"] adjusting the respective comment),
Config.mk's debug= setting still affects the hypervisor build: CFLAGS
gets -g added there.
xen/arch/x86/boot/build32.mk includes that file, and hence inherits the
On 15/12/16 14:04, Jan Beulich wrote:
> Despite all attempts so far (ending in commit fecf584294 ["Config.mk:
> fix comment for debug option"] adjusting the respective comment),
> Config.mk's debug= setting still affects the hypervisor build: CFLAGS
> gets -g added there.
>
> xen/arch/x86/boot/buil
On 09/12/16 08:59, Jan Beulich wrote:
On 08.12.16 at 18:51, wrote:
>> On 08/12/16 16:02, Jan Beulich wrote:
>>> variable. With an IRQ happening at the deepest point of the stack, and
>>> with send_guest_pirq() being called from there (leading to vcpu_kick()
>>> -> ... -> csched_vcpu_wake() ->
>>> On 15.12.16 at 13:52, wrote:
> On 15/12/16 09:54, Jan Beulich wrote:
> On 09.12.16 at 09:47, wrote:
>> On 08.12.16 at 18:33, wrote:
On 08/12/16 16:01, Jan Beulich wrote:
> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
Which commit?
>>> Oops - initi
The first patch corrects description of __cpuhp_setup_state()'s possible
return values and the second fixes a bug (which causes Xen guests to crash).
As a follow-up question for the first patch --- should we allow calling
__cpuhp_setup_state() with state in [CPUHP_AP_ONLINE_DYN + 1 ..
CPUHP_AP_ON
>>> On 15.12.16 at 15:15, wrote:
> On 09/12/16 08:59, Jan Beulich wrote:
> On 08.12.16 at 18:51, wrote:
>>> On 08/12/16 16:02, Jan Beulich wrote:
variable. With an IRQ happening at the deepest point of the stack, and
with send_guest_pirq() being called from there (leading to vcpu_ki
>>> On 15.12.16 at 13:03, wrote:
> On 15/12/16 09:57, Jan Beulich wrote:
> On 09.12.16 at 16:27, wrote:
>> On 09.12.16 at 16:19, wrote:
>>> On 09.12.16 at 15:56, wrote:
> It is a layering violation to remove the host_has_* part of the check
> from the emulator.
This is
Since cpu hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state,
successful callback initialization will result in cpuhp_setup_state()
returning a positive value. Therefore acpi_cpufreq_online being zero
indicates that callbacks have not been installed.
This means that acpi_cpufreq_boost_e
When ivoked with CPUHP_AP_ONLINE_DYN state __cpuhp_setup_state()
is expected to return positive value which is the hotplug state that
the routine assigns.
Signed-off-by: Boris Ostrovsky
---
kernel/cpu.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/kernel/cpu.c b
>>> On 15.12.16 at 12:04, wrote:
> On 15/12/16 09:49, Jan Beulich wrote:
> On 06.12.16 at 11:51, wrote:
>>> As such clearing of flags may have an impact on the selected rendezvous
>>> function, handle such in a central place.
>>>
>>> But don't allow such feature flags to be cleared during CPU
Ian Jackson writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"):
> Andrew Cooper writes ("Re: [xen-4.5-testing test] 103161: regressions -
> FAIL"):
> > These leak check failures are because the XSA-195 PoC is somehow causing
> > qemu to segfault. I cant explain why, because qemu sho
flight 103339 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103339/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 5f54a923b496210af833b902afcc56b1982818a4
baseline version:
xtf 1f021c88130b4d2d818ba4
>>> On 06.12.16 at 14:46, wrote:
> ...as a set of hypercalls to be used by a device model.
>
> As stated in the new docs/designs/dm_op.markdown:
>
> "The aim of DMOP is to prevent a compromised device model from
> compromising domains other then the one it is associated with. (And is
> therefore
>>> On 06.12.16 at 14:46, wrote:
> switch ( op.op )
> {
> +case XEN_DMOP_create_ioreq_server:
> +{
> +struct domain *curr_d = current->domain;
> +struct xen_dm_op_create_ioreq_server *data =
> +&op.u.create_ioreq_server;
> +
> +rc = -EINVAL;
>
On 15/12/16 14:59, Jan Beulich wrote:
On 15.12.16 at 15:15, wrote:
>> On 09/12/16 08:59, Jan Beulich wrote:
>> On 08.12.16 at 18:51, wrote:
On 08/12/16 16:02, Jan Beulich wrote:
> variable. With an IRQ happening at the deepest point of the stack, and
> with send_guest_pirq()
On 15/12/16 14:16, Jan Beulich wrote:
On 15.12.16 at 13:52, wrote:
>> On 15/12/16 09:54, Jan Beulich wrote:
>> On 09.12.16 at 09:47, wrote:
>>> On 08.12.16 at 18:33, wrote:
> On 08/12/16 16:01, Jan Beulich wrote:
>> That commit ("VT-d: use msi_compose_msg()) together with 15
flight 103406 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103406/
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 06.12.16 at 14:46, wrote:
> @@ -68,6 +70,35 @@ static int
> copy_buf_to_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
> return copy_to_guest(buf.h, src, size) ? -EFAULT : 0;
> }
>
> +static int track_dirty_vram(struct domain *d,
> +unsigned int nr_
>>> On 06.12.16 at 14:46, wrote:
> --- a/xen/include/public/hvm/dm_op.h
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -191,6 +191,49 @@ struct xen_dm_op_track_dirty_vram {
> uint64_aligned_t first_pfn;
> };
>
> +/*
> + * XEN_DMOP_set_pci_intx_level: Set the logical level of one of a domain's
On 06/12/16 11:25, Jan Beulich wrote:
> Their size parameters being "unsigned", there's neither a point for
> them returning "unsigned long", nor for any of their (assembly)
> arithmetic to involved 64-bit operations on other than addresses.
>
> Take the opportunity and fold __do_clear_user() into
Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with
15aa6c6748 ("amd iommu: use base platform MSI implementation"),
introducing the use of a per-CPU scratch CPU mask, went too far:
dma_msi_set_affinity() may, at least in theory, be called in
interrupt context, and hence the use of that s
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson
> wrote:
> > [...] Are there other reasons,
> > besides previously suppressed serialisation failur
flight 103347 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103347/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aaa61995af9e0b65c37bdad6796867760fa1d5fe
baseline version:
ovmf dc756baeda55490202f31
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 December 2016 15:23
> To: Paul Durrant
> Cc: Andrew Cooper ; Ian Jackson
> ; Jennifer Herbert ;
> Wei Liu ; xen-de...@lists.xenproject.org; Daniel De
> Graaf
> Subject: Re: [PATCH v2 1/8] public / x86: Introduc
On 15/12/16 15:53, Jan Beulich wrote:
> Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with
> 15aa6c6748 ("amd iommu: use base platform MSI implementation"),
> introducing the use of a per-CPU scratch CPU mask, went too far:
> dma_msi_set_affinity() may, at least in theory, be called in
>>> On 06.12.16 at 14:46, wrote:
> @@ -142,18 +143,77 @@ static int set_isa_irq_level(struct domain *d, uint8_t
> isa_irq,
> return 0;
> }
>
> +static int modified_memory(struct domain *d, xen_pfn_t *first_pfn,
> + unsigned int *nr)
> +{
> +xen_pfn_t last_pfn
>>> On 06.12.16 at 14:46, wrote:
> --- a/xen/arch/x86/hvm/dm.c
> +++ b/xen/arch/x86/hvm/dm.c
> @@ -199,6 +199,87 @@ static int modified_memory(struct domain *d, xen_pfn_t
> *first_pfn,
> return rc;
> }
>
> +static bool allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
> +{
> +retu
Boris,
with today's kernel the system isn't coming up when booted as Xen dom0:
[ 33.575326] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
[swapper/0:1]
[ 33.589795] Modules linked in:
[ 33.596015] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-pv+ #687
[ 33.608844] Hardware name:
Hi George,
On 15/12/16 04:54, George Dunlap wrote:
On Wed, Dec 14, 2016 at 8:05 PM, Julien Grall wrote:
Note that ARM does not provide any hardware instruction to translate
an IPA (guest physical address) to a PA. So we have a walker there.
We also a walk for debugging guest page table (thoug
On 12/12/16 19:05, Dejan Markic wrote:
> Hello all,
>
> sorry, as this might be a stupid question for some of you, but I
> wonder why here:
>
> https://github.com/mirage/xen/blob/master/tools/firmware/hvmloader/smbios.c#L438
>
>
> You allow almost everything to be overwritten in SMBIOS type 1 table
>>> On 06.12.16 at 14:46, wrote:
> +struct xen_dm_op_inject_trap {
> +/* IN - index of vCPU */
> +uint32_t vcpuid;
> +/* IN - interrupt vector */
> +uint8_t vector;
> +/* IN - trap type (DMOP_TRAP_* ) */
> +uint8_t type;
> +/* NB. This enumeration precisely matches hvm.h:X8
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 December 2016 15:45
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; xen-de...@lists.xenproject.org; Daniel
> De Graaf ; Tim (Xen.org)
> Subject: Re: [PATCH v2 3/8] dm_op: co
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 15 December 2016 16:06
> To: Paul Durrant
> Cc: Andrew Cooper ; Daniel De Graaf
> ; Wei Liu ; Ian Jackson
> ; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 15 December 2016 16:23
> To: Paul Durrant
> Cc: Andrew Cooper ; Daniel De Graaf
> ; Wei Liu ; Ian Jackson
> ; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH
On Thu, Dec 15, 2016 at 9:53 AM, Ian Jackson wrote:
> I don't think "set max_pred_locks_per_transaction generously" is a
> practical thing to write in the documentation, because the application
> programmer, or admin, has no sensible way to calculate what a
> sufficiently generous value is.
ok
Hello,
We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon
L5640 and Xeon L5520). The same xen binary boots fine on a third server with a
Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01
instead of -02 (gcc 4.9.2-10 from Debian jessie).
I've att
>>> On 09.12.16 at 16:44, wrote:
> +/*
> + * DESIGN PRINCIPLES FOR THE SAFETY OF LIBELF
> + *
> + * libelf is a complex piece of code on a security boundary: when
> + * built as part of the tools, it parses guest kernels and loads them
> + * into guest memory. Bugs in libelf can become privilege
On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
> with today's kernel the system isn't coming up when booted as Xen dom0:
Remind me again pls, is dom0 even supposed to load microcode? Isn't the
hypervisor supposed to apply microcode?
> Looking into the state of cpu 1 I find the fol
On 15/12/16 16:33, Vincent Legout wrote:
> Hello,
>
> We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon
> L5640 and Xeon L5520). The same xen binary boots fine on a third server with a
> Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01
> instead
On Thu, 15 Dec 2016, Boris Ostrovsky wrote:
> Since cpu hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state,
> successful callback initialization will result in cpuhp_setup_state()
> returning a positive value. Therefore acpi_cpufreq_online being zero
> indicates that callbacks have not
1 - 100 of 156 matches
Mail list logo
