Re: [Xen-devel] [PATCH v2 00/18] mini-os: support of auto-ballooning

On 10/08/16 23:07, Samuel Thibault wrote: > Hello, > > Juergen Gross, on Fri 05 Aug 2016 19:35:44 +0200, wrote: >> Support ballooning Mini-OS automatically up in case of memory shortage. > > Thanks! You are welcome. Be prepared for more to come: I'm just adding HVMlite support to Mini-OS.

Re: [Xen-devel] [PATCH v2 18/18] mini-os: balloon up in case of oom

On 10/08/16 23:07, Samuel Thibault wrote: > Juergen Gross, on Fri 05 Aug 2016 19:36:02 +0200, wrote: >> +static inline int chk_free_pages(unsigned long needed) >> +{ >> +return needed > nr_free_pages; >> +} > > The logic looks reversed to me: > >> +if ( chk_free_pages(1UL << order) ) >>

Re: [Xen-devel] [PATCH v2 17/18] mini-os: add support for ballooning up

On 10/08/16 23:02, Samuel Thibault wrote: > Juergen Gross, on Fri 05 Aug 2016 19:36:01 +0200, wrote: >> +#define N_BALLOON_FRAMES 64 >> +static unsigned long balloon_frames[N_BALLOON_FRAMES]; >> + >> +int balloon_up(unsigned long n_pages) >> +{ >> +unsigned long page, pfn; >> +int rc; >> +

Re: [Xen-devel] [PATCH v2 16/18] mini-os: map page allocator's bitmap to virtual kernel area for ballooning

On 10/08/16 22:45, Samuel Thibault wrote: > It looks a bit odd to be remapping something that was just allocated, > but I guess it makes portability easier. Remapping needs the page allocator to be active as page tables need to be allocated. :-) > > Juergen Gross, on Fri 05 Aug 2016 19:36:00

Re: [Xen-devel] [PATCH v2 15/18] mini-os: remap p2m list in case of ballooning

