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 For
> -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 ste
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 bit
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
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 MSI/M
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 +02
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 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 t
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, Ju
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 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 miss
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 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 w
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 discussion
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 c
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 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
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 a
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:
Hel
> 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 en
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 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 05:10:05PM
> 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 BDFs
> 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 responsi
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. Wh
> 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 gu
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
(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 p
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
test-amd64-amd
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 responsi
> 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 no
> 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 cre
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:
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 s
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
i
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 header
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 suffic
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 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 S
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 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: Jan
> 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, w
> 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 wrote
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 havin
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,
> 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 doing
> 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/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 passt
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, 2
> 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 devi
> 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 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 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 dependin
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, 2
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,
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 bug.
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 d9269d69138860edb1ec9
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
test-amd64-amd64-xl-qemuu-win7-amd64
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 also
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 1
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 1
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 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 21a23e6966c2eb597a8db
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
cross-co
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 bu
65 matches
Mail list logo
