flight 96371 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 5 xen-build fail REGR. vs. 96296
test-armhf-armhf-xl
AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.
Signed-off-by: Luwei Kang
---
[V4]:
Update the description about features dependency.
[V3]:
Adjust dependencies betw
flight 96367 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96367/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 94856
test-amd64
flight 96444 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96444/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96439 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96439/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96435 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: ovmf https://g
flight 96430 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96428 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96422 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96422/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96374 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96374/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 80927
test-amd64-amd64
flight 96418 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96418/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96416 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96411 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96411/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: ovmf https://gi
flight 96408 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96394 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96394/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96399 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96399/
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 12
branch xen-unstable
xenbranch xen-unstable
job build-armhf-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 08cffe6696
On 06/29/2016 10:39 AM, Konrad Rzeszutek Wilk wrote:
Hey Jens,
Please git pull the 'stable/for-jens-4.7' branch which is based on your
'for-4.7/drivers' branch. It will nicely merge in your 'for-linus' branch:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jen
On 06/28/2016 09:41 AM, Boris Ostrovsky wrote:
> On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>> On 06/27/2016 06:29 AM, Julien Grall wrote:
(CC Boris and Doug)
Hi Shannon,
On 27/06/16 07:01, Shannon Zhao wrote:
> On 2016/6/
I have been trying to trace a problem when using Fedora's qemu with a pv
guest which is that no graphics are available. I get the errors
xen be core: xen be: watching backend path (backend/console/2) failed
xen be core: xen be: watching backend path (backend/vkbd/2) failed
xen be core: xen be: w
On Tue, Jun 28, 2016 at 1:37 AM, Jan Beulich wrote:
On 27.06.16 at 20:08, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3376,7 +3376,29 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
flight 96376 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96376/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96382 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96382/
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 12
On Sat, 2016-06-25 at 20:48 -0400, Tianyang Chen wrote:
> Vcpu flags are checked and cleared atomically. Performance can be
> improved with corresponding non-atomic versions since schedule.c
> already has spin_locks in place.
>
> Signed-off-by: Tianyang Chen
>
Reviewed-by: Dario Faggioli
Thanks
Hey Jens,
Please git pull the 'stable/for-jens-4.7' branch which is based on your
'for-4.7/drivers' branch. It will nicely merge in your 'for-linus' branch:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.7
which has one fix for migration of guest. We fou
On Wed, 2016-06-29 at 10:18 +, osstest service owner wrote:
> flight 96351 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/96351/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-armhf-xsm
On 29/06/16 17:19, Vitaly Kuznetsov wrote:
> Vitaly Kuznetsov writes:
>
>> > Andrew Cooper writes:
>> >
>>> >> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>>> Andrew Cooper writes:
>>>
> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>> > @@ -1808,6 +1822,8 @@ static int xe
In summary, there's a problem
An indication of the guest trying to allocate more memory that the host
admin has allowed.
that's filling logs with 10s of thousands of redundant log entries, with
a suspicion that it's 'ballooning' issue in the guest
Perhaps something wrong in the gue
On Sat, 2016-06-25 at 20:48 -0400, Tianyang Chen wrote:
> No functional change:
> -aligned comments in rt_vcpu struct
> -removed double underscores from the names of some functions
> -fixed coding sytle for control structures involving lists
> -fixed typos in the comments
> -added comments for
Vitaly Kuznetsov writes:
> Andrew Cooper writes:
>
>> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>>> Andrew Cooper writes:
>>>
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
> *self, unsigned long action,
>>> On 29.06.16 at 17:38, wrote:
> On 06/29/2016 07:17 AM, Jan Beulich wrote:
>> I don't think a guest would itself issue any relevant messages.
>
> You mentioned ballooning in the guest. The doc I found addressed
> ballooning, in the guest.
>
> If not that, then what output, with specificity,
On Wed, Jun 29, 2016 at 05:50:48PM +0200, Juergen Gross wrote:
> The qdisk implementation is using the native xenbus protocol only in
> case of no protocol specified at all. As using the explicit 32- or
> 64-bit protocol is slower than the native one due to copying requests
> not by memcpy but elem
The qdisk implementation is using the native xenbus protocol only in
case of no protocol specified at all. As using the explicit 32- or
64-bit protocol is slower than the native one due to copying requests
not by memcpy but element for element, this is not optimal.
Correct this by using the native
Hi Julien,
On 22.06.2016 17:26, Julien Grall wrote:
Hello Dirk,
On 21/06/16 11:16, Dirk Behme wrote:
Some clocks might be used by the Xen hypervisor and not by the Linux
kernel. If these are not registered by the Linux kernel, they might be
disabled by clk_disable_unused() as the kernel doesn'
[Cc-ing Roger and Wei, which have *BSD experience]
On Tue, 2016-06-28 at 18:00 -0700, John Nemeth wrote:
> I'm trying to package Xen 4.6 (specifically Xen 4.6.3) for
> use with NetBSD. I have it mostly done; however, when I try to
> create a domU, libxl goes into an infinite loop calling the
On 29/06/16 16:00, Amitoj Kaur Chawla wrote:
> The kernel.h macro DIV_ROUND_UP performs the computation
> (((n) + (d) - 1) /(d)) but is perhaps more readable.
>
> The Coccinelle script used to make this change is as follows:
> @haskernel@
> @@
>
> #include
>
> @depends on haskernel@
> expressio
On 29/06/16 17:20, Anthony PERARD wrote:
> On Fri, Jun 17, 2016 at 01:14:56PM +0200, Juergen Gross wrote:
>> The qdisk implementation is using the native xenbus protocol only in
>> case of no protocol specified at all. As using the explicit 32- or
>> 64-bit protocol is slower than the native one du
On 29/06/16 17:34, Jan Beulich wrote:
On 29.06.16 at 17:00, wrote:
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -591,7 +591,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
>> {
>> unsigned long va = dtr->address;
>> unsigned int size = dtr->si
On 06/29/2016 07:17 AM, Jan Beulich wrote:
I don't think a guest would itself issue any relevant messages.
You mentioned ballooning in the guest. The doc I found addressed
ballooning, in the guest.
If not that, then what output, with specificity, would be helpful in
troubleshooting this ?
>>> On 29.06.16 at 17:00, wrote:
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -591,7 +591,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
> {
> unsigned long va = dtr->address;
> unsigned int size = dtr->size + 1;
> - unsigned pages = (size + PA
On 06/29/2016 03:51 AM, Xu, Quan wrote:
On June 15, 2016 7:49 PM, < wei.l...@citrix.com > wrote:
On Tue, Jun 14, 2016 at 12:32:19PM +0200, Andrea Genuise wrote:
[...]
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
/local/domain/748/backend/vtpm/749/0/state (hoping for state c
On Fri, Jun 17, 2016 at 01:14:56PM +0200, Juergen Gross wrote:
> The qdisk implementation is using the native xenbus protocol only in
> case of no protocol specified at all. As using the explicit 32- or
> 64-bit protocol is slower than the native one due to copying requests
> not by memcpy but elem
This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor. The policy provided by the bootloader, if present, will
override the built-in
On 06/29/2016 06:58 AM, Ian Jackson wrote:
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 96330: regressions -
trouble: blocked/broken/fail/pass"):
On 28.06.16 at 21:16, wrote:
This latter one is
objcopy -S -I binary -O elf64-little --rename-section=.data=.init.xsm_policy
policy.bi
The kernel.h macro DIV_ROUND_UP performs the computation
(((n) + (d) - 1) /(d)) but is perhaps more readable.
The Coccinelle script used to make this change is as follows:
@haskernel@
@@
#include
@depends on haskernel@
expression n,d;
@@
(
- (n + d - 1) / d
+ DIV_ROUND_UP(n,d)
|
- (n + (d - 1)
>>> On 29.06.16 at 13:27, wrote:
> AVX-512 is an extention of AVX2. Its spec can be found at:
> https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
> This patch detects AVX-512 features by CPUID.
>
> Signed-off-by: Luwei Kang
> ---
> [V3]
> 1.adjust dependencies between
>>> On 29.06.16 at 13:45, wrote:
> From table 2-2 I can see that
> AVX512F = AVX512F & AVX512VL
> AVX512CD = AVX512F & AVX512VL & AVX512CD
> AVX512DQ = AVX512F & AVX512VL & AVX512DQ
> AVX512BW = AVX512F & AVX512VL & AVX512BW
> AVX512IFMA = AVX512F & AVX512VL & AVX512IFMA
> A
>>> On 29.06.16 at 13:21, wrote:
> The other reason I am hesitant about PTR_ERR() is that it obfuscates the
> semantics sufficiently for Coverity to give up.
Mind giving some more detail? These inline functions aren't all that
obfuscating - just a couple of casts. If that's enough to confuse
Cove
>>> On 29.06.16 at 14:58, wrote:
> On 06/29/2016 03:07 AM, Jan Beulich wrote:
>>> What needs to be fixed, or if of no concern, can these messages be silenced?
>>
>> Perhaps something wrong in the guest's balloon driver.
>
> I'm seeing these @host log-entries for Ubuntu, Arch & Opensuse guests.
>
>>> On 29.06.16 at 13:37, wrote:
> On 29/06/16 11:03, Jan Beulich wrote:
> On 29.06.16 at 11:50, wrote:
>>> On 29/06/16 03:20, Luwei Kang wrote:
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -235,6 +235,10 @@ def crunch_numbers(state):
# subsequent
fyi, per
Verify Xen Project PVHVM drivers are working in the Linux HVM guest
kernel
http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers
"Run "dmesg | egrep -i 'xen|front'" in the HVM guest VM."
with Guest cmd line,
... systemd.log_level=debug systemd.log_target=
On 29/06/16 15:31, Ross Lagerwall wrote:
> On 06/29/2016 02:00 PM, Juergen Gross wrote:
>> On 29/06/16 14:52, Andrew Cooper wrote:
>>> On 29/06/16 13:44, Juergen Gross wrote:
@@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
/* Tell the kernel we're up and running. */
flight 96355 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96355/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
build-amd64-libvi
On 2016年06月29日 17:42, Julien Grall wrote:
> On 29/06/2016 10:29, Shannon Zhao wrote:
>>
>>
>> On 2016/6/27 18:17, Julien Grall wrote:
>>> On 27/06/16 02:44, Shannon Zhao wrote:
On 2016/6/24 0:26, Julien Grall wrote:
> On 23/06/16 04:16, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
On 06/29/2016 02:00 PM, Juergen Gross wrote:
On 29/06/16 14:52, Andrew Cooper wrote:
On 29/06/16 13:44, Juergen Gross wrote:
@@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
/* Tell the kernel we're up and running. */
xenbus_notify_running();
-#if defined(XEN_SYSTEMD_ENA
On 29/06/16 14:52, Andrew Cooper wrote:
> On 29/06/16 13:44, Juergen Gross wrote:
>> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
>> /* Tell the kernel we're up and running. */
>> xenbus_notify_running();
>>
>> -#if defined(XEN_SYSTEMD_ENABLED)
>> -if (systemd) {
>> -
On 06/29/2016 03:07 AM, Jan Beulich wrote:
What are these 'Over-allocation' messages?
An indication of the guest trying to allocate more memory that the
host admin has allowed.
currently, each guest has allocated
maxmem = 2048
memory = 2048
What needs to be fixed, or if of no concern,
On 29/06/16 13:44, Juergen Gross wrote:
> @@ -2068,13 +1964,6 @@ int main(int argc, char *argv[])
> /* Tell the kernel we're up and running. */
> xenbus_notify_running();
>
> -#if defined(XEN_SYSTEMD_ENABLED)
> - if (systemd) {
> - sd_notify(1, "READY=1");
> -
Andrew Cooper writes:
> On 29/06/16 13:16, Vitaly Kuznetsov wrote:
>> Andrew Cooper writes:
>>
>>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
@@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
*self, unsigned long action,
int cpu = (long)hcpu;
sw
On 31/05/16 17:56, Bhaktipriya Shridhar wrote:
> System workqueues have been able to handle high level of concurrency
> for a long time now and there's no reason to use dedicated workqueues
> just to gain concurrency. Replace dedicated xenbus_frontend_wq with the
> use of system_wq.
>
> Unlike a
On 01/06/16 15:15, Bhaktipriya Shridhar wrote:
> System workqueues have been able to handle high level of concurrency
> for a long time now and there's no reason to use dedicated workqueues
> just to gain concurrency. Replace dedicated xen_pcibk_wq with the
> use of system_wq.
>
> Unlike a dedica
Add a configuration option to /etc/sysconfig/xencommons to let the
user configure whether he wants to start xenstore service as a daemon
or as a stubdom.
Juergen Gross (2):
tools: remove systemd xenstore socket definitions
tools: make xenstore domain easy configurable
tools/configure
Add configuration entries to sysconfig.xencommons for selection of the
xenstore type (domain or daemon) and start the selected xenstore
service via a script called from sysvinit or systemd.
Signed-off-by: Juergen Gross
---
tools/configure| 2 +-
tools/hotplug
On a system with systemd the xenstore sockets are created via systemd.
Remove the related configuration files in order to be able to decide
at runtime whether the sockets should be created or not. This will
enable Xen to start xenstore either via a daemon or via a stub domain.
Signed-off-by: Juerg
On 27/06/16 08:24, Jan Beulich wrote:
On 24.06.16 at 17:01, wrote:
>> On 07/06/16 07:31, Jan Beulich wrote:
>>> - drop unused function parameter of read_dev_bar()
>>> - drop rom_init() (now identical to bar_init())
>>> - fold read_dev_bar() into its now single caller
>>> - simplify determinat
flight 96373 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96373/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
On 29/06/16 10:16, Vitaly Kuznetsov wrote:
> David Vrabel writes:
>
>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>> and unlike plain kexec where we do
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> shared_info page has space for 32 vcpu info slots for first 32 vCPUs but
> these are the first 32 vCPUs from Xen's perspective and we should map them
> accordingly with the newly introduced xen_vcpu_id mapping.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
On 29/06/16 13:16, Vitaly Kuznetsov wrote:
> Andrew Cooper writes:
>
>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
>>> *self, unsigned long action,
>>> int cpu = (long)hcpu;
>>> switch (action) {
>>> case CP
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> HYPERVISOR_vcpu_op passes Linux's idea of vCPU id as a parameter while
> Xen's idea is expected. In some cases these ideas diverge so we need to
> do remapping.
>
> There is an issue, however. PV guests do VCPUOP_is_up very early
> (see xen_fill_possibl
Hi Andrew,
On 28/06/2016 18:21, Andrew Cooper wrote:
On 28/06/16 17:17, Julien Grall wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f11094e..5ffc3df 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1211,20 +1211,20 @@ int unmap_mmio_regions(struct domain *d,
}
Andrew Cooper writes:
> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
>> *self, unsigned long action,
>> int cpu = (long)hcpu;
>> switch (action) {
>> case CPU_UP_PREPARE:
>> +/* vLAPIC_ID == Xen
On 29/06/2016 12:55, Dirk Behme wrote:
On 29.06.2016 13:47, Julien Grall wrote:
To be honest, the device-tree bindings does not mention any estimation
(see [2]). I have noticed that some pages on the wiki use hardcoded DT
(see [3]). So the documentation needs to be fixed.
Which ignores the
On 29.06.2016 13:47, Julien Grall wrote:
On 29/06/2016 12:31, Dirk Behme wrote:
On 29.06.2016 13:08, Dirk Behme wrote:
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error:
On 29/06/2016 12:31, Dirk Behme wrote:
On 29.06.2016 13:08, Dirk Behme wrote:
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule
From table 2-2 I can see that
AVX512F = AVX512F & AVX512VL
AVX512CD = AVX512F & AVX512VL & AVX512CD
AVX512DQ = AVX512F & AVX512VL & AVX512DQ
AVX512BW = AVX512F & AVX512VL & AVX512BW
AVX512IFMA = AVX512F & AVX512VL & AVX512IFMA
AVX512VBMI = AVX512F & AVX512VL & AVX512VBMI
Fro
flight 96353 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96353/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
Hi Julien,
On 29.06.2016 13:33, Julien Grall wrote:
On 29/06/2016 12:08, Dirk Behme wrote:
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodul
On 29/06/16 11:03, Jan Beulich wrote:
On 29.06.16 at 11:50, wrote:
>> On 29/06/16 03:20, Luwei Kang wrote:
>>> --- a/xen/tools/gen-cpuid.py
>>> +++ b/xen/tools/gen-cpuid.py
>>> @@ -235,6 +235,10 @@ def crunch_numbers(state):
>>> # subsequent instruction groups may only be VEX encoded
On 29/06/2016 12:08, Dirk Behme wrote:
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_siz
On 29.06.2016 13:08, Dirk Behme wrote:
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage
AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.
Signed-off-by: Luwei Kang
---
[V3]
1.adjust dependencies between features.
[V2]
1.one per bit, change from
> + x
On 29.06.2016 13:08, Dirk Behme wrote:
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage
On 29/06/16 12:11, Tim Deegan wrote:
> At 03:55 -0600 on 29 Jun (1467172554), Jan Beulich wrote:
> On 28.06.16 at 20:56, wrote:
>>> Using PTR_ERR() is less disruptive to the code, but will cause
>>> collateral damage for anyone with out-of-tree patches, as the code will
>>> compile but the err
flight 96364 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96364/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
At 03:55 -0600 on 29 Jun (1467172554), Jan Beulich wrote:
> >>> On 28.06.16 at 20:56, wrote:
> > Using PTR_ERR() is less disruptive to the code, but will cause
> > collateral damage for anyone with out-of-tree patches, as the code will
> > compile but the error logic will be wrong. The use of PTR
Hi Julien,
On 29.06.2016 12:32, Julien Grall wrote:
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
bootmodule size: %lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+p
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 96330: regressions -
trouble: blocked/broken/fail/pass"):
> On 28.06.16 at 21:16, wrote:
> This latter one is
>
> objcopy -S -I binary -O elf64-little --rename-section=.data=.init.xsm_policy
> policy.bin policy.o
...
> :policy.o: Invalid
flight 96368 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96368/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64-xsm
flight 96369 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96369/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen 3cdad93704aaa8bf1f274969e401ca21152bc4a2
baseline version:
xen 8384dc2d95538c5910
Hi Dirk,
On 27/06/2016 08:53, Dirk Behme wrote:
+if ( (end - start) > size ) {
+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes > bootmodule size:
%lu bytes\n",
+ zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the
flight 96351 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96351/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 5 xen-build fail REGR. vs. 96296
test-armhf-armhf-xl-
>>> On 29.06.16 at 02:06, wrote:
> What are these 'Over-allocation' messages?
An indication of the guest trying to allocate more memory that the
host admin has allowed.
> What needs to be fixed, or if of no concern, can these messages be silenced?
Perhaps something wrong in the guest's balloon
>>> On 29.06.16 at 11:50, wrote:
> On 29/06/16 03:20, Luwei Kang wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -235,6 +235,10 @@ def crunch_numbers(state):
>> # subsequent instruction groups may only be VEX encoded.
>> AVX: [FMA, FMA4, F16C, AVX2, X
>>> On 28.06.16 at 20:56, wrote:
> On 28/06/16 18:56, Andrew Cooper wrote:
>>
>>
>> This is the first in a number of changes trying to clean up error reporting
> of
>> memory conditions.
>
> One area which is constantly causing problems is creation of domains in
> low memory conditions. In the
On 29/06/16 10:50, Andrew Cooper wrote:
> On 29/06/16 03:20, Luwei Kang wrote:
>> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
>> index 7c45eca..897e660 100755
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -235,6 +235,10 @@ def crunch_numbers(state):
>>
>>> On 28.06.16 at 19:58, wrote:
> On 28/06/16 18:56, Andrew Cooper wrote:
>> assign_pages() has a return type of int, but uses for a boolean value. As
>> there are two distinct failure cases, return a more meaningful error.
>
> Sorry - sent an out of date version. This sentence actually reads
On 29/06/16 03:20, Luwei Kang wrote:
> AVX-512 is an extention of AVX2. Its spec can be found at:
> https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
> This patch detects AVX-512 features by CPUID.
>
> Signed-off-by: Luwei Kang
> ---
> xen/arch/x86/hvm/hvm.c
1 - 100 of 112 matches
Mail list logo
