[qemu-mainline test] 180621: regressions - trouble: blocked/broken/fail/pass

flight 180621 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/180621/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-arm64-xsm 6

RE: [PATCH v2 2/2] xen/arm: domain_build: Fix format specifiers in map_{dt_}irq_to_domain()

Hi Michal, > -Original Message- > Subject: [PATCH v2 2/2] xen/arm: domain_build: Fix format specifiers in > map_{dt_}irq_to_domain() > > IRQ is of unsigned type so %u should be used. When printing domain id, > %pd should be the correct format to maintain the consistency. > > Also,

RE: [PATCH v2 1/2] xen/arm: domain_build: Propagate return code of map_irq_to_domain()

Hi Michal, > -Original Message- > Subject: [PATCH v2 1/2] xen/arm: domain_build: Propagate return code of > map_irq_to_domain() > > From map_dt_irq_to_domain() we are assigning a return code of > map_irq_to_domain() to a variable without checking it for an error. > Fix it by propagating

Re: [PATCH v3 04/14 RESEND] cpufreq: Add Hardware P-State (HWP) driver

On Wed, May 10, 2023 at 04:19:57PM +0200, Jan Beulich wrote: > On 10.05.2023 15:54, Jason Andryuk wrote: > > On Mon, May 8, 2023 at 2:33 AM Jan Beulich wrote: > >> On 05.05.2023 17:35, Jason Andryuk wrote: > >>> On Fri, May 5, 2023 at 3:01 AM Jan Beulich wrote: > >>> The other issue is that if

[PATCH] docs/misra: adds Mandatory rules

From: Stefano Stabellini Add the Mandatory rules agreed by the MISRA C working group to docs/misra/rules.rst. Signed-off-by: Stefano Stabellini --- docs/misra/rules.rst | 62 1 file changed, 62 insertions(+) diff --git a/docs/misra/rules.rst

[xen-unstable test] 180618: regressions - trouble: blocked/broken/fail/pass/starved

flight 180618 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/180618/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 5

[linux-linus test] 180614: regressions - trouble: broken/fail/pass

flight 180614 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/180614/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 broken test-armhf-armhf-libvirt-qcow2 5

Re: [PATCH v4 20/20] aio: remove aio_disable_external() API

On Thu, May 04, 2023 at 11:34:17PM +0200, Kevin Wolf wrote: > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben: > > All callers now pass is_external=false to aio_set_fd_handler() and > > aio_set_event_notifier(). The aio_disable_external() API that > > temporarily disables fd handlers that

Re: [PATCH v4 17/20] virtio-blk: implement BlockDevOps->drained_begin()

On Thu, May 04, 2023 at 11:13:42PM +0200, Kevin Wolf wrote: > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben: > > Detach ioeventfds during drained sections to stop I/O submission from > > the guest. virtio-blk is no longer reliant on aio_disable_external() > > after this patch. This will

Re: [PATCH v4 17/20] virtio-blk: implement BlockDevOps->drained_begin()

On Thu, May 04, 2023 at 11:13:42PM +0200, Kevin Wolf wrote: > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben: > > Detach ioeventfds during drained sections to stop I/O submission from > > the guest. virtio-blk is no longer reliant on aio_disable_external() > > after this patch. This will

Re: [PATCH v3 07/14 RESEND] cpufreq: Export HWP parameters to userspace

On Thu, May 11, 2023 at 10:10 AM Jan Beulich wrote: > > On 11.05.2023 15:49, Jason Andryuk wrote: > > On Thu, May 11, 2023 at 2:21 AM Jan Beulich wrote: > >> > >> On 10.05.2023 19:49, Jason Andryuk wrote: > >>> On Mon, May 8, 2023 at 6:26 AM Jan Beulich wrote: > > On 01.05.2023 21:30,

Re: [PATCH v4 16/20] virtio: make it possible to detach host notifier from any thread

On Thu, May 04, 2023 at 11:00:35PM +0200, Kevin Wolf wrote: > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben: > > virtio_queue_aio_detach_host_notifier() does two things: > > 1. It removes the fd handler from the event loop. > > 2. It processes the virtqueue one last time. > > > > The

[xen-unstable-smoke test] 180622: tolerable all pass - PUSHED

flight 180622 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/180622/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

[PATCH v2 5/8] pci/arm: Use iommu_add_dt_pci_device()

From: Oleksandr Tyshchenko On Arm we need to parse DT PCI-IOMMU specifier and provide it to the driver (for describing the relationship between PCI devices and IOMMUs) before adding a device to it. Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Stewart Hildebrand --- v1->v2: * new patch

[PATCH v2 8/8] xen/arm: smmuv3: Add PCI devices support for SMMUv3

