flight 100611 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100611/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100608
test-amd64-amd64-xl-rtds
flight 100617 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100617/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1219c85df42d5c9ed187565328e2f5cead5682ed
baseline version:
ovmf d82d59edb0ec23e6ef708
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, August 25, 2016 2:45 PM
> To: Wu, Feng
> Cc: Tian, Kevin ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] VT-d: drop pointless uses of __func__
>
> >>> On 25.08.16 at 03:08, wrote:
> >>
On 2016/8/24 20:50, Wei Liu wrote:
>> -localents[i++] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
>> > +localents[i++] = (libxl_defbool_val(info->acpi) &&
>> > + libxl_defbool_val(info->u.hvm.acpi)) ? "1" : "0";
> Please provide a function for this.
On 2016/8/24 20:58, Wei Liu wrote:
> On Tue, Aug 16, 2016 at 06:24:57PM +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao
>> >
>> > The design of this feature is described as below.
>> > Firstly, the toolstack (libxl) generates the ACPI tables according the
>> > number of vcpus and gic control
On 2016/8/24 22:13, Roger Pau Monné wrote:
> On Wed, Aug 24, 2016 at 01:56:04PM +0100, Wei Liu wrote:
>> On Tue, Aug 16, 2016 at 06:25:04PM +0800, Shannon Zhao wrote:
>>> From: Shannon Zhao
>>>
>>> Construct GTDT table with the interrupt information of timers.
>>>
>>> Signed-off-by: Shannon Zhao
flight 100615 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100615/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 12 migrate-s
On 2016/8/24 20:52, Wei Liu wrote:
> On Tue, Aug 16, 2016 at 06:25:02PM +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao
>> >
>> > Construct ACPI RSDP table and add a helper to calculate the ACPI table
>> > checksum.
>> >
>> > Signed-off-by: Shannon Zhao
>> > ---
>> > tools/libxl/libxl_arm
On Thu, Aug 25, 2016 at 04:05:46PM +0800, Shannon Zhao wrote:
>
>
> On 2016/8/24 20:52, Wei Liu wrote:
> > On Tue, Aug 16, 2016 at 06:25:02PM +0800, Shannon Zhao wrote:
> >> > From: Shannon Zhao
> >> >
> >> > Construct ACPI RSDP table and add a helper to calculate the ACPI table
> >> > checksum
On Thu, Aug 25, 2016 at 03:54:32PM +0800, Shannon Zhao wrote:
>
>
> On 2016/8/24 20:50, Wei Liu wrote:
> >> -localents[i++] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
> >> > +localents[i++] = (libxl_defbool_val(info->acpi) &&
> >> > + libxl_defbool_
On 2016/8/25 17:05, Wei Liu wrote:
> On Thu, Aug 25, 2016 at 03:54:32PM +0800, Shannon Zhao wrote:
>> >
>> >
>> > On 2016/8/24 20:50, Wei Liu wrote:
> >> -localents[i++] = libxl_defbool_val(info->u.hvm.acpi) ? "1" :
> >> "0";
> > >> > +localents[i++] = (libxl_defb
flight 100619 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100619/
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 24.08.16 at 14:43, wrote:
> And accomodate platform time source initialization in
> try_platform_time(). This is a preparatory patch for deferring
> TSC clocksource initialization to the stage where all CPUS are
> up (verify_tsc_reliability init call).
>
> Signed-off-by: Joao Martins
> Re
>>> 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
>>> 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:
> 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
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:
> 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.
>>> 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 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 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 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:
> 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:
> ..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
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:
> 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
>>> 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);
>
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 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
>>> 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 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:
> @@ -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)
> +.
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:
> +#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); \
> +
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
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
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
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
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 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
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
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
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
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-
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
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
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
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 +
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
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
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 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 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
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:
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
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 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
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 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
>>> 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:
> @@ -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: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:
> 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:
> 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
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
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
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
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
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 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
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
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 %
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
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
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 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
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:
> 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:
> 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
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 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
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:
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 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
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
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 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
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:-
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.
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
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
1 - 100 of 113 matches
Mail list logo