On 10/08/16 22:41, Samuel Thibault wrote: > Juergen Gross, on Fri 05 Aug 2016 19:35:59 +0200, wrote: >> +void arch_remap_p2m(unsigned long max_pfn) >> +{ > ... >> + >> +virt_kernel_area_end += PAGE_SIZE * p2m_pages(nr_max_pages); > > I'd however rather see an assertion against hitting

[Xen-devel] xen does not support the 8G large bar

Hi George, I found that you have submitted a patch about "libxl,hvmloader: Don't relocate memory for MMIO hole". So, I have a "8G large bar PCI device(NVIDIA Tesla M60)" passthrough question to ask you. Host passthrough PCI Device info: lspci -vs 06:00.0 06:00.0 3D controller: NVIDIA

[Xen-devel] [PATCH V2] xen: support enabling SMEP/SMAP for HVM only

Enhance "smep" and "smap" command line options to support enabling SMEP or SMAP for HVM only with allowing "hvm" as a value. Signed-off-by: He Chen --- Changes in V2: * Allow "hvm" as a value to "smep" and "smap" command line options. * Clear SMEP/SMAP CPUID bits for pv

[Xen-devel] [ovmf test] 100398: all pass - PUSHED

flight 100398 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100398/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 298f83612375bda69e8a7230dfea036e85eda553 baseline version: ovmf

Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711

On 08/10/2016 10:54 PM, Evgenii Shatokhin wrote: > On 10.08.2016 15:49, Bob Liu wrote: >> >> On 08/10/2016 08:33 PM, Evgenii Shatokhin wrote: >>> On 14.07.2016 15:04, Bob Liu wrote: On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote: > On 11.07.2016 15:04, Bob Liu wrote: >> >>

[Xen-devel] Livepatch, symbol resolutions between two livepatchs (new_symbol=0)

Hey Ross, I am running in a symbol dependency issue that I am not exactly sure how to solve. I have an payload that introduces a new function (xen_foobar) which will patch over xen_extra_version(). The loading says: (XEN) livepatch_elf.c:321: livepatch: xen_foobar: Symbol resolved: xen_foobar

Re: [Xen-devel] [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case

On Wed, Aug 10, 2016 at 03:46:49AM -0600, Jan Beulich wrote: > >>> On 09.08.16 at 20:01, wrote: > >> >> > @@ -70,7 +71,11 @@ struct payload { > >> >> > unsigned int nsyms; /* Nr of entries in .strtab > >> >> > and > >> >> > symbols. */ > >> >> >

[Xen-devel] [qemu-mainline baseline-only test] 66960: regressions - FAIL

This run is configured for baseline tests only. flight 66960 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66960/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-pvgrub 9

Re: [Xen-devel] unable start xen in hikey

You should compile kernel first. Please follow the "Getting Started" page on 96boards On 8/10/2016 7:07 AM, Kamenee Arumugam wrote: Hi Chen, I have tried to flash UEFI in my board with latest one but still facing the same issue. Regarding to use dtb file from kernel source, I couldnt find

Re: [Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file

On Wed, 10 Aug 2016, Lars Kurth wrote: > COPYING file: > The motivation of this change is to make it easier for new > contributors to conduct a license and patent review, WITHOUT > changing any licenses. > - Remove references to BSD-style licenses as we have more > common license exceptions and

[Xen-devel] [linux-3.14 test] 100389: regressions - FAIL

flight 100389 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/100389/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 99747

[Xen-devel] [distros-debian-squeeze test] 66959: tolerable FAIL

flight 66959 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66959/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail blocked in 66894

Re: [Xen-devel] [PATCH v2 00/18] mini-os: support of auto-ballooning

Hello, Juergen Gross, on Fri 05 Aug 2016 19:35:44 +0200, wrote: > Support ballooning Mini-OS automatically up in case of memory shortage. Thanks! Samuel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 18/18] mini-os: balloon up in case of oom

Juergen Gross, on Fri 05 Aug 2016 19:36:02 +0200, wrote: > +static inline int chk_free_pages(unsigned long needed) > +{ > +return needed > nr_free_pages; > +} The logic looks reversed to me: > +if ( chk_free_pages(1UL << order) ) > +goto no_memory; I would have written it > +

[Xen-devel] [ovmf baseline-only test] 66958: all pass

This run is configured for baseline tests only. flight 66958 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66958/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1fbd0ca16a997b68ed320340aef18645e71e8a73 baseline

[Xen-devel] [linux-3.18 test] 100385: tolerable FAIL - PUSHED

flight 100385 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/100385/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 11 guest-start fail in 100372 pass in 100385 test-armhf-armhf-xl-rtds 15

Re: [Xen-devel] [PATCH v2 16/18] mini-os: map page allocator's bitmap to virtual kernel area for ballooning

It looks a bit odd to be remapping something that was just allocated, but I guess it makes portability easier. Juergen Gross, on Fri 05 Aug 2016 19:36:00 +0200, wrote: > diff --git a/balloon.c b/balloon.c > index 4c18c5c..75b87c8 100644 > --- a/balloon.c > +++ b/balloon.c > @@ -44,3 +44,20 @@

Re: [Xen-devel] [PATCH v2 15/18] mini-os: remap p2m list in case of ballooning

Juergen Gross, on Fri 05 Aug 2016 19:35:59 +0200, wrote: > +void arch_remap_p2m(unsigned long max_pfn) > +{ ... > + > +virt_kernel_area_end += PAGE_SIZE * p2m_pages(nr_max_pages); I'd however rather see an assertion against hitting VIRT_DEMAND_AREA here, even if the figures happen to make it

Re: [Xen-devel] [PATCH v2 15/18] mini-os: remap p2m list in case of ballooning

Juergen Gross, on Fri 05 Aug 2016 19:35:59 +0200, wrote: > In case of enabled ballooning we must be prepared for a growing p2m > list. If the maximum memory size of the domain can't be covered by the > actual p2m list remap it to the kernel virtual mapping area and leave > enough space at the end.

Re: [Xen-devel] [PATCH v2 14/18] mini-os: move p2m related macros to header file

Juergen Gross, on Fri 05 Aug 2016 19:35:58 +0200, wrote: > In order to be able to use p2m related macros for ballooning move > their definitions to arch/x86/mm.h. > > There is no need to define different macros regarding index masks and > number of entries for the different levels, as all levels

Re: [Xen-devel] [PATCH v2 13/18] mini-os: add function to map one frame

Juergen Gross, on Fri 05 Aug 2016 19:35:57 +0200, wrote: > Add a function to map one physical frame to a specified virtual > address as read/write. This will be used later multiple times. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault

Re: [Xen-devel] [PATCH v2 12/18] mini-os: don't allocate new pages for level 1 p2m tree

Juergen Gross, on Fri 05 Aug 2016 19:35:56 +0200, wrote: > When constructing the 3 level p2m tree there is no need to allocate > new pages for the level 1 containing the p2m info for all pages. The > pages from the linear p2m list constructed by the hypervisor can be > used for that purpose. > >

Re: [Xen-devel] [PATCH v2 11/18] mini-os: add checks for out of memory

Juergen Gross, on Fri 05 Aug 2016 19:35:55 +0200, wrote: > There are several core functions in Mini-OS not checking for failed > memory allocations. Add such checks. > > Add do_map_frames() dummy function to arm architecture as it will be > needed in future for compilations to succeed. > >

Re: [Xen-devel] [PATCH v2 10/18] mini-os: remove unused mem_test() function

Juergen Gross, on Fri 05 Aug 2016 19:35:54 +0200, wrote: > mem_test() isn't used anywhere and its value is rather questionable > with mini-os being in a mature state. Remove the function. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault

Re: [Xen-devel] [PATCH v2 09/18] mini-os: modify virtual memory layout for support of ballooning

Juergen Gross, on Fri 05 Aug 2016 19:35:53 +0200, wrote: > In order to be able to support ballooning the virtual memory layout > of Mini-OS has to be modified: instead of a (nearly) consecutive > area used for physical memory mapping, on demand mappings, and heap > we need enough spare place for

Re: [Xen-devel] [PATCH v2 08/18] mini-os: get maximum memory size from hypervisor

Juergen Gross, on Fri 05 Aug 2016 19:35:52 +0200, wrote: > Add support for obtaining the maximum memory size from the hypervisor. > This will make it possible to support ballooning. > > Signed-off-by: Juergen Gross Acked-by: Samuel Thibault >

[Xen-devel] [xen-unstable baseline-only test] 66957: tolerable FAIL

This run is configured for baseline tests only. flight 66957 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66957/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-build

Re: [Xen-devel] [PATCH v2 07/18] mini-os: add ballooning config item

Juergen Gross, on Fri 05 Aug 2016 19:35:51 +0200, wrote: > Add CONFIG_BALLOON defaulting to 'n' as a config item to Mini-OS. > > Add balloon.c, balloon.h and arch/*/balloon.c for future use. > > Signed-off-by: Juergen Gross Not much to be against here :) Acked-by: Samuel

Re: [Xen-devel] [PATCH v2 06/18] mini-os: let memory allocation fail if no free page available

Juergen Gross, on Fri 05 Aug 2016 19:35:50 +0200, wrote: > Instead of panicing when no page can be allocated try to fail the > memory allocation by returning NULL instead. > > Signed-off-by: Juergen Gross > Reviewed-by: Wei Liu Acked-by: Samuel Thibault

Re: [Xen-devel] [PATCH v2 05/18] mini-os: add nr_free_pages counter

Juergen Gross, on Fri 05 Aug 2016 19:35:49 +0200, wrote: > Add a variable holding the number of available memory pages. This will > aid auto-ballooning later. > > Signed-off-by: Juergen Gross > Reviewed-by: Wei Liu Acked-by: Samuel Thibault

Re: [Xen-devel] [PATCH v2 04/18] mini-os: add description of x86 memory usage

Juergen Gross, on Fri 05 Aug 2016 19:35:48 +0200, wrote: > Add a brief description how the physical and virtual address usage > looks like on x86 to include/x86/arch_mm.h > > Signed-off-by: Juergen Gross > Reviewed-by: Wei Liu Acked-by: Samuel Thibault

Re: [Xen-devel] [PATCH v2 03/18] mini-os: remove MM_DEBUG code

Juergen Gross, on Fri 05 Aug 2016 19:35:47 +0200, wrote: > mm.c contains unused code inside #ifdef MM_DEBUG areas. Its usability > is rather questionable and some parts are even wrong (e.g. > print_chunks() called with nr_pages > 1000 will clobber an arbitrary > stack content with a 0 byte). > >

Re: [Xen-devel] [PATCH v2 02/18] mini-os: remove unused alloc_contig_pages() function

Juergen Gross, on Fri 05 Aug 2016 19:35:46 +0200, wrote: > alloc_contig_pages() is never used anywhere in mini-os. Remove it. > > Signed-off-by: Juergen Gross > Reviewed-by: Wei Liu Acked-by: Samuel Thibault > --- >

Re: [Xen-devel] [PATCH v2 01/18] mini-os: correct first free pfn

Juergen Gross, on Fri 05 Aug 2016 19:35:45 +0200, wrote: > The first free pfn available for allocation is calculated by adding the > number of page table frames to the pfn of the first page table and > then the magic number 3 to account for start info page et al. > > As the start info page,

[Xen-devel] [linux-4.1 test] 100383: tolerable FAIL - PUSHED

flight 100383 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/100383/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl 11 guest-start fail like 99847

Re: [Xen-devel] [DRAFT v5] PV Calls protocol design document (former XenSock)

Ping? On Thu, 4 Aug 2016, Stefano Stabellini wrote: > Hi all, > > This is the design document of the PV Calls protocol. You can find > prototypes of the Linux frontend and backend drivers here: > > git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-5 > > To use them,

[Xen-devel] [ovmf test] 100388: all pass - PUSHED

flight 100388 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100388/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf af90df3cb099ed8e009579b7b55e7142dc0fc410 baseline version: ovmf

[Xen-devel] [xen-unstable-smoke test] 100396: tolerable all pass - PUSHED

flight 100396 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100396/ 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

[Xen-devel] [seabios baseline-only test] 66956: regressions - FAIL

This run is configured for baseline tests only. flight 66956 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66956/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 4

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

On Tue, Aug 09, 2016 at 09:09:07AM -0700, James Bottomley wrote: > On Tue, 2016-08-09 at 15:24 +0100, One Thousand Gnomes wrote: > > > table development go under copyleft-next, Rusty recently asked for > > > code to go in prior to the license tag being added denoting this > > > license as

[Xen-devel] [qemu-mainline test] 100379: tolerable FAIL - PUSHED

flight 100379 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100379/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100363

Re: [Xen-devel] [PATCH 2/2] x86/vmx: conditionally disable LBR support due to TSX format quirk

On Wed, Aug 10, 2016 at 06:34:10AM -0600, Jan Beulich wrote: > >>> On 10.08.16 at 08:59, wrote: > > Systems that support LBR formats that include TSX information but do > > not support TSX require special handling when saving and restoring MSR > > values. For example, see the Linux

Re: [Xen-devel] xl dump-core fails, j!=nr_pages

On Wed, Aug 10, Wei Liu wrote: > On Wed, Aug 10, 2016 at 10:25:30AM +0200, Olaf Hering wrote: > > On Wed, Aug 10, Olaf Hering wrote: > > > > This fails also with 4.4/4.5/4.6. Is 'xl dump-core' supposed to work > > with HVM guests? I think at some point 'xm dump-core' used to work, just > >

[Xen-devel] [xen-unstable-smoke test] 100394: regressions - FAIL

flight 100394 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100394/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 100391 Tests which

[Xen-devel] [XTF PATCH 1/3] xtf-runner: introduce get_xen_version

Signed-off-by: Wei Liu --- xtf-runner | 13 + 1 file changed, 13 insertions(+) diff --git a/xtf-runner b/xtf-runner index c063699..7b69c45 100755 --- a/xtf-runner +++ b/xtf-runner @@ -151,6 +151,19 @@ def __repr__(self): return "TestInfo(%s)" %

[Xen-devel] [XTF PATCH 0/3] Support getting output from either console or log file

Wei Liu (3): xtf-runner: introduce get_xen_version xtf-runner: options for different modes to get output xtf-runner: support two modes for getting output xtf-runner | 144 - 1 file changed, 123 insertions(+), 21 deletions(-) --

[Xen-devel] [XTF PATCH 3/3] xtf-runner: support two modes for getting output

We need two modes for getting output: 1. Use console directly with newer (>=4.8) Xen 2. Use log files for older Xen This patch implements both. The default behaviour is to choose mode automatically based on Xen version. User can also explicitly specify which mode to use. Signed-off-by: Wei Liu

[Xen-devel] [XTF PATCH 2/3] xtf-runner: options for different modes to get output

Only options and help text. Implementation will come later. Signed-off-by: Wei Liu --- xtf-runner | 27 +++ 1 file changed, 27 insertions(+) diff --git a/xtf-runner b/xtf-runner index 7b69c45..73a4e0d 100755 --- a/xtf-runner +++ b/xtf-runner @@

[Xen-devel] [PATCH v2 1/2] x86/altp2m: use __get_gfn_type_access to avoid lock conflicts

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 can make dom0 freeze. During mem_access setting the hp2m is already locked. For

[Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case

Currently setting altp2mhvm=1 in the domain configuration allows access to the altp2m interface for both in-guest and external privileged tools. This poses a problem for use-cases where only external access should be allowed, requiring the user to compile Xen with XSM enabled to be able to

Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711

On 10.08.2016 15:49, Bob Liu wrote: On 08/10/2016 08:33 PM, Evgenii Shatokhin wrote: On 14.07.2016 15:04, Bob Liu wrote: On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote: On 11.07.2016 15:04, Bob Liu wrote: On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote: On 06.06.2016 11:42, Dario

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

On Aug 10, 2016 03:52, "Julien Grall" wrote: > > Hello Tamas, > > > On 09/08/2016 21:16, Tamas K Lengyel wrote: >> >> On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall wrote: >>> >>> Hello Sergej, >>> >>> >>> On 01/08/16 18:10, Sergej Proskurin wrote:

Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()

On Aug 10, 2016 05:52, "Jan Beulich" wrote: > > >>> On 10.08.16 at 12:55, wrote: > > On 08/10/2016 01:12 PM, Jan Beulich wrote: > > On 10.08.16 at 09:35, wrote: > >>> --- a/xen/common/vm_event.c > >>> +++

Re: [Xen-devel] [PATCH 1/2] x86/vmx: dump MSR load area

On Wed, Aug 10, 2016 at 04:44:21AM -0600, Jan Beulich wrote: > >>> On 10.08.16 at 08:59, wrote: > > --- a/xen/arch/x86/hvm/vmx/vmcs.c > > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > > @@ -1740,6 +1740,20 @@ static void vmx_dump_sel2(char *name, uint32_t lim) > > printk("%s:

Re: [Xen-devel] [PATCH v2 13/23] acpi/hvmloader: Include file/paths adjustments

On 08/10/2016 09:30 AM, Jan Beulich wrote: >> +#ifndef __ACPI_X86_H__ >> +#define __ACPI_X86_H__ >> + >> +#define IOAPIC_BASE_ADDRESS 0xfec0 > This will need re-basing - looks like your submission and my commit > happened at about the same time. Right, I saw that but this series is based on

Re: [Xen-devel] [PATCH v2 12/23] acpi/hvmloader: Link ACPI object files directly

On 08/10/2016 09:17 AM, Jan Beulich wrote: On 04.08.16 at 23:06, wrote: >> v2: >> * Reordered .gitignore changes alphabetically >> * Dropped trailing slashes >> * Use relative path for ACPI_PATH >> * Use $(addprefix...) >> * Dropped use of 'cd' in rules and

Re: [Xen-devel] help -- A question about ' XENFEAT_auto_translated_physmap':

>>> On 10.08.16 at 15:19, wrote: > On August 09, 2016 9:02 PM, < jbeul...@suse.com > wrote: >> >>> On 09.08.16 at 14:36, wrote: >> > Hi Jan, >> > >> > A question about ' XENFEAT_auto_translated_physmap': >> > >> > In linux code, in arch/x86/xen/mmu.c, >>

Re: [Xen-devel] [PATCH v2 17/23] libacpi: Build DSDT for PVH guests

>>> On 04.08.16 at 23:06, wrote: > @@ -34,13 +34,15 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl > $(MK_DSDT): mk_dsdt.c > $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c > > -$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT) >

[Xen-devel] [libvirt test] 100381: tolerable FAIL - PUSHED

flight 100381 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/100381/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12

Re: [Xen-devel] [PATCH v2 13/23] acpi/hvmloader: Include file/paths adjustments

>>> On 04.08.16 at 23:06, wrote: > --- a/tools/firmware/hvmloader/acpi/README > +++ b/tools/firmware/hvmloader/acpi/README > @@ -1,11 +1,19 @@ > -ACPI Table for domain firmware > +ACPI builder for domain firmware > > > -INSTALL > +BUILDING ACPI > -

Re: [Xen-devel] Save/Restore is not working properly

On Wed, Aug 10, 2016 at 12:11 PM, Roger Pau Monné wrote: > On Sun, Aug 07, 2016 at 07:51:14PM +0430, Cendrin Sa wrote: >> Hi, >> I was searching a way to clone a machine using both memory and disk >> approach. >> I checked xen save/restore but after restoring, I can only

Re: [Xen-devel] help -- A question about ' XENFEAT_auto_translated_physmap':

On August 09, 2016 9:02 PM, < jbeul...@suse.com > wrote: > >>> On 09.08.16 at 14:36, wrote: > > Hi Jan, > > > > A question about ' XENFEAT_auto_translated_physmap': > > > > In linux code, in arch/x86/xen/mmu.c, > > I assume you know that I'm not a maintainer of the Linux code.

[Xen-devel] [xen-unstable test] 100377: tolerable FAIL

flight 100377 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100377/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass in 100367 Regressions which are

Re: [Xen-devel] [PATCH v2 12/23] acpi/hvmloader: Link ACPI object files directly

>>> On 04.08.16 at 23:06, wrote: > v2: > * Reordered .gitignore changes alphabetically > * Dropped trailing slashes > * Use relative path for ACPI_PATH > * Use $(addprefix...) > * Dropped use of 'cd' in rules and instead add $(ACPI_BUILD_DIR)/ to $* What about the

Re: [Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0

>>> On 10.08.16 at 14:18, wrote: > On 10/08/16 11:21, Jan Beulich wrote: > On 10.08.16 at 11:58, wrote: >>> On 10/08/16 10:23, Jan Beulich wrote: --- a/xen/arch/x86/numa.c +++ b/xen/arch/x86/numa.c @@ -355,11 +355,21 @@

Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711

On 08/10/2016 08:33 PM, Evgenii Shatokhin wrote: > On 14.07.2016 15:04, Bob Liu wrote: >> >> On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote: >>> On 11.07.2016 15:04, Bob Liu wrote: On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote: > On 06.06.2016 11:42, Dario Faggioli wrote:

[Xen-devel] [xen-unstable-smoke test] 100391: tolerable all pass - PUSHED

flight 100391 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100391/ 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

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 8/10/2016 6:43 PM, Paul Durrant wrote: -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: 10 August 2016 11:33 To: Paul Durrant; Yu Zhang Cc: Andrew Cooper; George Dunlap; Jun Nakajima; Kevin Tian; zhiyuan...@intel.com; xen-devel@lists.xen.org; Tim (Xen.org)

Re: [Xen-devel] [BUG] kernel BUG at drivers/block/xen-blkfront.c:1711

On 14.07.2016 15:04, Bob Liu wrote: On 07/14/2016 07:49 PM, Evgenii Shatokhin wrote: On 11.07.2016 15:04, Bob Liu wrote: On 07/11/2016 04:50 PM, Evgenii Shatokhin wrote: On 06.06.2016 11:42, Dario Faggioli wrote: Just Cc-ing some Linux, block, and Xen on CentOS people... Ping. Any

Re: [Xen-devel] [PATCH 2/2] x86/vmx: conditionally disable LBR support due to TSX format quirk

>>> On 10.08.16 at 08:59, wrote: > Systems that support LBR formats that include TSX information but do > not support TSX require special handling when saving and restoring MSR > values. For example, see the Linux kernel quirks[1, 2] in the MSR > context switching code. As a wrmsr

Re: [Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0

On 10/08/16 11:21, Jan Beulich wrote: On 10.08.16 at 11:58, wrote: >> On 10/08/16 10:23, Jan Beulich wrote: >>> --- a/xen/arch/x86/numa.c >>> +++ b/xen/arch/x86/numa.c >>> @@ -355,11 +355,21 @@ void __init init_cpu_to_node(void) >>> } >>> } >>> >>>

Re: [Xen-devel] [PATCH] x86/string: Use compiler builtins whenever possible

On 09/08/16 15:39, Jan Beulich wrote: On 09.08.16 at 16:27, wrote: >> On 09/08/16 15:01, Jan Beulich wrote: >> On 09.08.16 at 14:41, wrote: The use of -fno-builtin inhibits this automatic transformation. Manually tranform

Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection

On 10/08/16 11:29, Jan Beulich wrote: On 10.08.16 at 11:58, wrote: >> On 03.08.16 at 03:32, wrote: > On 25/07/16 07:09, Kang, Luwei wrote: > First of all - please don't top post. > >> What about remove the

Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()

>>> On 10.08.16 at 12:55, wrote: > On 08/10/2016 01:12 PM, Jan Beulich wrote: > On 10.08.16 at 09:35, wrote: >>> --- a/xen/common/vm_event.c >>> +++ b/xen/common/vm_event.c >>> @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d,

Re: [Xen-devel] [PATCH 2/2] x86/NUMA: cleanup

>>> On 10.08.16 at 12:35, wrote: > On 10/08/16 10:24, Jan Beulich wrote: >> - drop the only left CONFIG_NUMA conditional (this is always true) > > I observe that CONFIG_NUMA_EMU is also unconditionally true, which > offers further cleanup opportunities (albeit it

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: use xl create -Fc directly

On 10/08/16 12:01, Wei Liu wrote: > On Tue, Aug 09, 2016 at 04:37:40PM +0100, Wei Liu wrote: >> On Tue, Aug 09, 2016 at 02:11:27PM +0100, Andrew Cooper wrote: >>> On 08/08/16 14:13, Wei Liu wrote: On Mon, Aug 08, 2016 at 02:06:37PM +0100, Andrew Cooper wrote: > On 08/08/16 12:24, Wei Liu

[Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file

COPYING file: The motivation of this change is to make it easier for new contributors to conduct a license and patent review, WITHOUT changing any licenses. - Remove references to BSD-style licenses as we have more common license exceptions and replace with "other license stanzas" - List the

Re: [Xen-devel] xl dump-core fails, j!=nr_pages

On Wed, Aug 10, 2016 at 10:25:30AM +0200, Olaf Hering wrote: > On Wed, Aug 10, Olaf Hering wrote: > > This fails also with 4.4/4.5/4.6. Is 'xl dump-core' supposed to work > with HVM guests? I think at some point 'xm dump-core' used to work, just > crash(1) could not deal with the result. > > >

[Xen-devel] [xen-unstable-coverity test] 100390: all pass - PUSHED

flight 100390 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/100390/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 7f5c8075364776eb139bbd421ad443ae9e4465dc baseline version: xen

Re: [Xen-devel] Save/Restore is not working properly

On Sun, Aug 07, 2016 at 07:51:14PM +0430, Cendrin Sa wrote: > Hi, > I was searching a way to clone a machine using both memory and disk > approach. > I checked xen save/restore but after restoring, I can only work some > seconds with my machine and it will crash with the_kernel_task_hang_up. >

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: use xl create -Fc directly

On Tue, Aug 09, 2016 at 04:37:40PM +0100, Wei Liu wrote: > On Tue, Aug 09, 2016 at 02:11:27PM +0100, Andrew Cooper wrote: > > On 08/08/16 14:13, Wei Liu wrote: > > > On Mon, Aug 08, 2016 at 02:06:37PM +0100, Andrew Cooper wrote: > > >> On 08/08/16 12:24, Wei Liu wrote: > > >>> Now that xl create

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 8/10/2016 6:33 PM, Jan Beulich wrote: On 10.08.16 at 10:09, wrote: On 8/8/2016 11:40 PM, Jan Beulich wrote: On 12.07.16 at 11:02, wrote: @@ -178,8 +179,34 @@ static int hvmemul_do_io( break; case

Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()

On 08/10/2016 01:12 PM, Jan Beulich wrote: On 10.08.16 at 09:35, wrote: >> --- a/xen/common/vm_event.c >> +++ b/xen/common/vm_event.c >> @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct >> vm_event_domain *ved) >> v =

Re: [Xen-devel] [PATCH 1/2] x86/vmx: dump MSR load area

>>> On 10.08.16 at 08:59, wrote: > --- a/xen/arch/x86/hvm/vmx/vmcs.c > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > @@ -1740,6 +1740,20 @@ static void vmx_dump_sel2(char *name, uint32_t lim) > printk("%s:%08x %016"PRIx64"\n", name, limit, base); > } > > +static void

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2016 11:33 > To: Paul Durrant; Yu Zhang > Cc: Andrew Cooper; George Dunlap; Jun Nakajima; Kevin Tian; > zhiyuan...@intel.com; xen-devel@lists.xen.org; Tim (Xen.org) > Subject: Re: [PATCH v5 3/4] x86/ioreq

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

>>> On 10.08.16 at 10:09, wrote: > > On 8/8/2016 11:40 PM, Jan Beulich wrote: > On 12.07.16 at 11:02, wrote: >>> @@ -178,8 +179,34 @@ static int hvmemul_do_io( >>> break; >>> case X86EMUL_UNHANDLEABLE: >>> { >>>

Re: [Xen-devel] [PATCH 2/2] x86/NUMA: cleanup

On 10/08/16 10:24, Jan Beulich wrote: > - drop the only left CONFIG_NUMA conditional (this is always true) I observe that CONFIG_NUMA_EMU is also unconditionally true, which offers further cleanup opportunities (albeit it probably a separate patch). > - drop struct node_data's node_id field

Re: [Xen-devel] [PATCH] solve SMAP/SMEP issues with 32-bit pv guests

On Tue, Aug 9, 2016 at 10:13 AM, He Chen wrote: > This patch is going to solve SMAP/SMEP issues with 32-bit pv guests by > adding new xen command line options "xen_smap" and "xen_smep". > > For the details, please see: >

Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection

>>> On 10.08.16 at 11:58, wrote: >> >>> On 03.08.16 at 03:32, wrote: >> >> On 25/07/16 07:09, Kang, Luwei wrote: >> >> First of all - please don't top post. >> >> >> >> > What about remove the dependency between AVX2 and AVX512F >> >> >>

Re: [Xen-devel] [PATCH v4 2/2] qdisk - hw/block/xen_disk: grant copy implementation

On Tue, Aug 09, 2016 at 07:34:14PM +0200, Paulina Szubarczyk wrote: > On 08/09/2016 06:56 PM, Anthony PERARD wrote: > > On Tue, Aug 02, 2016 at 04:06:30PM +0200, Paulina Szubarczyk wrote: > > > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h > > > index 640c31e..e80c61f

Re: [Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0

>>> On 10.08.16 at 11:58, wrote: > On 10/08/16 10:23, Jan Beulich wrote: >> --- a/xen/arch/x86/numa.c >> +++ b/xen/arch/x86/numa.c >> @@ -355,11 +355,21 @@ void __init init_cpu_to_node(void) >> } >> } >> >> -EXPORT_SYMBOL(cpu_to_node); >>

[Xen-devel] [xen-unstable-smoke test] 100387: regressions - FAIL

flight 100387 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100387/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 100365 Tests which

Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()

>>> On 10.08.16 at 09:35, wrote: > --- a/xen/common/vm_event.c > +++ b/xen/common/vm_event.c > @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct > vm_event_domain *ved) > v = d->vcpu[rsp.vcpu_id]; > > /* > + * Make sure the

Re: [Xen-devel] [PATCH] x86/traps: Fix failed ASSERT() in do_guest_trap()

>>> On 10.08.16 at 11:53, wrote: > c/s 2e426d6 "x86/traps: Drop use_error_code parameter from do_{,guest_}trap()" > introduced an assertion which covered the correctness of shifting 1u by an > input parameter. > > While all other inputs provide a constants vector, the

Re: [Xen-devel] [xen-unstable-smoke test] 100382: regressions - FAIL

>>> On 10.08.16 at 10:57, wrote: > On Wed, Aug 10, 2016 at 07:43:38AM +, osstest service owner wrote: >> flight 100382 xen-unstable-smoke real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/100382/ >> >> Regressions :-( >> >> Tests which did not succeed and

Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection

> >>> On 03.08.16 at 03:32, wrote: > >> On 25/07/16 07:09, Kang, Luwei wrote: > >> First of all - please don't top post. > >> > >> > What about remove the dependency between AVX2 and AVX512F > >> >> ( AVX2: > >> [AVX512F], ) ? > >> > >> Yes,

  1   2   >