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
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
test-amd64-amd64-xl-rtds
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-boo
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
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 introduces a new libxc function
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 v
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 v
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 GFNs.
> The alternative would
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
test-amd64-amd64-xl-qemu
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
>> ---
>> arch/x86/xen/enlighten.c | 115
>> +
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 3ed4e502b5f23fbcef235
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
> 1 file changed, 48 deletions(-)
>
>
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
> ---
> arch/x86/x86_32.S | 7 +--
> 1 file changed, 1 inser
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
test-amd
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 the counter
>> read by the cl
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 would be more like the very first patch I posted but
>>> 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 number in the calling domain. This would be a problem becau
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 option.
OK, I merged this back
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 clocksource=tsc we will
>> use
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 processor).
>
> Do we really want to
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 the recently added fences?
>>> 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 low limit to 0x4000.
I thought
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 HYPERVIS
> 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
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
>> up (verify_tsc_reliability
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 12.08.16 at 14:53, wrote:
> >> >> On 12/08/201
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.
Signed-off-by:
>>> 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 limit applied to the multi boot
> va
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
+++ b/sched.c
@@ -63,16 +63,6
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
---
arch/x86/x86_64.S | 4
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 Beulich" wrote:
>> >> On 12.08.16 at 01:13, wrote:
>> +##
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
--- a/arch/x86/x86_32.S
+++ b/arch/x8
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
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 would be nothing to stop qem
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 log
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 whi
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 ?
> > > > >
> > > > > I
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 linktables and section ranges.
> > > > > > > Or
>>> 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 builder is currently distributed under GPLv2 license.
>
> We plan to make the bu
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 components other
>>> than the hvmloader (which is also GP
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 components other
>> >
>>> 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 +108,8 @@ __start:
>>> shl $10-4,%edx
>>> cmp %eax,%edx
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 %eax,%edx /* compare with BDA value */
>>
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 calculate
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 usi
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 to make the builder available to components other
t
>>> 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 /* and use the smaller */
> +
>>> 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
https://lists.xen.org/xen-devel
>>> 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 lack of `class 2' bugs - for HVMCTL from the beginning ?
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 40
>>> 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 other
>>> than the hvmloader (which is also GPLv2). Some of t
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 sa
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
>> components (such as libxl) may be
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 any
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
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.
Repo
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...
>>> Sa
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, wrote:
> +### Lazy Consensus {#lazyconsensus}
> +
> [s
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 zero at that point (not entirel
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 so, since ...
>
> > This w
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 looks simpler to me to fix the
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 been
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. Re
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Ross Philipson
Cc: Lars Kurth
[ more than 40k lines truncated ]
___
Xen-devel ma
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 Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Ross Philipson
Cc: Lars Kurth
.gitignore
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 class
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 0x
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
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
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 securi
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 even
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 corresponding function "kmalloc_ar
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.
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 migrate-s
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
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 tbh).
This is the simplest patc
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
test-armhf-armhf-
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 alternative
>>> 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 compat_domid_t
>>> #undef xen_domid_t
>>>
>>> -CHECK_mem_ac
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 unused
>>> 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
> failing on store CPU MSR
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 enough, will rename it.
>> -
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 +1000, Nicholas Piggin wrote:
> > > > On Thu, 25 Aug 2016
>>> 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
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1815,7 +1815,7
84 matches
Mail list logo
