>>> On 29.04.16 at 03:36, wrote:
> On Mon, Apr 25, 2016 at 12:51:44AM -0600, Jan Beulich wrote:
>> >>> On 31.03.16 at 10:57, wrote:
>> > +#define XRSTOR(pfx) \
>> > +if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \
>> > +{ \
>> > +if ( unlikely(!(ptr->xsave_hdr.xcomp_b
flight 44370 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44370/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-pvops 3 host-install(3) broken like 44354
build-armhf
>>> On 29.04.16 at 04:41, wrote:
> Now I check the status in caller to make the print include caller which is
> failed, instead print in iommu_flush_all().
> i.e.,
> vtd_crash_shutdown()
> {
> ..
> if ( iommu_flush_all() )
> printk(XENLOG_WARNING VTDPREFIX
>" vtd_cra
>>> On 28.04.16 at 17:33, wrote:
> On Wed, Mar 16, 2016 at 05:22:27AM -0600, Jan Beulich wrote:
>> >>> On 15.03.16 at 16:38, wrote:
>> > Jan Beulich writes ("Re: [PATCH v2 3/3] xl: new "loglvl" command"):
>> >> Yes and no. If all of the sudden the hypervisor didn't have an "error"
>> >> log level
>>> 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 like this:
>> disk=[ 'file:/path,hda,w' ]
>>
>> With pvops and xen_blkfront I get xvd
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?
> >> In my PV domU.cfg I still have something like this:
> >> d
>>> On 29.04.16 at 03:52, wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -1363,6 +1363,9 @@ static int xsplice_action(xen_sysctl_xsplice_action_t
> *action)
> return PTR_ERR(data);
> }
>
> +if ( data->rc == -EAGAIN ) /* schedule_work has been called. */
On Thu, Apr 28, 2016 at 09:49:11PM +0100, Wei Liu wrote:
> On Thu, Apr 28, 2016 at 06:29:03PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type
> > argument to xc_psr_*"):
> > > On Tue, Apr 26, 2016 at 04:52:21PM +0200, Roger Pau Monne wrote:
>
On Fri, Apr 29, 2016 at 01:35:08AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 03:52, wrote:
> > --- a/xen/common/xsplice.c
> > +++ b/xen/common/xsplice.c
> > @@ -1363,6 +1363,9 @@ static int xsplice_action(xen_sysctl_xsplice_action_t
> > *action)
> > return PTR_ERR(data);
> > }
Hi,
My name is Sangram Pawar, a developer at NetApp. I'm currently measuring the
performance of multi-queue support added to the netfront driver (in Jan'16).
I noticed the backend is not advertising the "multi-queue-max-queues" key. So
whenever netfront driver (freebsd vm) checks for the "multi-
>>> On 29.04.16 at 09:49, wrote:
> On Fri, Apr 29, 2016 at 01:35:08AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 03:52, wrote:
>> > --- a/xen/common/xsplice.c
>> > +++ b/xen/common/xsplice.c
>> > @@ -1363,6 +1363,9 @@ static int
>> > xsplice_action(xen_sysctl_xsplice_action_t
> *action)
>>
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 lock, as the
offending invocation of sh_remove_
On Thu, Apr 28, 2016 at 07:34:32PM +, Pawar, Sangram wrote:
> Hi,
> My name is Sangram Pawar, a developer at NetApp. I'm currently measuring the
> performance of multi-queue support added to the netfront driver (in Jan'16).
>
> I noticed the backend is not advertising the "multi-queue-max-que
On April 29, 2016 3:14 PM, Jan Beulich wrote:
> >>> On 29.04.16 at 04:41, wrote:
> > Now I check the status in caller to make the print include caller
> > which is failed, instead print in iommu_flush_all().
> > i.e.,
> > vtd_crash_shutdown()
> > {
> > ..
> > if ( iommu_flush_all() )
> >
On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote:
> With considerable pain we just got rid of paravirt_enabled() in the
> x86 tree, and Xen is now reintroducing it in the EFI code.
I think Matt is working towards removing EFI_PARAVIRT but he'll comment
himself when he wakes up... :)
--
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 April 2016 09:14
> To: xen-devel
> Cc: Paul Durrant; Wei Liu; Tim (Xen.org)
> Subject: [PATCH] x86/shadow: account for ioreq server pages before
> complaining about not found mapping
>
> prepare_ring_for_helper(
On Fri, Apr 29, 2016 at 09:21:39AM +0800, Shuai Ruan wrote:
> On Mon, Apr 25, 2016 at 01:07:54AM -0600, Jan Beulich wrote:
> > Commit 4d27280572 ("x86/xsaves: fix overwriting between non-lazy/lazy
> > xsaves") switched to always saving full state when using compacted
> > format (which is the only o
hi all
in
- p2m-ept.c
- ept_set_entry
i see code about iommu,
those code for what?
-
if ( rc == 0 && p2m_is_hostp2m(p2m) && need_iommu(d) &&
need_modify_vtd_table )
{
if ( iommu_hap_pt_share )
iommu_pte_flush(d, gfn, &ept_entry->epte, order, vtd_pte_p
>>> On 29.04.16 at 10:29, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 29 April 2016 09:14
>> To: xen-devel
>> Cc: Paul Durrant; Wei Liu; Tim (Xen.org)
>> Subject: [PATCH] x86/shadow: account for ioreq server pages before
>> complaining about not f
>>> On 29.04.16 at 11:14, wrote:
> hi all
>
> in
> - p2m-ept.c
> - ept_set_entry
>
> i see code about iommu,
> those code for what?
For keeping the IOMMU translation tables in sync with the CPU ones?
But perhaps I'm simply not understanding what you try to get at...
Jan
> -
>
> if
hi jan
On 29.04.16 at 11:14, wrote:
>> hi all
>>
>> in
>> - p2m-ept.c
>> - ept_set_entry
>>
>> i see code about iommu,
>> those code for what?
>
>For keeping the IOMMU translation tables in sync with the CPU ones?
got it, thanks.
i will check IOMMU translation.
>But perhaps I'm simply no
On Fri, 29 Apr, at 10:25:02AM, Borislav Petkov wrote:
> On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote:
> > With considerable pain we just got rid of paravirt_enabled() in the
> > x86 tree, and Xen is now reintroducing it in the EFI code.
>
> I think Matt is working towards removing E
Propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrough/vtd/iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/vtd
Propagate the IOMMU Device-TLB flush error up to IOMMU suspending.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Liu Jinsong
CC: Keir Fraser
CC: Andrew Cooper
CC: Suravee Suthikulpanit
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
---
xen/arch/x86/acpi/power.c
When IOMMU mapping is failed, we issue a best effort rollback, stopping
IOMMU mapping, unmapping the previous IOMMU maps and then reporting the
error up to the call trees. When rollback is not feasible (in early
initialization phase or trade-off of complexity) for the hardware domain,
we do things
The propagation value from IOMMU flush interfaces may be positive, which
indicates callers need to flush cache, not one of faliures.
when the propagation value is positive, this patch fixes this flush issue
as follows:
- call iommu_flush_write_buffer() to flush cache.
- return zero.
Signed-of
This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.
While IOMMU Device-TLB flush timed out, xen calls panic() at present. However
the existing panic()
is going to be eliminated, so we must propagate the IOMMU Device-TLB flush
error up to the call trees.
This patch set
Propagate the IOMMU Device-TLB flush error up to IOMMU unmapping.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrough/vtd/iommu.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/xen/drivers/pa
Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
This patch fixes the top level ones (this patch doesn't fix the leaf ones but
the next patch does).
Signed-off-by: Quan Xu
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Kevin Tian
---
xen/arch/arm/
Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
This patch fixes the leaf ones.
Signed-off-by: Quan Xu
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/arm/smmu.c | 12 +++-
xen/drivers/p
Propagate the IOMMU Device-TLB flush error up to ME phantom function
mapping and unmapping.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/vtd/extern.h | 3 ++-
xen/drivers/passthrough/vtd/iommu.c | 18 ++
xen/drivers/passthrou
Treat IOMMU mapping and unmapping failures as a fatal to the domain
(with the exception of the hardware domain).
If IOMMU mapping and unmapping failed, crash the domain (with the
exception of the hardware domain) and propagate the error up to the
call trees.
Signed-off-by: Quan Xu
Reviewed-by: K
Propagate the IOMMU Device-TLB flush error up to the ept_set_entry(),
when VT-d shares EPT page table.
Signed-off-by: Quan Xu
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Feng Wu
---
xen/arch/x86/mm/p2m-ept.c | 3 ++-
xen/drivers/passth
Il 28/04/2016 18:33, Martin Cerveny ha scritto:
On Thu, 28 Apr 2016, Fabio Fantoni wrote:
Il 27/04/2016 20:03, Martin Cerveny ha scritto:
On Wed, 27 Apr 2016, Fabio Fantoni wrote:
Il 27/04/2016 13:26, George Dunlap ha scritto:
On 27/04/16 12:02, Fabio Fantoni wrote:
Hi, I took a look
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 April 2016 10:22
> To: Paul Durrant
> Cc: Wei Liu; xen-devel; Tim (Xen.org)
> Subject: RE: [PATCH] x86/shadow: account for ioreq server pages before
> complaining about not found mapping
>
> >>> On 29.04.16 at 1
As discussed on the hackathon, avoid us having to issue security
advisories for issues affecting only heavily disaggregated tool stack
setups, which no-one appears to use (or else they should step up to get
things into shape).
Signed-off-by: Jan Beulich
---
As we want to retain supported status o
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 like this:
>>> disk=[ 'file:/path,hda,w' ]
>
On Fri, Apr 29, 2016 at 05:42:35AM -0400, Konrad Rzeszutek Wilk wrote:
> Currently it is possible to:
>
> 1) xc_xsplice_apply()
> \-> xsplice_action
> spin_lock(payload_lock)
> \- schedule_work()
> spin_unlock(payload_lock);
>
> 2) xc_xsplice_unload()
> \->
Currently it is possible to:
1) xc_xsplice_apply()
\-> xsplice_action
spin_lock(payload_lock)
\- schedule_work()
spin_unlock(payload_lock);
2) xc_xsplice_unload()
\-> xsplice_action
spin_lock(payload_lock)
free_payload(data);
s
On April 29, 2016 5:24 PM, Jan Beulich wrote:
> >>> On 29.04.16 at 11:14, wrote:
> > hi all
> >
> > in
> > - p2m-ept.c
> > - ept_set_entry
> >
> > i see code about iommu,
> > those code for what?
Maybe Chunyu's question is -- why EPT update is along with IOMMU page table
update.
I guess :(
>On April 29, 2016 5:24 PM, Jan Beulich wrote:
>> >>> On 29.04.16 at 11:14, wrote:
>> > hi all
>> >
>> > in
>> > - p2m-ept.c
>> > - ept_set_entry
>> >
>> > i see code about iommu,
>> > those code for what?
>
>Maybe Chunyu's question is -- why EPT update is along with IOMMU page table
>upda
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 | 6 +
> drivers/firmware/efi/arm-runt
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
* 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
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
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?
> > >
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
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 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
>>> 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
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 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
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 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
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/
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
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
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
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:
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
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
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
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 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
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 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
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
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 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
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 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, 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 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 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 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é
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
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:
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:
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
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:
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 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: 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 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
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
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
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
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
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é
> >> ---
> >>
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 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 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 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
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
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
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 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
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
1 - 100 of 142 matches
Mail list logo
