> On 10 Jul 2020, at 05:26, Manikandan Chockalingam (RBEI/ECF3)
> wrote:
>
> Hello Bertrand,
>
> I couldn't find dunfell branch in the following repos
> 1. meta-selinux
> 2. xen-troops
> 3. meta-renesas [I took dunfell-dev]
Those are not layers i am using.
Not having a dunfell branch could m
For support of long running hypercalls xen_maybe_preempt_hcall() is
calling cond_resched() in case a hypercall marked as preemptible has
been interrupted.
Normally this is no problem, as only hypercalls done via some ioctl()s
are marked to be preemptible. In rare cases when during such a
preemptib
Hello Bertrand,
I couldn't find dunfell branch in the following repos
1. meta-selinux
2. xen-troops
3. meta-renesas [I took dunfell-dev]
Mit freundlichen Grüßen / Best regards
Chockalingam Manikandan
ES-CM Core fn,ADIT (RBEI/ECF3)
Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMA
On 10.07.2020 09:50, Juergen Gross wrote:
> For support of long running hypercalls xen_maybe_preempt_hcall() is
> calling cond_resched() in case a hypercall marked as preemptible has
> been interrupted.
>
> Normally this is no problem, as only hypercalls done via some ioctl()s
> are marked to be p
[ added EFI Maintainer & ML to Cc: ]
Hi,
On 7/9/20 11:17 AM, Jürgen Groß wrote:
> On 28.06.20 10:50, Jürgen Groß wrote:
>> Ping?
>>
>> On 10.06.20 16:10, Juergen Gross wrote:
>>> efifb_probe() will issue an error message in case the kernel is booted
>>> as Xen dom0 from UEFI as EFI_MEMMAP won't
On 10.07.20 11:49, Jan Beulich wrote:
On 10.07.2020 09:50, Juergen Gross wrote:
For support of long running hypercalls xen_maybe_preempt_hcall() is
calling cond_resched() in case a hypercall marked as preemptible has
been interrupted.
Normally this is no problem, as only hypercalls done via som
On 10/07/2020 08:53, Wieczorkiewicz, Pawel wrote:
>> On 9. Jul 2020, at 20:46, Julien Grall wrote:
>>
>> XenStore response can be bigger than the response ring. In this case,
>> it is possible to have the ring full (e.g cons = 19 and prod = 1043).
>>
>> However, XTF will consider that there is no
flight 151777 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151777/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151496
test-armhf-armhf-libvirt-raw 13 saveresto
When there is an error the caller frees "info->node" so the free here
will result in a double free. We should just delete first kfree().
Fixes: 3848e4e0a32a ("xen/xenbus: avoid large structs and arrays on the stack")
Signed-off-by: Dan Carpenter
---
drivers/xen/xenbus/xenbus_client.c | 4 +---
> On 9. Jul 2020, at 20:46, Julien Grall wrote:
>
>
> From: Julien Grall
>
> XenStore response can be bigger than the response ring. In this case,
> it is possible to have the ring full (e.g cons = 19 and prod = 1043).
>
> However, XTF will consider that there is no data and therefore wait
On 10.07.2020 12:50, Jürgen Groß wrote:
> On 10.07.20 11:49, Jan Beulich wrote:
>> On 10.07.2020 09:50, Juergen Gross wrote:
>>> For support of long running hypercalls xen_maybe_preempt_hcall() is
>>> calling cond_resched() in case a hypercall marked as preemptible has
>>> been interrupted.
>>>
>>>
On 10.07.20 13:55, Jan Beulich wrote:
On 10.07.2020 12:50, Jürgen Groß wrote:
On 10.07.20 11:49, Jan Beulich wrote:
On 10.07.2020 09:50, Juergen Gross wrote:
For support of long running hypercalls xen_maybe_preempt_hcall() is
calling cond_resched() in case a hypercall marked as preemptible has
On 09.07.20 11:22, Jan Beulich wrote:
On 09.07.2020 07:56, Jürgen Groß wrote:
Yesterday's design session at Xen Developer Summit "Hypervisor Team: .."
had one topic regarding whether we should find specific maintainers of
all the files currently assigned to "THE REST" in order to lower the
amoun
On 10.07.20 13:36, Dan Carpenter wrote:
When there is an error the caller frees "info->node" so the free here
will result in a double free. We should just delete first kfree().
Fixes: 3848e4e0a32a ("xen/xenbus: avoid large structs and arrays on the stack")
Signed-off-by: Dan Carpenter
Thanks
flight 151774 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151774/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass
in 151759
Tests which did not suc
From: Paul Durrant
The generic pc_machine_initfn() calls pc_system_flash_create() which creates
'system.flash0' and 'system.flash1' devices. These devices are then realized
by pc_system_flash_map() which is called from pc_system_firmware_init() which
itself is called via pc_memory_init(). The lat
erard/qemu-dm.git
tags/pull-xen-20200710
for you to fetch changes up to dd29b5c30cd2a13f8c12376a8de84cb090c338bf:
xen: cleanup unrealized flash devices (2020-07-10 13:49:16 +0100)
xen patches
Fixes following harden chec
From: Jason Andryuk
xen-sysdev is a TYPE_SYS_BUS_DEVICE. bus_type should not be changed so
that it can plug into the System bus. Otherwise this assert triggers:
qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion
`dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)'
On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
wrote:
>
>
> [ added EFI Maintainer & ML to Cc: ]
>
> Hi,
>
> On 7/9/20 11:17 AM, Jürgen Groß wrote:
> > On 28.06.20 10:50, Jürgen Groß wrote:
> >> Ping?
> >>
> >> On 10.06.20 16:10, Juergen Gross wrote:
> >>> efifb_probe() will issue an erro
On 10.07.20 15:27, Ard Biesheuvel wrote:
On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
wrote:
[ added EFI Maintainer & ML to Cc: ]
Hi,
On 7/9/20 11:17 AM, Jürgen Groß wrote:
On 28.06.20 10:50, Jürgen Groß wrote:
Ping?
On 10.06.20 16:10, Juergen Gross wrote:
efifb_probe() will
On Fri, 10 Jul 2020 at 16:38, Jürgen Groß wrote:
>
> On 10.07.20 15:27, Ard Biesheuvel wrote:
> > On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
> > wrote:
> >>
> >>
> >> [ added EFI Maintainer & ML to Cc: ]
> >>
> >> Hi,
> >>
> >> On 7/9/20 11:17 AM, Jürgen Groß wrote:
> >>> On 28.06.20
efifb_probe() will issue an error message in case the kernel is booted
as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set.
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when
mapping th
On Fri, 10 Jul 2020 at 17:24, Juergen Gross wrote:
>
> efifb_probe() will issue an error message in case the kernel is booted
> as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
> that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set.
>
> Fixes: 38ac0287b7f4 ("
flight 151789 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151789/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf f645a19115e666ce6401ca63b7d7388571463b55
baseline version:
xtf 2dd14fbcf9d03fdc300491
On 7/10/20 8:15 AM, Jürgen Groß wrote:
> On 10.07.20 13:36, Dan Carpenter wrote:
>> When there is an error the caller frees "info->node" so the free here
>> will result in a double free. We should just delete first kfree().
>>
>> Fixes: 3848e4e0a32a ("xen/xenbus: avoid large structs and arrays on
Sorry for the late reply -- a couple of conferences kept me busy.
On Wed, 1 Jul 2020, Michael S. Tsirkin wrote:
> On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> > Would you be in favor of a more flexible check along the lines of the
> > one proposed in the patch that starte
Gentle ping on this series.
--
Anchal
Hello,
This series fixes PM hibernation for hvm guests running on xen hypervisor.
The running guest could now be hibernated and resumed successfully at a
later time. The fixes for PM hibernation are added to block and
network device driv
flight 151778 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151778/
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 151780 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151780/
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 151802 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151802/
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
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve c
Hi all,
This series is a collection of fixes to get Linux running on the RPi4 as
dom0. Conceptually there are only two significant changes:
- make sure not to call virt_to_page on vmalloc virt addresses (patch
#1)
- use phys_to_dma and dma_to_phys to translate phys to/from dma
addresses (all
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve c
From: Stefano Stabellini
xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
getting called passing dma addresses. On some platforms dma addresses
could be different from physical addresses. Before doing any operations
on these addresses we need to convert them back to physic
From: Stefano Stabellini
XEN_PFN_PHYS is only used in one place in swiotlb-xen making things more
complex than need to be.
Remove the definition of XEN_PFN_PHYS and open code the cast in the one
place where it is needed.
Signed-off-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 7 +---
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve c
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve c
From: Stefano Stabellini
dma_cache_maint is getting called passing a dma address which could be
different from a physical address.
Add a struct device* parameter to dma_cache_maint.
Translate the dma_addr_t parameter of dma_cache_maint by calling
dma_to_phys. Do it for the first page and all th
From: Stefano Stabellini
No functional changes. The parameter is unused in this patch but will be
used by next patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Tested-by: Corey Minyard
Tested-by: Roman Shaposhnik
---
Changes in v3:
- add whitespace in title
- improve c
From: Stefano Stabellini
It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr around with the
next patches.
Note that virt_to_phys is not the same as xen_virt_to_bus but actually
it is used to compared again __pa(xen_io_tlb_star
From: Stefano Stabellini
With some devices physical addresses are different than dma addresses.
To be able to deal with these cases, we need to call phys_to_dma on
physical addresses (including machine addresses in Xen terminology)
before returning them from xen_swiotlb_alloc_coherent and
xen_swi
From: Boris Ostrovsky
xen_alloc_coherent_pages might return pages for which virt_to_phys and
virt_to_page don't work, e.g. ioremap'ed pages.
So in xen_swiotlb_free_coherent we can't assume that virt_to_page works.
Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc
virt addres
flight 151808 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151808/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 151214
test-arm64-arm64-li
flight 151804 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151804/
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 151812 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151812/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f7f1b33282b7dc52a0c77860d3f4523b231a750f
baseline version:
ovmf bdafda8c457eb90c65f37
45 matches
Mail list logo