From: Rahul Singh Signed-off-by: Rahul Singh Signed-off-by: Stewart Hildebrand --- v1->v2: * ignore add_device/assign_device/reassign_device calls for phantom functions (i.e. devfn != pdev->devfn) downstream->v1: * rebase * move 2 replacements of

[PATCH v2 7/8] xen/arm: smmuv2: Add PCI devices support for SMMUv2

From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Stewart Hildebrand --- v1->v2: * ignore add_device/assign_device/reassign_device calls for phantom functions (i.e. devfn != pdev->devfn) downstream->v1: * wrap unused

[RFC PATCH v2 6/8] pci/arm: don't do iommu call for phantom functions

It's not necessary to add/remove/assign/deassign pci phantom functions for the ARM SMMU drivers. All associated AXI stream IDs are added during the iommu call for the base PCI device/function. However, the ARM SMMU drivers can cope with the extra/unnecessary calls just fine, so this patch is RFC

[PATCH v2 4/8] iommu/arm: iommu_add_dt_pci_device phantom handling

Handle phantom functions in iommu_add_dt_pci_device(). Each phantom function will have a unique requestor ID (RID)/BDF. On ARM, we need to map/translate the RID/BDF to an AXI stream ID for each phantom function according to the pci-iommu device tree mapping [1]. The RID/BDF -> AXI stream ID

[PATCH v2 3/8] iommu/arm: Introduce iommu_add_dt_pci_device API

From: Oleksandr Tyshchenko The main purpose of this patch is to add a way to register PCI device (which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1] before assigning that device to a domain. This behaves in almost the same way as existing iommu_add_dt_device API, the

[PATCH v2 2/8] iommu/arm: Add iommu_dt_xlate()

From: Oleksandr Tyshchenko Move code for processing DT IOMMU specifier to a separate helper. This helper will be re-used for adding PCI devices by the subsequent patches as we will need exact the same actions for processing DT PCI-IOMMU specifier. While at it introduce NO_IOMMU to avoid magic

[PATCH v2 1/8] xen/arm: Move is_protected flag to struct device

From: Oleksandr Tyshchenko This flag will be re-used for PCI devices by the subsequent patches. Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Stewart Hildebrand --- v1->v2: * no change downstream->v1: * rebase * s/dev_node->is_protected/dev_node->dev.is_protected/ in smmu.c *

[PATCH v2 0/8] SMMU handling for PCIe Passthrough on ARM

