While hiding details of build output looks pretty to some, defaulting to
doing so deviates from the rest of Xen. Switch the OCAML tools to match
everything else.
Signed-off-by: Elliott Mitchell
---
Time for a bit of controversy.
Presently the OCAML tools build mismatches the rest of the Xen
This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7.
Signed-off-by: Elliott Mitchell
---
Doesn't look like much of 16504669c5cbb8b195d20412aadc838da5c428f7
actually remains due to passage of time.
Of the 3, both Python and pygrub appear to mostly be building just fine
flight 151972 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151972/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6ff53d2a13740e39dea110d6b3509c156c659586
baseline version:
ovmf
flight 151962 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151962/
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
build-i386-pvops
flight 151970 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151970/
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
On 17.07.20 19:18, Julien Grall wrote:
Hello Bertrand
[two threads with the same name are shown in my mail client, so not
completely sure I am asking in the correct one]
On 17/07/2020 17:08, Roger Pau Monné wrote:
On Fri, Jul 17, 2020 at 03:51:47PM +, Bertrand Marquis wrote:
On
On 17.07.20 18:00, Roger Pau Monné wrote:
Hello,
Hello Roger
I'm very happy to see this proposal, as I think having proper (1st
class) VirtIO support on Xen is crucial to our survival. Almost all
OSes have VirtIO frontends, while the same can't be said about Xen PV
frontends. It would
flight 151957 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151957/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151942
flight 151959 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151959/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 21a23e6966c2eb597a8db98d6837a4c01b3cad4a
baseline version:
ovmf
Ian Jackson writes ("Re: [PATCH 0/2] osstest: update FreeBSD guest tests"):
> Roger Pau Monne writes ("[PATCH 0/2] osstest: update FreeBSD guest tests"):
> > The following series adds FreeBSD 11 and 12 guests tests to osstest.
> > ATM this is only tested on amd64, since the i386 versions had a
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:23:57PM +, Bertrand Marquis wrote:
On 17 Jul 2020, at 17:05, Roger Pau Monné wrote:
On Fri,
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:23:57PM +, Bertrand Marquis wrote:
> >>
> >>
> >>> On 17 Jul 2020, at 17:05, Roger Pau Monné wrote:
> >>>
> >>> On Fri, Jul 17,
On Fri, Jul 17, 2020 at 03:47:25PM +, Bertrand Marquis wrote:
> > On 17 Jul 2020, at 17:26, Julien Grall wrote:
> > On 17/07/2020 15:47, Bertrand Marquis wrote:
> > * Dom0Less implementation will require to have the capacity inside Xen
> > to discover the PCI devices (without
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 +, Bertrand Marquis wrote:
> >>> On 17 Jul 2020, at 13:16, Roger Pau Monné wrote:
> * ACS capability is disable for ARM as of now
> On 17 Jul 2020, at 17:30, Roger Pau Monné wrote:
>
> On Fri, Jul 17, 2020 at 03:23:57PM +, Bertrand Marquis wrote:
>>
>>
>>> On 17 Jul 2020, at 17:05, Roger Pau Monné wrote:
>>>
>>> On Fri, Jul 17, 2020 at 02:49:20PM +, Bertrand Marquis wrote:
> On 17 Jul 2020, at
> On 17 Jul 2020, at 17:26, Julien Grall wrote:
>
>
>
> On 17/07/2020 15:47, Bertrand Marquis wrote:
> # Title:
>
> PCI devices passthrough on Arm design proposal
>
> # Problem statement:
>
> On ARM there in no support to assign a PCI device to a guest. PCI
On Fri, Jul 17, 2020 at 03:23:57PM +, Bertrand Marquis wrote:
>
>
> > On 17 Jul 2020, at 17:05, Roger Pau Monné wrote:
> >
> > On Fri, Jul 17, 2020 at 02:49:20PM +, Bertrand Marquis wrote:
> >>
> >>
> >>> On 17 Jul 2020, at 16:41, Roger Pau Monné wrote:
> >>>
> >>> On Fri, Jul 17,
On 17/07/2020 15:47, Bertrand Marquis wrote:
# Title:
PCI devices passthrough on Arm design proposal
# Problem statement:
On ARM there in no support to assign a PCI device to a guest. PCI device
passthrough capability allows guests to have full access to some PCI devices.
PCI device
> On 17 Jul 2020, at 17:05, Roger Pau Monné wrote:
>
> On Fri, Jul 17, 2020 at 02:49:20PM +, Bertrand Marquis wrote:
>>
>>
>>> On 17 Jul 2020, at 16:41, Roger Pau Monné wrote:
>>>
>>> On Fri, Jul 17, 2020 at 02:34:55PM +, Bertrand Marquis wrote:
> On 17 Jul 2020, at
> On 17 Jul 2020, at 16:31, Roger Pau Monné wrote:
>
> On Fri, Jul 17, 2020 at 01:22:19PM +, Bertrand Marquis wrote:
>>
>>
>>> On 17 Jul 2020, at 13:16, Roger Pau Monné wrote:
>>>
>>> I've wrapped the email to 80 columns in order to make it easier to
>>> reply.
>>>
>>> Thanks for
On Fri, Jul 17, 2020 at 02:49:20PM +, Bertrand Marquis wrote:
>
>
> > On 17 Jul 2020, at 16:41, Roger Pau Monné wrote:
> >
> > On Fri, Jul 17, 2020 at 02:34:55PM +, Bertrand Marquis wrote:
> >>
> >>
> >>> On 17 Jul 2020, at 16:06, Jan Beulich wrote:
> >>>
> >>> On 17.07.2020 15:59,
Hello,
I'm very happy to see this proposal, as I think having proper (1st
class) VirtIO support on Xen is crucial to our survival. Almost all
OSes have VirtIO frontends, while the same can't be said about Xen PV
frontends. It would also allow us to piggyback on any new VirtIO
devices without
> On 17 Jul 2020, at 16:41, Roger Pau Monné wrote:
>
> On Fri, Jul 17, 2020 at 02:34:55PM +, 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
> On 17 Jul 2020, at 15:50, Julien Grall wrote:
>
> (Resending to the correct ML)
>
> On 17/07/2020 14:23, Julien Grall wrote:
>> On 16/07/2020 18:02, Rahul Singh wrote:
>>> Hello All,
>> Hi,
>>> Following up on discussion on PCI Passthrough support on ARM that we had at
>>> the XEN summit,
On 15/07/2020 11:39, Jan Beulich wrote:
asm/domain.h is a dependency of xen/sched.h, and hence should not itself
include xen/sched.h. Nor should any of the other #include-s used by it.
While at it, also drop two other #include-s that aren't needed by this
particular header.
Signed-off-by:
On Fri, Jul 17, 2020 at 02:34:55PM +, 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 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 10:10, Jan Beulich wrote:
> On 16.07.2020 19:10, Rahul
On Fri, Jul 17, 2020 at 01:22:19PM +, Bertrand Marquis wrote:
>
>
> > On 17 Jul 2020, at 13:16, Roger Pau Monné wrote:
> >
> > I've wrapped the email to 80 columns in order to make it easier to
> > reply.
> >
> > Thanks for doing this, I think the design is good, I have some
> > questions
On 17.07.2020 16:12, Julien Grall wrote:
> On 17/07/2020 14:59, Jan Beulich wrote:
>> Personally I'd much
>> prefer if we didn't have two fundamentally different PCI implementations
>> in the tree. Perhaps some of what Arm wants or needs can actually
>> benefit x86 as well, but this requires
Hi,
On 15/07/2020 13:28, Jan Beulich wrote:
May I ask that you drop the if() around this block of code?
Also, looking at this, I wonder whether it's a good idea to use the
"start extent" model here anyway: You could as well update the
struct (saying that it may be clobbered in the public
Hi,
On 17/07/2020 14:59, Jan Beulich wrote:
On 17.07.2020 15:50, Julien Grall wrote:
(Resending to the correct ML)
On 17/07/2020 14:23, Julien Grall wrote:
On 16/07/2020 18:02, Rahul Singh wrote:
# Discovering PCI devices:
PCI-PCIe enumeration is a process of detecting devices connected to
Hello all.
We would like to resume Virtio in Xen on Arm activities. You can find some
background at [1] and Virtio specification at [2].
*A few words about importance:*
There is an increasing interest, I would even say, the requirement to have
flexible, generic and standardized cross-hypervisor
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 10:10, Jan Beulich wrote:
On 16.07.2020 19:10, Rahul Singh wrote:
> # Emulated PCI device tree node in libxl:
> On 17 Jul 2020, at 15:49, Julien Grall wrote:
>
>
>
> On 17/07/2020 14:44, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 15:29, Julien Grall wrote:
>>>
>>>
>>>
>>> On 17/07/2020 14:22, Bertrand Marquis wrote:
>> # Emulated PCI device tree node in libxl:
>>
>> Libxl is
> On 17 Jul 2020, at 15:19, Jan Beulich wrote:
>
> On 17.07.2020 15:14, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 10:10, Jan Beulich wrote:
>>> On 16.07.2020 19:10, Rahul Singh wrote:
# Emulated PCI device tree node in libxl:
Libxl is creating a virtual PCI device tree
On 17.07.2020 15:50, Julien Grall wrote:
> (Resending to the correct ML)
> On 17/07/2020 14:23, Julien Grall wrote:
>> On 16/07/2020 18:02, Rahul Singh wrote:
>>> # Discovering PCI devices:
>>>
>>> PCI-PCIe enumeration is a process of detecting devices connected to
>>> its host. It is the
flight 151952 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151952/
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
(Resending to the correct ML)
On 17/07/2020 14:23, Julien Grall wrote:
On 16/07/2020 18:02, Rahul Singh wrote:
Hello All,
Hi,
Following up on discussion on PCI Passthrough support on ARM that we
had at the XEN summit, we are submitting a Review For Comment and a
design proposal for PCI
On 17/07/2020 14:44, Bertrand Marquis wrote:
On 17 Jul 2020, at 15:29, Julien Grall wrote:
On 17/07/2020 14:22, Bertrand Marquis wrote:
# Emulated PCI device tree node in libxl:
Libxl is creating a virtual PCI device tree node in the device tree
to enable the guest OS to discover the
> On 17 Jul 2020, at 15:29, Julien Grall wrote:
>
>
>
> On 17/07/2020 14:22, Bertrand Marquis wrote:
# Emulated PCI device tree node in libxl:
Libxl is creating a virtual PCI device tree node in the device tree
to enable the guest OS to discover the virtual PCI during
On 17/07/2020 14:22, Bertrand Marquis wrote:
# Emulated PCI device tree node in libxl:
Libxl is creating a virtual PCI device tree node in the device tree
to enable the guest OS to discover the virtual PCI during guest
boot. We introduced the new config option [vpci="pci_ecam"] for
guests.
> On 17 Jul 2020, at 9:47 am, Oleksandr Andrushchenko
> wrote:
>
>
> On 7/17/20 11:10 AM, Jan Beulich wrote:
>> On 16.07.2020 19:10, Rahul Singh wrote:
>>> # Discovering PCI devices:
>>>
>>> PCI-PCIe enumeration is a process of detecting devices connected to its
>>> host. It is the
> On 17 Jul 2020, at 13:41, Oleksandr Andrushchenko
> wrote:
>
>
> On 7/17/20 2:26 PM, Julien Grall wrote:
>>
>>
>> On 17/07/2020 08:41, Oleksandr Andrushchenko wrote:
> We need to come up with something similar for dom0less too. It could be
> exactly the same thing (a list of
> On 17 Jul 2020, at 13:16, Roger Pau Monné wrote:
>
> I've wrapped the email to 80 columns in order to make it easier to
> reply.
>
> Thanks for doing this, I think the design is good, I have some
> questions below so that I understand the full picture.
>
> On Thu, Jul 16, 2020 at
On 17.07.2020 15:14, Bertrand Marquis wrote:
>> On 17 Jul 2020, at 10:10, Jan Beulich wrote:
>> On 16.07.2020 19:10, Rahul Singh wrote:
>>> # Emulated PCI device tree node in libxl:
>>>
>>> Libxl is creating a virtual PCI device tree node in the device tree to
>>> enable the guest OS to discover
> On 17 Jul 2020, at 10:10, Jan Beulich wrote:
>
> On 16.07.2020 19:10, Rahul Singh wrote:
>> # Discovering PCI devices:
>>
>> PCI-PCIe enumeration is a process of detecting devices connected to its
>> host. It is the responsibility of the hardware domain or boot firmware to do
>> the PCI
Hi,
I will reply for Rahul until he gets his mail client fixed.
> On 17 Jul 2020, at 09:41, Oleksandr Andrushchenko
> wrote:
>
>
> On 7/17/20 9:53 AM, Bertrand Marquis wrote:
>>
>>> On 16 Jul 2020, at 22:51, Stefano Stabellini wrote:
>>>
>>> On Thu, 16 Jul 2020, Rahul Singh 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 none ought to exist), also extend
guest_io_{read,write}() to decompose
On 17.07.2020 14:46, Rahul Singh wrote:
> Sorry for previous mail formatting issue. Replying again so that any comment
> history should not missed.
I'm sorry, but from a plain text view I cannot determine what parts
your replies were (in fact all nesting of prior replies is lost).
Please can you
On 7/17/20 2:26 PM, Julien Grall wrote:
>
>
> On 17/07/2020 08:41, Oleksandr Andrushchenko wrote:
We need to come up with something similar for dom0less too. It could be
exactly the same thing (a list of BDFs as strings as a device tree
property) or something else if we can come up
On 17/07/2020 08:41, Oleksandr Andrushchenko wrote:
We need to come up with something similar for dom0less too. It could be
exactly the same thing (a list of BDFs as strings as a device tree
property) or something else if we can come up with a better idea.
Fully agree.
Maybe a tree topology
I've wrapped the email to 80 columns in order to make it easier to
reply.
Thanks for doing this, I think the design is good, I have some
questions below so that I understand the full picture.
On Thu, Jul 16, 2020 at 05:10:05PM +, Rahul Singh wrote:
> Hello All,
>
> Following up on
On 17.07.2020 11:22, Julien Grall wrote:
>
>
> On 17/07/2020 09:16, Jan Beulich wrote:
>> On 16.07.2020 18:17, Julien Grall wrote:
>>> On Thu, 16 Jul 2020, 17:01 Jan Beulich, wrote:
>>>
On 16.07.2020 16:42, Roger Pau Monné wrote:
> On Thu, Jul 16, 2020 at 01:48:51PM +0200, Jan Beulich
On 17/07/2020, 8:42 am, "Oleksandr Andrushchenko"
wrote:
On 7/17/20 9:53 AM, Bertrand Marquis wrote:
>
>> On 16 Jul 2020, at 22:51, Stefano Stabellini
wrote:
>>
>> On Thu, 16 Jul 2020, Rahul Singh wrote:
>>> Hello All,
>>>
>>> Following up on discussion on PCI
On 16.07.2020 16:31, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 11:47:56AM +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.
>
> I think you are
Roger Pau Monne writes ("[osstest PATCH] Revert "make-flight: Temporarily
disable flaky test""):
> This reverts commit c436ff754810c15e4d2a434257d1d07498883acb.
>
> Now that XSA-321 has been released we can try to enable PVH dom0
> tests again.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Ian
On 17/07/2020 09:16, Jan Beulich wrote:
On 16.07.2020 18:17, Julien Grall wrote:
On Thu, 16 Jul 2020, 17:01 Jan Beulich, wrote:
On 16.07.2020 16:42, Roger Pau Monné wrote:
On Thu, Jul 16, 2020 at 01:48:51PM +0200, Jan Beulich wrote:
On 16.07.2020 13:41, Roger Pau Monné wrote:
On Wed,
On 7/17/20 11:10 AM, Jan Beulich wrote:
On 16.07.2020 19:10, Rahul Singh wrote:
# Discovering PCI devices:
PCI-PCIe enumeration is a process of detecting devices connected to its host.
It is the responsibility of the hardware domain or boot firmware to do the PCI
enumeration and configure
flight 151944 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151944/
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
build-i386-pvops
On 16.07.2020 18:17, Julien Grall wrote:
> On Thu, 16 Jul 2020, 17:01 Jan Beulich, wrote:
>
>> On 16.07.2020 16:42, Roger Pau Monné wrote:
>>> On Thu, Jul 16, 2020 at 01:48:51PM +0200, Jan Beulich wrote:
On 16.07.2020 13:41, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 12:15:10PM
On 16.07.2020 19:10, Rahul Singh wrote:
> # Discovering PCI devices:
>
> PCI-PCIe enumeration is a process of detecting devices connected to its host.
> It is the responsibility of the hardware domain or boot firmware to do the
> PCI enumeration and configure the BAR, PCI capabilities, and
flight 151956 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151956/
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
Hello,
Will a CVE be assigned to this flaw?
Thanks,
On Thu, Jul 16, 2020 at 3:21 PM Xen.org security team
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Xen Security Advisory XSA-329
> version 2
>
> Linux ioperm
> -Original Message-
> From: Brian Marcotte
> Sent: 16 July 2020 21:24
> To: Paul Durrant
> Cc: p...@xen.org; 'Jules' ; xen-devel@lists.xenproject.org;
> oleksandr_gryt...@epam.com; w...@xen.org
> Subject: Re: [EXTERNAL] [Xen-devel] XEN Qdisk Ceph rbd support broken?
>
> > Your issue
On 7/17/20 9:53 AM, Bertrand Marquis wrote:
>
>> On 16 Jul 2020, at 22:51, Stefano Stabellini wrote:
>>
>> On Thu, 16 Jul 2020, Rahul Singh wrote:
>>> Hello All,
>>>
>>> Following up on discussion on PCI Passthrough support on ARM that we had at
>>> the XEN summit, we are submitting a Review
> On 16 Jul 2020, at 22:51, Stefano Stabellini wrote:
>
> On Thu, 16 Jul 2020, Rahul Singh wrote:
>> Hello All,
>>
>> Following up on discussion on PCI Passthrough support on ARM that we had at
>> the XEN summit, we are submitting a Review For Comment and a design proposal
>> for PCI
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm
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
flight 151947 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151947/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151387
test-amd64-amd64-xl-qemuu-win7-amd64 17
68 matches
Mail list logo
