flight 152045 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152045/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 152031
test-amd64-amd64-xl-qemuu-win7-amd64
On 20.07.2020 18:27, Jan Beulich wrote:
> On 20.07.2020 17:28, Andrew Cooper wrote:
>> On 16/07/2020 11:06, Jan Beulich wrote:
>>> ACCESS_ONCE() guarantees single access, but doesn't guarantee that
>>> the compiler wouldn't split this single access into multiple insns.
>>
>> ACCESS_ONCE() does guar
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xen
flight 152049 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152049/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf ba5923110c2f562170b82f955d9ace70f6a4a8e2
baseline version:
xtf f645a19115e666ce6401ca
On Mon, Jul 20, 2020 at 5:24 PM Stefano Stabellini
wrote:
>
> + Rob Herring
>
> On Fri, 17 Jul 2020, Bertrand Marquis wrote:
> > >> Regarding the DT entry, this is not coming from us and this is already
> > >> defined this way in existing DTBs, we just reuse the existing entry.
> > >
> > > Is it p
flight 152043 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152043/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12
Hello,
Here are the notes from the golang bindings design session at Xen Summit
earlier this month:
Possible improvements:
- Expanding the IDL to have information about device add / remove functions
Ian: It's important that the IDL generates the C prototypes as well.
We could
> Before python 2.7, str.format() calls required that the format fields
> were explicitly enumerated, e.g.:
>
> '{0} {1}'.format(foo, bar)
>
> vs.
>
> '{} {}'.format(foo, bar)
>
> Currently, gengotypes.py uses the latter pattern everywhere, which means
> the Go bindings do not build on python
Before python 2.7, str.format() calls required that the format fields
were explicitly enumerated, e.g.:
'{0} {1}'.format(foo, bar)
vs.
'{} {}'.format(foo, bar)
Currently, gengotypes.py uses the latter pattern everywhere, which means
the Go bindings do not build on python 2.6. Use the 2.6
On Fri, 17 Jul 2020, Bertrand Marquis wrote:
> > On 17 Jul 2020, at 16:06, Jan Beulich wrote:
> >
> > On 17.07.2020 15:59, Bertrand Marquis wrote:
> >>
> >>
> >>> On 17 Jul 2020, at 15:19, Jan Beulich wrote:
> >>>
> >>> On 17.07.2020 15:14, Bertrand Marquis wrote:
> > On 17 Jul 2020, at 1
+ Rob Herring
On Fri, 17 Jul 2020, Bertrand Marquis wrote:
> >> Regarding the DT entry, this is not coming from us and this is already
> >> defined this way in existing DTBs, we just reuse the existing entry.
> >
> > Is it possible to standardize the property and drop the linux prefix?
>
> Hone
flight 152039 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152039/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
151065
test-amd64-amd
flight 152054 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152054/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, 20 Jul 2020, Roger Pau Monné wrote:
> On Mon, Jul 20, 2020 at 01:56:51PM +0300, Oleksandr wrote:
> > On 20.07.20 12:17, Roger Pau Monné wrote:
> > > On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
> > > > On 17.07.20 18:00, Roger Pau Monné wrote:
> > > > > On Fri, Jul 17, 2020 at
On Mon, 20 Jul 2020, Roger Pau Monné wrote:
> On Mon, Jul 20, 2020 at 10:40:40AM +0100, Julien Grall wrote:
> >
> >
> > On 20/07/2020 10:17, Roger Pau Monné wrote:
> > > On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
> > > > On 17.07.20 18:00, Roger Pau Monné wrote:
> > > > > On Fri,
On Fri, 17 Jul 2020, Oleksandr wrote:
> > > *A few word about solution:*
> > > As it was mentioned at [1], in order to implement virtio-mmio Xen on Arm
> > Any plans for virtio-pci? Arm seems to be moving to the PCI bus, and
> > it would be very interesting from a x86 PoV, as I don't think
> > virt
On 20/07/2020 18:48, Julien Grall wrote:
>
> On 20/07/2020 18:45, Andrew Cooper wrote:
>> On 20/07/2020 18:36, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> Signed-off-by: Julien Grall
>>
>> Acked-by: Andrew Cooper
>>
>> Although I'd suggest the subject be changed rearranged to "Spell
>> Ex
On 20/07/2020 18:45, Andrew Cooper wrote:
On 20/07/2020 18:36, Julien Grall wrote:
From: Julien Grall
Signed-off-by: Julien Grall
Acked-by: Andrew Cooper
Although I'd suggest the subject be changed rearranged to "Spell
Experimentally correctly".
Did you intend to write "Experimental"
On 20/07/2020 18:36, Julien Grall wrote:
> From: Julien Grall
>
> Signed-off-by: Julien Grall
Acked-by: Andrew Cooper
Although I'd suggest the subject be changed rearranged to "Spell
Experimentally correctly".
~Andrew
At 10:55 +0200 on 20 Jul (1595242521), Jan Beulich wrote:
> On 18.07.2020 20:20, Tim Deegan wrote:
> > At 12:00 +0200 on 15 Jul (1594814409), Jan Beulich wrote:
> >> ... by the very fact that they're 3-level specific, while PV always gets
> >> run in 4-level mode. This requires adding some seemingl
From: Julien Grall
Signed-off-by: Julien Grall
---
SUPPORT.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index b81d36eea541..1479055c450d 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -249,13 +249,13 @@ to boot with memory < maxmem.
Allow sh
flight 152046 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152046/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 20/07/2020 18:07, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Andrew
>> Cooper
>> Sent: 20 July 2020 17:59
>> To: Xen-devel
>> Cc: Juergen Gross ; Stefano Stabellini
>> ; Julien Grall
>> ; Wei Liu ; George Dunlap
>> ; Andrew Cooper
>> ; Jan Beulich ; Ia
> -Original Message-
> From: Xen-devel On Behalf Of Andrew
> Cooper
> Sent: 20 July 2020 17:59
> To: Xen-devel
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall
> ; Wei Liu ; George Dunlap
> ; Andrew Cooper
> ; Jan Beulich ; Ian Jackson
>
> Subject: [PATCH] docs: Replace non-
>From the docs cronjob on xenbits:
/usr/bin/pandoc --number-sections --toc --standalone misc/hypfs-paths.pandoc
--output html/misc/hypfs-paths.html
pandoc: Cannot decode byte '\x92': Data.Text.Internal.Encoding.decodeUtf8:
Invalid UTF-8 stream
make: *** [Makefile:236: html/misc/hypfs-paths
Le lun. 20 juil. 2020 à 09:00, Roger Pau Monné a écrit :
> You need to set entry_nr and table_base.
Yes, I do that. I use the table_base set to what would be written to
the register for "native".
> Are you enabling the capability and unmasking the interrupt in the
> MSI-X table?
Yes, I'm doing
On 20.07.2020 17:28, Andrew Cooper wrote:
> On 16/07/2020 11:06, Jan Beulich wrote:
>> ACCESS_ONCE() guarantees single access, but doesn't guarantee that
>> the compiler wouldn't split this single access into multiple insns.
>
> ACCESS_ONCE() does guarantee single accesses for any natural integer
Hi Jan,
On 15/07/2020 11:40, Jan Beulich wrote:
A subsequent change will exclude domctl.c from getting built for a
particular configuration, yet the two functions get used from elsewhere.
Signed-off-by: Jan Beulich
--- a/xen/common/bitmap.c
+++ b/xen/common/bitmap.c
@@ -9,6 +9,9 @@
#include
On 20/07/2020 16:15, Julien Grall wrote:
Hi Jan,
On 20/07/2020 12:28, Jan Beulich wrote:
On 20.07.2020 11:09, Julien Grall wrote:
On 20/07/2020 09:17, Jan Beulich wrote:
On 17.07.2020 16:44, Julien Grall wrote:
On 15/07/2020 11:39, Jan Beulich wrote:
--- a/xen/include/asm-arm/domain.h
flight 152032 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152032/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which did no
On 16/07/2020 11:06, Jan Beulich wrote:
> ACCESS_ONCE() guarantees single access, but doesn't guarantee that
> the compiler wouldn't split this single access into multiple insns.
ACCESS_ONCE() does guarantee single accesses for any natural integer size.
There is a section about this specifically
wakeup_32 sets %ds and %es to BOOT_DS, while leaving %fs at what
wakeup_start did set it to, and %gs at whatever BIOS did load into it.
All of this may end up confusing the first load_segments() to run on
the BSP after resume, in particular allowing a non-nul selector value
to be left in %fs.
Alon
Hi Jan,
On 20/07/2020 12:28, Jan Beulich wrote:
On 20.07.2020 11:09, Julien Grall wrote:
On 20/07/2020 09:17, Jan Beulich wrote:
On 17.07.2020 16:44, Julien Grall wrote:
On 15/07/2020 11:39, Jan Beulich wrote:
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -2,7 +2
Hi,
On 24/06/2020 18:38, Stefano Stabellini wrote:
On Wed, 24 Jun 2020, Ian Jackson wrote:
I think it would be a good idea to rename this branch name. This name
has unfortunate associations[1], even if it can be argued[2] that the
etymology is not as bad as in some uses of the word.
This is r
Hello all.
I'm new to this community, and firstly I'd like to thank you all for
your efforts on supporting Xen in ARM devices.
I'm trying Xen 4.13.1 in a Allwinner H6 SoC (more precisely a Pine H64
model B, with a ARM Cortex-A53 CPU).
I managed to get a dom0 Linux 5.8-rc5 kernel running fine, unp
flight 152037 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152037/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3d9d66ad760b67bfdfb5b4b8e9b34f6af6c45935
baseline version:
ovmf 3d8327496762b4f2a54c9
/sigh - it seems that stuff like this doesn't get done when I'm on holiday.
I'll get one sorted.
~Andrew
On 17/07/2020 08:54, Mauro Matteo Cascella wrote:
> Hello,
>
> Will a CVE be assigned to this flaw?
>
> Thanks,
>
> On Thu, Jul 16, 2020 at 3:21 PM Xen.org security team
mailto:secur...@xen.o
flight 152041 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152041/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, Jul 20, 2020 at 01:58:40PM +0200, Jan Beulich wrote:
> On 20.07.2020 12:52, Roger Pau Monné wrote:
> > On Fri, Jul 17, 2020 at 03:10:43PM +0200, Jan Beulich wrote:
> >> Since we intercept RTC/CMOS port accesses, let's do so consistently in
> >> all cases, i.e. also for e.g. a dword access t
flight 152031 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152031/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 152004 pass in 152031
test-amd64-amd64-xl-rtds 18
On 20.07.2020 12:52, Roger Pau Monné wrote:
> On Fri, Jul 17, 2020 at 03:10:43PM +0200, Jan Beulich wrote:
>> Since we intercept RTC/CMOS port accesses, let's do so consistently in
>> all cases, i.e. also for e.g. a dword access to [006E,0071]. To avoid
>> the risk of unintended impact on Dom0 code
On 20.07.2020 13:34, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 20 July 2020 12:33
>> To: Juergen Gross ; p...@xen.org
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; George Dunlap
>> ; Ian Jackson ; Julien
>> Grall ;
>> Stefano Stabellini ; Wei Liu
> -Original Message-
> From: Jan Beulich
> Sent: 20 July 2020 12:33
> To: Juergen Gross ; p...@xen.org
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ;
> Stefano Stabellini ; Wei Liu
> Subject: Re: [PATCH v3] docs: specify stabilit
On 20.07.2020 13:21, Juergen Gross wrote:
> In docs/misc/hypfs-paths.pandoc the supported paths in the hypervisor
> file system are specified. Make it more clear that path availability
> might change, e.g. due to scope widening or narrowing (e.g. being
> limited to a specific architecture).
>
> Si
> -Original Message-
> From: Juergen Gross
> Sent: 20 July 2020 12:22
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Juergen Gross ; Andrew Cooper
> ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich
> ; Julien Grall ; Stefano Stabellini
> ; Wei
> Liu
> Subject: [PATCH v3] docs:
> On 18 Jul 2020, at 12:14 pm, Julien Grall wrote:
>
>
>
> On 18/07/2020 10:55, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 18:05, Roger Pau Monné wrote:
>>>
>>> On Fri, Jul 17, 2020 at 03:47:25PM +, Bertrand Marquis wrote:
> On 17 Jul 2020, at 17:26, Julien Grall wrote:
> O
On 20.07.2020 11:09, Julien Grall wrote:
>
>
> On 20/07/2020 09:17, Jan Beulich wrote:
>> On 17.07.2020 16:44, Julien Grall wrote:
>>> On 15/07/2020 11:39, Jan Beulich wrote:
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -2,7 +2,7 @@
#define __ASM
On 18.07.20 14:24, Julien Grall wrote:
Hello Julien
On 17/07/2020 20:17, Oleksandr wrote:
I would like to clarify regarding an IOMMU driver changes which
should be done to support PCI pass-through properly.
Design document mentions about SMMU, but Xen also supports IPMMU-VMSA
(under tec
> On 18 Jul 2020, at 12:08 pm, Julien Grall wrote:
>
> Hi,
>
> On 17/07/2020 16:47, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 17:26, Julien Grall wrote:
>>> On 17/07/2020 15:47, Bertrand Marquis wrote:
>>> pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ...]
>>>
>>> Guest wi
In docs/misc/hypfs-paths.pandoc the supported paths in the hypervisor
file system are specified. Make it more clear that path availability
might change, e.g. due to scope widening or narrowing (e.g. being
limited to a specific architecture).
Signed-off-by: Juergen Gross
Release-acked-by: Paul Dur
On Wed, Jul 15, 2020 at 01:57:07PM +0200, Jan Beulich wrote:
> ... in order to also intercept accesses through the alias ports.
>
> Also stop intercepting accesses to the CMOS ports if we won't ourselves
> use the CMOS RTC.
Will wait for v4 with the fixed additions to PVH dom0.
Roger.
On Mon, Jul 20, 2020 at 01:56:51PM +0300, Oleksandr wrote:
> On 20.07.20 12:17, Roger Pau Monné wrote:
> > On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
> > > On 17.07.20 18:00, Roger Pau Monné wrote:
> > > > On Fri, Jul 17, 2020 at 05:11:02PM +0300, Oleksandr Tyshchenko wrote:
> > > T
On 20.07.20 12:19, George Dunlap wrote:
On Jul 16, 2020, at 3:34 PM, Jürgen Groß wrote:
On 16.07.20 16:20, George Dunlap wrote:
On Jul 16, 2020, at 12:34 PM, Jürgen Groß wrote:
On 16.07.20 13:24, Jan Beulich wrote:
On 16.07.2020 12:31, Jürgen Groß wrote:
On 16.07.20 12:11, Jan Beulich w
On 20.07.20 12:17, Roger Pau Monné wrote:
Hello Roger
On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
On 17.07.20 18:00, Roger Pau Monné wrote:
On Fri, Jul 17, 2020 at 05:11:02PM +0300, Oleksandr Tyshchenko wrote:
requires
some implementation to forward guest MMIO access to a de
On Fri, Jul 17, 2020 at 03:10:43PM +0200, Jan Beulich wrote:
> Since we intercept RTC/CMOS port accesses, let's do so consistently in
> all cases, i.e. also for e.g. a dword access to [006E,0071]. To avoid
> the risk of unintended impact on Dom0 code actually doing so (despite
> the belief that non
Hello,
I am trying to get Xen working on a Jetson Nano board (which is based on
NVIDIA's Tegra210 SoC). After some searching through the Xen-devel archives,
I learnt that there was a set of patches developed in 2017 to port Xen to
Tegra
(https://lists.xenproject.org/archives/html/xen-devel/2017
On Mon, Jul 20, 2020 at 10:40:40AM +0100, Julien Grall wrote:
>
>
> On 20/07/2020 10:17, Roger Pau Monné wrote:
> > On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
> > > On 17.07.20 18:00, Roger Pau Monné wrote:
> > > > On Fri, Jul 17, 2020 at 05:11:02PM +0300, Oleksandr Tyshchenko wro
> On Jul 16, 2020, at 3:34 PM, Jürgen Groß wrote:
>
> On 16.07.20 16:20, George Dunlap wrote:
>>> On Jul 16, 2020, at 12:34 PM, Jürgen Groß wrote:
>>>
>>> On 16.07.20 13:24, Jan Beulich wrote:
On 16.07.2020 12:31, Jürgen Groß wrote:
> On 16.07.20 12:11, Jan Beulich wrote:
>> On 1
On 20/07/2020 10:17, Roger Pau Monné wrote:
On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
On 17.07.20 18:00, Roger Pau Monné wrote:
On Fri, Jul 17, 2020 at 05:11:02PM +0300, Oleksandr Tyshchenko wrote:
requires
some implementation to forward guest MMIO access to a device model.
On 19.07.20 02:33, Randy Dunlap wrote:
Drop the repeated word "of" in a comment.
Signed-off-by: Randy Dunlap
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
Reviewed-by: Juergen Gross
Juergen
On Mon, 2020-07-20 at 10:38 +0200, Christian Lindig wrote:
> > Time for a bit of controversy.
>
> OCaml outside Xen has moved to a different model of building based on
> dune which is fast, declarative and reliable. The OCaml xenstore is
> stagnating because nobody with OCaml experience wants to t
On Sat, Jul 18, 2020 at 09:47:04PM -0400, Boris Ostrovsky wrote:
> (Roger, question for you at the very end)
>
> On 7/17/20 3:10 PM, Anchal Agarwal wrote:
> > On Wed, Jul 15, 2020 at 05:18:08PM -0400, Boris Ostrovsky wrote:
> >> CAUTION: This email originated from outside of the organization. Do n
I think this would at least force a clean-up and open the project to wider set
of OCaml developers. This might lead to a situation where the OCaml xenstore is
not readily available for the consumers of Xen and I don't know who wants it
how much. But I would prefer a situation where the OCaml xe
Hi Roger,
On 20/07/2020 09:47, Roger Pau Monné wrote:
On Fri, Jul 17, 2020 at 05:18:46PM +0100, Julien Grall wrote:
Do you really need to specify the ECAM and MMIO regions there?
You need to define those values somewhere :). The layout is only shared
between the tools and the hypervisor. I th
On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
> On 17.07.20 18:00, Roger Pau Monné wrote:
> > On Fri, Jul 17, 2020 at 05:11:02PM +0300, Oleksandr Tyshchenko wrote:
> > > requires
> > > some implementation to forward guest MMIO access to a device model. And as
> > > it
> > > turned out
On 20/07/2020 09:17, Jan Beulich wrote:
On 17.07.2020 16:44, Julien Grall wrote:
On 15/07/2020 11:39, Jan Beulich wrote:
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -2,7 +2,7 @@
#define __ASM_DOMAIN_H__
#include
-#include
+#include
#include
#
> -Original Message-
> From: Xen-devel On Behalf Of
> Christian Lindig
> Sent: 20 July 2020 09:39
> To: Elliott Mitchell ; xen-de...@lists.xen.org
> Cc: Ian Jackson ; Edwin Torok
> ; w...@xen.org;
> d...@recoil.org
> Subject: Re: [PATCH 2/2] tools/ocaml: Default to useful build output
>
On 18.07.2020 20:20, Tim Deegan wrote:
> At 12:00 +0200 on 15 Jul (1594814409), Jan Beulich wrote:
>> ... by the very fact that they're 3-level specific, while PV always gets
>> run in 4-level mode. This requires adding some seemingly redundant
>> #ifdef-s - some of them will be possible to drop ag
On 20.07.2020 09:00, Roger Pau Monné wrote:
> On Sun, Jul 19, 2020 at 05:54:28PM +0200, Jaromír Doleček wrote:
>> I've implemented support for using MSI under NetBSD Dom0 with 4.11.
>> This works well.
>>
>> I have some trouble now with getting MSI-X work under Xen.
>> PHYSDEVOP_map_pirq hypercall
On Fri, Jul 17, 2020 at 05:18:46PM +0100, Julien Grall wrote:
>
>
> On 17/07/2020 17:08, Roger Pau Monné wrote:
> > On Fri, Jul 17, 2020 at 03:51:47PM +, Bertrand Marquis wrote:
> > >
> > >
> > > > On 17 Jul 2020, at 17:30, Roger Pau Monné wrote:
> > > >
> > > > On Fri, Jul 17, 2020 at 03
On Sat, Jul 18, 2020 at 09:49:43AM +, Bertrand Marquis wrote:
>
>
> > On 17 Jul 2020, at 17:55, Roger Pau Monné wrote:
> >
> > On Fri, Jul 17, 2020 at 03:21:57PM +, Bertrand Marquis wrote:
> >>> On 17 Jul 2020, at 16:31, Roger Pau Monné wrote:
> >>> On Fri, Jul 17, 2020 at 01:22:19PM +
> Time for a bit of controversy.
OCaml outside Xen has moved to a different model of building based on dune
which is fast, declarative and reliable. The OCaml xenstore is stagnating
because nobody with OCaml experience wants to touch it anymore. It would be
beneficial for the health of the OC
From: Elliott Mitchell
Sent: 18 July 2020 04:31
To: xen-de...@lists.xen.org
Cc: Ian Jackson; w...@xen.org; Christian Lindig; d...@recoil.org
Subject: [PATCH 1/2] Partially revert "Cross-compilation fixes."
This partially reverts commit 16504669c5cbb8b195d
From: Elliott Mitchell
Sent: 18 July 2020 04:32
To: xen-de...@lists.xen.org
Cc: Ian Jackson; w...@xen.org; Christian Lindig; d...@recoil.org
Subject: [PATCH 2/2] tools/ocaml: Default to useful build output
While hiding details of build output looks pretty
On 17.07.2020 16:44, Julien Grall wrote:
> On 15/07/2020 11:39, Jan Beulich wrote:
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-arm/domain.h
>> @@ -2,7 +2,7 @@
>> #define __ASM_DOMAIN_H__
>>
>> #include
>> -#include
>> +#include
>> #include
>> #include
>> #includ
flight 152026 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152026/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
151065
test-amd64-amd
flight 152034 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152034/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Sun, Jul 19, 2020 at 05:54:28PM +0200, Jaromír Doleček wrote:
> Hello,
>
> I've implemented support for using MSI under NetBSD Dom0 with 4.11.
> This works well.
>
> I have some trouble now with getting MSI-X work under Xen.
> PHYSDEVOP_map_pirq hypercall succeeds just as well as for MSI, but
78 matches
Mail list logo