This series introduces SMMU handling for PCIe passthrough on ARM. These patches are independent from (and don't depend on) the vPCI reference counting/locking work in progress, and should be able to be upstreamed independently. v1-v2: * phantom device handling * shuffle around

[libvirt test] 180613: tolerable FAIL - PUSHED

flight 180613 libvirt real [real] flight 180623 libvirt real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/180613/ http://logs.test-lab.xenproject.org/osstest/logs/180623/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [PATCH] x86/vPIT: check/bound values loaded from state save record

On Thu, May 11, 2023 at 7:50 AM Jan Beulich wrote: > > In particular pit_latch_status() and speaker_ioport_read() perform > calculations which assume in-bounds values. Several of the state save > record fields can hold wider ranges, though. > > Note that ->gate should only be possible to be zero

[PATCH v7 0/5] enable MMU for RISC-V

The patch series introduces the following things: 1. Functionality to build the page tables for Xen that map link-time to physical-time location. 2. Check that Xen is less then page size. 3. Check that load addresses don't overlap with linker addresses. 4. Prepare things for proper switch to

[PATCH v7 4/5] xen/riscv: setup initial pagetables

The patch does two thing: 1. Setup initial pagetables. 2. Enable MMU which end up with code in cont_after_mmu_is_enabled() Signed-off-by: Oleksii Kurochko --- Changes in V7: - Nothing changed. Only rebase --- Changes in V6: - Nothing changed. Only rebase --- Changes in V5: - Nothing

[PATCH v7 3/5] xen/riscv: align __bss_start

bss clear cycle requires proper alignment of __bss_start. Signed-off-by: Oleksii Kurochko --- Changes in V7: * the patch was introduced in the current patch series. --- xen/arch/riscv/xen.lds.S | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/riscv/xen.lds.S

[PATCH v7 2/5] xen/riscv: introduce setup_initial_pages

The idea was taken from xvisor but the following changes were done: * Use only a minimal part of the code enough to enable MMU * rename {_}setup_initial_pagetables functions * add an argument for setup_initial_mapping to have an opportunity to make set PTE flags. * update

[PATCH v7 1/5] xen/riscv: add VM space layout

Also it was added explanation about ignoring of top VA bits Signed-off-by: Oleksii Kurochko --- Changes in V7: - Fix range of frametable range in RV64 layout. - Add ifdef SV39 to the RV64 layout comment to make it explicit that description if for SV39 mode. - Add missed row in the RV64

[PATCH v7 5/5] xen/riscv: remove dummy_bss variable

After introduction of initial pagetables there is no any sense in dummy_bss variable as bss section will not be empty anymore. Signed-off-by: Oleksii Kurochko --- Changes in V6: - Nothing changed. Only rebase --- Changes in V5: - Nothing changed. Only rebase --- Changes in V4: - Nothing

Re: [PATCH v6 00/16] x86/mtrr: fix handling with PAT but without MTRR

On Wed, May 10, 2023 at 05:53:15PM +0200, Juergen Gross wrote: > Urgh, yes, there is something missing: > > diff --git a/arch/x86/kernel/cpu/mtrr/generic.c > b/arch/x86/kernel/cpu/mtrr/generic.c > index 031f7ea8e72b..9544e7d13bb3 100644 > --- a/arch/x86/kernel/cpu/mtrr/generic.c > +++

Re: [PATCH v2 0/2] Add API for making parts of a MMIO page R/O and use it in XHCI console

On Thu, May 11, 2023 at 11:27:02AM -0400, Jason Andryuk wrote: > On Thu, May 11, 2023 at 11:22 AM Marek Marczykowski-Górecki > wrote: > > > > On Thu, May 11, 2023 at 10:58:48AM -0400, Jason Andryuk wrote: > > > On Fri, May 5, 2023 at 5:26 PM Marek Marczykowski-Górecki > > > wrote: > > > > > > >

Re: [PATCH v2 0/2] Add API for making parts of a MMIO page R/O and use it in XHCI console

On Thu, May 11, 2023 at 11:22 AM Marek Marczykowski-Górecki wrote: > > On Thu, May 11, 2023 at 10:58:48AM -0400, Jason Andryuk wrote: > > On Fri, May 5, 2023 at 5:26 PM Marek Marczykowski-Górecki > > wrote: > > > > > > On older systems, XHCI xcap had a layout that no other (interesting) > > >

Re: [PATCH v2 0/2] Add API for making parts of a MMIO page R/O and use it in XHCI console

On Thu, May 11, 2023 at 10:58:48AM -0400, Jason Andryuk wrote: > On Fri, May 5, 2023 at 5:26 PM Marek Marczykowski-Górecki > wrote: > > > > On older systems, XHCI xcap had a layout that no other (interesting) > > registers > > were placed on the same page as the debug capability, so Linux was

Re: [PATCH v2 2/2] xen/arm: domain_build: Fix format specifiers in map_{dt_}irq_to_domain()

On 11/05/2023 14:02, Michal Orzel wrote: IRQ is of unsigned type so %u should be used. When printing domain id, %pd should be the correct format to maintain the consistency. Also, wherever possible, reduce the number of splitted lines for printk(). Signed-off-by: Michal Orzel Reviewed-by:

Re: [PATCH v2 1/2] xen/arm: domain_build: Propagate return code of map_irq_to_domain()

On 11/05/2023 14:02, Michal Orzel wrote: From map_dt_irq_to_domain() we are assigning a return code of map_irq_to_domain() to a variable without checking it for an error. Fix it by propagating the return code directly since this is the last call. Fixes: 467e5cbb2ffc ("xen: arm: consolidate

[xen-unstable-smoke test] 180619: regressions - trouble: blocked/broken/pass

flight 180619 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/180619/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 5

Re: [PATCH v2 0/2] Add API for making parts of a MMIO page R/O and use it in XHCI console

On Fri, May 5, 2023 at 5:26 PM Marek Marczykowski-Górecki wrote: > > On older systems, XHCI xcap had a layout that no other (interesting) registers > were placed on the same page as the debug capability, so Linux was fine with > making the whole page R/O. But at least on Tiger Lake and Alder

Re: [PATCH] iommu/amd-vi: fix assert comparing boolean to enum

On 11/05/2023 3:53 pm, Jan Beulich wrote: > On 11.05.2023 16:51, Roger Pau Monne wrote: >> Or else when iommu_intremap is set to iommu_intremap_full the assert >> triggers. >> >> Fixes: 1ba66a870eba ('AMD/IOMMU: without XT, x2APIC needs to be forced into >> physical mode') >> Signed-off-by: Roger

Re: [PATCH] iommu/amd-vi: fix assert comparing boolean to enum

On 11.05.2023 16:51, Roger Pau Monne wrote: > Or else when iommu_intremap is set to iommu_intremap_full the assert > triggers. > > Fixes: 1ba66a870eba ('AMD/IOMMU: without XT, x2APIC needs to be forced into > physical mode') > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich

[PATCH] iommu/amd-vi: fix assert comparing boolean to enum

Or else when iommu_intremap is set to iommu_intremap_full the assert triggers. Fixes: 1ba66a870eba ('AMD/IOMMU: without XT, x2APIC needs to be forced into physical mode') Signed-off-by: Roger Pau Monné --- xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH] SUPPORT.md: explicitly mention EFI (secure) boot status

Hi Jan, On 11/05/2023 15:34, Jan Beulich wrote: While normal booting is properly supported on both x86 and Arm64, secure boot reportedly requires quite a bit more work to be actually usable (and providing the intended guarantees). The mere use of the shim protocol for verifying the Dom0 kernel

Re: [PATCH] 9pfs/xen: Fix segfault on shutdown

On Tuesday, May 2, 2023 4:37:22 PM CEST Jason Andryuk wrote: > xen_9pfs_free can't use gnttabdev since it is already closed and NULL-ed > out when free is called. Do the teardown in _disconnect(). This > matches the setup done in _connect(). > > trace-events are also added for the XenDevOps

Re: [PATCH] SUPPORT.md: explicitly mention EFI (secure) boot status

On 11/05/2023 3:34 pm, Jan Beulich wrote: > While normal booting is properly supported on both x86 and Arm64, secure > boot reportedly requires quite a bit more work to be actually usable > (and providing the intended guarantees). The mere use of the shim > protocol for verifying the Dom0 kernel

[PATCH] SUPPORT.md: explicitly mention EFI (secure) boot status

While normal booting is properly supported on both x86 and Arm64, secure boot reportedly requires quite a bit more work to be actually usable (and providing the intended guarantees). The mere use of the shim protocol for verifying the Dom0 kernel image isn't enough. Signed-off-by: Jan Beulich

[qemu-mainline test] 180610: tolerable FAIL - PUSHED

flight 180610 qemu-mainline real [real] flight 180620 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/180610/ http://logs.test-lab.xenproject.org/osstest/logs/180620/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [PATCH v1 4/6] pci/arm: Use iommu_add_dt_pci_device() instead of arch hook

On 11.05.2023 15:59, Julien Grall wrote: > On 11/05/2023 14:49, Stewart Hildebrand wrote: >> On 5/8/23 10:51, Jan Beulich wrote: >>> On 08.05.2023 16:16, Stewart Hildebrand wrote: On 5/2/23 03:50, Jan Beulich wrote: > On 01.05.2023 22:03, Stewart Hildebrand wrote: >> ---

Re: [PATCH v3 07/14 RESEND] cpufreq: Export HWP parameters to userspace

On 11.05.2023 15:49, Jason Andryuk wrote: > On Thu, May 11, 2023 at 2:21 AM Jan Beulich wrote: >> >> On 10.05.2023 19:49, Jason Andryuk wrote: >>> On Mon, May 8, 2023 at 6:26 AM Jan Beulich wrote: On 01.05.2023 21:30, Jason Andryuk wrote: > Extend xen_get_cpufreq_para to return hwp

Re: [PATCH v1 4/6] pci/arm: Use iommu_add_dt_pci_device() instead of arch hook

Hi, Can you make sure to CC the Arm/SMMU maintainers as I feel it is important for them to also review the generic changes. On 11/05/2023 14:49, Stewart Hildebrand wrote: On 5/8/23 10:51, Jan Beulich wrote: On 08.05.2023 16:16, Stewart Hildebrand wrote: On 5/2/23 03:50, Jan Beulich wrote:

Re: [PATCH v1 4/6] pci/arm: Use iommu_add_dt_pci_device() instead of arch hook

On 5/8/23 10:51, Jan Beulich wrote: > On 08.05.2023 16:16, Stewart Hildebrand wrote: >> On 5/2/23 03:50, Jan Beulich wrote: >>> On 01.05.2023 22:03, Stewart Hildebrand wrote: --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -1305,7 +1305,7 @@

Re: [PATCH v3 07/14 RESEND] cpufreq: Export HWP parameters to userspace

On Thu, May 11, 2023 at 2:21 AM Jan Beulich wrote: > > On 10.05.2023 19:49, Jason Andryuk wrote: > > On Mon, May 8, 2023 at 6:26 AM Jan Beulich wrote: > >> > >> On 01.05.2023 21:30, Jason Andryuk wrote: > >>> Extend xen_get_cpufreq_para to return hwp parameters. These match the > >>> hardware

Re: [PATCH v2 2/2] xen/arm: domain_build: Fix format specifiers in map_{dt_}irq_to_domain()

On 11/05/2023 2:02 pm, Michal Orzel wrote: > IRQ is of unsigned type so %u should be used. When printing domain id, > %pd should be the correct format to maintain the consistency. > > Also, wherever possible, reduce the number of splitted lines for printk(). Very minor grammar note.  Just "split"

[PATCH v2 0/2] xen/arm: domain_build: map_{dt_}irq_to_domain() fixes

Propagate return code correctly + fix the format specifiers. Michal Orzel (2): xen/arm: domain_build: Propagate return code of map_irq_to_domain() xen/arm: domain_build: Fix format specifiers in map_{dt_}irq_to_domain() xen/arch/arm/domain_build.c | 16 ++-- 1 file changed,

[PATCH v2 1/2] xen/arm: domain_build: Propagate return code of map_irq_to_domain()

>From map_dt_irq_to_domain() we are assigning a return code of map_irq_to_domain() to a variable without checking it for an error. Fix it by propagating the return code directly since this is the last call. Fixes: 467e5cbb2ffc ("xen: arm: consolidate mmio and irq mapping to dom0") Signed-off-by:

[PATCH v2 2/2] xen/arm: domain_build: Fix format specifiers in map_{dt_}irq_to_domain()

IRQ is of unsigned type so %u should be used. When printing domain id, %pd should be the correct format to maintain the consistency. Also, wherever possible, reduce the number of splitted lines for printk(). Signed-off-by: Michal Orzel --- Changes in v2: - split the v1 patch so that the format

Re: [PATCH v2 3/3] x86: Add support for CpuidUserDis

On 11.05.2023 14:12, Alejandro Vallejo wrote: > On Thu, May 11, 2023 at 01:05:42PM +0200, Jan Beulich wrote: >>> --- a/xen/arch/x86/cpu/amd.c >>> +++ b/xen/arch/x86/cpu/amd.c >>> @@ -279,8 +279,12 @@ static void __init noinline amd_init_levelling(void) >>> * that can only be present when Xen

Re: [PATCH 1/6] x86/cpu-policy: Drop build time cross-checks of featureset sizes

On 11/05/2023 7:43 am, Jan Beulich wrote: > On 10.05.2023 17:06, Andrew Cooper wrote: >> On 09/05/2023 5:15 pm, Jan Beulich wrote: >>> On 09.05.2023 17:59, Andrew Cooper wrote: On 09/05/2023 3:28 pm, Jan Beulich wrote: > On 09.05.2023 15:04, Andrew Cooper wrote: >> On 08/05/2023 7:47

[PATCH 6/7] x86: don't allow Dom0 (direct) access to port F0

This controls the driving of IGNNE# (if such emulation is enabled in hardware), and hence would need proper handling in the hypervisor to be safe to use by Dom0 (and fully emulating for PVH/HVM DomU-s). Signed-off-by: Jan Beulich --- RFC: Really this disabling of access would want to be

Re: [PATCH] xen/arm: domain_build: Propagate return code of map_irq_to_domain()

Hi Julien, On 11/05/2023 13:55, Julien Grall wrote: > > > Hi Michal, > > On 11/05/2023 12:25, Michal Orzel wrote: >> From map_dt_irq_to_domain() we are assigning a return code of >> map_irq_to_domain() to a variable without checking it for an error. >> Fix it by propagating the return code

Re: [PATCH v2 3/3] x86: Add support for CpuidUserDis

On Thu, May 11, 2023 at 01:05:42PM +0200, Jan Beulich wrote: > > --- a/xen/arch/x86/cpu/amd.c > > +++ b/xen/arch/x86/cpu/amd.c > > @@ -279,8 +279,12 @@ static void __init noinline amd_init_levelling(void) > > * that can only be present when Xen is itself virtualized (because > > * it can

[PATCH 7/7] x86: don't allow Dom0 access to ELCR ports

Much like the other PIC ports, Dom0 has no business touching these. Even our own uses are somewhat questionable, as the corresponding IO-APIC code in Linux is enclosed in a CONFIG_EISA conditional; I don't think there are any x86-64 EISA systems. Signed-off-by: Jan Beulich --- RFC: For Linux'es

[PATCH 5/7] x86: detect PIT aliasing on ports other than 0x4[0-3]

... in order to also deny Dom0 access through the alias ports. Without this it is only giving the impression of denying access to PIT. Unlike for CMOS/RTC, do detection pretty early, to avoid disturbing normal operation later on (even if typically we won't use much of the PIT). Like for CMOS/RTC

Re: [PATCH v5 05/14] tools/xenstore: use accounting buffering for node accounting

Hi Juergen, On 11/05/2023 06:25, Juergen Gross wrote: On 10.05.23 23:31, Julien Grall wrote: On 10/05/2023 13:54, Juergen Gross wrote: On 09.05.23 20:46, Julien Grall wrote: Hi Juergen, On 08/05/2023 12:47, Juergen Gross wrote: Add the node accounting to the accounting information

[PATCH 4/7] x86: detect PIC aliasing on ports other than 0x[2A][01]

... in order to also deny Dom0 access through the alias ports. Without this it is only giving the impression of denying access to both PICs. Unlike for CMOS/RTC, do detection very early, to avoid disturbing normal operation later on. Like for CMOS/RTC a fundamental assumption of the probing is

[PATCH 3/7] x86/PVH: deny Dom0 access to the ISA DMA controller

Unlike PV, a PVH Dom0 has no sensible way of driving the address and page registers correctly, as it would need to translate guest physical addresses to host ones. Rather than allowing data corruption to occur from e.g. the use of a legacy floppy drive, disallow access altogether. Signed-off-by:

[PATCH 2/7] x86: don't allow Dom0 access to port 92

Somewhat like port CF9 this may have a bit controlling the CPU's INIT# signal, and it also may have a bit involved in the driving of A20M#. Neither of these - just like CF9 - we want to allow Dom0 to drive. Signed-off-by: Jan Beulich --- a/xen/arch/x86/dom0_build.c +++

[PATCH 1/7] x86: don't allow Dom0 access to port CF9

This allows to initiate machine reset, which we don't want to permit Dom0 to invoke that way. While there insert blank lines and convert the sibling PCI config space port numbers to upper case, matching style earlier in the function. Signed-off-by: Jan Beulich --- a/xen/arch/x86/dom0_build.c

[PATCH 0/7] x86: Dom0 I/O port access permissions

Following on from the CMOS/RTC port aliasing change, there are quite a few more missing restrictions, and there's more port aliasing to be aware of. The last two patches are pretty much RFC for now. Of course an alternative to all of this would be to do away with all policy-only

Re: [PATCH] xen/arm: pci: fix -Wtype-limits warning in pci-host-common.c

Hi, On 04/05/2023 11:32, Bertrand Marquis wrote: Hi, On 4 May 2023, at 12:10, Julien Grall wrote: Hi, On 04/05/2023 09:59, Bertrand Marquis wrote: Hi Stewart, On 3 May 2023, at 21:18, Stewart Hildebrand wrote: When building with EXTRA_CFLAGS_XEN_CORE="-Wtype-limits", we observe the

Re: [PATCH] xen/arm: domain_build: Propagate return code of map_irq_to_domain()

Hi Michal, On 11/05/2023 12:25, Michal Orzel wrote: From map_dt_irq_to_domain() we are assigning a return code of map_irq_to_domain() to a variable without checking it for an error. Fix it by propagating the return code directly since this is the last call. Take the opportunity to use the

[PATCH] x86/vRTC: minor adjustment to reads from index port

Whether to handle this shouldn't depend on the present value of the index register. Since the handling is done outside of the lock anyway, pull it out into the sole caller and drop the no longer needed function parameter. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/rtc.c +++

[PATCH] x86/vPIC: check values loaded from state save record

Loading is_master from the state save record can lead to out-of-bounds accesses via at least the two container_of() uses by vpic_domain() and __vpic_lock(). Calculate the field from the supplied instance number instead. Adjust the public header comment accordingly. For ELCR follow what

[PATCH] x86/vPIT: check/bound values loaded from state save record

In particular pit_latch_status() and speaker_ioport_read() perform calculations which assume in-bounds values. Several of the state save record fields can hold wider ranges, though. Note that ->gate should only be possible to be zero for channel 2; enforce that as well. Adjust pit_reset()'s

Re: [XEN v6 11/12] xen/arm: p2m: Use the pa_range_info table to support ARM_32 and ARM_64

On 03/05/2023 13:20, Julien Grall wrote: Hi, Hi Julien, I have some clarification. On 28/04/2023 18:55, Ayan Kumar Halder wrote: Restructure the code so that one can use pa_range_info[] table for both ARM_32 as well as ARM_64. Also, removed the hardcoding for P2M_ROOT_ORDER and

[PATCH] xen/arm: domain_build: Propagate return code of map_irq_to_domain()

>From map_dt_irq_to_domain() we are assigning a return code of map_irq_to_domain() to a variable without checking it for an error. Fix it by propagating the return code directly since this is the last call. Take the opportunity to use the correct printk() format specifiers, since both irq and

[ovmf test] 180617: all pass - PUSHED

flight 180617 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/180617/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0a0e60caf20ab621ee9c1fc66b82b739158c05cf baseline version: ovmf

Re: [PATCH v2 3/3] x86: Add support for CpuidUserDis

On 09.05.2023 18:43, Alejandro Vallejo wrote: > Because CpuIdUserDis is reported in CPUID itself, the extended leaf > containing that bit must be retrieved before calling c_early_init() > > Signed-off-by: Alejandro Vallejo Looks largely okay when taken together with patch 2, but ... > ---

Re: [PATCH v2 2/3] x86: Refactor conditional guard in probe_cpuid_faulting()

On 09.05.2023 18:43, Alejandro Vallejo wrote: > Move vendor-specific checks to the vendor-specific callers. > > No functional change. > > Signed-off-by: Alejandro Vallejo Reviewed-by: Jan Beulich

Re: [PATCH] domctl: bump interface version

On 11/05/2023 11:52 am, Jan Beulich wrote: > The change to XEN_DOMCTL_getdomaininfo was a binary incompatible one, > and the interface version wasn't bumped yet during the 4.18 release > cycle. > > Fixes: 31c655497461 ("domctl: Modify XEN_DOMCTL_getdomaininfo to fail if > domid is not found") >

[PATCH] domctl: bump interface version

The change to XEN_DOMCTL_getdomaininfo was a binary incompatible one, and the interface version wasn't bumped yet during the 4.18 release cycle. Fixes: 31c655497461 ("domctl: Modify XEN_DOMCTL_getdomaininfo to fail if domid is not found") Signed-off-by: Jan Beulich ---

Re: [PATCH v2 1/3] x86: Add AMD's CpuidUserDis bit definitions

On 11.05.2023 12:38, Alejandro Vallejo wrote: > On Thu, May 11, 2023 at 11:41:13AM +0200, Jan Beulich wrote: >> On 09.05.2023 18:43, Alejandro Vallejo wrote: >>> --- a/xen/include/public/arch-x86/cpufeatureset.h >>> +++ b/xen/include/public/arch-x86/cpufeatureset.h >>> @@ -287,6 +287,7 @@

Re: [PATCH v4 3/3] domctl: Modify XEN_DOMCTL_getdomaininfo to fail if domid is not found

On 11/05/2023 11:41 am, Jan Beulich wrote: > On 09.05.2023 18:07, Alejandro Vallejo wrote: >> --- a/xen/common/domctl.c >> +++ b/xen/common/domctl.c >> @@ -314,7 +314,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) >> u_domctl) >> /* fall through */ >> default: >>

Re: [PATCH v4 3/3] domctl: Modify XEN_DOMCTL_getdomaininfo to fail if domid is not found

On 09.05.2023 18:07, Alejandro Vallejo wrote: > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -314,7 +314,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) > u_domctl) > /* fall through */ > default: > d = rcu_lock_domain_by_id(op->domain); > -if

