Hi all,
> === ARM ===
>
> * Altp2m for ARM
> - Sergej Proskurin
>
We have submitted a patch-series version 3 and still waiting for
remaining reviews.
Cheers,
~Sergej
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-dev
On 30/08/16 23:38, Samuel Thibault wrote:
> Hello,
>
> Juergen Gross, on Tue 30 Aug 2016 13:51:23 +0200, wrote:
>> @@ -51,7 +51,7 @@ endif
>>
>> libc = $(stubdom)
>>
>> -XEN_INTERFACE_VERSION := 0x00030205
>> +XEN_INTERFACE_VERSION ?= 0x00030205
>
> Why making it overridable? AIUI changing
On 31/08/16 10:30, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.8 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> wo
This run is configured for baseline tests only.
flight 67617 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67617/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-build
On 2016/8/30 1:46, Julien Grall wrote:
>> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
>> index d741ac5..7f50a33 100644
>> --- a/tools/libacpi/Makefile
>> +++ b/tools/libacpi/Makefile
>> @@ -19,6 +19,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>>
>> # Sources to be generated
>> C_S
On 2016年08月31日 20:02, Jan Beulich wrote:
On 31.08.16 at 10:39, wrote:
>> > On 2016年08月25日 19:11, Jan Beulich wrote:
>> > On 17.08.16 at 14:05, wrote:
>>> 1 Motivation for Xen vIOMMU
>>>
>>> ==
This patch is mainly modified from Linux kernel:
[1] commit a2c1d73b94ed: arm64: Update the Image header
[2] commit 6ad1fe5d9077: arm64: avoid R_AARCH64_ABS64 relocations for Image
header fields
From [1]:
"
This patch adds an effective image size to the kernel header which
describes the amount of
flight 100681 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100681/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 14 guest-start/debian.repeat fail REGR. vs. 100674
Regressions which
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 31, 2016 8:03 PM
> >>> 3.5 Implementation consideration
> >>> Linux Intel IOMMU driver will fail to be loaded without 2th level
> >>> translation support even if interrupt remapping and 1th level
> >>> translation are availabl
Extend the CPUID monitor event to include EAX and ECX values that were used
when CPUID was executed. This is useful in identifying which leaf was queried.
We also adjust the xen-access output format to more closely resemble the output
of the Linux cpuid tool's raw format.
Signed-off-by: Tamas K Le
On Thu, Aug 11, 2016 at 5:57 AM, Jan Beulich wrote:
On 10.08.16 at 17:00, wrote:
>> From: Tamas K Lengyel
>>
>> Use __get_gfn_type_access instead of get_gfn_type_access when checking
>> the hostp2m entries during altp2m mem_access setting and gfn remapping
>> to avoid a lock conflict which
On Wed, Aug 31, 2016 at 09:18:39PM +0100, Andrew Cooper wrote:
> On 19/08/2016 23:43, Daniel Kiper wrote:
> > @@ -106,3 +121,122 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32
> > trampoline)
> >
> > return mbi_out;
> > }
> > +
> > +static multiboot_info_t *mbi2_mbi(u32 mbi_in)
> > +{
On Wed, Aug 31, 2016 at 09:46:31AM -0600, Jan Beulich wrote:
> >>> On 31.08.16 at 16:59, wrote:
> > On Thu, Aug 25, 2016 at 08:41:39AM -0600, Jan Beulich wrote:
> >> >>> On 20.08.16 at 00:43, wrote:
[...]
> >> > --- a/xen/arch/x86/boot/head.S
> >> > +++ b/xen/arch/x86/boot/head.S
> >> > @@ -12,
flight 100682 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100682/
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 19/08/2016 23:43, Daniel Kiper wrote:
> @@ -106,3 +121,122 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32
> trampoline)
>
> return mbi_out;
> }
> +
> +static multiboot_info_t *mbi2_mbi(u32 mbi_in)
> +{
> +const multiboot2_memory_map_t *mmap_src;
> +const multiboot2_tag_t *
On Tue, 16 Aug 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 16/08/2016 01:21, Stefano Stabellini wrote:
> > On Thu, 28 Jul 2016, Julien Grall wrote:
> > > A follow-up patch will add more case to the switch that will require the
> > > IPA. So move the computation out of the switch.
> > >
> > > S
On Wed, Aug 31, 2016 at 09:25:57AM -0600, Jan Beulich wrote:
> >>> On 31.08.16 at 17:13, wrote:
> > On Tue, Aug 30, 2016 at 09:12:45AM -0600, Jan Beulich wrote:
> >> >>> On 30.08.16 at 16:32, wrote:
> >> > On Thu, Aug 25, 2016 at 05:34:31AM -0600, Jan Beulich wrote:
> >> >> >>> On 20.08.16 at 00:
On Wed, 31 Aug 2016, Julien Grall wrote:
> > > @@ -236,28 +238,99 @@ static lpae_t *p2m_get_root_pointer(struct
> > > p2m_domain *p2m,
> > >
> > > /*
> > > * Lookup the MFN corresponding to a domain's GFN.
> > > + * Lookup mem access in the ratrix tree.
> > > + * The entries associated to the G
On Wed, Aug 31, 2016 at 07:01:10AM -0600, Jan Beulich wrote:
> >>> On 30.08.16 at 21:58, wrote:
> > On Thu, Aug 25, 2016 at 07:27:21AM -0600, Jan Beulich wrote:
> >> >>> On 20.08.16 at 00:43, wrote:
[...]
> >> > +static unsigned int strtoui(const char *s, const char *stop, const char
> >> > **
On Wed, 31 Aug 2016, Julien Grall wrote:
> Hi Shannon,
>
> On 31/08/16 07:37, Shannon Zhao wrote:
> > On 2016/8/30 1:46, Julien Grall wrote:
> > > On 16/08/2016 06:25, Shannon Zhao wrote:
> > > > From: Shannon Zhao
> > > >
> > > > It uses static DSDT table like the way x86 uses. Currently the DS
On 24/08/16 09:02, Jan Beulich wrote:
> Non-debugging message text should be (and is in the cases here)
> distinguishable without also logging function names. Debugging message
> text, otoh, already includes file name and line number, so also
> logging function names is redundant. One relatively po
On 24/08/16 09:01, Jan Beulich wrote:
> Non-debugging message text should be (and is here) distinguishable
> without also logging function names.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -469,8 +469,9 @@ static int paging_log_dirty_op(
On 24/08/16 08:51, Jan Beulich wrote:
> Non-debugging message text should be (and is in the cases here)
> distinguishable without also logging function names. Additionally log
> the PCI device coordinates for alloc_pdev() failure.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On thi
On 24/08/16 09:41, Jan Beulich wrote:
On 23.08.16 at 19:26, wrote:
>> Contrary to c/s b2507fe7 "x86/domctl: Update PV domain cpumasks when setting
>> cpuid policy", Intel CPUID masks are applied after fast forwarding hardware
>> state, rather than before. (All behaviour in this regard appear
On 24/08/16 08:42, Jan Beulich wrote:
> Recent enough binutils (2.25 onwards) support --build-id also for
> COFF/PE output, and hence we should use that in favor of the original
> hack when possible.
>
> This gets complicated by the linker requiring at least one COFF object
> file to attach the .bu
flight 100680 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100680/
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 100674 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100674/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 4 host-ping-check-native fail in 100667 pass in 100674
test-armhf-armhf-xl 15 guest-st
On Wed, Aug 31, 2016 at 06:49:51AM -0600, Jan Beulich wrote:
> >>> On 30.08.16 at 21:32, wrote:
> > On Thu, Aug 25, 2016 at 06:59:54AM -0600, Jan Beulich wrote:
> >> >>> On 20.08.16 at 00:43, wrote:
[...]
> >> > +paddr_t __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> >> > *Sy
On 17/08/16 18:18, Dario Faggioli wrote:
Right now, the following scenario can occurr:
- upon vcpu v wakeup, v itself is put in the runqueue,
and pcpu X is tickled;
- pcpu Y schedules (for whatever reason), sees v in
the runqueue and picks it up.
This may seem ok (or even a good thin
This run is configured for baseline tests only.
flight 67615 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 3 host-install(3
On 2016-08-26 15:37:38 [-0400], Boris Ostrovsky wrote:
> > If you do find the time, you might manage to rework the code to avoid
> > using the _nocalls() function. If see this right, you use
> > xen_setup_vcpu_info_placement() for the init in the first place. This
> > uses for_each_possible_cpu mac
>>> On 26.08.16 at 10:09, wrote:
On 25.08.16 at 18:53, wrote:
>> 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
On Wed, Aug 31, 2016 at 04:26:48PM +0100, Wei Liu wrote:
> A small series to fix gcov build for both x86 and arm.
>
> Wei Liu (4):
> arm: acpi/boot.c is only used during initialisation
> arm64: use "b" to branch to start_xen
> xen: fix gcov compilation
> xen: add a gcov Kconfig option
>
>>> On 31.08.16 at 17:31, wrote:
> On 24/08/16 08:44, Jan Beulich wrote:
>> Section start symbols frequently obscure the actual symbol name living
>> at the start of the section. Eliminate them where they can be replaced
>> by linker resolved .startof.* symbols. (Section end symbols may have
>> th
>>> On 31.08.16 at 16:59, wrote:
> On Thu, Aug 25, 2016 at 08:41:39AM -0600, Jan Beulich wrote:
>> >>> 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
>> > compa
Hi Konrad,
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
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
s/neccessary/necessary/
can use the ones that the caller p
>>> On 31.08.16 at 17:24, wrote:
> On 31/08/16 16:09, Julien Grall wrote:
>> On 31/08/16 16:06, Konrad Rzeszutek Wilk wrote:
>>> So you are thinking of exposing this 'xen feature bits' that Andrew
>>> mention
>>> to be on ARM as well.
>>
>> I only chat with Andrew about it and I have not looked at
On 31/08/16 16:24, Andrew Cooper wrote:
On 31/08/16 16:09, Julien Grall wrote:
On 31/08/16 16:06, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 31, 2016 at 03:49:55PM +0100, Julien Grall wrote:
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
Hey!
Hi Konrad,
Since v1 (and RFC):
[https://lis
Hi Konrad,
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
Hi Konrad,
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
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 B
On 24/08/16 08:44, Jan Beulich wrote:
> Section start symbols frequently obscure the actual symbol name living
> at the start of the section. Eliminate them where they can be replaced
> by linker resolved .startof.* symbols. (Section end symbols may have
> the same undesirable effect, but they're l
Wei Liu writes ("[PATCH v2 3/4] xen: fix gcov compilation"):
> Currently enabling gcov in hypervisor won't build because although
> 26c9d03d ("gcov: Adding support for coverage information") claimed that
> %.init.o files were excluded from applying compilation options, it was
> in fact not true.
>
Currently enabling gcov in hypervisor won't build because although
26c9d03d ("gcov: Adding support for coverage information") claimed that
%.init.o files were excluded from applying compilation options, it was
in fact not true.
Fix that by filtering out the options correctly. Because the dependenc
A small series to fix gcov build for both x86 and arm.
Wei Liu (4):
arm: acpi/boot.c is only used during initialisation
arm64: use "b" to branch to start_xen
xen: fix gcov compilation
xen: add a gcov Kconfig option
Config.mk | 3 ---
xen/Kconfig.debug | 5 +
The cbz instruction has range limitation. When compiled with gcov
support the object is larger so cbz can't handle that anymore. The error
message is like:
aarch64-linux-gnu-ld-EL -T xen.lds -N prelink.o \
/local/work/xen.git/xen/common/symbols-dummy.o -o
/local/work/xen.git/xen/.xen-sym
That file should contain code and data used during initialisation only.
Mark it as such in build system and correctly annotate enabled_cpus.
Signed-off-by: Wei Liu
Reviewed-by: Julien Grall
---
xen/arch/arm/acpi/Makefile | 2 +-
xen/arch/arm/acpi/boot.c | 2 +-
2 files changed, 2 insertions(
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
Config.mk | 3 ---
xen/Kconfig.debug | 5 +
xen/Rules.mk| 2 +-
xen/common/Makefile | 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Config.mk b/Config.mk
index 9c60896..08
>>> On 31.08.16 at 17:13, wrote:
> On Tue, Aug 30, 2016 at 09:12:45AM -0600, Jan Beulich wrote:
>> >>> On 30.08.16 at 16:32, wrote:
>> > On Thu, Aug 25, 2016 at 05:34:31AM -0600, Jan Beulich wrote:
>> >> >>> On 20.08.16 at 00:43, wrote:
>> >> > Create generic alloc and copy functions. We need
>>
On 31/08/16 16:09, Julien Grall wrote:
>
>
> On 31/08/16 16:06, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 31, 2016 at 03:49:55PM +0100, Julien Grall wrote:
>>> On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
Hey!
>>>
>>> Hi Konrad,
>>>
Since v1 (and RFC):
[https://lists.xen.org/arc
On Tue, Aug 30, 2016 at 09:14:28AM -0600, Jan Beulich wrote:
> >>> On 30.08.16 at 16:41, wrote:
> > On Thu, Aug 25, 2016 at 05:50:04AM -0600, Jan Beulich wrote:
> >> >>> On 20.08.16 at 00:43, wrote:
> >> > +case MULTIBOOT2_TAG_TYPE_MMAP:
> >> > +if ( get_mb2_data(tag, mmap, en
On Tue, Aug 30, 2016 at 09:12:45AM -0600, Jan Beulich wrote:
> >>> On 30.08.16 at 16:32, wrote:
> > On Thu, Aug 25, 2016 at 05:34:31AM -0600, Jan Beulich wrote:
> >> >>> On 20.08.16 at 00:43, wrote:
> >> > Create generic alloc and copy functions. We need
> >> > separate tools for memory allocatio
On 31/08/16 16:06, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 31, 2016 at 03:49:55PM +0100, Julien Grall wrote:
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
Hey!
Hi Konrad,
Since v1 (and RFC):
[https://lists.xen.org/archives/html/xen-devel/2016-08/msg01835.html]
- Acted on most all com
On Wed, Aug 31, 2016 at 03:49:55PM +0100, Julien Grall wrote:
> On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
> > Hey!
>
> Hi Konrad,
>
> > Since v1 (and RFC):
> > [https://lists.xen.org/archives/html/xen-devel/2016-08/msg01835.html]
> > - Acted on most all comments.
> > - Added ARM32 suppor
On Tue, Aug 30, 2016 at 09:09:50AM -0600, Jan Beulich wrote:
> >>> On 30.08.16 at 16:15, wrote:
> > On Mon, Aug 22, 2016 at 04:10:04AM -0600, Jan Beulich wrote:
> >> >>> On 20.08.16 at 00:43, wrote:
> >> > The final goal is xen.efi binary file which could be loaded by EFI
> >> > loader, multiboot
On 08/31/2016 04:30 AM, Wei Liu wrote:
>
> * Make ACPI builder available to components other than hvmloader
> - Boris Ostrovsky
>
Stuck due to licensing.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Thu, Aug 25, 2016 at 08:41:39AM -0600, Jan Beulich wrote:
> >>> 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 speci
On 25/08/16 14:37, Konrad Rzeszutek Wilk wrote:
Hey!
Hi Konrad,
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
This run is configured for baseline tests only.
flight 67616 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67616/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6c59c7c2f488d7c9b951b5ead780f6102dafae8a
baseline v
> * Per-cpu tasklet
> - Konrad Rzeszutek Wilk
Waiting for review and hopefully test results from Intel.
> === ARM ===
>
> * Livepatching
> - Konrad Rzeszutek Wilk
Need review from Stefano & Julien.
___
Xen-devel mailing list
Xen-devel@lists.x
>>> On 31.08.16 at 15:42, wrote:
> On 03/08/16 10:43, Jan Beulich wrote:
> On 02.08.16 at 21:08, wrote:
>>> On 04/07/16 16:53, Jan Beulich wrote:
>>> On 04.07.16 at 17:39, wrote:
> On 20/06/16 16:20, Jan Beulich wrote:
> On 20.06.16 at 16:32, wrote:
>>> On 15/06/16 11:28
On 31/08/16 14:45, Wei Liu wrote:
On Wed, Aug 31, 2016 at 02:25:59PM +0100, Julien Grall wrote:
Hi Wei,
On 30/08/16 13:01, Wei Liu wrote:
That file should contain code and data used during initialisation only.
Mark it as such in build system and correctly annotate enabled_cpus.
This is requ
On Wed, Aug 31, 2016 at 02:25:59PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 30/08/16 13:01, Wei Liu wrote:
> >That file should contain code and data used during initialisation only.
> >
> >Mark it as such in build system and correctly annotate enabled_cpus.
> >This is required to enable gcov su
On 03/08/16 10:43, Jan Beulich wrote:
On 02.08.16 at 21:08, wrote:
>> On 04/07/16 16:53, Jan Beulich wrote:
>> On 04.07.16 at 17:39, wrote:
On 20/06/16 16:20, Jan Beulich wrote:
On 20.06.16 at 16:32, wrote:
>> On 15/06/16 11:28, Jan Beulich wrote:
>>> --- a/xen/arc
Hi Wei,
On 30/08/16 13:01, Wei Liu wrote:
The cbz instruction has range limitation. When compiled with gcov
support the object is larger so cbz can't handle that anymore. The error
message is like:
aarch64-linux-gnu-ld-EL -T xen.lds -N prelink.o \
/local/work/xen.git/xen/common/symbols
Hi Wei,
On 30/08/16 13:01, Wei Liu wrote:
That file should contain code and data used during initialisation only.
Mark it as such in build system and correctly annotate enabled_cpus.
This is required to enable gcov support on ARM.
I am not sure to understand the requirement here. Does it mean
>>> On 31.08.16 at 14:32, wrote:
> On 31/08/16 13:28, Jan Beulich wrote:
> On 30.08.16 at 18:35, wrote:
>>> On 19/08/16 13:57, Jan Beulich wrote:
>>> On 19.08.16 at 14:39, wrote:
> On 19/08/16 08:52, Jan Beulich wrote:
>> Page tables get pre-populated with physical addresses whic
>>> On 30.08.16 at 21:58, wrote:
> On Thu, Aug 25, 2016 at 07:27:21AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43, wrote:
>> > +#define NULL ((void *)0)
>> > +
>> > +#define __packed __attribute__((__packed__))
>> > +#define __stdcall __attribute__((__stdcall__))
>> > +
>> > +#def
>>> On 30.08.16 at 21:32, wrote:
> On Thu, Aug 25, 2016 at 06:59:54AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43, wrote:
>> > @@ -223,14 +425,22 @@ trampoline_setup:
>> > callreloc
>> > mov %eax,sym_phys(multiboot_ptr)
>> >
>> > -/* Initialize BSS (no
On Wed, Aug 31, 2016 at 01:37:52PM +0100, Andrew Cooper wrote:
> On 31/08/16 09:30, Wei Liu wrote:
> > == Completed ==
> >
> > * Load BIOS via toolstack
> > - Anthony Perard
>
> This should be removed from the completed section. It is not yet in a
> suitable state for release.
>
> The issue
On 31/08/16 09:30, Wei Liu wrote:
> == Completed ==
>
> * Load BIOS via toolstack
> - Anthony Perard
This should be removed from the completed section. It is not yet in a
suitable state for release.
The issue of the "bios.bin" is a release blocker IMO.
~Andrew
On 31/08/16 13:28, Jan Beulich wrote:
On 30.08.16 at 18:35, wrote:
>> On 19/08/16 13:57, Jan Beulich wrote:
>> On 19.08.16 at 14:39, wrote:
On 19/08/16 08:52, Jan Beulich wrote:
> Page tables get pre-populated with physical addresses which, due to
> living inside the Xen ima
>>> On 30.08.16 at 19:19, wrote:
> On Thu, Aug 25, 2016 at 06:16:35AM -0600, Jan Beulich wrote:
>> >>> 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
>> > -cons
>>> On 30.08.16 at 18:35, wrote:
> On 19/08/16 13:57, Jan Beulich wrote:
> On 19.08.16 at 14:39, wrote:
>>> On 19/08/16 08:52, Jan Beulich wrote:
Page tables get pre-populated with physical addresses which, due to
living inside the Xen image, will never exceed 32 bits in width. That
Hi Stefano,
On 31/08/16 01:30, Stefano Stabellini wrote:
On Thu, 28 Jul 2016, Julien Grall wrote:
Currently, for a given GFN, the function __p2m_lookup will only return
the associated MFN and the p2m type of the mapping.
In some case we need the order of the mapping and the memaccess
permissio
>>> On 31.08.16 at 10:39, wrote:
> On 2016年08月25日 19:11, Jan Beulich wrote:
> On 17.08.16 at 14:05, wrote:
>>> 1 Motivation for Xen vIOMMU
>>>
>>> ===
>>> 1.1 Enable more than 255 vcpu support
>>> HPC virtualization
Hi Stefano,
On 23/08/16 02:20, Stefano Stabellini wrote:
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.
Good point. I will change it in the next version.
Regards,
--
Juli
Hi Stefano,
On 23/08/16 02:05, Stefano Stabellini wrote:
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 injectin
This run is configured for baseline tests only.
flight 67614 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67614/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 86079a4d2198b62b88140b9decb92ca73d443f94
baseline v
Hi Stefano,
On 16/08/16 01:49, Stefano Stabellini wrote:
On Thu, 28 Jul 2016, Julien Grall wrote:
static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
const union hsr hsr)
{
@@ -2487,40 +2519,16 @@ static void do_trap_data_abort_guest(struct
Hi Stefano,
On 16/08/16 01:35, Stefano Stabellini wrote:
On Thu, 28 Jul 2016, Julien Grall wrote:
Each entry in the page table has to table clean when the IOMMU does not
What does it mean to "table clean" ?
I meant "has to be cleaned".
support coherent walk. Rather than querying every
flight 100676 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100676/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4b314c89be24c26abfad47900f806cebeafc805e
baseline version:
xen 8bc0
The following HVM domU.cfg crashes during boot from emulated network
with qemu 2.7, but it works fine with qemu stable-2.6 branch:
name='hvm'
memory=1024
vcpus=2
boot="n"
disk=[ 'file:/disk0.raw,hda,w', ]
vif=[ 'mac=00:08:15:41:10:80,bridge=br0', ]
keymap="de"
serial="pty"
builder="hvm"
vnc=1
vncu
flight 100673 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100673/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6c59c7c2f488d7c9b951b5ead780f6102dafae8a
baseline version:
ovmf 86079a4d2198b62b88140
Hi Stefano,
On 16/08/16 17:20, Julien Grall wrote:
On 16/08/2016 01:21, Stefano Stabellini wrote:
On Thu, 28 Jul 2016, Julien Grall wrote:
A follow-up patch will add more case to the switch that will require the
IPA. So move the computation out of the switch.
Signed-off-by: Julien Grall
---
Hi Shannon,
On 31/08/16 07:37, Shannon Zhao wrote:
On 2016/8/30 1:46, Julien Grall wrote:
On 16/08/2016 06:25, Shannon Zhao wrote:
From: Shannon Zhao
It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal
SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.
SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest whi
flight 100669 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100669/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100664
test-amd64-i386-xl-qemuu-w
flight 67613 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67613/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-build fail REGR. vs. 67588
Regres
Hi Jan:
Sorry for later response. Thanks a lot for your comments.
On 2016年08月25日 19:11, Jan Beulich wrote:
On 17.08.16 at 14:05, wrote:
>> 1 Motivation for Xen vIOMMU
>>
>> ===
>> 1.1 Enable more than 255 vc
This run is configured for baseline tests only.
flight 67611 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67611/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 6 xen-boot
flight 100667 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100667/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 4 host-ping-check-native fail REGR. vs. 100657
test-armhf-armhf-x
This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.8 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a fixed
flight 100672 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100672/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 86079a4d2198b62b88140b9decb92ca73d443f94
baseline version:
ovmf 965268ea6df485d78b982
This run is configured for baseline tests only.
flight 67612 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67612/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 965268ea6df485d78b982d00270bd4ce7f673820
baseline v
flight 100671 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100671/
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 12 migrate-s
95 matches
Mail list logo
