On 20.04.2016 15:21, Julien Grall wrote:
(CC REST maintainers)
Hello Dirk,
Please CC the relevant maintainers for this patch. You can use
scripts/get_maintainers.pl for this purpose.
On 19/04/16 06:59, Dirk Behme wrote:
On ARM64 Linux the HVC instruction is used to trap into Xen. As this
can
Add a section about what the firmware should do in EL3 before starting Xen.
E.g. on ARM Linux the HVC instruction is used to trap into Xen. As this
can be set only at EL3, i.e. outside from Xen, document this boot requirement.
Signed-off-by: Dirk Behme
---
docs/misc/arm/booting.txt | 15 +++
This run is configured for baseline tests only.
flight 44352 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44352/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-build
flight 92229 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92229/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684
build-i386
On 21/04/16 18:03, George Dunlap wrote:
> Clarify the meaning of nested maintainership.
>
> Signed-off-by: George Dunlap
> ---
> We had a discussion about the meaning of nested maintainership at the
> recent Xen Hackathon. The notes of that meeting can be found on this
> list [1]. No decision i
On 04/21/16 01:04, Jan Beulich wrote:
> >>> On 21.04.16 at 07:09, wrote:
> > On 04/12/16 16:45, Haozhong Zhang wrote:
> >> On 04/08/16 09:52, Jan Beulich wrote:
> >> > >>> On 08.04.16 at 07:02, wrote:
> >> > > On 03/29/16 04:49, Jan Beulich wrote:
> >> > >> >>> On 29.03.16 at 12:10, wrote:
> >>
2016-04-21 22:19 GMT+08:00 Jan Beulich :
> >>> On 30.03.16 at 09:28, wrote:
> > 2016-03-29 18:39 GMT+08:00 Jan Beulich :
> >> ---
> >> I assume this also addresses the issue which
> >>
> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03189.html
> >> attempted to deal with in a not
flight 92223 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92223/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 9 debian-installfail REGR. vs. 92071
Regressions which a
This run is configured for baseline tests only.
flight 44351 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44351/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 10 xen-boot/dst_h
flight 92219 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92219/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REGR. vs. 878
flight 92208 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92208/
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
flight 92198 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92198/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-buildfail like 91148
build-amd64-rumpuserxen 6
On Thu, Apr 21, 2016 at 12:59:00AM -0600, Jan Beulich wrote:
> >>> On 21.04.16 at 02:33, wrote:
> > On Wed, Apr 20, 2016 at 01:14:17AM -0600, Jan Beulich wrote:
> >> >>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
> >> >--- a/Config.mk
> >> >+++ b/Config.mk
> >> >@@ -126,6 +126,17 @@ endef
> >>
On Thu, Apr 21, 2016 at 12:44:41AM -0600, Jan Beulich wrote:
> >>> On 21.04.16 at 02:28, wrote:
> >> >+ASSERT(sec);
> >> >+if ( sec->sec->sh_size % sizeof(*payload->funcs) )
> >> >+{
> >> >+dprintk(XENLOG_ERR, XSPLICE "%s: Wrong size of
> >> >.xsplice.funcs!\n",
> >> >+
flight 92230 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92230/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 91479
build-i386-libvirt
This run is configured for baseline tests only.
flight 44350 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44350/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-rumpuserxen-amd64 15
rumpuserxen-de
flight 92189 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92189/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in
92139 pass in 92189
test-armhf-armhf-x
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. Also, allow the hostp2m entries to be of type
p2m_ram_shared.
Signed-off-by: Tamas K Lengyel
---
Cc: George Dunlap
Cc: Keir Frase
On 21/04/2016 17:03, "George Dunlap" wrote:
>Clarify the meaning of nested maintainership.
>
>Signed-off-by: George Dunlap
>---
>
> MAINTAINERS | 34 ++
> 1 file changed, 34 insertions(+)
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index a34685d..be901d5 100644
>-
On April 21, 2016 11:36:24 AM EDT, Jan Beulich wrote:
On 21.04.16 at 17:15, wrote:
>> On Wed, Apr 20, 2016 at 11:59:34AM -0400, Konrad Rzeszutek Wilk
>wrote:
>>> > >@@ -29,6 +30,13 @@ struct payload {
>>> > >uint32_t state; /* One of the
>XSPLICE_STATE_*. */
>>> >
Clarify the meaning of nested maintainership.
Signed-off-by: George Dunlap
---
We had a discussion about the meaning of nested maintainership at the
recent Xen Hackathon. The notes of that meeting can be found on this
list [1]. No decision is official until discussed on this list, so
consider t
In commit aa7c1fdf9d ("x86/MSI: properly track guest masking requests")
I neglected to consider devices allowing for both MSI and MSI-X to be
used (not at the same time of course): The MSI-X part of the intercept
logic needs to fall through to the MSI one when the access is outside
the MSI-X capabi
In commit 9256f66c16 ("x86/PCI: intercept all PV Dom0 MMCFG writes")
for an unclear to me reason I left pci_conf_write_intercept()'s return
value unchecked. Correct this.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5430,11 +5430,11 @@ int mmcfg_intercept_write(
>>> On 21.04.16 at 17:15, wrote:
> On Wed, Apr 20, 2016 at 11:59:34AM -0400, Konrad Rzeszutek Wilk wrote:
>> > >@@ -29,6 +30,13 @@ struct payload {
>> > >uint32_t state; /* One of the XSPLICE_STATE_*.
>> > */
>> > >int32_t rc; /* 0 or -XEN_E
On Thu, Apr 21, 2016 at 9:13 AM, Maryam Masoudian wrote:
>
>
> On Thu, Apr 21, 2016 at 5:17 PM, Dario Faggioli > wrote:
>
>> On Wed, 2016-04-20 at 13:01 -0600, Tamas K Lengyel wrote:
>> > On Apr 20, 2016 12:34, "Dario Faggioli"
>> > wrote:
>> > > On Wed, 2016-04-20 at 10:25 -0600, Tamas K Lengy
On Wed, Apr 20, 2016 at 11:59:34AM -0400, Konrad Rzeszutek Wilk wrote:
> > >+void arch_xsplice_free_payload(void *va)
> > >+{
> > >+vfree_xen(va);
> > >+}
> >
> > What is the idea behind having this hook (instead of generic code just
> > calling
> > vfree_xen() [or really just vfree()])?
>
>
flight 92185 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92185/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeatfail like 91745
build-amd64-rumpuserxen
Add a Xenstore directory for each supported pv backend. This will allow
Xen tools to decide which backend type to use in case there are
multiple possibilities.
The information is added under
/local/domain//device-model//backends
before the "running" state is written to Xenstore. Using a directory
>>> On 21.04.16 at 15:56, wrote:
>> > So I did try that and it all worked nicely on x86. However on ARM32:
>> >
>> > arm make -j8 1>1
>> > symbols.c: In function 'symbols_lookup_by_name':
>> > symbols.c:287:20: error: cast to pointer from integer of different size
>> > [-Werror=int-to-pointer-cas
>>> On 30.03.16 at 09:28, wrote:
> 2016-03-29 18:39 GMT+08:00 Jan Beulich :
>> ---
>> I assume this also addresses the issue which
>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03189.html
>> attempted to deal with in a not really acceptable way.
>
> I hope this issue is resolv
On 21/04/16 14:56, Paul Durrant wrote:
>> -Original Message-
>> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
>> Sent: 21 April 2016 14:49
>> To: Paul Durrant; George Dunlap; Jan Beulich; Wei Liu
>> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); xen-
>> de...@lists.xen.
On Thu, Apr 21, 2016 at 07:22:25AM +0300, Razvan Cojocaru wrote:
> On 04/21/16 03:39, Tamas K Lengyel wrote:
> > Without specifying the altp2m flag on the response the view never got
> > switched.
> > Also, add extra information printouts that can be useful during debugging.
> >
> > Signed-off-by
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 21 April 2016 14:49
> To: Paul Durrant; George Dunlap; Jan Beulich; Wei Liu
> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); xen-
> de...@lists.xen.org; zhiyuan...@intel.com; jun.nakaj...@intel
> > So I did try that and it all worked nicely on x86. However on ARM32:
> >
> > arm make -j8 1>1
> > symbols.c: In function 'symbols_lookup_by_name':
> > symbols.c:287:20: error: cast to pointer from integer of different size
> > [-Werror=int-to-pointer-cast]
> >
> > 275 uint64_t addr = 0; /*
On 4/21/2016 9:31 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 21 April 2016 13:25
To: George Dunlap; Paul Durrant; Jan Beulich; Wei Liu
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); xen-
de...@lists.xen.org; zhiyua
On 4/21/2016 12:30 AM, Paul Durrant wrote:
-Original Message-
From: George Dunlap
Sent: 20 April 2016 16:38
To: Paul Durrant
Cc: Yu, Zhang; Kevin Tian; jun.nakaj...@intel.com; Andrew Cooper; Tim
(Xen.org); xen-devel@lists.xen.org; Lv, Zhiyuan; Jan Beulich
Subject: Re: [Xen-devel] [PATCH
xen/x86: don't lose event interrupts
On slow platforms with unreliable TSC, such as QEMU emulated machines,
it is possible for the FreeBSD kernel to request the next event in the
past. In that case, in the current implementation of
xentimer_vcpu_start_timer, we simply return -ETIME. To be precise
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 21 April 2016 13:25
> To: George Dunlap; Paul Durrant; Jan Beulich; Wei Liu
> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); xen-
> de...@lists.xen.org; zhiyuan...@intel.com; jun.nakaj...@intel
For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time()
using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct
vcpu_time_info, is calculated from stime_local_stamp using
gtime_to_gtsc.
However gtime_to_gtsc can return 0, if time < vtsc_offset, which can
actually happen wh
On Thursday 21 April 2016 15:12:52 Juergen Gross wrote:
> On 21/04/16 12:57, Pali Rohár wrote:
> > On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote:
> >> On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote:
> >>> On Tue, Apr 05, 2016 at 07:10:07AM +0200, Juergen Gross wrote:
> Use the smp_
Thank you, George.
On 4/20/2016 10:50 PM, George Dunlap wrote:
On Tue, Apr 19, 2016 at 12:59 PM, Yu, Zhang wrote:
So what about the VM suspend case you mentioned above? Will that trigger
the unmapping of ioreq server? Could the device model also take the role
to change the p2m type back in suc
On 21/04/16 12:57, Pali Rohár wrote:
> On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote:
>> On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote:
>>> On Tue, Apr 05, 2016 at 07:10:07AM +0200, Juergen Gross wrote:
Use the smp_call_on_cpu() function to call system management
mode on cpu
On Wed, 2016-04-20 at 13:01 -0600, Tamas K Lengyel wrote:
> On Apr 20, 2016 12:34, "Dario Faggioli"
> wrote:
> > On Wed, 2016-04-20 at 10:25 -0600, Tamas K Lengyel wrote:
> > > On Wed, Apr 20, 2016 at 7:24 AM, Wei Liu
> wrote:
> > > > Not sure. You can check xl manpage for those commands.
> > > x
On 4/21/2016 1:06 AM, George Dunlap wrote:
On 20/04/16 17:58, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
Beulich
Sent: 20 April 2016 17:53
To: George Dunlap; Paul Durrant; Wei Liu; yu.c.zh...@linux.intel.com
Cc: Kevi
maintainers,
Thanks for the discussion and sorry for my delayed reply...
On 4/21/2016 12:52 AM, Jan Beulich wrote:
George Dunlap 04/20/16 6:30 PM >>>
On Wed, Apr 20, 2016 at 4:02 PM, George Dunlap wrote:
On 19/04/16 12:02, Yu, Zhang wrote:
So I suppose the only place we need change for th
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 April 2016 12:44
> To: Paul Durrant
> Cc: Andrew Cooper; Wei Liu; xen-devel; Keir (Xen.org)
> Subject: RE: [PATCH] x86/vMSI-X: avoid missing first unmask of vectors
>
> >>> On 21.04.16 at 13:33, wrote:
> >> Fro
>>> On 21.04.16 at 13:33, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 21 April 2016 10:38
>> --- a/xen/arch/x86/hvm/vmsi.c
>> +++ b/xen/arch/x86/hvm/vmsi.c
>> @@ -341,7 +352,21 @@ static int msixtbl_range(struct vcpu *v,
>> desc = msixtbl_addr_to_desc(msixtbl_find_entry(v,
>>> On 21.04.16 at 13:07, wrote:
Please follow the patch submission rules: Mail them _to_ the list,
_cc_-ing relevant people. Cc-ing the list twice makes little sense.
And please also apply some common sense when deciding who to
Cc - I don't think there's much point in Cc-ing other than ARM
maint
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 April 2016 10:38
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant; Wei Liu; Keir (Xen.org)
> Subject: [PATCH] x86/vMSI-X: avoid missing first unmask of vectors
>
> Recent changes to Linux result in there just b
Hi Julien,
Great thanks for your review and suggestion.
I have taken almost all your suggestion, but did some modification,
please have a look:
http://lists.xen.org/archives/html/xen-devel/2016-04/msg02637.html
Thanks for your help! :-)
On 20 April 2016 at 19:27, Julien Grall wrote:
> Hello Fu
flight 92181 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92181/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumpuserxen-i386 15
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 88309
t
From: Fu Wei
This patch updates the documentation for allowing detection of an XSM
module that lacks a specific compatible string.
This mechanism has been added by the commit
ca32012341f3de7d3975407fb963e6028f0d0c8b.
Signed-off-by: Fu Wei
---
v2: Improve the doc, according to the suggestion fro
On Wed, Apr 20, Stefano Stabellini wrote:
> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> probe_8259A(). Use NR_IRQS_LEGACY instead.
>
> Signed-off-by: Stefano Stabellini
Tested-by: Olaf Hering
On Thu, Apr 21, Juergen Gross wrote:
> http://lists.xen.org/archives/html/xen-devel/2016-04/msg02512.html
Thanks, this helps.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote:
> On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote:
> > On Tue, Apr 05, 2016 at 07:10:07AM +0200, Juergen Gross wrote:
> > > Use the smp_call_on_cpu() function to call system management
> > > mode on cpu 0.
> > > Make call secure by adding ge
>>> On 21.04.16 at 12:35, wrote:
> On Thu, Apr 21, Jan Beulich wrote:
>
>> >>> On 21.04.16 at 11:52, wrote:
>> > On Thu, Apr 21, Jan Beulich wrote:
>> >
>> >> Does the device actually use IRQ19, or does it instead use IRQ14
>> >> and IRQ15 (which then may require some special casing somewhere)?
On Thu, Apr 21, Jan Beulich wrote:
> >>> On 21.04.16 at 11:52, wrote:
> > On Thu, Apr 21, Jan Beulich wrote:
> >
> >> Does the device actually use IRQ19, or does it instead use IRQ14
> >> and IRQ15 (which then may require some special casing somewhere)?
> >
> > How do I find out?
>
> Check wha
>>> On 21.04.16 at 11:52, wrote:
> On Thu, Apr 21, Jan Beulich wrote:
>
>> Does the device actually use IRQ19, or does it instead use IRQ14
>> and IRQ15 (which then may require some special casing somewhere)?
>
> How do I find out?
Check what the native kernel uses.
Jan
_
On 21/04/16 11:37, Olaf Hering wrote:
> On my Fujitsu Esprimo Mobile M9400 laptop the upstream dom0 kernel does
> not find the DVD drive. The DVD drive is found with native kernels and
> also with xenlinux based kernels, like 4.1 based openSUSE Leap.
>
> [6.242286] ata_piix :00:1f.1: versi
>>> On 21.04.16 at 11:38, wrote:
> Recent changes to Linux result in there just being a single unmask
> operation prior to expecting the first interrupts to arrive. However,
> we've had a chicken-and-egg problem here: Qemu invokes
> xc_domain_update_msi_irq(), ultimately leading to
> msixtbl_pt_re
On Thu, Apr 21, Jan Beulich wrote:
> Does the device actually use IRQ19, or does it instead use IRQ14
> and IRQ15 (which then may require some special casing somewhere)?
How do I find out?
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http:/
>>> On 21.04.16 at 11:37, wrote:
> On my Fujitsu Esprimo Mobile M9400 laptop the upstream dom0 kernel does
> not find the DVD drive. The DVD drive is found with native kernels and
> also with xenlinux based kernels, like 4.1 based openSUSE Leap.
>
> [6.242286] ata_piix :00:1f.1: version 2
On 20/04/16 09:04, Paulina Szubarczyk wrote:
> Functions libxl_tmem_freeze(), libxl_tmem_thaw(), libxl_tmem_set() and
> libxl_tmem_shared_auth() located in libxl.c file return
> ERROR_FAIL/ERROR_INVAL or internal error codes from libxc library
> improve main_tmem_* return codes by returning EXIT_{S
Recent changes to Linux result in there just being a single unmask
operation prior to expecting the first interrupts to arrive. However,
we've had a chicken-and-egg problem here: Qemu invokes
xc_domain_update_msi_irq(), ultimately leading to
msixtbl_pt_register(), upon seeing that first unmask oper
On my Fujitsu Esprimo Mobile M9400 laptop the upstream dom0 kernel does
not find the DVD drive. The DVD drive is found with native kernels and
also with xenlinux based kernels, like 4.1 based openSUSE Leap.
[6.242286] ata_piix :00:1f.1: version 2.13
[6.242625] xen: registering gsi 19 t
On Thu, 21 Apr 2016, Juergen Gross wrote:
> On 20/04/16 15:15, Stefano Stabellini wrote:
> > b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> > of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> > probe_8259A(). Use NR_IRQS_LEGACY instead.
>
> Would you
On Thu, 21 Apr 2016, Jan Beulich wrote:
> As proposed on the hackathon.
>
> Signed-off-by: Jan Beulich
> Acked-by: Ian Jackson
Acked-by: Stefano Stabellini
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -437,10 +437,15 @@ F: xen/xsm/
> F: docs/misc/xsm-flask.txt
>
> THE REST
> +M: Andr
On Thu, Apr 21, 2016 at 01:31:15AM -0600, Jan Beulich wrote:
> As proposed on the hackathon.
>
> Signed-off-by: Jan Beulich
> Acked-by: Ian Jackson
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 21.04.16 at 10:36, wrote:
> On 11/03/16 16:01, Jan Beulich wrote:
>> In that case (with the new value being held in, or now in one case cast
>> to, a 32-bit variable) there's no need to go through the long mode part
>> of the checks.
>>
>> Primarily this was meant to hopefully address Cover
On 20/04/16 15:15, Stefano Stabellini wrote:
> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
> probe_8259A(). Use NR_IRQS_LEGACY instead.
Would you mind describing the resulting problem? With this comm
On 16/04/16 03:23, Stefano Stabellini wrote:
> On slow platforms with unreliable TSC, such as QEMU emulated machines,
> it is possible for the kernel to request the next event in the past. In
> that case, in the current implementation of xen_vcpuop_clockevent, we
> simply return -ETIME. To be preci
On 11/03/16 16:01, Jan Beulich wrote:
> In that case (with the new value being held in, or now in one case cast
> to, a 32-bit variable) there's no need to go through the long mode part
> of the checks.
>
> Primarily this was meant to hopefully address Coverity ID 1355278, but
> since the change pr
>>> On 20.04.16 at 19:33, wrote:
> * Userspace tooling
>
> Plan to move to xl / libxl. Need to have stable interface in libxl
> Tool is simple now, but might be more complex when sig verification
> is involved.
>
> Jan: use external utility to veirfy, better. Xl should only do basic
> uplo
On 21/04/16 08:31, Jan Beulich wrote:
> As proposed on the hackathon.
>
> Signed-off-by: Jan Beulich
> Acked-by: Ian Jackson
Acked-by: Andrew Cooper
>
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -437,10 +437,15 @@ F: xen/xsm/
> F: docs/misc/xsm-flask.txt
>
> THE REST
> +M: Andrew Coop
This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
detects the MSI frames from device tree and creates corresponding device
tree nodes in Domain0's DTB. It also provides one hw_ops callback to map
v2m MMIO regions to domain0 and route v2m SPIs to domain0.
With this GICv2m ext
(re-adding xen-devel)
>>> On 21.04.16 at 09:48, wrote:
> 2016-04-21 14:24 GMT+08:00 Jan Beulich :
>
>> >>> On 30.03.16 at 09:28, wrote:
>> > 2016-03-29 18:39 GMT+08:00 Jan Beulich :
>> >> Forwarding entire batches to the device model when an individual
>> >> iteration of them got rejected by in
This run is configured for baseline tests only.
flight 44348 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44348/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-build
flight 92183 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92183/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 9 debian-di-install fail REGR. vs. 87990
Regressions which
As proposed on the hackathon.
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -437,10 +437,15 @@ F: xen/xsm/
F: docs/misc/xsm-flask.txt
THE REST
+M: Andrew Cooper
+M: George Dunlap
M: Ian Jackson
M: Jan Beulich
M: Keir Fra
On Wed, 2016-04-20 at 22:24 +0200, Olaf Hering wrote:
> On Wed, Apr 20, Paulina Szubarczyk wrote:
>
> > @@ -398,34 +398,34 @@ libxl_device_pci
> > *libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num)
> > dir = opendir(SYSFS_PCIBACK_DRIVER);
>
> > +while((de = readdir(dir))) {
>
flight 44349 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44349/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-pvops 3 host-install(3) broken like 44330
build-armhf
>>> On 21.04.16 at 07:09, wrote:
> On 04/12/16 16:45, Haozhong Zhang wrote:
>> On 04/08/16 09:52, Jan Beulich wrote:
>> > >>> On 08.04.16 at 07:02, wrote:
>> > > On 03/29/16 04:49, Jan Beulich wrote:
>> > >> >>> On 29.03.16 at 12:10, wrote:
>> > >> > On 03/29/16 03:11, Jan Beulich wrote:
>> > >>
flight 92182 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92182/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-installfail REGR. vs. 87998
test-amd64-i386-x
>>> On 21.04.16 at 02:33, wrote:
> On Wed, Apr 20, 2016 at 01:14:17AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>> >--- a/Config.mk
>> >+++ b/Config.mk
>> >@@ -126,6 +126,17 @@ endef
>> >check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least
>>
84 matches
Mail list logo
