[Xen-devel] [xen-4.6-testing baseline-only test] 67599: tolerable FAIL

This run is configured for baseline tests only. flight 67599 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67599/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-i386-pvgrub 10 guest-start

[Xen-devel] [xen-4.5-testing test] 100637: tolerable FAIL - PUSHED

flight 100637 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100637/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 100507

[Xen-devel] [xen-unstable baseline-only test] 67597: regressions - FAIL

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

[Xen-devel] [xen-4.7-testing test] 100635: tolerable FAIL - PUSHED

flight 100635 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100635/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl 11 guest-start fail in 100632 pass in 100635 test-armhf-armhf-libvirt

Re: [Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()

On 08/26/16 23:33, Tamas K Lengyel wrote: > On Fri, Aug 26, 2016 at 12:11 AM, Razvan Cojocaru > wrote: >> 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

[Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device

Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches from old kernel") using the INTx interrupt from Xen PCI platform device for event channel notification would just lockup the guest during bootup. postcore_initcall now calls xs_reset_watches which will eventually try to read a

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

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

Re: [Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()

On Fri, Aug 26, 2016 at 12:11 AM, Razvan Cojocaru wrote: > 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

[Xen-devel] [xen-4.6-testing test] 100630: tolerable FAIL - PUSHED

flight 100630 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100630/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 100504

Re: [Xen-devel] [PATCH 1/2] xen/x86: Convert to hotplug state machine

On 08/17/2016 04:33 AM, Sebastian Andrzej Siewior wrote: > On 2016-08-15 10:46:46 [-0400], Boris Ostrovsky wrote: >> Switch to new CPU hotplug infrastructure. >> >> Signed-off-by: Boris Ostrovsky >> Suggested-by: Sebastian Andrzej Siewior >> ---

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

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

Re: [Xen-devel] [PATCH 3/3] mini-os: remove unused functions from sched.c

Juergen Gross, on Fri 26 Aug 2016 16:35:36 +0200, wrote: > sched.c contains some functions nobody is using. Remove them. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault > --- > sched.c | 48

Re: [Xen-devel] [PATCH 1/3] mini-os: cleanup x86_32.S

Juergen Gross, on Fri 26 Aug 2016 16:35:34 +0200, wrote: > arch/x86/x86_32.S has some superfluous instructions. Remove them. > > Signed-off-by: Juergen Gross These are indeed remnants from the past. Reviewed-by: Samuel Thibault > --- >

[Xen-devel] [xen-4.5-testing test] 100631: regressions - FAIL

flight 100631 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100631/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 100507

Re: [Xen-devel] [PATCH v3 5/6] x86/time: implement PVCLOCK_TSC_STABLE_BIT

On 08/25/2016 11:37 AM, Jan Beulich wrote: 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

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

On Fri, Aug 26, 2016 at 5:10 PM, Jan Beulich wrote: On 26.08.16 at 16:53, wrote: >>> I'm not sure. I'd like to see the current logic altered as little as >>> possible, and what you suggest above is more than that minimum. >> >> Then, that

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

>>> On 26.08.16 at 16:35, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 26.08.16 at 13:38, wrote: >> > Another example would be a DMOP that takes (or returns) an event >> > channel

Re: [Xen-devel] [PATCH v3 6/6] docs: update clocksource option

On 08/25/2016 11:38 AM, Jan Beulich wrote: 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

Re: [Xen-devel] [PATCH v3 4/6] x86/time: refactor read_platform_stime()

On 08/25/2016 11:17 AM, Jan Beulich wrote: 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 ..."? Yeap, sounds better that way. > >> In the case of

Re: [Xen-devel] [PATCH v3 3/6] x86/time: streamline platform time init on plt_update()

On 08/25/2016 11:13 AM, Jan Beulich wrote: 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

Re: [Xen-devel] [PATCH v3 2/6] x86/time: implement tsc as clocksource

On 08/25/2016 11:06 AM, Jan Beulich wrote: 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

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

>>> On 26.08.16 at 16:53, wrote: >> I'm not sure. I'd like to see the current logic altered as little as >> possible, and what you suggest above is more than that minimum. > > Then, that would be more like the very first patch I posted but just > change the 0x1000

Re: [Xen-devel] [PATCH 2/3] mini-os: cleanup x86_64.S

On 26/08/16 16:46, Andrew Cooper wrote: > On 26/08/16 15:35, Juergen Gross wrote: >> arch/x86/x86_64.S contains some unnecessary macros. Remove them. >> >> Add a SAVE_PARAVIRT macro for saving %rcx and %r11 on the stack in >> case of CONFIG_PARAVIRT defined. >> >> Remove the parameter from

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

> I'm not sure. I'd like to see the current logic altered as little as > possible, and what you suggest above is more than that minimum. Then, that would be more like the very first patch I posted but just change the 0x1000 low limit to 0x4000. > So another question: Can you > detect whether we

Re: [Xen-devel] [PATCH v3 1/6] x86/time: refactor init_platform_time()

On 08/25/2016 11:03 AM, Jan Beulich wrote: 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 >>

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

On Fri, Aug 26, 2016 at 03:35:38PM +0100, Lars Kurth wrote: > > > On 26/08/2016 07:49, "Wei Liu" wrote: > > >On Sat, Aug 13, 2016 at 09:28:49AM +, Lars Kurth wrote: > >> > >> > >> On 12/08/2016 14:01, "Jan Beulich" wrote: > >> > >> On

Re: [Xen-devel] [PATCH 2/3] mini-os: cleanup x86_64.S

On 26/08/16 15:35, Juergen Gross wrote: arch/x86/x86_64.S contains some unnecessary macros. Remove them. Add a SAVE_PARAVIRT macro for saving %rcx and %r11 on the stack in case of CONFIG_PARAVIRT defined. Remove the parameter from HYPERVISOR_IRET macro as it is used with 0 only.

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

>>> On 26.08.16 at 16:21, wrote: > Hi, > > >> At the very least we shouldn't overlap with the BDA (starting at >> 0040: and iirc covering up to 256 bytes, which is why DOS >> never used any memory below 0050:). > > Mmm, I misread the assembly the low

[Xen-devel] [PATCH 3/3] mini-os: remove unused functions from sched.c

sched.c contains some functions nobody is using. Remove them. Signed-off-by: Juergen Gross --- sched.c | 48 1 file changed, 48 deletions(-) diff --git a/sched.c b/sched.c index 1e843d9..6f89ea4 100644 --- a/sched.c +++

[Xen-devel] [PATCH 2/3] mini-os: cleanup x86_64.S

arch/x86/x86_64.S contains some unnecessary macros. Remove them. Add a SAVE_PARAVIRT macro for saving %rcx and %r11 on the stack in case of CONFIG_PARAVIRT defined. Remove the parameter from HYPERVISOR_IRET macro as it is used with 0 only. Signed-off-by: Juergen Gross ---

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

On 26/08/2016 07:49, "Wei Liu" wrote: >On Sat, Aug 13, 2016 at 09:28:49AM +, Lars Kurth wrote: >> >> >> On 12/08/2016 14:01, "Jan Beulich" wrote: >> >> On 12.08.16 at 14:53, wrote: >> >> On 12/08/2016 13:41, "Jan

[Xen-devel] [PATCH 1/3] mini-os: cleanup x86_32.S

arch/x86/x86_32.S has some superfluous instructions. Remove them. Signed-off-by: Juergen Gross --- arch/x86/x86_32.S | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/x86/x86_32.S b/arch/x86/x86_32.S index f70fc65..3de0027 100644 ---

[Xen-devel] [PATCH 0/3] mini-os: some cleanups

Do some cleanups in Mini-OS. Juergen Gross (3): mini-os: cleanup x86_32.S mini-os: cleanup x86_64.S mini-os: remove unused functions from sched.c arch/x86/x86_32.S | 7 +-- arch/x86/x86_64.S | 44 sched.c | 48

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 26.08.16 at 13:38, wrote: > > Another example would be a DMOP that takes (or returns) an event > > channel number in the calling domain. This would be a problem because > > there

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

Hi, > At the very least we shouldn't overlap with the BDA (starting at > 0040: and iirc covering up to 256 bytes, which is why DOS > never used any memory below 0050:). Mmm, I misread the assembly the low limit applied to the multi boot value was 0x4000 and not 0x1000 ... Would this

[Xen-devel] [xen-4.7-testing test] 100632: regressions - FAIL

flight 100632 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100632/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl 11 guest-start fail REGR. vs. 100499 Regressions

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

On Fri, Aug 26, 2016 at 05:33:38PM +1000, Nicholas Piggin wrote: > On Thu, 25 Aug 2016 23:38:44 -0700 > "Luis R. Rodriguez" wrote: > > > > > > Ah, thing is we use this for both linktables and section ranges. > > > > > > Or do we want macros for both that do the same thing ? >

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

On Fri, 26 Aug 2016 15:22:19 +0200 "Luis R. Rodriguez" wrote: > On Fri, Aug 26, 2016 at 05:33:38PM +1000, Nicholas Piggin wrote: > > On Thu, 25 Aug 2016 23:38:44 -0700 > > "Luis R. Rodriguez" wrote: > > > > > > > Ah, thing is we use this for both

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

>>> On 26.08.16 at 15:08, wrote: > On 08/26/2016 08:51 AM, Jan Beulich wrote: > On 26.08.16 at 14:13, wrote: >>> On 08/26/2016 02:54 AM, Jan Beulich wrote: >>> On 18.07.16 at 16:01, wrote: > ACPI

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

On 26/08/2016 08:13, "Boris Ostrovsky" wrote: >On 08/26/2016 02:54 AM, Jan Beulich wrote: > On 18.07.16 at 16:01, wrote: >>> ACPI builder is currently distributed under GPLv2 license. >>> >>> We plan to make the builder available to

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

On 04/08/2016 07:52, "Tian, Kevin" wrote: >> From: Boris Ostrovsky >> Sent: Monday, August 01, 2016 9:57 PM >> On 07/18/2016 10:01 AM, Boris Ostrovsky wrote: >> > ACPI builder is currently distributed under GPLv2 license. >> > >> > We plan to make the builder available to

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

>>> On 26.08.16 at 15:10, wrote: > Hi, > > On Fri, Aug 26, 2016 at 3:06 PM, Jan Beulich wrote: > On 26.08.16 at 11:09, wrote: >>> --- a/xen/arch/x86/boot/head.S >>> +++ b/xen/arch/x86/boot/head.S >>> @@ -108,6

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

Hi, On Fri, Aug 26, 2016 at 3:06 PM, Jan Beulich wrote: On 26.08.16 at 11:09, wrote: >> --- a/xen/arch/x86/boot/head.S >> +++ b/xen/arch/x86/boot/head.S >> @@ -108,6 +108,8 @@ __start: >> shl $10-4,%edx >> cmp

Re: [Xen-devel] [PATCH] libxc: correct max_pfn calculation for saving domain

On Fri, Aug 26, 2016 at 01:58:55PM +0200, Juergen Gross wrote: > Commit 91e204d37f44913913776d0a89279721694f8b32 ("libxc: try to find > last used pfn when migrating") introduced a bug for the case of a > domain supporting the virtual mapped linear p2m list: the maximum pfn > of the domain

Re: [Xen-devel] xen-4.7 regression when saving a pv guest

On Fri, Aug 26, 2016 at 02:55:06PM +0200, Stefan Bader wrote: > On 26.08.2016 13:53, Juergen Gross wrote: > > On 26/08/16 12:52, Stefan Bader wrote: > >> On 25.08.2016 19:31, Juergen Gross wrote: > >>> On 25/08/16 17:48, Stefan Bader wrote: > When I try to save a PV guest with 4G of memory

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

On 08/26/2016 08:51 AM, Jan Beulich wrote: On 26.08.16 at 14:13, wrote: >> On 08/26/2016 02:54 AM, Jan Beulich wrote: >> On 18.07.16 at 16:01, wrote: ACPI builder is currently distributed under GPLv2 license. We plan

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

>>> On 26.08.16 at 11:09, wrote: > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -108,6 +108,8 @@ __start: > shl $10-4,%edx > cmp %eax,%edx /* compare with BDA value */ > cmovb %edx,%eax

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

>>> On 26.08.16 at 13:29, wrote: > Is this plan a good one for everyone ? Sounds reasonable to me; just needs settling on a few of the actual details. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

>>> On 26.08.16 at 13:38, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 08.08.16 at 15:46, wrote: >> > So would it therefore be OK to introduce the enhanced security promise >> > - the

Re: [Xen-devel] xen-4.7 regression when saving a pv guest

On 26.08.2016 13:53, Juergen Gross wrote: > On 26/08/16 12:52, Stefan Bader wrote: >> On 25.08.2016 19:31, Juergen Gross wrote: >>> 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

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

>>> On 26.08.16 at 14:13, wrote: > On 08/26/2016 02:54 AM, Jan Beulich wrote: > 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

Re: [Xen-devel] xen-4.7 regression when saving a pv guest

On 26/08/16 14:11, Ian Jackson wrote: > Juergen Gross writes ("Re: xen-4.7 regression when saving a pv guest"): >> Weird that nobody else stumbled over it. >> Ian, don't we have any test in OSSTEST which should catch this problem? >> A 4GB 64-bit pv-domain with Linux kernel 4.3 or newer can't be

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

On 08/26/2016 02:54 AM, Jan Beulich wrote: 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 >>

Re: [Xen-devel] xen-4.7 regression when saving a pv guest

Juergen Gross writes ("Re: xen-4.7 regression when saving a pv guest"): > Weird that nobody else stumbled over it. > Ian, don't we have any test in OSSTEST which should catch this problem? > A 4GB 64-bit pv-domain with Linux kernel 4.3 or newer can't be saved > currently. I don't think we have

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

On Fri, Aug 12, 2016 at 12:13:46AM +0100, Lars Kurth wrote: [...] > +The table below maps active votes against votes needed to pass: > + > + --- -- -- -- -- -- -- -- -- > + **Active Votes** 10 9 8 7 6 5 4 3 2 > + **+1 votes needed to pass**7

[Xen-devel] [PATCH] libxc: correct max_pfn calculation for saving domain

Commit 91e204d37f44913913776d0a89279721694f8b32 ("libxc: try to find last used pfn when migrating") introduced a bug for the case of a domain supporting the virtual mapped linear p2m list: the maximum pfn of the domain calculated from the p2m memory allocation might be too low. Correct this.

Re: [Xen-devel] xen-4.7 regression when saving a pv guest

On 26/08/16 12:52, Stefan Bader wrote: > On 25.08.2016 19:31, Juergen Gross wrote: >> 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... >>>

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

On Sat, Aug 13, 2016 at 09:28:49AM +, Lars Kurth wrote: > > > On 12/08/2016 14:01, "Jan Beulich" wrote: > > On 12.08.16 at 14:53, wrote: > >> On 12/08/2016 13:41, "Jan Beulich" wrote: > >> On 12.08.16 at 01:13,

Re: [Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

On 26/08/16 10:09, Sylvain Munaut wrote: If we have an multiboot value and the value we got from the BDA seems too small, use the safe one Signed-off-by: Sylvain Munaut --- I need this when using linux-as-a-bootloader (i.e. kexec into Xen) because the BDA is just

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 08.08.16 at 15:46, wrote: > > So would it therefore be OK to introduce the enhanced security promise > > - the lack of `class 2' bugs - for HVMCTL from the beginning ? > > I think

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > On 15.08.16 at 16:50, wrote: > > It seems simpler to me to have in the privcmd driver: > > > > if (op == HVMCTL_track_dirty_vram) > > ret = access_ok(...); > > > > It

Re: [Xen-devel] IOMMU initialization failure when using linux-as-bootloader

On 26/08/16 10:57, Sylvain Munaut wrote: Hello, I'm trying to use "linux as a bootloader", i.e. kexec into Xen 4.7 and I've been struggling for the past week. I've been able to debug and fix some issues on my own ( ELF header issue, invalid BDA entries, some kexec-tools bugs, ...) but I've

[Xen-devel] [PATCH v2 1/2] tools: remove blktap2 related code and documentation

Blktap2 is effectively dead code for a few years. Notable changes in this patch: 0. Unhook blktap2 from build system 1. Now libxl no longer supports TAP disk backend, appropriate assertions are added and some code paths now return ERROR_FAIL 2. Tap is no longer a supported backend in doc 3.

[Xen-devel] [PATCH v2 2/2] tools: remove blktap2 source code

Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini

[Xen-devel] [PATCH v2 0/2] Remove blktap2

Wei Liu (2): tools: remove blktap2 related code and documentation tools: remove blktap2 source code Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad

Re: [Xen-devel] [RFC] Classify and remove (some) abort()s in libxl

Wei Liu writes ("[RFC] Classify and remove (some) abort()s in libxl"): > There has been some interest in removing abort() in libxl in another > thread. I think this topic deserves a dedicated thread. > > I've checked most instances of abort() and exit() in code and classify > them as several

Re: [Xen-devel] xen-4.7 regression when saving a pv guest

On 25.08.2016 19:31, Juergen Gross wrote: > 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

Re: [Xen-devel] [RFC PATCH] tools: remove blktap2 related code and documentation

On Mon, Aug 15, 2016 at 11:50:56AM +0100, Wei Liu wrote: > Blktap2 is effectively dead code for a few years. > > Notable changes in this patch: > > 0. Unhook blktap2 from build system > 1. Now libxl no longer supports TAP ask backend, appropriate assertions >are added and some code paths now

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

Den 25. aug. 2016 23:18, skrev li...@eikelenboom.it: > 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

[Xen-devel] [PATCH] libxl: update flex output files

Libxl ships output files from flex (libxlu_*_l.{c,h}). We use the flex shipped in Debian to generate those files. Debian just patched their flex (DSA 3653-1) to fix CVE-2016-6354, which is a buffer overrun bug. Note that libxl is _NOT_ vulnerable to that CVE. See below for Ian's analysis to

[Xen-devel] IOMMU initialization failure when using linux-as-bootloader

Hello, I'm trying to use "linux as a bootloader", i.e. kexec into Xen 4.7 and I've been struggling for the past week. I've been able to debug and fix some issues on my own ( ELF header issue, invalid BDA entries, some kexec-tools bugs, ...) but I've been stuck on this one with no idea how to

Re: [Xen-devel] [PATCH] xen/grant-table: Use kmalloc_array() in arch_gnttab_valloc()

On 25/08/16 12: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

Re: [Xen-devel] [PATCH v2 1/5] tasklet: Introduce per-cpu tasklet for softirq.

On Thu, Aug 25, 2016 at 03:23:57PM -0400, Konrad Rzeszutek Wilk wrote: [...] > +static inline void tasklet_unlock_wait(struct tasklet *t) > +{ > +while (test_bit(TASKLET_STATE_RUN, &(t)->state)) > +{ > +barrier(); Need cpu_relax() here? > +} Wei.

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

flight 100628 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/100628/ 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

[Xen-devel] [xen-unstable test] 100627: tolerable FAIL - PUSHED

flight 100627 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100627/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 4 host-ping-check-native fail in 100624 pass in 100627 test-amd64-amd64-xl-rtds

[Xen-devel] [RFC] x86/boot: Don't use BDA value if it's suspiciously small

If we have an multiboot value and the value we got from the BDA seems too small, use the safe one Signed-off-by: Sylvain Munaut --- I need this when using linux-as-a-bootloader (i.e. kexec into Xen) because the BDA is just zero at that point (not entirely sure why

[Xen-devel] [distros-debian-jessie test] 67596: tolerable all pass

flight 67596 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67596/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail never pass

Re: [Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()

On Fri, Aug 26, 2016 at 09:11:42AM +0300, Razvan Cojocaru wrote: > 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

Re: [Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()

>>> On 26.08.16 at 09:40, wrote: > On 08/26/16 10:18, Jan Beulich wrote: > On 26.08.16 at 08:11, wrote: >>> --- a/xen/common/compat/memory.c >>> +++ b/xen/common/compat/memory.c >>> @@ -15,7 +15,6 @@ CHECK_TYPE(domid); >>> #undef

Re: [Xen-devel] [MINIOS PATCH 0/5] x86 assmebly code clean up

On Thu, Aug 25, 2016 at 06:48:34PM +0100, Wei Liu wrote: > 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

Re: [Xen-devel] Issue in MPX support in Xen

>>> 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 VMX, XEN is

Re: [Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()

On 08/26/16 10:18, Jan Beulich wrote: On 26.08.16 at 08:11, wrote: > > One general note first: I don't really like the term "sparse" here, > as that suggests to me you want to skip address space holes. > How about calling it "multi", "array", or some such? Fair

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

On Thu, 25 Aug 2016 23:38:44 -0700 "Luis R. Rodriguez" wrote: > 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

Re: [Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()

>>> On 26.08.16 at 08:11, wrote: One general note first: I don't really like the term "sparse" here, as that suggests to me you want to skip address space holes. How about calling it "multi", "array", or some such? > --- a/xen/arch/x86/mm/p2m.c > +++

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

>>> 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

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

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"

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

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. >

[Xen-devel] [PATCH RFC] tools/libxc, xen/x86: Added xc_set_mem_access_sparse()

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