flight 100588 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 100385
Regressions which ar
flight 100587 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100587/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 100383
Regres
Vrabel ,Konrad Rzeszutek Wilk
,Michael Brown ,Juergen Gross
,Andrew Cooper ,Andy Shevchenko
,Paul Gortmaker
,"xen-de...@lists.xensource.com"
,Andi Kleen
,pali.ro...@gmail.com,dvh...@infradead.org,platform-driver-...@vger.kernel.org,Michal
Marek ,Rasmus Villemoes ,Jiri
Kosina ,=?UTF-8?B?7KGw
From: Wei Yongjun
The callback function of call_rcu() just calls a kfree(), so we
can use kfree_rcu() instead of call_rcu() + callback function.
Signed-off-by: Wei Yongjun
---
drivers/net/xen-netback/hash.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/driv
On 2016/8/22 22:57, Jan Beulich wrote:
On 22.08.16 at 15:09, wrote:
On 2016/8/22 20:04, Jan Beulich wrote:
On 22.08.16 at 13:41, wrote:
On August 22, 2016 6:36 PM, wrote:
On 19.08.16 at 14:58, wrote:
From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu
Da
AVX512 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 AVX512 features by CPUID.
Signed-off-by: Luwei Kang
---
[V5]:
Modify the comment of dependency between AVX512 and AVX2.
[V4]:
Update the descrip
On Thu, 28 Jul 2016, Julien Grall wrote:
> Mapping the root table is always done the same way. To avoid duplicating
> the code in a later patch, move the code in a separate helper.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/p2m.c | 53 +
On Fri, 19 Aug 2016 14:34:02 -0700
mcg...@kernel.org wrote:
> From: "Luis R. Rodriguez"
>
> Linux makes extensive use of custom ELF header sections,
> documentation for these are well scatterred. Unify this
> documentation in a central place and provide helpers to
> build custom Linux sections.
On Thu, 28 Jul 2016, Julien Grall wrote:
> The level shift can be encoded with 32-bit. So it is not necessary to
> use paddr_t (i.e 64-bit).
You might as well use 8 bit.
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/p2m.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Thu, 28 Jul 2016, Julien Grall wrote:
> Sometimes the invalidation of the TLBs can be deferred until the p2m is
> unlocked. This is for instance the case when multiple mappings are
> removed. In other case, such as shattering a superpage, an immediate
> flush is required.
>
> Keep track whether
flight 100585 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100585/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 100578
build-amd64-rumpuserxen
On Thu, 28 Jul 2016, Julien Grall wrote:
> Modify the prototype to directly pass the mfn and the type in
> parameters. This will be useful later when we do not have the entry in
> hand.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/p2m.c | 17 +++-
On Thu, 28 Jul 2016, Julien Grall wrote:
> A data/instruction abort may have occurred if another CPU was playing
> with the stage-2 page table when following the break-before-make
> sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly
> the fault to the guest, we need to check w
On 6/28/16 2:06 PM, David Vrabel wrote:
> Using /proc/xen/xenbus can cause deadlocks on the atomic file position
> mutex since this file should behave like a character device and not a
> regular file. This is easiest to achive by making it a symlink to the
> existing /dev/xen/xenbus device.
>
> T
On August 22, 2016 11:12 PM, wrote:
On 22.08.16 at 16:02, wrote:
>> On August 22, 2016 8:04 PM, wrote:
>> On 22.08.16 at 13:41, wrote:
On August 22, 2016 6:36 PM, wrote:
On 19.08.16 at 14:58, wrote:
>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17
>00:00:
On 8/19/16 11:54 AM, Andrew Cooper wrote:
> Most of the comments are duplicated from the help text, and those without help
> provide no useful additional input.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Doug Goldstein
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Julien Grall
Reviewed-
On Fri, Aug 19, 2016 at 03:31:47PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:41 PM, wrote:
> > From: "Luis R. Rodriguez"
> >
> > Add a userspace sandbox to allow easy experimentation and
> > test extensions with linker tables, section ranges and the
> > new section core definitions.
>
On Fri, Aug 19, 2016 at 03:10:33PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM, wrote:
> > diff --git a/init/Kconfig b/init/Kconfig
> > index cac3f096050d..ef09e83b9196 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -53,6 +53,28 @@ config CROSS_COMPILE
> > nee
On Fri, Aug 19, 2016 at 03:02:07PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM, wrote:
> > diff --git a/arch/c6x/include/asm/tables.h b/arch/c6x/include/asm/tables.h
> > new file mode 100644
> > index ..09a9e31c573a
> > --- /dev/null
> > +++ b/arch/c6x/include/asm/tables
On Fri, Aug 19, 2016 at 02:55:43PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM, wrote:
> > From: "Luis R. Rodriguez"
> >
> > Section ranges are on one of the types of custom sections
> > types used in Linux. This provides a series of helpers for
> > defining them and using them. Mo
This run is configured for baseline tests only.
flight 67578 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 9 debian-di-in
On Fri, Aug 19, 2016 at 02:47:48PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM, wrote:
> > From: "Luis R. Rodriguez"
> >
> > +SECTION_RODATA
> > +--
> > +.. kernel-doc:: include/asm-generic/section-core.h
> > + :doc: SECTION_RODATA
> > +
> > +SECTION_RODATA
>
> Typo:
On Fri, Aug 19, 2016 at 03:29:24PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM, wrote:
> > From: "Luis R. Rodriguez"
> >
> > This v4 addresses feedback from the previous v3 series [0], and also
> > addresses a huge array of additional tests against many architectures
> > outside of
This run is configured for baseline tests only.
flight 67579 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67579/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 72388f9c10126a718a7ac381dc6879d3337ccb8b
baseline v
flight 100584 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100584/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 100581
Regressions which
> > > @@ -24,7 +27,9 @@ const char *xen_hello_world(void)
> > > */
> > > rc = __get_user(tmp, non_canonical_addr);
> > > BUG_ON(rc != -EFAULT);
> > > -
> > > +#else
> > > + asm(ALTERNATIVE("nop", "nop", 1));
> >
> > Why the hardcoded 1 here? I am wondering if we should introduc
It has definition of domid_t. Fixes userspace compiler error when
xen/privcmd.h is compiled alone:
xen/evtchn.h:100:2: error: unknown type name ‘domid_t’
domid_t domid;
^~~
Signed-off-by: Mikko Rapeli
---
include/uapi/xen/evtchn.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/in
> > > -/* On ARM32,64 instructions are always 4 bytes long. */
> > > -#define PATCH_INSN_SIZE 4
> >
> > Rather than moving again PATCH_INSN_SIZE in this patch. Can you directly
> > move it in patch [1]?
>
> Sure.
The patch [1] changed where it does not have anymore. And because
of that (and som
xen/interface/xen.h is not exported from kernel headers so remove the
dependency and provide needed defines for domid_t and xen_pfn_t if they
are not already defined by some other e.g. Xen specific headers.
Suggested by Andrew Cooper on lkml message
<5569f9c9.8000...@citrix.com>.
The ifdef for A
Tamas,
My experiment is using the same HVMOP - HVMOP_get_param.
Usermode code is using it from
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/hvm/hvm_op.h;hb=2a99aa99fc84a45f505f84802af56b006d14c52e
Kernelmode is using it from
http://lxr.free-electrons.com/source/include/xen
Both are needed to compile wihtout compiler warnings
in userspace. Fixes these userspace compile errors:
xen/gntdev.h:151:4: error: unknown type name ‘grant_ref_t’
grant_ref_t ref;
^
xen/gntdev.h:153:4: error: unknown type name ‘domid_t’
domid_t domid;
^
Signed-off-by: Mikko Rape
On Mon, Aug 22, 2016 at 12:42 PM, Dmitry Rockosov wrote:
> Tamas, what do you think, why the same hypercall operations (get_param) are
> executed by Xen differently? Does Xen know anything about caller domU CPL:
> usermode or kernelmode?
It's not about the guest's CPL - all hypercalls are issued
Tamas, what do you think, why the same hypercall operations (get_param) are
executed by Xen differently? Does Xen know anything about caller domU CPL:
usermode or kernelmode?
Thank you for answers!
Best Regards,
Rockosov Dmitry
2016-08-22 21:28 GMT+03:00 Tamas K Lengyel :
> On Mon, Aug 22, 2016
On Mon, Aug 22, 2016 at 12:12 PM, Dmitry Rockosov wrote:
> The problem is in hypervisor checking definitely. I deeper debugged the
> code, I met vmcall instruction execution. This means EFAULT is coming from
> hypervisor.
As it should, question is where exactly it gets denied in Xen.
>
> Best Re
Thank you!
On Sun, 21 Aug 2016, Christopher Clark wrote:
> The PV Calls (formerly XenSock) protocol design has recently attracted
> interest within the OpenXT software
> development community, as it is a novel interdomain communication mechanism
> and protocol.
>
> We have a longstanding and ac
The problem is in hypervisor checking definitely. I deeper debugged the
code, I met vmcall instruction execution. This means EFAULT is coming from
hypervisor.
Best Regards,
Rockosov Dmitry
2016-08-22 18:09 GMT+03:00 Dmitry Rockosov :
> Hello Tamas,
>
> Thank you for the answer!
>
> I installed t
> > > > +#else
> > > > + asm(ALTERNATIVE("nop", "nop", 1));
> > >
> > > Why the hardcoded 1 here? I am wondering if we should introduce a new
> > > capability "LIVEPATCH_TEST" which is enabled by default. So we can test
> > > that
> > > the the alternative is working on all the platform. What
On 19/08/16 19:07, Andrew Cooper wrote:
> On 19/08/16 18:09, Andrew Cooper wrote:
>> On 19/08/16 13:53, Jan Beulich wrote:
>>> User mode code generally cannot be expected to invoke the PV-enabled
>>> CPUID Xen supports, and prior to the CPUID levelling changes for 4.7
>>> (as well as even nowadays
On 04/08/16 16:16, David Vrabel wrote:
> Currently libxencall using mlocked buffers for hypercall buffers.
> This pages are subject to compaction and page migration. A userspace
> process may see a hypercall fail with -EFAULT if a page backing a
> hypercall buffer is in the process of being migrate
On 04/08/16 17:02, Jan Beulich wrote:
On 04.08.16 at 17:16, wrote:
>> Using mlock() for hypercall buffers is not sufficient since mlocked
>> pages are still subject to compaction and page migration. Page
>> migration can be prevented by taking additional references to the
>> pages.
>>
>> Int
On Wed, Aug 17, 2016 at 06:21:03AM -0600, Jan Beulich wrote:
> >>> On 15.08.16 at 01:07, wrote:
>
> According to the code you mean $t instead of $p in the subject.
Yes! Thanks for noticing that.
>
> > --- a/xen/arch/arm/livepatch.c
> > +++ b/xen/arch/arm/livepatch.c
> > @@ -90,6 +90,35 @@ void
On Wed, Aug 17, 2016 at 06:00:22AM -0600, Jan Beulich wrote:
> >>> On 15.08.16 at 01:07, wrote:
> > On x86 it works great but on ARM 32,64 not so much.
>
> Considering the nature of the change ...
>
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -101,7 +101,7 @@ _uninstall:
> >
> > .PHO
This run is configured for baseline tests only.
flight 67577 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67577/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d36447418d32d82c4d1033ffcf5cb6244031ac9f
baseline v
On 22/08/16 16:42, Vitaly Kuznetsov wrote:
>
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
> the original SKB structure. We'll have to add a flag indicating the fact
> that the particular request is a part of the original linear
Small packet loss is reported on complex multi host network configurations
including tunnels, NAT, ... My investigation led me to the following check
in netback which drops packets:
if (unlikely(txreq.size < ETH_HLEN)) {
netdev_err(queue->vif->dev,
flight 100583 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100583/
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
flight 100581 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100581/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100562
test-amd64-i386-xl-qemuu-w
On Mon, Aug 22, 2016 at 04:09:07PM +0100, Andrew Cooper wrote:
> On 22/08/16 15:26, Wei Liu wrote:
> > On Mon, Aug 22, 2016 at 02:26:11PM +0100, Andrew Cooper wrote:
> >> On 22/08/16 14:13, Wei Liu wrote:
> >>> On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
> On 18/08/16 15:13,
On Fri, 19 Aug 2016 14:34:12 -0700
mcg...@kernel.org wrote:
> From: "Luis R. Rodriguez"
>
> Often all is needed is these small helpers, instead of compiler.h
> or a full kprobes.h. This is important for asm helpers, in fact even
> some asm/kprobes.h make use of these helpers... instead just keep
>>> On 22.08.16 at 16:02, wrote:
> On August 22, 2016 8:04 PM, wrote:
> On 22.08.16 at 13:41, wrote:
>>> On August 22, 2016 6:36 PM, wrote:
>>> On 19.08.16 at 14:58, wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
> 2001
> From: Quan Xu
> Da
Hello Tamas,
Thank you for the answer!
I installed the same xen source code (4.7.0) as on dom0 to domU, built
dist-tools, installed xen-tools, updated rc.d configuration and rebooted.
IOCTL channel to privcmd driver is working fine, but all requests to
hypervisor like hvm_get_param, translate_for
On 22/08/16 15:26, Wei Liu wrote:
> On Mon, Aug 22, 2016 at 02:26:11PM +0100, Andrew Cooper wrote:
>> On 22/08/16 14:13, Wei Liu wrote:
>>> On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
On 18/08/16 15:13, Wei Liu wrote:
> From: Anthony PERARD
>
> The path to the B
Signed-off-by: Wei Liu
---
Rerun autogen.sh
---
tools/configure| 8
tools/configure.ac | 16 ++--
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/tools/configure b/tools/configure
index 81ccf34..998090a 100755
--- a/tools/configure
+++ b/tools/configure
@
Signed-off-by: Wei Liu
---
tools/libxl/libxl_paths.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index 6972b90..0643c1b 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -37,12 +37,20 @@ const char *libx
They shouldn't be available when the respective BIOS is disabled at build time.
This should fix the issus that causes xtf fail to launch hvm guests.
Wei Liu (2):
tools: only define {OVMF,SEABIOS}_PATH when they are enabled
libxl: only return {OVMF,SEABIOS}_PATH if available
tools/configure
>>> On 22.08.16 at 15:09, wrote:
> On 2016/8/22 20:04, Jan Beulich wrote:
> On 22.08.16 at 13:41, wrote:
>>> On August 22, 2016 6:36 PM, wrote:
>>> On 19.08.16 at 14:58, wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
> From: Quan Xu
> Date:
On Mon, Aug 22, 2016 at 02:26:11PM +0100, Andrew Cooper wrote:
> On 22/08/16 14:13, Wei Liu wrote:
> > On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
> >> On 18/08/16 15:13, Wei Liu wrote:
> >>> From: Anthony PERARD
> >>>
> >>> The path to the BIOS blob can be overriden by the xl's
2016年8月22日星期一，Xuquan (Euler) 写道：
> On August 22, 2016 8:04 PM, > wrote:
> On 22.08.16 at 13:41, > wrote:
> >> On August 22, 2016 6:36 PM, > wrote:
> >> On 19.08.16 at 14:58, wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
> 2001
> From: Quan Xu
2016年8月22日星期一，Xuquan (Euler) 写道：
> On August 22, 2016 8:04 PM, > wrote:
> On 22.08.16 at 13:41, > wrote:
> >> On August 22, 2016 6:36 PM, > wrote:
> >> On 19.08.16 at 14:58, wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
> 2001
> From: Quan Xu
On August 22, 2016 8:04 PM, wrote:
On 22.08.16 at 13:41, wrote:
>> On August 22, 2016 6:36 PM, wrote:
>> On 19.08.16 at 14:58, wrote:
From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
2001
From: Quan Xu
Date: Fri, 19 Aug 2016 20:40:31 +0800
Su
## Jan Beulich (jbeul...@suse.com):
> See https://patchwork.kernel.org/patch/9281193/.
Yes, that's it. Thanks, fix confirmed.
Regards,
Christoph
--
Spare Space
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 100582 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100582/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 72388f9c10126a718a7ac381dc6879d3337ccb8b
baseline version:
ovmf 8866d337ea9eba258e942
On 22/08/16 14:13, Wei Liu wrote:
> On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
>> On 18/08/16 15:13, Wei Liu wrote:
>>> From: Anthony PERARD
>>>
>>> The path to the BIOS blob can be overriden by the xl's
>>> bios_path_override option, or provided by u.hvm.bios_firmware in the
>
On Mon, Aug 22, 2016 at 01:47:51PM +0100, Wei Liu wrote:
> Wei Liu (2):
> hvmloader: correctly copy signature to info structures
> hvmloader: use bound checking in get_module_entry
>
Pushed.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https:
On August 22, 2016 9:10 PM, Yang Zhang wrote:
>On 2016/8/22 20:04, Jan Beulich wrote:
> On 22.08.16 at 13:41, wrote:
>>> On August 22, 2016 6:36 PM, wrote:
>>> On 19.08.16 at 14:58, wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
> 2001
> From: Quan
On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
> On 18/08/16 15:13, Wei Liu wrote:
> > From: Anthony PERARD
> >
> > The path to the BIOS blob can be overriden by the xl's
> > bios_path_override option, or provided by u.hvm.bios_firmware in the
> > domain_build_info struct by other
On 2016/8/22 20:04, Jan Beulich wrote:
On 22.08.16 at 13:41, wrote:
On August 22, 2016 6:36 PM, wrote:
On 19.08.16 at 14:58, wrote:
From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Fri, 19 Aug 2016 20:40:31 +0800
Subject: [RFC PATCH] x86/apicv: fix
>>> On 22.08.16 at 14:47, wrote:
> The original code used sizeof(info->signature) as the size parameter for
> memcpy, which was wrong.
>
> Fix that by using structure assignment.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel maili
>>> On 22.08.16 at 14:47, wrote:
> Coverity complains:
>
> overflow_before_widen: Potentially overflowing expression
> info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is
> evaluated using 32-bit arithmetic, and then used in a context that
> expects an expression of type uint64_t
The original code used sizeof(info->signature) as the size parameter for
memcpy, which was wrong.
Fix that by using structure assignment.
Signed-off-by: Wei Liu
---
tools/firmware/hvmloader/ovmf.c| 8
tools/firmware/hvmloader/seabios.c | 8
2 files changed, 8 insertions(+)
Coverity complains:
overflow_before_widen: Potentially overflowing expression
info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is
evaluated using 32-bit arithmetic, and then used in a context that
expects an expression of type uint64_t (64 bits, unsigned).
The overflow is unlikel
Wei Liu (2):
hvmloader: correctly copy signature to info structures
hvmloader: use bound checking in get_module_entry
tools/firmware/hvmloader/hvmloader.c | 4 ++--
tools/firmware/hvmloader/ovmf.c | 8
tools/firmware/hvmloader/seabios.c | 8
3 files changed, 10 insert
Hi
The reproduction should be pretty simple:
Apply the patch to enable altp2m unconditionally:
d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] = SHUTDOWN_reboot;
+d->arch.hvm_domain.params[HVM_PARAM_ALTP2M] = 1;
+
>>> On 22.08.16 at 13:41, wrote:
> On August 22, 2016 6:36 PM, wrote:
> On 19.08.16 at 14:58, wrote:
>>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
>>> From: Quan Xu
>>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic ti
>>> On 22.08.16 at 13:37, wrote:
> On Fri, Aug 19, 2016 at 06:00:12AM -0600, Jan Beulich wrote:
>> >>> On 19.08.16 at 12:09, wrote:
>> > On 19/08/16 09:31, Jan Beulich wrote:
>> > On 19.08.16 at 10:06, wrote:
>> >>> --- a/tools/firmware/hvmloader/hvmloader.c
>> >>> +++ b/tools/firmware/hvmlo
>>> On 22.08.16 at 13:40, wrote:
> On 2016/8/22 18:35, Jan Beulich wrote:
> On 19.08.16 at 14:58, wrote:
>>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
>>> From: Quan Xu
>>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic
On 19/08/16 11:01, kevin.ma...@gdata.de wrote:
> Hi
>
> I took another look at Xen and a new crashdump.
> The last successful __vmwrite should be in
> static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
> [...]
> __vmwrite(SECONDARY_VM_EXEC_CONTROL,
> v->arch.hvm_vmx.secondary_
On August 22, 2016 7:40 PM, Yang Zhang wrote:
>On 2016/8/22 18:35, Jan Beulich wrote:
> On 19.08.16 at 14:58, wrote:
>>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
>>> 2001
>>> From: Quan Xu
>>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>>> Subject: [RFC PATCH] x86/apicv: f
On August 22, 2016 6:36 PM, wrote:
On 19.08.16 at 14:58, wrote:
>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
>> From: Quan Xu
>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
>>
>> When Xen apicv
On 2016/8/22 18:35, Jan Beulich wrote:
On 19.08.16 at 14:58, wrote:
From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Fri, 19 Aug 2016 20:40:31 +0800
Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
When Xen apicv is enabled, wall
I use xen-access to trace the paegs which are accessed to be wrtitten but
when I print out the page content immediately after getting the event in
xen-access,
its content is unchanged .
What should I do??
On Sat, Aug 20, 2016 at 5:13 PM, sepanta s wrote:
> Hi,
> How can I check if a page is dirt
On Fri, Aug 19, 2016 at 06:00:12AM -0600, Jan Beulich wrote:
> >>> On 19.08.16 at 12:09, wrote:
> > On 19/08/16 09:31, Jan Beulich wrote:
> > On 19.08.16 at 10:06, wrote:
> >>> --- a/tools/firmware/hvmloader/hvmloader.c
> >>> +++ b/tools/firmware/hvmloader/hvmloader.c
> >>> @@ -272,8 +272,8 @
>>> On 22.08.16 at 13:22, wrote:
>> > >> First of all - please don't top post.
>> > >>
>> > >>> What about remove the dependency between AVX2 and AVX512F
>> > ( AVX2:
>> > >> [AVX512F], ) ?
>> > >>
>> > >> Yes, that's what I think we want, b
> > >> First of all - please don't top post.
> > >>
> > >>> What about remove the dependency between AVX2 and AVX512F
> > ( AVX2:
> > >> [AVX512F], ) ?
> > >>
> > >> Yes, that's what I think we want, but we need Andrew's agreement
> > >>
flight 100580 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100580/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8866d337ea9eba258e942585b172d57d39376e70
baseline version:
ovmf d36447418d32d82c4d103
On August 22, 2016 5:38 PM, Yang Zhang wrote:
>On 2016/8/19 20:58, Xuquan (Euler) wrote:
>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
>> From: Quan Xu
>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
>>
Hi,
On 19/08/16 16:54, Andrew Cooper wrote:
Most of the comments are duplicated from the help text, and those without help
provide no useful additional input.
Signed-off-by: Andrew Cooper
---
CC: Doug Goldstein
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
For ARM bits:
Acked-
On 19/08/16 23:44, Kamenee Arumugam wrote:
Hi Julien/Chen,
Hello,
Thanks, it is working for me after setting CONFIG_ARCH_HISI = y in
config file. So, when i tried to boot linux thru startup.sh, it seems to
hangs and below are the traces of log:
Press ESC in 1 seconds to skip startup.nsh or
On Mon, Aug 22, 2016 at 11:24:56AM +0100, David Vrabel wrote:
> On 22/08/16 11:10, Wei Liu wrote:
> > On Mon, Aug 22, 2016 at 10:46:50AM +0100, David Vrabel wrote:
> >> On 17/08/16 15:33, Wei Liu wrote:
> >>> The semantics of alloca(3) is not very nice. If the stack overflows,
> >>> program behavio
>>> On 19.08.16 at 14:58, wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
> From: Quan Xu
> Date: Fri, 19 Aug 2016 20:40:31 +0800
> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
>
> When Xen apicv is enabled, wall clock time is faster on W
On 22/08/16 11:10, Wei Liu wrote:
> On Mon, Aug 22, 2016 at 10:46:50AM +0100, David Vrabel wrote:
>> On 17/08/16 15:33, Wei Liu wrote:
>>> The semantics of alloca(3) is not very nice. If the stack overflows,
>>> program behaviour is undefined.
>>>
>>> Remove the use of alloca(3) and always use mmap
On Fri, Aug 19, 2016 at 03:26:23PM +0100, Andrew Cooper wrote:
> bios.bin as a name is far too generic. Rename it to seabios.bin.
>
> Signed-off-by: Andrew Cooper
Hmm... I remember the first few versions of that series had it named
seabios.bin and I acked that.
Anyway, I think I will give Anth
>>> On 21.08.16 at 00:33, wrote:
> Hi,
>
> I'm running Xen 4.4.1 as packaged in Debian 8.5 (jessie) with home-baked
> kernels (that is, from kernel.org) (hardware is x86-64, in case that
> matters).
>
> After upgrading to kernel 4.7, xenstore-write is not able to set
> the Dom0 name anymore (and
On Mon, Aug 22, 2016 at 10:46:50AM +0100, David Vrabel wrote:
> On 17/08/16 15:33, Wei Liu wrote:
> > The semantics of alloca(3) is not very nice. If the stack overflows,
> > program behaviour is undefined.
> >
> > Remove the use of alloca(3) and always use mmap.
>
> This is only using alloca() i
flight 67575 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67575/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail REGR. vs.
66937
Regre
>>> On 20.08.16 at 00:43, wrote:
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> multiboot2 protocol. This way we will have:
> - smaller Xen code base,
> - one code base for xen.gz and xen.efi,
> - o
On 17/08/16 15:33, Wei Liu wrote:
> The semantics of alloca(3) is not very nice. If the stack overflows,
> program behaviour is undefined.
>
> Remove the use of alloca(3) and always use mmap.
This is only using alloca() if the allocation is < PAGE_SIZE. I think
assuming there's this much extra s
On Thu, Aug 18, 2016 at 11:15:23AM +0100, Wei Liu wrote:
> Wei Liu (3):
> Introduce asm_macros.h
> x86: switch to use elfnote
> x86: use unified linker script
>
Series pushed.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.o
On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote:
> Fix two issues discovered by coverity.
>
Pushed with fixed up commit message.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 2016/8/19 20:58, Xuquan (Euler) wrote:
From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Fri, 19 Aug 2016 20:40:31 +0800
Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
When Xen apicv is enabled, wall clock time is faster on Win
1 - 100 of 107 matches
Mail list logo
