flight 167525 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
The backport of commit 8f5a695d99000fc ("xen/blkfront: don't take local
copy of a request from the ring page") to stable 4.4 kernel introduced
a bug when adding the needed blkif_ring_get_request() function, as
info->ring.req_prod_pvt was incremented twice now.
Fix that be deleting the now superflu
On Thu, Dec 23, 2021 at 11:53:08AM +0100, Juergen Gross wrote:
> The backport of commit 8f5a695d99000fc ("xen/blkfront: don't take local
> copy of a request from the ring page") to stable 4.4 kernel introduced
> a bug when adding the needed blkif_ring_get_request() function, as
> info->ring.req_pro
flight 167523 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167523/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail in 167510 pass in
167523
test-amd64-amd64-dom0pvh-x
flight 167527 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167527/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 15c596aeebc24bb97deb78d98bd8517a8b9ac243
baseline version:
ovmf ae8272ef787d80950803c
On 23.12.21 11:57, Greg KH wrote:
On Thu, Dec 23, 2021 at 11:53:08AM +0100, Juergen Gross wrote:
The backport of commit 8f5a695d99000fc ("xen/blkfront: don't take local
copy of a request from the ring page") to stable 4.4 kernel introduced
a bug when adding the needed blkif_ring_get_request() fu
flight 167524 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167524/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167519
test-armhf-armhf-libvirt 16 sav
flight 167526 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167526/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167520
test-amd64-amd64-qemuu-nested-amd 20
On Wed, Dec 22, 2021 at 3:13 AM Roger Pau Monné wrote:
> Could you build a debug kernel with the following patch applied and
> give me the trace when it explodes?
Please find the trace and the kernel CL below.
Note, the domU get stuck into a bootloop with this assertion as the
situation will com
The first thing XEN_SYSCTL_physinfo does is zero op->u.physinfo.
Do not copy-in. It's pointless, and most callers don't initialise their
xc_physinfo_t buffer to begin with. Remove the pointless zeroing from the
remaining callers.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
---
CC: Antho
Hi Stefano, Oleksii,
Stefano Stabellini writes:
> On Wed, 22 Dec 2021, Oleksii Moisieiev wrote:
>> On Tue, Dec 21, 2021 at 01:22:50PM -0800, Stefano Stabellini wrote:
>> > On Tue, 21 Dec 2021, Oleksii Moisieiev wrote:
>> > > Hi Stefano,
>> > >
>> > > On Mon, Dec 20, 2021 at 04:52:01PM -0800,
On Wed, 22 Dec 2021, Stefano Stabellini wrote:
> # Future Ideas
>
> A great suggestion by Julien is to start supporting the dom0less partial
> device tree format in xl/libxl as well so that we can have a single
> "device_tree" option in dom.cfg instead of 4 (device_tree, iomem, irqs,
> dtdev).
>
Hi Stefano,
On Wed, Dec 22, 2021 at 06:23:24PM -0800, Stefano Stabellini wrote:
> On Wed, 22 Dec 2021, Oleksii Moisieiev wrote:
> > On Tue, Dec 21, 2021 at 01:22:50PM -0800, Stefano Stabellini wrote:
> > > On Tue, 21 Dec 2021, Oleksii Moisieiev wrote:
> > > > Hi Stefano,
> > > >
> > > > On Mon, D
Hi Stefano,
On Wed, Dec 22, 2021 at 06:23:13PM -0800, Stefano Stabellini wrote:
> On Wed, 22 Dec 2021, Julien Grall wrote:
> > > > > > > To me dtdev and XEN_DOMCTL_assign_device are appropriate because
> > > > > > > they
> > > > > > > signify device assignment of one or more devices. We are not
>
Hi Stefano,
On Wed, Dec 22, 2021 at 06:23:33PM -0800, Stefano Stabellini wrote:
> On Wed, 22 Dec 2021, Oleksii Moisieiev wrote:
> > On Mon, Dec 20, 2021 at 04:54:25PM -0800, Stefano Stabellini wrote:
> > > On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> > > > This enumeration sets SCI type for the
On Wed, 22 Dec 2021, Julien Grall wrote:
> Hello,
>
> On 22/12/2021 09:38, Dongjiu Geng wrote:
> > when enable CONFIG_NEW_VGIC in ARM64 QEMU Platform, it will build failed.
> > so fix it and make it can select GICV2.
>
> Last time I checked QEMU, it was only able to support GICv3 virtualization.
On Thu, 23 Dec 2021, Oleksii Moisieiev wrote:
> On Wed, Dec 22, 2021 at 06:23:24PM -0800, Stefano Stabellini wrote:
> > On Wed, 22 Dec 2021, Oleksii Moisieiev wrote:
> > > On Tue, Dec 21, 2021 at 01:22:50PM -0800, Stefano Stabellini wrote:
> > > > On Tue, 21 Dec 2021, Oleksii Moisieiev wrote:
> > >
On Wed, 22 Dec 2021, Julien Grall wrote:
> Hi,
>
> On 09/11/2021 08:02, Vikram Garhwal wrote:
> > Introduce sysctl XEN_SYSCTL_overlay to remove device-tree nodes added using
>
> I agree with Jan about the name being too generic. I will comment on this a
> bit further down.
>
> > device tree over
flight 167529 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167529/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167526
test-amd64-amd64-qemuu-nested-amd 20
On Wed, 22 Dec 2021, Sergiy Kibrik wrote:
> Currently no IOMMU properties are exposed to dom0, thus kernel by default
> assumes no protection and enables swiotlb-xen, which leads to costly and
> unnecessary buffers bouncing.
>
> To let kernel know which device is behing IOMMU and hence needs no sw
On Wed, 22 Dec 2021, Sergiy Kibrik wrote:
> Only Xen is able to know if a device can safely avoid to use xen-swiotlb.
> However since Xen links FDT nodes of protected devices to special dummy
> xen-iommu node we can use that information to decide whether
> xen-swiotlb is needed.
>
> Signed-off-by:
flight 167530 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167530/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167524
test-armhf-armhf-libvirt 16 sav
> From: Jan Beulich
> Sent: Thursday, December 2, 2021 5:19 PM
>
> On 01.12.2021 15:39, Andrew Cooper wrote:
> > On 01/12/2021 09:40, Jan Beulich wrote:
> >> The actual function should always have lived in core x86 code; move it
> >> there, replacing get_cache_line_size() by readily available (ex
> From: Jan Beulich
> Sent: Thursday, December 2, 2021 4:48 PM
>
> On 01.12.2021 14:02, Andrew Cooper wrote:
> > On 01/12/2021 09:41, Jan Beulich wrote:
> >> --- a/xen/drivers/passthrough/vtd/iommu.c
> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
> >> @@ -591,7 +591,8 @@ static int __must_check i
> From: Jan Beulich
> Sent: Friday, December 3, 2021 6:41 PM
>
> When an IOMMU implements the full 16 bits worth of DID in context
> entries, there's no point going through a memory base translation table.
> For IOMMUs not using Caching Mode we can simply use the domain IDs
> verbatim, while for
> From: Jan Beulich
> Sent: Thursday, December 9, 2021 11:52 PM
>
> While putting together patch 1, I've noticed two further aspects to
> clean up a little.
>
> 1: properly parenthesize a number of macros
> 2: use DMA_TLB_IVA_ADDR()
> 3: shorten vtd_flush_{context,iotlb}_reg()
>
Reviewed-by: K
> From: Jan Beulich
> Sent: Wednesday, December 1, 2021 12:11 AM
>
> ept_free_entry() gets called after a flush - if one is necessary in the
> first place - was already issued. That behavior is similar to NPT, which
> also doesn't have any further flush in p2m_free_entry(). (Furthermore,
> the fu
27 matches
Mail list logo
