On Thu, Dec 14, 2017 at 05:41:37PM +, Paul Durrant wrote:
>A subsequent patch will introduce a new scheme to allow an emulator to
>map ioreq server pages directly from Xen rather than the guest P2M.
>
>This patch lays the groundwork for that change by deferring mapping of
>gfns until their valu
flight 117173 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117173/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
build-armhf 6 xen
On Thu, Dec 14, 2017 at 02:50:17PM +, Paul Durrant wrote:
>> -Original Message-
>> >
>> > Hmm. That looks like it is because the ioreq server pages are not owned by
>> > the correct domain. The Xen patch series underwent some changes later in
>> > review and I did not re-test my QEMU pa
flight 117130 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117130/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.15-rc4-tag
xen: fixes for 4.15-rc4
It contains two minor fixes for running as Xen dom0:
- when built as 32 bit kernel on large machines the Xen LAPIC emulation
should report a rat
flight 117169 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117169/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
flight 117129 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigrate fail REGR. vs.
116619
test-amd64-i
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Reviewed-by: Anthony PERARD
---
hw/audio/pcspk.c| 1 -
hw/i386/xen/xen_platform.c | 1 -
hw/isa/vt82c686.c | 1 -
hw/misc/ivshmem.c | 1 -
hw/misc/sga.c
exec: housekeeping (funny since 02d0e095031)
applied using ./scripts/clean-includes
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Peter Maydell
Acked-by: Cornelia Huck
Reviewed-by: Anthony PERARD
---
accel/tcg/translate-all.c | 1 -
exec.c | 3 ---
h
Hello all,
Looking to see if there is interest from anyone in having machine
readable feeds for the XSA content (e.g. JSON). I mentioned it on IRC
but figured I should post this on the ML to get interest and see if
anyone has strong feelings about a format. I am currently converting the
HTML index
Hello,
I'm trying to understand how Xen and each domain use RAM
on Aarch64 systems.
My understanding is that during Xen startup, Xen will copy
itself to upper physical memory, and continue to run from there,
correct? Is there any information on how the heap is handled here
compared to Xen on ARM
flight 117166 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117166/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
flight 117122 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117122/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 broken in 117010
test-amd6
From: Owen Smith
If the frontend requests raw pointers, the input handlers must be
activated to have the input events delivered to the xenfb backend.
Without activation, the input events are delivered to handlers
registered earlier, which would be the emulated USB tablet or
emulated PS/2 mouse.
H
From: Simon Gaiser
The passed-through device might be an express device. In this case the
old code allocated a too small emulated config space in
pci_config_alloc() since pci_config_size() returned the size for a
non-express device. This leads to an out-of-bound write in
xen_pt_config_reg_init(),
The following changes since commit 0a0dc59d27527b78a195c2d838d28b7b49e5a639:
Update version for v2.11.0 release (2017-12-13 14:31:09 +)
are available in the git repository at:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20171214-tag
for you to fetch changes up to
From: Owen Smith
Writes "feature-raw-pointer" during init to indicate the backend
can pass raw unscaled values for absolute axes to the frontend.
Frontends set "request-raw-pointer" to indicate the backend should
not attempt to scale absolute values to console size.
"request-raw-pointer" is only
From: Owen Smith
Use keycodedb to generate a qcode to linux mapping
Signed-off-by: Owen Smith
Reviewed-by: Gerd Hoffmann
Signed-off-by: Stefano Stabellini
---
Makefile | 1 +
include/ui/input.h | 3 +++
ui/input-keymap.c | 1 +
3 files changed, 5 insertions(+)
diff --git a/Makefi
From: Owen Smith
Avoid the unneccessary calls through the input-legacy.c file by
using the qemu_input_handler_*() calls directly. This did require
reworking the event and sync handlers to use the reverse mapping
from qcode to linux using qemu_input_qcode_to_linux().
Removes the scancode2linux map
From: Paul Durrant
This patch allocates an IOThread object for each xen_disk instance and
sets the AIO context appropriately on connect. This allows processing
of I/O to proceed in parallel.
The patch also adds tracepoints into xen_disk to make it possible to
follow the state transtions of an in
On Thu, Dec 14, 2017 at 04:52:06AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 13, 2017 at 03:24:21PM -0600, Bjorn Helgaas wrote:
> > Prior to a60a2b73ba69, we had
> >
> > int pcie_flr(struct pci_dev *dev, int probe);
> >
> > like all the other reset methods. AFAICT, the addition of
> > pcie
flight 117162 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117162/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
When kexec is utilized in a Xen environment, it has an explicit
run-time dependency on libxenctrl.so. This dependency occurs
during the configure stage and when building kexec-tools.
When kexec is utilized in a non-Xen environment (either bare
metal or KVM), the configure and build of kexec-tools
This run is configured for baseline tests only.
flight 72798 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72798/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
Den 14. des. 2017 21:22, skrev Govinda Tatti:
>
In which case, xl needs to be backwards-compatible with kernels that
don't have your new feature: it will have to check for %s/reset, and
if it's not there, then try %/do_flr.
>>> I think this fix was planned more than a year back an
flight 117157 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117157/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
In which case, xl needs to be backwards-compatible with kernels that
don't have your new feature: it will have to check for %s/reset, and
if it's not there, then try %/do_flr.
I think this fix was planned more than a year back and even we pushed libxl
fix
("do_flr" SysFSattribute) but linux ker
flight 117119 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117119/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117011
test-amd64-i386-xl-qemuu-win7-amd64 17
flight 117121 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
116658
Tests whi
flight 117152 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117152/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Co
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
---
xen/arch/x86/hvm/ioreq.c | 44 +++
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_tr
This series introduces support for direct mapping of guest resources.
The resources are:
- IOREQ server pages
- Grant tables
v15:
- Correct page ownership of ioreq pages
v14:
- Responded to more comments from Jan.
v13:
- Responded to more comments from Jan and Julien.
- Build-tested using
flight 72780 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72780/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i38
Ian Jackson writes ("[OSSTEST PATCH 11/11] production-config: Update jessie
amd64 kernel for NUMA bugfix"):
> Bump TftpDiVersion_jessie. This installer was generated by me today,
> with the git branch including the di_special_kernel series, using this
> rune:
>
>
> OSSTEST_SPECIALKERNELDEB_jes
osstest service owner writes ("[xen-unstable-smoke test] 117145: trouble:
broken/pass"):
> flight 117145 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/117145/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> includin
flight 117118 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117118/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116145
test-armhf-armhf-libvirt-xsm 14 saveres
A symptom that the old patterns lack !build-arm64-xsm, so the xsm job
might be reused. The overall cause is that it contained a (partial)
list of architectures.
Instead, we observe that:
* The things we want to avoid reusing are Xen and libvirt (which
builds against Xen.
* Non-Xen builds are
The smoke flight contains test-arm64-arm64-xl-xsm so it should contain
build-arm64-xsm (and not contain build-arm64).
I have checked the results with
OSSTEST_CONFIG=standalone-config-example eatmydata
./standalone-generate-dump-flight-runvars
and looking at the diff shows precisely the expected
Bump TftpDiVersion_jessie. This installer was generated by me today,
with the git branch including the di_special_kernel series, using this
rune:
OSSTEST_SPECIALKERNELDEB_jessie_amd64=$PWD/linux-image-3.16.0-4-amd64_3.16.51-3~a.test_amd64.deb
./mg-debian-installer-update-all
The file linux-im
* In the first half of the backports kernel processing, set
the new variable specialkernel to the string "backports".
(This token occurs in the output .deb and kernel name, and
is also referenced by hostflags of the form
need-kernel-deb--backports.)
* Break out the second half of the ba
This abolishes yet another open-coding of need-kernel-deb-* handling.
Again, there is little functional change. A significant change is
that now if the special kernel deb does not exist, we do not fail.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 10 --
1 file changed, 4 inserti
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 31 +++
ts-host-install | 29 +
2 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 845027a..ba39ad2 100644
Make both of these paths relative to $ho->{Tftp}{Path}. Previously
$kernel was relative to that, but $cpio contained it.
Adjust all callers, so no functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 28
ts-host-install | 8
2 files cha
No significant functional change. We now honour cfg_tftp_di_version
if the $ho doesn't have the information.
Signed-off-by: Ian Jackson
---
ts-host-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-host-install b/ts-host-install
index 520983f..a5cf93b 100755
--- a/t
Adjust the one current caller. No functional change
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 4 ++--
ts-host-install | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index ba39ad2..6a1babf 100644
--- a/Osstest/Debian.pm
+++
This variable can be set to the absolute pathname of a kernel .deb to
use. It will be used only for hosts for which the corresponding
hostflag "need-kernel-deb--special" is set.
There is not currently any facility for more than one special kernel
for each architecture.
As with backports kernels,
The effect is simply to reuse the loop in di_special_kernel. The
extra tests etc. to compute $k and $c in di_special_kernel are of no
import here, and are harmless. We have already called
di_special_kernel so if it was going to fail due to this extra
computation, it would do so earlier.
No overa
This avoids the caller having to supply $d_i. This is good because
there is a site we want to call this from which uses that name for a
different value!
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 5 +++--
ts-host-install | 4 ++--
2 files changed, 5 insertions(+
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 6a1babf..7664194 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -34,7 +34,7 @@ BEGIN
Committers,
as 4.10 has been released, feel free to commit patches again.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 117145 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117145/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
> -Original Message-
> >
> > Hmm. That looks like it is because the ioreq server pages are not owned by
> > the correct domain. The Xen patch series underwent some changes later in
> > review and I did not re-test my QEMU patch after that so I wonder if
> > mapping IOREQ pages has simply be
>>> On 13.12.17 at 11:58, wrote:
> Zero the msr structure once at initialisation time, and avoid re-zeroing the
> reserved field every time the structure is used.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xe
>>> On 13.12.17 at 11:50, wrote:
> @@ -3158,24 +3153,23 @@ static int vmx_msr_write_intercept(unsigned int msr,
> uint64_t msr_content)
>
> switch ( long_mode_do_msr_write(msr, msr_content) )
> {
> -case HNDL_unhandled:
> -if ( (vmx_write_guest_msr(
>>> On 13.12.17 at 11:50, wrote:
> Since c/s 49de10f3c1718 "x86/hvm: Don't raise #GP behind the emulators back
> for MSR accesses", returning X86EMUL_EXCEPTION has pushed the exception
> generation to the top of the call tree.
>
> Using hvm_inject_hw_exception() and returning X86EMUL_EXCEPTION ca
>>> On 13.12.17 at 11:36, wrote:
> There is no need for the overhead of a call to a separate translation unit.
Indeed, the more that the per-CPU variable wasn't even static.
> While moving the implementation, update them to use uint64_t over u64
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan
This run is configured for baseline tests only.
flight 72775 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72775/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 14/12/17 15:15, Jan Beulich wrote:
On 14.12.17 at 15:04, wrote:
>> On 12/12/17 11:31, Jan Beulich wrote:
>>> @@ -335,42 +346,45 @@ static inline bool kasan_page_table(stru
>>>
>>> #if PTRS_PER_PMD > 1
>>>
>>> -static void walk_pmd_level(struct seq_file *m, struct pg_state *st, pud_t
On Thu, 14 Dec 2017, Jan Beulich wrote:
> >>> On 14.12.17 at 15:04, wrote:
> > On 12/12/17 11:31, Jan Beulich wrote:
> >> @@ -335,42 +346,45 @@ static inline bool kasan_page_table(stru
> >>
> >> #if PTRS_PER_PMD > 1
> >>
> >> -static void walk_pmd_level(struct seq_file *m, struct pg_state *st
>>> On 14.12.17 at 15:04, wrote:
> On 12/12/17 11:31, Jan Beulich wrote:
>> @@ -335,42 +346,45 @@ static inline bool kasan_page_table(stru
>>
>> #if PTRS_PER_PMD > 1
>>
>> -static void walk_pmd_level(struct seq_file *m, struct pg_state *st, pud_t
>> addr, unsigned long P)
>> +static void wal
From: Oleksandr Grytsov
libxl__is_driver_domain determines the driver domain by
presence of libxl entry in the domain xen store. Use
this function on device destroy to properly manage cleanup
in case backends are located on domain with non zero id.
Signed-off-by: Oleksandr Grytsov
---
tools/li
From: Oleksandr Grytsov
We have following arm-based setup:
- Dom0 with xen and xen tools;
- Dom1 with device backends (but it is not the driver domain);
- Dom2 with device frontend;
On Dom2 destroying we have timeout error. Because xl treats our
Dom1 as driver domain and waits for backend path
On Thu, 14 Dec 2017, Juergen Gross wrote:
> On 12/12/17 11:31, Jan Beulich wrote:
> > for (i = 0; i < PTRS_PER_PMD; i++) {
> > st->current_address = normalize_addr(P + i * PMD_LEVEL_MULT);
> > if (!pmd_none(*start)) {
> > + prot = pmd_flags(*start);
> >
>>> On 14.12.17 at 08:56, wrote:
> 4. Should we try harder to negotiate embargo dates of security issues to
>match the (targeted) release dates?
Personally I don't think embargo dates should be made match
release dates; if anything, the other way around. Holding back
security issues is just b
>>> On 14.12.17 at 12:38, wrote:
> Next try:
>
> 2. Should we have released 4.10 without those late security patches,
>resulting in the need for 4.10.1 at once?
We don't make point releases just for security issues on other
branches - why would we do so right after a .0 release? We
really ha
On 12/12/17 11:31, Jan Beulich wrote:
> Using just the leaf page table entry flags would cause a false warning
> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
> Hand through both the current entry's flags as well as the accumulated
> effective value (the latter as pgprotval_
On Mon, Nov 27, 2017 at 08:42:29AM -0700, Jan Beulich wrote:
> >>> On 10.11.17 at 11:36, wrote:
> > Signed-off-by: Yang Zhong
>
> First and foremost - did you try out your own patch? There not being
> any (minimal) test added makes this at least questionable.
>
> > --- a/xen/arch/x86/x86_emulat
>>> On 13.12.17 at 18:03, wrote:
> Looking through the code, the only one thing that bothers me is the
> page_set_owner() done in shadow_enable() for the page used for HVM guest
> vcpus that have paging disabled. AFAICT that page would become mappable by an
> emulating domain with MMU_PT_UPDATE
On Mon, Nov 27, 2017 at 08:53:24AM -0700, Jan Beulich wrote:
> >>> On 10.11.17 at 11:36, wrote:
> > @@ -7672,7 +7673,12 @@ x86_emulate(
> > host_and_vcpu_must_have(pclmulqdq);
> > if ( vex.opcx == vex_none )
> > goto simd_0f3a_common;
> > -generate_exception_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 December 2017 13:46
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> de...@lists.xenproject.org; Tim (Xen.org)
> Subject: Re: [PA
>>> On 14.12.17 at 10:51, wrote:
>> From: Paul Durrant [mailto:paul.durr...@citrix.com]
>> Sent: 28 November 2017 15:09
>> +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
>> +{
>> +struct domain *currd = current->domain;
>> +struct hvm_ioreq_page *iorp = buf ? &s->buf
On Mon, Nov 27, 2017 at 09:30:15AM -0700, Jan Beulich wrote:
> >>> On 10.11.17 at 11:36, wrote:
> > --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> > @@ -1626,6 +1626,7 @@ static bool vcpu_has(
> > #define vcpu_has_clwb()vcpu_has( 7,
On 14/12/17 13:43, Julien Grall wrote:
>
>
> On 14/12/17 11:38, Juergen Gross wrote:
>> On 14/12/17 12:28, Julien Grall wrote:
>>>
>>>
>>> On 14/12/17 07:56, Juergen Gross wrote:
Hi all,
>>>
>>> Hi Juergen,
>>>
>>> I would recommend to CC committers on that thread, so your thread don't
>>> g
flight 117139 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117139/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
Tests which di
flight 117097 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117097/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On Wed, Dec 13, 2017 at 03:24:21PM -0600, Bjorn Helgaas wrote:
> Prior to a60a2b73ba69, we had
>
> int pcie_flr(struct pci_dev *dev, int probe);
>
> like all the other reset methods. AFAICT, the addition of
> pcie_has_flr() was to optimize the path slightly because when drivers
> call pcie_flr
On 14/12/17 11:38, Juergen Gross wrote:
On 14/12/17 12:28, Julien Grall wrote:
On 14/12/17 07:56, Juergen Gross wrote:
Hi all,
Hi Juergen,
I would recommend to CC committers on that thread, so your thread don't
get lost in the xen-devel meanders :).
with 4.10 more or less finished it i
flight 117092 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117092/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-i386
Dear community members,
I'm pleased to announce that Xen 4.10.0 is released.
Please find the tarball and its signature at:
https://xenproject.org/downloads/xen-archives/xen-project-410-series/xen-project-4100.html
You can also check out the tag in xen.git:
https://xenbits.xen.org/git-http
flight 117115 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117115/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 116665
test-amd64-i386
On 14/12/17 12:32, Daniel Kiper wrote:
> On Thu, Dec 14, 2017 at 12:26:02PM +0100, Juergen Gross wrote:
>> On 14/12/17 12:19, Daniel Kiper wrote:
>>> On Fri, Dec 01, 2017 at 12:12:50PM +0100, Daniel Kiper wrote:
On Fri, Dec 01, 2017 at 06:37:37AM +0100, Juergen Gross wrote:
> On 30/11/17 2
On 14/12/17 12:28, Julien Grall wrote:
>
>
> On 14/12/17 07:56, Juergen Gross wrote:
>> Hi all,
>
> Hi Juergen,
>
> I would recommend to CC committers on that thread, so your thread don't
> get lost in the xen-devel meanders :).
>
>> with 4.10 more or less finished it is time to plan for the n
On Thu, Dec 14, 2017 at 12:26:02PM +0100, Juergen Gross wrote:
> On 14/12/17 12:19, Daniel Kiper wrote:
> > On Fri, Dec 01, 2017 at 12:12:50PM +0100, Daniel Kiper wrote:
> >> On Fri, Dec 01, 2017 at 06:37:37AM +0100, Juergen Gross wrote:
> >>> On 30/11/17 22:03, Daniel Kiper wrote:
> On Wed, N
On 14/12/17 07:56, Juergen Gross wrote:
Hi all,
Hi Juergen,
I would recommend to CC committers on that thread, so your thread don't
get lost in the xen-devel meanders :).
with 4.10 more or less finished it is time to plan for the next release
4.11. Since 4.7 we are using a 6 month releas
On 14/12/17 12:19, Daniel Kiper wrote:
> On Fri, Dec 01, 2017 at 12:12:50PM +0100, Daniel Kiper wrote:
>> On Fri, Dec 01, 2017 at 06:37:37AM +0100, Juergen Gross wrote:
>>> On 30/11/17 22:03, Daniel Kiper wrote:
On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen Gross wrote:
> This patch se
On Fri, Dec 01, 2017 at 12:12:50PM +0100, Daniel Kiper wrote:
> On Fri, Dec 01, 2017 at 06:37:37AM +0100, Juergen Gross wrote:
> > On 30/11/17 22:03, Daniel Kiper wrote:
> > > On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen Gross wrote:
> > >> This patch series adds support for booting Linux as P
Dear community members,
I'm pleased to announce that Jurgen Gross will be the
Release Manager for the next Xen release.
Jurgen has been an active developer for the past few years, making
significant code contributions to advance Xen support in Linux. He is a
virtualization kernel developer
flight 117078 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117078/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
test-arm64-arm64-xl
flight 117135 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117135/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
test-arm64-arm
On Wed, Dec 13, 2017 at 9:05 PM, Govinda Tatti wrote:
>
> Thanks George for your review comments. Please see below for my comments.
>
>
> On 12/13/2017 8:01 AM, George Dunlap wrote:
>>
>> On Thu, Dec 7, 2017 at 10:26 PM, Govinda Tatti
>> wrote:
>>>
>>> The life-cycle of a PCI device in Xen pcibac
1 - 100 of 108 matches
Mail list logo
