flight 93225 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93225/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 93001
Regressions
This run is configured for baseline tests only.
flight 44372 linux-3.4 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-bo
flight 93220 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93220/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 11 guest-startfail in 93111 pass in 93220
test-armhf-armhf-xl-xsm 11 guest
flight 93223 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93223/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-saverestore fail REGR. vs. 91479
test-amd64-amd64-libvirt-
This run is configured for baseline tests only.
flight 44371 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44371/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-build
flight 93229 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93229/
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 12
On 04/29/16 23:27, Tamas K Lengyel wrote:
>
>
>
>
> > diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> > index 2906407..a29bda8 100644
> > --- a/xen/common/vm_event.c
> > +++ b/xen/common/vm_event.c
> > @@ -818,7 +818,6 @@ int vm_event_mo
>
>
>
>
>>
>> > diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
>> > index 2906407..a29bda8 100644
>> > --- a/xen/common/vm_event.c
>> > +++ b/xen/common/vm_event.c
>> > @@ -818,7 +818,6 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t
>> sync,
>> > req->altp2m_idx = altp2m
> @@ -2491,6 +2492,21 @@ bad_data_abort:
> > inject_dabt_exception(regs, info.gva, hsr.len);
> > }
> >
> > +static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
> > +{
> > +int rc = 0;
> > +if ( current->domain->arch.monitor.privileged_call_enabled )
> > +{
> >
On 04/29/16 21:07, Tamas K Lengyel wrote:
> The ARM SMC instructions are already configured to trap to Xen by default. In
> this patch we allow a user-space process in a privileged domain to receive
> notification of when such event happens through the vm_event subsystem by
> introducing the PRIVIL
flight 93213 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93213/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On Thu, Apr 28, 2016 at 10:27 PM, Big Strong wrote:
> You can always just add a new page to the domain to be used for #VE.
>
> It's there a method to directly assign physical pages to guest from dom0?
> Using xc_map_foreign_address just like libvmi?
>
Please don't top-post on xen-devel.
You cou
On Tue, Mar 1, 2016 at 9:54 AM, Luis R. Rodriguez wrote:
> On Tue, Mar 01, 2016 at 08:10:24AM -0800, James Bottomley wrote:
>> On Mon, 2016-02-29 at 10:12 +, David Woodhouse wrote:
>> > On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
>> > > This ports built-in firmware to use linke
On Fri, Apr 29, 2016 at 04:33:31PM +0200, Filipe Manco wrote:
> Hi
>
> Regarding LiXS, our goal is to make it one of the upstream xenstore
> alternatives. For that I already started getting internal approvals
> to release the code open source, which should happen somewhere
> around next month. I a
flight 93226 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93226/
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 12
Mechanical renaming to better describe that the code in hvm/event is part of
the monitor subsystem.
Signed-off-by: Tamas K Lengyel
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Razvan Cojocaru
Cc: Jun Nakajima
Cc: Kevin Tian
---
MAINTAINERS| 1 -
xen/arch/x8
The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the PRIVILEGED_CALL type.
Signed-off-by: Tamas K Lengyel
-
The monitor_get_capabilities check actually belongs to the monitor subsystem so
relocating and renaming it to sanitize the code's name and location. Mechanical
patch, no code changes introduced.
Signed-off-by: Tamas K Lengyel
Acked-by: Andrew Cooper
Acked-by: Razvan Cojocaru
---
Cc: Razvan Cojo
Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
a hook for vm_event subscribers to tap into this new always-on guest event. We
rename along the way hvm_event_breakpoint_type to hvm_event_type to better
match the various events that can be passed with it. We also intro
Add headers to the covered list.
Signed-off-by: Tamas K Lengyel
---
Cc: Razvan Cojocaru
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
MAINTAINERS | 5 -
1 file changed, 4 insertions
Don't propagate altp2m changes from ept_set_entry for memshare as memshare
already has the lock. We call altp2m propagate changes once memshare
successfully finishes. Allow the hostp2m entries to be of type
p2m_ram_shared when applying mem_access. Also, do not trigger PoD for hostp2m
when setting a
On Fri, Apr 29, 2016 at 01:26:39PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 29, 2016 at 06:25:31PM +0100, Wei Liu wrote:
> > When cross-compiling xen on a 32 bit build host:
> >
> > boot/mkelf32.c: In function 'main':
> > boot/mkelf32.c:360:21: error: format '%ld' expects argument of type
On Fri, Apr 29, 2016 at 06:25:31PM +0100, Wei Liu wrote:
> When cross-compiling xen on a 32 bit build host:
>
> boot/mkelf32.c: In function 'main':
> boot/mkelf32.c:360:21: error: format '%ld' expects argument of type 'long
> int', but argument 3 has type 'Elf64_Off' [-Werror=format]
> cc1: all w
On 29/04/16 18:25, Wei Liu wrote:
> When cross-compiling xen on a 32 bit build host:
>
> boot/mkelf32.c: In function 'main':
> boot/mkelf32.c:360:21: error: format '%ld' expects argument of type 'long
> int', but argument 3 has type 'Elf64_Off' [-Werror=format]
> cc1: all warnings being treated as
On Fri, Apr 29, 2016 at 07:07:44PM +0200, Roger Pau Monne wrote:
> On Fri, Apr 29, 2016 at 12:59:30PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > IMHO, the best way to solve this is to define a set of
> > > > > XSPLICE_ERROR_* that
> > > > > covers the error codes returned by xsplice, and use t
When cross-compiling xen on a 32 bit build host:
boot/mkelf32.c: In function 'main':
boot/mkelf32.c:360:21: error: format '%ld' expects argument of type 'long int',
but argument 3 has type 'Elf64_Off' [-Werror=format]
cc1: all warnings being treated as errors
Fix that by using PRId64 in format s
On Fri, Apr 29, 2016 at 10:38:07AM -0600, Jan Beulich wrote:
> >>> On 27.04.16 at 21:27, wrote:
> > @@ -304,6 +338,32 @@ int main(int argc, char **argv)
> > /*mem_siz = (u32)in64_phdr.p_memsz;*/
> > mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
> >
> > +note_sz = note_base
On 29/04/16 18:10, Tim Deegan wrote:
> At 06:39 -0600 on 29 Apr (1461911995), Jan Beulich wrote:
> On 29.04.16 at 14:28, wrote:
>>> It would be nice if we could use gfn_t rather than having more unsigned
>>> longs.
>> I generally agree, but intentionally didn't to match all the other
>> shadow
On Fri, Apr 29, 2016 at 12:59:30PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > IMHO, the best way to solve this is to define a set of XSPLICE_ERROR_*
> > > > that
> > > > covers the error codes returned by xsplice, and use that instead of
> > > > XEN_*
> > > > errno values. This would make it m
> > > IMHO, the best way to solve this is to define a set of XSPLICE_ERROR_*
> > > that
> > > covers the error codes returned by xsplice, and use that instead of XEN_*
> > > errno values. This would make it much more easier to avoid mistakes when
> > > coding the toolstack part of xsplice.
> >
On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 18:34, wrote:
> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 17:06, wrote:
> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >> >>> On 29.04.16 at 16:
>>> On 29.04.16 at 18:34, wrote:
> On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 17:06, wrote:
>> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
>> >> >>> On 29.04.16 at 16:21, wrote:
>> >> > According to the POSIX standard for error codes [0]
>>> On 27.04.16 at 21:27, wrote:
> @@ -304,6 +338,32 @@ int main(int argc, char **argv)
> /*mem_siz = (u32)in64_phdr.p_memsz;*/
> mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
>
> +note_sz = note_base = offset = 0;
> +if ( num_phdrs > 1 )
> +{
> +offset = in
On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 17:06, wrote:
> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 16:21, wrote:
> >> > According to the POSIX standard for error codes [0], ENODATA is both
> >> > obsolescent (so
On Fri, Apr 29, 2016 at 12:22:32PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 29, 2016 at 06:16:19PM +0200, Roger Pau Monne wrote:
> > On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
> > > On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
> > > > On Fri, Apr 29, 2016
>>> On 29.04.16 at 18:16, wrote:
> On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
>> On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
>> > On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
>> > > I have a gut feeling that returning XEN_ errno to userspace program i
flight 93001 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93001/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 16 guest-start.2fail blocked in 92925
build-i386-rumpuserxen
On Fri, Apr 29, 2016 at 06:16:19PM +0200, Roger Pau Monne wrote:
> On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
> > > On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> > > > I have a gut feeling that returning
>>> On 29.04.16 at 17:06, wrote:
> On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 16:21, wrote:
>> > According to the POSIX standard for error codes [0], ENODATA is both
>> > obsolescent (so it may be removed in the future) and optional.
>>
>> It being optiona
On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
> > On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> > > I have a gut feeling that returning XEN_ errno to userspace program is
> > > layering violation. They should
flight 92798 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92798/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
On 04/09/16 08:54, Razvan Cojocaru wrote:
> It is meaningless (and potentially dangerous - see
> hvmemul_virtual_to_linear())
> to set mem_access_emulate_each_rep before xc_monitor_enable() (which allocates
> vcpu->arch.vm_event) has been called, so return an error from the
> XEN_DOMCTL_MONITOR_OP
On 29/04/16 17:03, Razvan Cojocaru wrote:
> Hello,
>
> Just for my internal patch book-keeping, I assume this patch did not get
> into staging because of the code freeze and is planned for 4.8?
>
> http://lists.xen.org/archives/html/xen-devel/2016-04/msg01444.html
That fix should go into 4.7, but
flight 93078 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93078/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 92767
test-amd64-amd64-xl-qemuu-wi
Hello,
Just for my internal patch book-keeping, I assume this patch did not get
into staging because of the code freeze and is planned for 4.8?
http://lists.xen.org/archives/html/xen-devel/2016-04/msg01444.html
Thanks,
Razvan
___
Xen-devel mailing li
flight 92983 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92983/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 86898
build-amd64-rumpuserxen 6
flight 93049 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93049/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
On Fri, Apr 29, 2016 at 08:41:14AM -0600, Jan Beulich wrote:
> 1: p2m: clean up altp2m
> 2: fix domain cleanup
>
> Signed-off-by: Jan Beulich
>
Release-acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-dev
On Fri, 29 Apr 2016, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Matt Fleming wrote:
> > On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> > > On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > > > Also, it would be nice to have all things EFI in a single tree, the
> > > > conflicts are
>
On 29/04/16 15:49, Jan Beulich wrote:
> Free d->arch.cpuids on both the creation error path and during
> destruction.
>
> Don't bypass iommu_domain_destroy().
>
> Move psr_domain_init() up so that hvm_domain_initialise() again is the
> last thing which can fail, and hence doesn't require undoing la
On 29/04/16 15:54, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 02:38:33AM -0400, Konrad Rzeszutek Wilk wrote:
>> . as it is not implemented on it.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>>
>> ---
>> v1: Initial botched patch that didn't compile.
>> v2: Andrew mentioned to "need to set ENOSYS in t
On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
> On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> > > Avoid using system errno values when comparing with Xen errno values.
> > >
> > > Signed-off-by: Ro
On Fri, Apr 29, 2016 at 04:11:47PM +0100, Andrew Cooper wrote:
> On 29/04/16 16:02, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> >> Avoid using system errno values when comparing with Xen errno values.
> >>
> >> Signed-off-by: Roger Pau Monné
> >> ---
> >>
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -618,9 +618,11 @@ void p2m_teardown(struct p2m_domain *p2m
void p2m_final_teardown(struct domain *d)
{
-/* We must teardown unconditionally because
+/*
+ * We must teardown both of them unconditi
flight 93129 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-saverestore fail REGR. vs. 91479
test-amd64-amd64-libvirt-
On Fri, Apr 29, 2016 at 08:48:39AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 16:21, wrote:
> > FreeBSD linker sets the OS ABI to ELFOSABI_FREEBSD, but the payload can
> > still be loaded without issues.
> >
> > All the ELF OS ABIs follow the System V calling convention, and the OS ABI
> > do
flight 93111 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93111/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 92143
Regressions which are r
On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> > Avoid using system errno values when comparing with Xen errno values.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Konrad Rzeszutek Wilk
> > Cc: Ross Lagerwal
>>> On 29.04.16 at 16:21, wrote:
> FreeBSD linker sets the OS ABI to ELFOSABI_FREEBSD, but the payload can
> still be loaded without issues.
>
> All the ELF OS ABIs follow the System V calling convention, and the OS ABI
> doesn't really matter because Xen is a standalone kernel.
Well, first of a
Gcc complains:
tcgbios.c: In function ‘HashLogEvent32’:
tcgbios.c:1131:10: error: ‘logdataptr’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
entry = tcpa_extend_acpi_log(logdataptr);
It fails to figure out when logdataptr is used it is always initialised
in a if bl
On 29/04/16 16:02, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
>> Avoid using system errno values when comparing with Xen errno values.
>>
>> Signed-off-by: Roger Pau Monné
>> ---
>> Cc: Konrad Rzeszutek Wilk
>> Cc: Ross Lagerwall
>> Cc: Ian Jackson
>> Cc:
Gcc complains:
tcgbios.c:1142:22: error: ‘entry’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
hleo->eventnumber = entry;
It fails to figure out if entry is used it is always initialised in
previous if block.
Signed-off-by: Wei Liu
---
tools/firmware/rombios/32b
On my Debian Jessie build box gcc complains about various maybe uninitialised
variables when -g is in use. In fact gcc -Wmaybe-uninitialized is not very
reliable according to gcc manpage, various search results and answer from
someone on freenode #gcc channel.
I go through those failures and try t
Gcc complains:
qcow2raw.c: In function ‘main’:
qcow2raw.c:387:17: error: ‘buf’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
treq.buf = buf;
^
But at the point of that assignment, buf is a valid buffer allocated by
posix_memalign and filled in
Gcc complains:
tcgbios.c:362:3: error: ‘size’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
memcpy((char *)lasa_last, (char *)entry_ptr, size);
It fails to figure out if size is used in memcpy it is always initialised.
Signed-off-by: Wei Liu
---
tools/firmware/ro
Gcc complains:
vhd-util-check.c: In function ‘vhd_util_check_footer’:
vhd-util-check.c:413:2: error: ‘buf’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
memcpy(&backup, buf, sizeof(backup));
In fact buf is initialised a few lines above.
Signed-off-by: Wei Liu
---
I
Gcc complains:
qcow2raw.c: In function ‘main’:
qcow2raw.c:387:17: error: ‘buf’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
treq.buf = buf;
^
But buf is a valid buffer allocated by posix_memalign at that point.
Signed-off-by: Wei Liu
---
to
On Fri, Apr 29, 2016 at 05:07:40PM +0200, Roger Pau Monne wrote:
> On Fri, Apr 29, 2016 at 03:57:23PM +0100, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 04:21:18PM +0200, Roger Pau Monne wrote:
> > > Some error paths incorrectly used rc instead of errno.
> > >
> > > Signed-off-by: Roger Pau Monné
On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> Avoid using system errno values when comparing with Xen errno values.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Konrad Rzeszutek Wilk
> Cc: Ross Lagerwall
> Cc: Ian Jackson
> Cc: Wei Liu
> ---
> Using errno values inside
On Fri, Apr 29, 2016 at 03:57:23PM +0100, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 04:21:18PM +0200, Roger Pau Monne wrote:
> > Some error paths incorrectly used rc instead of errno.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Konrad Rzeszutek Wilk
> > Cc: Ross Lagerwall
> > Cc: Ian
On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 16:21, wrote:
> > According to the POSIX standard for error codes [0], ENODATA is both
> > obsolescent (so it may be removed in the future) and optional.
>
> It being optional still doesn't preclude us using it.
>
On Fri, Apr 29, 2016 at 02:38:33AM -0400, Konrad Rzeszutek Wilk wrote:
> . as it is not implemented on it.
>
> Signed-off-by: Konrad Rzeszutek Wilk
>
> ---
> v1: Initial botched patch that didn't compile.
> v2: Andrew mentioned to "need to set ENOSYS in the xch last
> error." - but we do not
On Fri, 29 Apr 2016, Matt Fleming wrote:
> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> > On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > > Also, it would be nice to have all things EFI in a single tree, the
> > > conflicts are
> > > going to be painful! There's very little reason not t
On Fri, Apr 29, 2016 at 04:21:18PM +0200, Roger Pau Monne wrote:
> Some error paths incorrectly used rc instead of errno.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Konrad Rzeszutek Wilk
> Cc: Ross Lagerwall
> Cc: Ian Jackson
> Cc: Wei Liu
> ---
> tools/misc/xen-xsplice.c | 5 +++--
> 1
Free d->arch.cpuids on both the creation error path and during
destruction.
Don't bypass iommu_domain_destroy().
Move psr_domain_init() up so that hvm_domain_initialise() again is the
last thing which can fail, and hence doesn't require undoing later on.
Move psr_domain_free() up on the creation
On 29 April 2016 at 16:39, Matt Fleming wrote:
> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
>> On Fri, 29 Apr 2016, Ingo Molnar wrote:
>> > Also, it would be nice to have all things EFI in a single tree, the
>> > conflicts are
>> > going to be painful! There's very little reason not
On 29/04/16 15:49, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
flight 92982 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92982/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 92189
test-amd64-amd64-xl-qemuu-debia
>>> On 29.04.16 at 16:21, wrote:
> According to the POSIX standard for error codes [0], ENODATA is both
> obsolescent (so it may be removed in the future) and optional.
It being optional still doesn't preclude us using it.
> Replace it's
> usage with ENOENT, which seems like the closest match. B
1: p2m: clean up altp2m
2: fix domain cleanup
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > Also, it would be nice to have all things EFI in a single tree, the
> > conflicts are
> > going to be painful! There's very little reason not to carry this kind of
> > commit:
> >
> > arch/ar
Hi
Regarding LiXS, our goal is to make it one of the upstream xenstore
alternatives. For that I already started getting internal approvals to
release the code open source, which should happen somewhere around next
month. I also need to fix some bugs and would like to do some
performance testi
Hello,
This series contains bugfixes for xSplice, that popped up when testing it on
OSes != Linux.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Julien,
On Thu, Apr 28, 2016 at 02:14:58PM +0100, Julien Grall wrote:
>Hello,
>
>On 28/04/16 13:56, Peng Fan wrote:
>>On Thu, Apr 28, 2016 at 11:27:22AM +0100, Julien Grall wrote:
>>>
>>>
>>>On 28/04/16 07:39, Peng Fan wrote:
Hi Julien,
>>>
>>>Hello Peng,
>>>
On Thu, Apr 28, 2016 at 10:
Avoid using system errno values when comparing with Xen errno values.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Ross Lagerwall
Cc: Ian Jackson
Cc: Wei Liu
---
Using errno values inside of hypercall structs is not right IMHO, but there
are already several occurrences of
FreeBSD linker sets the OS ABI to ELFOSABI_FREEBSD, but the payload can
still be loaded without issues.
All the ELF OS ABIs follow the System V calling convention, and the OS ABI
doesn't really matter because Xen is a standalone kernel.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wil
According to the POSIX standard for error codes [0], ENODATA is both
obsolescent (so it may be removed in the future) and optional. Replace it's
usage with ENOENT, which seems like the closest match. Both FreeBSD and
OpenBSD don't have this error code in the native errno.h headers.
[0] http://pubs
Some error paths incorrectly used rc instead of errno.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Ross Lagerwall
Cc: Ian Jackson
Cc: Wei Liu
---
tools/misc/xen-xsplice.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/misc/xen-xsplice.c b/
On Fri, Apr 29, 2016 at 01:27:35PM +0200, Olaf Hering wrote:
> On Fri, Apr 29, Konrad Rzeszutek Wilk wrote:
>
> > On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
> > > Why does xen_blkfront not enforce kernel device names from domU.cfg?
> > > In my PV domU.cfg I still have something l
Please do get in touch if you have any packaging problems concerning OCaml.
It's pretty good on modern Linux and FreeBSD though, and oxenstored works on
most modern releases.
We've not got a set of patches that are suitable for upstreaming for the
Xenstored/Irmin tree that we demonstrated at X
On Fri, Apr 29, 2016 at 02:13:35AM -0600, Jan Beulich wrote:
> prepare_ring_for_helper(), just like share_xen_page_with_guest(),
> takes a write reference on the page, and hence should similarly be
> accounted for when determining whether to log a complaint.
>
> This requires using recursive locki
flight 93204 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93204/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
>>> On 29.04.16 at 14:28, wrote:
> On 29/04/16 09:13, Jan Beulich wrote:
>> prepare_ring_for_helper(), just like share_xen_page_with_guest(),
>> takes a write reference on the page, and hence should similarly be
>> accounted for when determining whether to log a complaint.
>>
>> This requires usin
On 29/04/16 09:13, Jan Beulich wrote:
> prepare_ring_for_helper(), just like share_xen_page_with_guest(),
> takes a write reference on the page, and hence should similarly be
> accounted for when determining whether to log a complaint.
>
> This requires using recursive locking for the ioreq server
flight 93195 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93195/
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 12
On Fri, Apr 29, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
> > Why does xen_blkfront not enforce kernel device names from domU.cfg?
> > In my PV domU.cfg I still have something like this:
> > disk=[ 'file:/path,hda,w' ]
> >
> > With pvops and xen_b
On Fri, 29 Apr 2016, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 29, 2016 at 01:29:17AM -0600, Jan Beulich wrote:
> > >>> On 29.04.16 at 08:45, wrote:
> > > On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
> > >> Why does xen_blkfront not enforce kernel device names from domU.cfg?
> > >
flight 93183 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93183/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
* Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Ingo Molnar wrote:
> > Also, it would be nice to have all things EFI in a single tree, the
> > conflicts are
> > going to be painful! There's very little reason not to carry this kind of
> > commit:
> >
> > arch/arm/xen/enlighten.c
On 29/04/16 10:39, David Vrabel wrote:
> On 29/04/16 08:29, Jan Beulich wrote:
> On 29.04.16 at 08:45, wrote:
>>> On Tue, Apr 26, 2016 at 03:28:45PM +0200, Olaf Hering wrote:
Why does xen_blkfront not enforce kernel device names from domU.cfg?
In my PV domU.cfg I still have something
1 - 100 of 142 matches
Mail list logo
