>>> On 18.07.16 at 16:01, wrote:
> ACPI builder is currently distributed under GPLv2 license.
>
> We plan to make the builder available to components other
> than the hvmloader (which is also GPLv2). Some of these
> components (such as libxl) may be distributed under LGPL-2.1
> so that they can b
On Aug 25, 2016 8:00 PM, "Nicholas Piggin" wrote:
>
> On Thu, 25 Aug 2016 19:52:39 +0200
> "Luis R. Rodriguez" wrote:
>
> > On Thu, Aug 25, 2016 at 04:51:21PM +1000, Nicholas Piggin wrote:
> > > On Thu, 25 Aug 2016 08:05:40 +0200
> > > "Luis R. Rodriguez" wrote:
> > > > > Oh, that makes more sen
Hi,
On Mon, Aug 15, 2016 at 08:57:40AM -0400, Boris Ostrovsky wrote:
> On 08/01/2016 09:56 AM, Boris Ostrovsky wrote:
> > Simon, Keir,
>
>
> Simon, ping?
Sorry, I didn't see this until now.
Acked-by: Simon Horman
> > In case you didn't realize --- this needs your ACK.
> >
> > Jan, now that I
Currently it is only possible to set mem_access restrictions only for
a contiguous range of GFNs (or, as a particular case, for a single GFN).
This patch introduces a new libxc function taking an array of GFNs.
The alternative would be to set each page in turn, using a userspace-HV
roundtrip for ea
flight 100624 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100624/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 4 host-ping-check-native fail REGR. vs. 100618
Regressions which
On Thu, 25 Aug 2016 19:52:39 +0200
"Luis R. Rodriguez" wrote:
> On Thu, Aug 25, 2016 at 04:51:21PM +1000, Nicholas Piggin wrote:
> > On Thu, 25 Aug 2016 08:05:40 +0200
> > "Luis R. Rodriguez" wrote:
> > > > Oh, that makes more sense. The SECTION stuff and custom sections was
> > > > confusing
On 2016-08-25 22:34, Doug Goldstein wrote:
On 8/25/16 4:21 PM, li...@eikelenboom.it wrote:
Today i tried to switch some of my HVM guests (qemu-xen) from booting
of
a kernel *inside* the guest, to a dom0 supplied kernel, which is
described as "Direct Kernel Boot" here:
https://xenbits.xen.org/do
On 8/25/16 4:21 PM, li...@eikelenboom.it wrote:
> Today i tried to switch some of my HVM guests (qemu-xen) from booting of
> a kernel *inside* the guest, to a dom0 supplied kernel, which is
> described as "Direct Kernel Boot" here:
> https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html :
>
>
Today i tried to switch some of my HVM guests (qemu-xen) from booting of
a kernel *inside* the guest, to a dom0 supplied kernel, which is
described as "Direct Kernel Boot" here:
https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html :
Direct Kernel Boot
Direct kernel boot allows boot
flight 100622 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 17 guest-destroyfail REGR. vs. 100618
Regressions which
With the "tasklet: Introduce per-cpu tasklet for softirq."
and "tasklet: Add cross CPU feeding of per-cpu tasklets."
we have all the neccessary pieces to swap over the
schedule tasklet. As such this patch has the same logic
as the softirq one except that is uses a different
name for its per-cpu lis
This implements a lockless per-cpu tasklet mechanism.
The existing tasklet mechanism has a single global
spinlock that is taken every-time the global list
is touched. And we use this lock quite a lot - when
we call do_tasklet_work which is called via an softirq
and from the idle loop. We take the
To catch any bisection issues, we had been replacing parts of
the tasklet code one functionality on top of each other. Now
that all of it is per-cpu and working we can remove the
old scaffolding and collapse functions.
We also remove the 'is_percpu' flag that is not needed
anymore. Most of this is
With the new percpu tasklet (see "tasklet: Introduce per-cpu tasklet."
and "tasklet: Add cross CPU feeding of per-cpu-tasklets") we have
now in a place a working version of per-cpu softirq tasklets.
We can now remove the old implementation of the
softirq tasklet. We also remove the temporary scaff
Since the per-cpu tasklets are lockfree and run only
within their own CPU context - we need a mechanism
for 'tasklet_schedule_on_cpu' from other CPUs to
insert tasklets in the destination per-cpu lists.
We use an IPI mechanism which function implements an
per-cpu 'feeding' list and a global lock.
Hey,
Dusting of this patchset which had been languishing
in my queue.
The presentation at XPDS 2016 by Intel poked me to brush this off.
The Intel folks have run guests with large amount of CPUs and have
discovered that the spinlock on the tasklet ends up taking an
quite large time. This patchse
Hi all,
if you are interested in PV Calls, or you just have any questions for me
about it, please join the following technical call:
Friday the 2nd of September at 9AM PST, 5PM UK
Join the call: https://www.uberconference.com/stefano-aporeto
Cheers,
StefanoBEGIN:VCALENDAR
VERSION:2.0
PRODID:-
This run is configured for baseline tests only.
flight 67593 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67593/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta
This run is configured for baseline tests only.
flight 67591 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67591/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 10 guest-start
This run is configured for baseline tests only.
flight 67595 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67595/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3ed4e502b5f23fbcef235b3a9d025c60c217272b
baseline v
On Thu, Aug 25, 2016 at 04:51:21PM +1000, Nicholas Piggin wrote:
> On Thu, 25 Aug 2016 08:05:40 +0200
> "Luis R. Rodriguez" wrote:
> > > Oh, that makes more sense. The SECTION stuff and custom sections was
> > > confusing me. I would prefer just to drop all the LINUX_SECTION naming
> > > and make
Send this cover letter to minios-devel -- forgot to do that when I sent
this series out.
On Thu, Aug 25, 2016 at 05:38:23PM +0100, Wei Liu wrote:
> Wei Liu (5):
> x86_32: remove inclusion of x86-32.h
> x86_64: remove unused labels
> x86_64: merge RESTORE_REST into RESTORE_ALL
> x86_64: int
On Thu, Aug 25, 2016 at 07:12:47PM +0200, Juergen Gross wrote:
> On 25/08/16 18:38, Wei Liu wrote:
> > Wei Liu (5):
> > x86_32: remove inclusion of x86-32.h
> > x86_64: remove unused labels
> > x86_64: merge RESTORE_REST into RESTORE_ALL
> > x86_64: introduce and use SAVE_ALL
> > x86_64:
On 25/08/16 17:48, Stefan Bader wrote:
> When I try to save a PV guest with 4G of memory using xen-4.7 I get the
> following error:
>
> II: Guest memory 4096 MB
> II: Saving guest state to file...
> Saving to /tmp/pvguest.save new xl format (info 0x3/0x0/1131)
> xc: info: Saving domain 23, type x8
Wei Liu, on Thu 25 Aug 2016 17:38:23 +0100, wrote:
> Wei Liu (5):
> x86_32: remove inclusion of x86-32.h
> x86_64: remove unused labels
> x86_64: merge RESTORE_REST into RESTORE_ALL
> x86_64: introduce and use SAVE_ALL
> x86_64: don't unnecessarily export some entries
For the whole serie
On 25/08/16 18:38, Wei Liu wrote:
> Wei Liu (5):
> x86_32: remove inclusion of x86-32.h
> x86_64: remove unused labels
> x86_64: merge RESTORE_REST into RESTORE_ALL
> x86_64: introduce and use SAVE_ALL
> x86_64: don't unnecessarily export some entries
>
> arch/x86/x86_32.S | 2 --
> ar
On 25/08/16 18:38, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 25/08/16 18:38, Wei Liu wrote:
> Introduce this macro to match RESTORE_ALL. Also delete the unused
> SAVE_REST.
>
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.o
On 25/08/16 18:38, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 25/08/16 18:38, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 25/08/16 18:38, Wei Liu wrote:
> There is no need to do that explicitly.
>
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hello Xen team,
We are working on enabling XEN with WindRiver Simics, which is Intel reference
functional simulator for servers.
We found the issue in XEN with MPX using.
If MPX is supported by CPUID, but MPX is not supported by VMX, XEN is failing
on store CPU MSR GUEST_BNDCFGS (file xen-4.7.0
On Thu, Aug 25, 2016 at 05:38:26PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
Signed-off-by: Wei Liu
Pressed Ctrl-X in Vim by mistake.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Introduce this macro to match RESTORE_ALL. Also delete the unused
SAVE_REST.
Signed-off-by: Wei Liu
---
arch/x86/x86_64.S | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/arch/x86/x86_64.S b/arch/x86/x86_64.S
index 8432d69..21fa61b 1006
There is no need to do that explicitly.
Signed-off-by: Wei Liu
---
arch/x86/x86_32.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/x86_32.S b/arch/x86/x86_32.S
index 9241418..f70fc65 100644
--- a/arch/x86/x86_32.S
+++ b/arch/x86/x86_32.S
@@ -3,9 +3,7 @@
#include
#include
#in
Signed-off-by: Wei Liu
---
arch/x86/x86_64.S | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/arch/x86/x86_64.S b/arch/x86/x86_64.S
index c57ee10..8432d69 100644
--- a/arch/x86/x86_64.S
+++ b/arch/x86/x86_64.S
@@ -101,27 +101,23 @@ KERNEL_CS_MASK
Wei Liu (5):
x86_32: remove inclusion of x86-32.h
x86_64: remove unused labels
x86_64: merge RESTORE_REST into RESTORE_ALL
x86_64: introduce and use SAVE_ALL
x86_64: don't unnecessarily export some entries
arch/x86/x86_32.S | 2 --
arch/x86/x86_64.S | 74 ++-
Signed-off-by: Wei Liu
---
arch/x86/x86_64.S | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/x86_64.S b/arch/x86/x86_64.S
index 5932bfb..c57ee10 100644
--- a/arch/x86/x86_64.S
+++ b/arch/x86/x86_64.S
@@ -177,7 +177,6 @@ ENTRY(error_entry)
movq %r14,1*8(%rsp)
movq %
Signed-off-by: Wei Liu
---
arch/x86/x86_64.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/x86_64.S b/arch/x86/x86_64.S
index 21fa61b..2046187 100644
--- a/arch/x86/x86_64.S
+++ b/arch/x86/x86_64.S
@@ -165,7 +165,7 @@ KERNEL_CS_MASK = 0xfc
* Exception entry po
On 24/08/16 09:55, Jan Beulich wrote:
On 24.08.16 at 04:22, wrote:
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -70,6 +70,9 @@ struct payload {
unsigned int nsyms; /* Nr of entries in .strtab and
symbols. */
struct livepatch_build_id id;/* E
Sorry for the incomplete subject. Got interrupted while writing the email and
then forgot to complete it... :/
On 25.08.2016 17:48, Stefan Bader wrote:
> When I try to save a PV guest with 4G of memory using xen-4.7 I get the
> following error:
>
> II: Guest memory 4096 MB
> II: Saving guest stat
On 08/23/2016 10:22 PM, Konrad Rzeszutek Wilk wrote:
Specifically the code that is looking up f->old_addr - which
can be in its own routine instead of having it part of prepare_payload.
No functional change.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Ross Lagerwall
v3: First submission.
v
This run is configured for baseline tests only.
flight 67594 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67594/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1219c85df42d5c9ed187565328e2f5cead5682ed
baseline v
When I try to save a PV guest with 4G of memory using xen-4.7 I get the
following error:
II: Guest memory 4096 MB
II: Saving guest state to file...
Saving to /tmp/pvguest.save new xl format (info 0x3/0x0/1131)
xc: info: Saving domain 23, type x86 PV
xc: error: Bad mfn in p2m_frame_list[0]: Interna
Because I have suspected that we are not getting as much out of the
test lab as we could have, I have been doing some digging in the
database.
I wrote some code to mine the database for historical information
about resource usage. (Patch below, which I will push to osstest
production at some poin
>>> On 25.08.16 at 15:37, wrote:
> On most architectures it does not matter what the aligment is.
>
> On ARM32 it is paramount that the aligment is word-size (4)
> otherwise we get a Data Abort when trying to perform ELF
> relocations. That is due to ARM 32 only being able to write to
> word-alig
>>> On 25.08.16 at 15:37, wrote:
> So they can be shared with ARM64 (but not yet, so they
> are only built on x86).
>
> No functional change.
>
> We also need to tweak the MAINTAINERS and .gitignore file
>
> Signed-off-by: Konrad Rzeszutek Wilk
for whichever parts it's relevant
Acked-by: Jan
>>> On 25.08.16 at 15:37, wrote:
> --- a/xen/include/xen/types.h
> +++ b/xen/include/xen/types.h
> @@ -14,6 +14,12 @@
> #define NULL ((void*)0)
> #endif
>
> +#define U16_MAX ((u16)~0U)
> +#define S16_MAX ((s16)(U16_MAX>>1))
> +#define S16_MIN ((s16)(-S16_MAX - 1))
> +#d
>>> On 25.08.16 at 15:37, wrote:
> @@ -22,6 +24,12 @@ config X86
> select NUMA
> select VGA
>
> +config ALTERNATIVE
> + bool
> +
> +config HAS_EX_TABLE
> + bool
These need to move out of arch/x86/, and the first one's name is
too generic (and should probably also start with
>>> On 25.08.16 at 15:58, wrote:
> On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
>
>> x86 implements all of them by default - and we just
>> add two extra CONFIG_ variables to be declared in autoconf.h.
>>
>> ARM 64 only has alternative while ARM 32 has none of them.
>>
>> And while at it chang
>>> On 25.08.16 at 15:37, wrote:
> The checks for SHT_REL[,A] ELF sanity checks does not need to
> be in the platform specific file and can be bubbled up
> in the platform agnostic file.
>
> This makes the ARM 32/64 implementation easier as the
> duplicate checks don't have to be in the platform
flight 100621 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100621/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 20.08.16 at 00:43, wrote:
> Every multiboot protocol (regardless of version) compatible image must
> specify its load address (in ELF or multiboot header). Multiboot protocol
> compatible loader have to load image at specified address. However, there
> is no guarantee that the requested mem
On 25/08/16 15:02, Julien Grall wrote:
Hi Andrew,
On 25/08/2016 09:58, Andrew Cooper wrote:
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
x86 implements all of them by default - and we just
add two extra CONFIG_ variables to be declared in autoconf.h.
ARM 64 only has alternative while ARM
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.
Either way - we can ignore the
Hi Andrew,
On 25/08/2016 09:58, Andrew Cooper wrote:
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
x86 implements all of them by default - and we just
add two extra CONFIG_ variables to be declared in autoconf.h.
ARM 64 only has alternative while ARM 32 has none of them.
And while at it ch
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
On ARM we need an alternative VA region to poke in the
hypervisor .text data. And since this is setup during runtime
we may fail (it uses vmap so most likely error is ENOMEM).
As such this error needs to be bubbled up and also abort
the livepatchi
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
x86 implements all of them by default - and we just
add two extra CONFIG_ variables to be declared in autoconf.h.
ARM 64 only has alternative while ARM 32 has none of them.
And while at it change the livepatch common code that
would benefit from
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
On x86 we squash 'apply_alternatives' in to
'alternative_instructions' (who was its sole user)
and 'apply_alternatives_nocheck' to 'apply_alternatives'.
On ARM we change the parameters for 'apply_alternatives'
to be of 'const struct alt_instr *' i
On ARM we need an alternative VA region to poke in the
hypervisor .text data. And since this is setup during runtime
we may fail (it uses vmap so most likely error is ENOMEM).
As such this error needs to be bubbled up and also abort
the livepatching if it occurs.
Signed-off-by: Konrad Rzeszutek W
With livepatching the alternatives that should be patched are
outside the Xen hypervisor _start -> _end. As such having
to use an alternative VA is not neccessary. In fact we
can use the ones that the caller provided us with.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Stefano Stabellini
Cc: Ju
Hey!
Since v1 (and RFC):
[https://lists.xen.org/archives/html/xen-devel/2016-08/msg01835.html]
- Acted on most all comments.
- Added ARM32 support.
The patches are based on: [PATCH v4] Livepatch fixes and features for v4.8.
(https://lists.xen.org/archives/html/xen-devel/2016-08/msg02705.html)
The checks for SHT_REL[,A] ELF sanity checks does not need to
be in the platform specific file and can be bubbled up
in the platform agnostic file.
This makes the ARM 32/64 implementation easier as the
duplicate checks don't have to be in the platform specific files.
Signed-off-by: Konrad Rzeszut
The implementation on x86 always returns zero, but
other platforms may return error values.
Suggested-by: Julien Grall
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Jan Beulich
Cc: Andrew Cooper
v2: First submission
---
xen/arch/x86/livepatch.c | 4 +
We need to two things:
1) Wrap the platform-specific objcopy parameters in defines
The input and output parameters for $(OBJCOPY) are different
based on the platforms. As such provide them in the
OBJCOPY_MAGIC define and use that.
2) The alternative is a bit different and there are no
It was missing 2MB.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Stefano Stabellini
Cc: Julien Grall
v2: First submission. Spun of from 'livepatch: Initial ARM64 support."
---
xen/include/asm-arm/config.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/asm-
This is copied from Linux 4.7, and the initial commit
that put this in is 5c5bf25d4f7a950382f94fc120a5818197b48fe9
"arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions"
This lays the groundwork for Livepatch to generate the
trampoline to jump to the new replacement function.
Also
Which is only used by Livepatch code. The purpose behind
this call is to modify the page table entries flags.
Specifically the .ro and .nx flags. The current mechanism
puts cache attributes in the flags and the .ro and .nx are
locked down and assumed to be .ro=0, nx=1.
Livepatch needs .nx=0 and a
As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and use the alternative virtual address
for patching.
Since we are
x86 implements all of them by default - and we just
add two extra CONFIG_ variables to be declared in autoconf.h.
ARM 64 only has alternative while ARM 32 has none of them.
And while at it change the livepatch common code that
would benefit from this.
Suggested-by: Julien Grall
Signed-off-by: K
On most architectures it does not matter what the aligment is.
On ARM32 it is paramount that the aligment is word-size (4)
otherwise we get a Data Abort when trying to perform ELF
relocations. That is due to ARM 32 only being able to write to
word-aligned addresses.
The default section alignments
When doing cross-compilation we should use proper $(OBJDUMP).
Otherwise decompiling say ARM 32 code using x86 objdump
won't help much.
Acked-by: Jan Beulich
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Stefano Stabellini
Cc: Julien Grall
v1: First submissi
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 58bc0b8..f257bbc 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -146,7 +146,7 @@ int map_pages_to_xen(
unsigned long nr_mfns,
unsigned int flags);
/* Alte
The code uses a mix of _start, _stext, and _etext. Lets unify
it and use the same 'style'.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Julien Grall
Cc: Stefano Stabellini
v2: First submission
---
xen/arch/arm/alternative.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/x
On x86 we squash 'apply_alternatives' in to
'alternative_instructions' (who was its sole user)
and 'apply_alternatives_nocheck' to 'apply_alternatives'.
On ARM we change the parameters for 'apply_alternatives'
to be of 'const struct alt_instr *' instead of void pointer and
size length.
We also ad
The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the neccessary livepatch infrastructure pieces in.
This patch adds three major pieces:
1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
means the adddendum had to be extracted from within the
So they can be shared with ARM64 (but not yet, so they
are only built on x86).
No functional change.
We also need to tweak the MAINTAINERS and .gitignore file
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Jan Beulich
Cc: Andrew Cooper
v1: First submi
That way common code can use the same macro to access
the most common attributes without much #ifdef.
Take advantage of it right away in the livepatch code.
Note: on ARM we use tabs to conform to the style of the file.
Acked-by: Jan Beulich
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Stefano
Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.
Either way - we can ignore these symbols.
Signed-off-by: Konrad Rzeszutek Wilk
>>> On 20.08.16 at 00:43, wrote:
> +#define NULL ((void *)0)
> +
> +#define __packed __attribute__((__packed__))
> +#define __stdcall__attribute__((__stdcall__))
> +
> +#define max(x,y) ({ \
> +const typeof(x) _x = (x); \
> +const typeof(y) _y = (y); \
> +
flight 100618 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100618/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 11 guest-startfail pass in 100610
Regressions which are regarded a
>>> On 20.08.16 at 00:43, wrote:
> @@ -100,19 +107,45 @@ multiboot2_header_start:
> gdt_boot_descr:
> .word 6*8-1
> .long sym_phys(trampoline_gdt)
> +.long 0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +.long sym_phys(cs32_switch)
> +.
>>> On 20.08.16 at 00:43, wrote:
> Build xen.gz with EFI code. We need this to support multiboot2
> protocol on EFI platforms.
>
> If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
> it must contain "linear" (or "flat") representation of code and data.
> This is requirement
>>> On 20.08.16 at 00:43, wrote:
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -4,9 +4,10 @@
> #include
> #include
>
> -#ifndef efi_enabled
> -const bool_t efi_enabled = 0;
> -#endif
> +bool_t efi_enabled(int feature)
> +{
> +return false;
> +}
Plain bool please,
On 25/08/16 13:30, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 25 Aug 2016 13:23:06 +0200
>
> * A multiplication for the size determination of a memory allocation
> indicated that an array data structure should be processed.
> Thus reuse the corresponding function "kmalloc_ar
flight 67592 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67592/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 67554
jobs:
build-amd64 pass
build-armh
>>> On 20.08.16 at 00:43, wrote:
> +case MULTIBOOT2_TAG_TYPE_MMAP:
> +if ( get_mb2_data(tag, mmap, entry_size) < sizeof(*mmap_src) )
> +break;
> +
> +mbi_out->flags |= MBI_MEMMAP;
> +mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
>
>>> On 20.08.16 at 00:43, wrote:
> Create generic alloc and copy functions. We need
> separate tools for memory allocation and copy to
> provide multiboot2 protocol support.
>
> Signed-off-by: Daniel Kiper
The amount of casting in this patch alone looks very reasonable now.
Before ack-ing this
From: Markus Elfring
Date: Thu, 25 Aug 2016 13:23:06 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus reuse the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle
>>> On 20.08.16 at 00:43, wrote:
> ..to increase code readability and ease its maintenance.
>
> Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 20.08.16 at 00:43, wrote:
> Newer GCC (e.g. gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)) does
> some code optimizations by creating data sections (e.g. jump addresses
> for C switch/case are calculated using data in .rodata section). This
> thing is not accepted by *.lnk build recipe
>>> On 20.08.16 at 00:43, wrote:
> Its visibility is not needed and just pollute symbol table.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Daniel Kiper
With Andrew effectively having NAK-ed v4 of this patch, I don't see
why - without further argumentation - this has been included again.
Ja
>>> On 20.08.16 at 00:43, wrote:
> ..nor EFI platforms with runtime services enabled.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Daniel Kiper
> ---
> v5 - suggestions/fixes:
>- fix build error
> (suggested by Jan Beulich),
>- improve commit message.
Not really - it is now stal
>>> On 17.08.16 at 14:05, wrote:
> 1 Motivation for Xen vIOMMU
>
> ===
> 1.1 Enable more than 255 vcpu support
> HPC virtualization requires more than 255 vcpus support in a single VM
> to meet parallel computing requirem
>>> On 24.08.16 at 14:43, wrote:
> Add TSC as another clocksource that can be used, plus
> a mention to the maxcpus parameter and that it requires
> being explicitly set.
This belongs in the patch introducing the option.
Jan
___
Xen-devel mailing lis
>>> On 24.08.16 at 14:43, wrote:
> This patch proposes relying on host TSC synchronization and
> passthrough to the guest, when running on a TSC-safe platform. On
> time_calibration we retrieve the platform time in ns and the counter
> read by the clocksource that was used to compute system time.
flight 100620 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100620/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3ed4e502b5f23fbcef235b3a9d025c60c217272b
baseline version:
ovmf 1219c85df42d5c9ed1875
>>> On 24.08.16 at 14:43, wrote:
> To fetch the last read from the clocksource which was used to
> calculate system_time.
DYM "To allow the caller to fetch ..."?
> In the case of clocksource=tsc we will
> use it to set tsc_timestamp.
I don't see how this relates to the patch here.
The change i
>>> On 24.08.16 at 14:43, wrote:
> And use to initialize platform time solely for clocksource=tsc,
> as opposed to initializing platform overflow timer, which would
> only fire in ~180 years (on 2.2 Ghz Broadwell processor).
Do we really want to risk this time period going down by two orders
of m
>>> On 24.08.16 at 14:43, wrote:
> This patch introduces support for using TSC as platform time source
> which is the highest resolution time and most performant to get (~20
> nsecs).
Is this indeed still the case with the recently added fences?
> Though there are also several problems associate
1 - 100 of 113 matches
Mail list logo