Re: [PATCH v2 1/3] x86: Add AMD's CpuidUserDis bit definitions

On Thu, May 11, 2023 at 11:41:13AM +0200, Jan Beulich wrote: > On 09.05.2023 18:43, Alejandro Vallejo wrote: > > --- a/xen/include/public/arch-x86/cpufeatureset.h > > +++ b/xen/include/public/arch-x86/cpufeatureset.h > > @@ -287,6 +287,7 @@ XEN_CPUFEATURE(AVX_IFMA, 10*32+23) /*A AVX-IFMA > >

[xen-unstable test] 180609: tolerable FAIL - PUSHED

flight 180609 xen-unstable real [real] flight 180616 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/180609/ http://logs.test-lab.xenproject.org/osstest/logs/180616/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: xen cache colors in ARM

Hi Oleg, On 11/05/2023 12:02, Oleg Nikitenko wrote: > > > > Hello, > > Thanks Stefano. > Then the next question. > I cloned xen repo from xilinx site https://github.com/Xilinx/xen.git > > I managed to build a xlnx_rebase_4.17 branch in my

Re: [PATCH v2 1/3] x86: Add AMD's CpuidUserDis bit definitions

On 09.05.2023 18:43, Alejandro Vallejo wrote: > --- a/xen/include/public/arch-x86/cpufeatureset.h > +++ b/xen/include/public/arch-x86/cpufeatureset.h > @@ -287,6 +287,7 @@ XEN_CPUFEATURE(AVX_IFMA, 10*32+23) /*A AVX-IFMA > Instructions */ > /* AMD-defined CPU features, CPUID level

Re: [PATCH 2/3] docs: document ~/control/feature-balloon

On 10.05.2023 16:20, Yann Dirson wrote: > --- a/docs/misc/xenstore-paths.pandoc > +++ b/docs/misc/xenstore-paths.pandoc > @@ -509,6 +509,12 @@ This may be initialized to "" by the toolstack and may > then be set > to 0 or 1 by a guest to indicate whether it is capable of responding > to a mode

[ovmf test] 180615: all pass - PUSHED

flight 180615 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/180615/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c6382ba0f2aec5200ee03e5d97018c303ddc64d8 baseline version: ovmf

Re: [PATCH v6 2/4] xen/riscv: introduce setup_initial_pages

On Tue, 2023-05-09 at 16:38 +0200, Jan Beulich wrote: > On 09.05.2023 14:59, Oleksii wrote: > > On Mon, 2023-05-08 at 10:58 +0200, Jan Beulich wrote: > > > On 03.05.2023 18:31, Oleksii Kurochko wrote: > > > > --- /dev/null > > > > +++ b/xen/arch/riscv/include/asm/page.h > > > > @@ -0,0 +1,62 @@ >

[PATCH V2 2/2] libxl: arm: Add grant_usage parameter for virtio devices

Currently, the grant mapping related device tree properties are added if the backend domain is not Dom0. While Dom0 is privileged and can do foreign mapping for the entire guest memory, it is still desired for Dom0 to access guest's memory via grant mappings and hence map only what is required.

[PATCH V2 1/2] libxl: virtio: Remove unused frontend nodes

The libxl_virtio file works for only PV devices and the nodes under the frontend path are not used by anyone. Remove them. While at it, also add a comment to the file describing what devices this file is used for. Signed-off-by: Viresh Kumar --- V2: New patch. tools/libs/light/libxl_virtio.c

Re: [PATCH] libxl: arm: Allow grant mappings for backends running on Dom0

On 09-05-23, 16:05, Anthony PERARD wrote: > I guess the way virtio devices are implemented in libxl suggest to me > that the are just Xen PV devices. So I guess some documentation in the > tree would be useful, maybe some comments in libxl_virtio.c. Our use case is just PV devices, not sure if

Re: [PATCH] x86: Use printk_once() instead of opencoding it

On 10.05.2023 21:33, Andrew Cooper wrote: > Technically our helper post-dates all of these examples, but it's good cleanup > nevertheless. None of these examples should be using fully locked > test_and_set_bool() in the first place. > > No functional change. > > Signed-off-by: Andrew Cooper

Re: [PATCH 5/6] x86/cpu-policy: Disentangle X86_NR_FEAT and FEATURESET_NR_ENTRIES

On 10.05.2023 22:13, Andrew Cooper wrote: > On 09/05/2023 3:24 pm, Jan Beulich wrote: >> On 09.05.2023 16:03, Andrew Cooper wrote: >>> On 08/05/2023 8:45 am, Jan Beulich wrote: On 04.05.2023 21:39, Andrew Cooper wrote: > When adding new words to a featureset, there is a reasonable amount

Re: [PATCH 1/6] x86/cpu-policy: Drop build time cross-checks of featureset sizes

On 10.05.2023 17:06, Andrew Cooper wrote: > On 09/05/2023 5:15 pm, Jan Beulich wrote: >> On 09.05.2023 17:59, Andrew Cooper wrote: >>> On 09/05/2023 3:28 pm, Jan Beulich wrote: On 09.05.2023 15:04, Andrew Cooper wrote: > On 08/05/2023 7:47 am, Jan Beulich wrote: >> On 04.05.2023

Re: [PATCH] iommu/vtd: fix address translation for superpages

On 10.05.2023 17:19, Roger Pau Monné wrote: > On Wed, May 10, 2023 at 03:30:21PM +0200, Jan Beulich wrote: >> On 10.05.2023 12:22, Roger Pau Monné wrote: >>> On Wed, May 10, 2023 at 12:00:51PM +0200, Jan Beulich wrote: On 10.05.2023 10:27, Roger Pau Monné wrote: > On Tue, May 09, 2023 at

Re: [PATCH v3 09/14 RESEND] xenpm: Print HWP parameters

On 10.05.2023 20:11, Jason Andryuk wrote: > On Mon, May 8, 2023 at 6:43 AM Jan Beulich wrote: >> On 01.05.2023 21:30, Jason Andryuk wrote: >>> --- a/tools/misc/xenpm.c >>> +++ b/tools/misc/xenpm.c >>> @@ -708,6 +708,44 @@ void start_gather_func(int argc, char *argv[]) >>> pause(); >>> } >>>

Re: [PATCH v3 07/14 RESEND] cpufreq: Export HWP parameters to userspace

On 10.05.2023 19:49, Jason Andryuk wrote: > On Mon, May 8, 2023 at 6:26 AM Jan Beulich wrote: >> >> On 01.05.2023 21:30, Jason Andryuk wrote: >>> Extend xen_get_cpufreq_para to return hwp parameters. These match the >>> hardware rather closely. >>> >>> We need the features bitmask to indicated

Re: [XEN PATCH 2/2] x86/Dom0: Use streaming decompression for ZSTD compressed kernels

On 10.05.2023 19:30, Rafaël Kooi wrote: > On 10/05/2023 11:48, Jan Beulich wrote: >> On 10.05.2023 10:51, Rafaël Kooi wrote: >>> On 10/05/2023 10:03, Jan Beulich wrote:> On 10.05.2023 02:18, Rafaël Kooi >>> wrote: > --- a/xen/common/decompress.c > +++ b/xen/common/decompress.c > @@

  1   2   >