>>> On 19.08.16 at 18:14, wrote:
> On Mon, Aug 15, 2016 at 10:15:47AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Aug 15, 2016 at 01:58:47AM -0600, Jan Beulich wrote:
>> > >>> On 15.08.16 at 01:42, wrote:
>> > >> --- a/xen/arch/x86/efi/Makefile
>> > >> +++ b/xen/arch/x86/efi/Makefile
>> > >> @
Hi Jan,
> See https://patchwork.kernel.org/patch/9281193/.
Thanks for the pointer !
I had checked the kernel git tree for a potential fix, but didn't
think of patchwork.
Cheers,
Sylvain Munaut
___
Xen-devel mailing list
Xen-devel@lists.xen.org
flight 100578 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100578/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 100569
build-amd64-rumpuserxen
Hi Neil
On Sun, Aug 21, 2016 at 01:22:15PM -0400, Neil Sikka wrote:
> Hello, how can i get write permission to update documentation on the Xen
> Wiki?
>
Please send me your account name for Xen wiki and I will grant you write
permission.
Wei.
> --
> My Blog: http://www.neilscomputerblog.blogs
Dario Faggioli writes ("[PATCH 14/24] libxl: allow to set the ratelimit value
online for Credit2"):
> This is the remaining part of the plumbing (the libxl
> one) necessary to be able to change the value of the
> ratelimit_us parameter online, for Credit2 (like it is
> already for Credit1).
I thi
flight 100579 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100579/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d36447418d32d82c4d1033ffcf5cb6244031ac9f
baseline version:
ovmf 35dc964bf1eab3f072538
Dario Faggioli writes ("[PATCH 14/24] libxl: allow to set the ratelimit value
online for Credit2"):
...
> -rc = xc_sched_credit_params_set(ctx->xch, poolid, &sparam);
> -if ( rc < 0 ) {
> -LOGE(ERROR, "setting sched credit param");
> -GC_FREE;
> -return ERROR_FAIL;
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
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 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 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 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
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 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
>>> 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 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 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 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 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 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
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 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
>>
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
> > >> 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
> > >>
>>> 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
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 @
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 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
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 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 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 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 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: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
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;
+
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
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(+)
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
>>> 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
>>> 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 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 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 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 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 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
>
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
## 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
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
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 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
>>> 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:
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
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
@
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
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 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
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 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,
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
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
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,
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
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 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
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 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 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 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
> > > > +#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
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
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
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
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: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
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
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
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
> > > -/* 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
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
> > > @@ -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
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
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
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
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:
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: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
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 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: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 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 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 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 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 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 +++-
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:
> 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
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 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.
1 - 100 of 107 matches
Mail list logo
